阿里QA导读：TICA2021自公布以来，我们感受到了大家对TICA2021满满的热情。小编收到很多私信，都在咨询TICA2021具体包含哪些议题。现在，我们为大家揭开神秘的面纱～疫情期间，安全为大。所以TICA2021将于2021年12月18日（周六），通过优酷以线上的形式与大家见面啦！小编个人还是很喜欢这种形式的，这样我们就可以随时随地享受我们的干货盛宴，而且，重点是，成本超低！本次大会议题经历数月的征集、审稿等工作，终于敲定了，议程海报奉上！小编还要提醒下大家哦，只要在2021.12.12之前买票，均可以享受我们的早鸟票，还可以观看回放视频，特别划算，欢迎大家滑至文末购买。 话不多说，下面就是本次大会的具体议程以及我们的出品人介绍。大会议程本次大会以“质测美好”为主题，开设一大主会场、五大分会场，全新议题，内容丰富，适用于测试工程师、研发工程师、测试经理、架构师、技术总监等多角色，并且经过出品人的仔细审核敲定，相信将会和各位一起，在质量保障领域碰撞出更多思维的火花。购票通道1、TICA2021早鸟票+TICA2020视频资料+优酷VIP半年大礼包购买通道

背景闲鱼作为一款垂直交易社区APP，拥有复杂多样的业务场景：涉及c2c、回收寄卖、租房租赁、见面交易、验货担保等，复杂多变的交易模式。比如验货流程：•涉及39个状态机节点•横跨10+应用系统•涉及6个业务部门的合作•涉及接口几十个需要保证每个接口、每个场景切实可行，稍微有一点点问题，就会涉及到人民币的味道，实际工作中，我们遇到各种各样的问题，比较棘手的问题如下问题业务先赢的快速迭代模式下，全靠人工主力进行测试验证，测完新功能，还得回归老功能，一个小需求也需要好几个人日，版本PTM也要回归好几遍，ROI并不乐观，以下2个问题比较突出：交易业务强依赖中台，沟通成本高，跨团队协作难，迭代效率低，测试环境下如何自洽？复杂多样交易模式下，如何支撑需求稳步迭代上线以及日常回归验证？测试策略-自动化闲鱼质量基建正在快马加鞭进行中，针对闲鱼多样的交易模式，全靠人力是不可行的，累不说，改动、风险漏评估也时有发生。对此，我们根据接口->链路的策略，探索对比了几个不同的方案，在保证每个接口OK的基础上，保障全链路。接口层对于每一个大型应用程序来说，接口数量会不断增加，代码变更频率越来越大、系统不定期重构，这个接口的质量怎么来保障？传统编写脚本来进行的方式，投入的人力、时间成本过大，在实际的测试过程中我们探索了一些接口测试的新想法。目前业界公认的有效方式是基于引流回放的自动化测试，实现方案业内众说纷纭各有其词，但万变不离其中，引用下面这段总结，简单明了一种是黑盒测试思路，它在线上接口请求时采集线上流量（主要是请求参数和结果），然后使用和线上环境相同的环境（数据库共用等）下用采集到的流量重新触发请求，然后断言被请求的返回值是不是和录制时的一致。这种方法比较适合对Get类型的接口进行测试，而对于写操作的请求容易造成数据污染，再加上所采集流量的数据状态（数据时效性）、环境依赖性（各种中间件、接口内部请求的RPC调用）等因素，所以这种测试方式具有一些局限性，不能满足实际测试场景中复杂的需求。另一种思路相对白盒，主要是通过智能化的Mock手段，流量采集时采集代码运行过程中所依赖的外部中间件或者RPC调用的返回结果，当流量回放时，能够Mock本机程序对外的依赖中有可能产生变化的内容，使测试更关注本地接口的代码逻辑。阿里集团内部，基于流量回放的思想，主要实现了2种不同的流量录制回放方案，一种是基于doom的天启/暴雪，一种是基于JVM-Sandbox的凤凰，两种实现都借力于JVM

阿里QA导读：“业务先赢”、“极致体验”一直是质量人的主旋律。今天小编带来已入选阿里巴巴内部《阿里集团21财年最值得读的前沿技术领域热文合集》，也是本年度唯一一篇质量领域入选“人工智能”板块的文章，跟大家一起分享交流，看看如何用「真正的」机器人测试来保障“业务先赢”和“极致体验”。一.背景

阿里QA导读：10月20日，阿里云移动研发平台EMAS应用质量管理沙龙，首站杭州取得圆满成功！此次沙龙邀请到淘宝高级技术专家韩锷，阿里云技术专家尚仁、玄工、宝文、州牧和大家进行分享交流。现场围绕无线性能测试解决方案、无线App线上质量监控实践、云原生移动DevOps解决方案、热修复服务展开分享交流。阿里云EMAS联合手淘技术，现场重磅发布了TMQ

阿里QA导读：最近一两年随着深度学习技术浪潮的诞生，智能化测试迎来了新的发展，而AI也会引领下一代测试的新航向。Testin云测CTO陈冠诚先生的分享让我们看到AI在移动自动化测试领域里面的创新机会点。一、技术方案

阿里QA导读：为什么要度量测试有效性？这么多的CASE，花了大量时间和资源去运行，真能发现bug吗？CI做到90%的行覆盖率了，能发现问题吗？测试用例越来越多，删一些，会不会就发现不了问题了？怎么找出那些为了覆盖而覆盖，发现不了真正问题的测试用例？本文带您探索其中的奥秘。什么是测试用例的有效性？我们的测试用例有两个比较关键的部分：1）调用被测代码：例如下面的RuleService.getLastRuleByClientId(ClientId)2）进行结果Check：例如下面的AssertEqual(OrderId,"ABCD1234")TestCaseA...