这么多CASE，跑起来耗费了很多时间和资源，你真的能找到BUG吗？CI做到90%行覆盖，你能找到问题所在吗？测试用例越来越多，删掉一些行不行？找不到问题？今天，我们就来说说如何评估测试用例的有效性？我们的测试用例有两个关键部分：1）调用被测代码：例如下面的RuleService.getLastRuleByClientId(ClientId)。2）查看结果：例如下面的AssertEqual(OrderId,"ABCD1234")。TestCaseA...RuleService.createRuleByClientId(ClientId,RuleDO);StringOrderId=RuleService.getLastRuleByClientId(ClientId);...TestCaseB...RuleService.createRuleByClientId(ClientId,RuleDO);StringOrderId=OrderService.getLastOrderByClientId(ClientId);AssertEqual(OrderId),"ABCD1234");...我们希望一组测试用例不仅能“触发被测代码的各个分支”，还能做好结果的验证。当业务代码出现问题时，测试用例可以发现这个问题，我们认为这套测试用例是有效的。当业务代码出现问题，测试用例未能发现问题时，我们认为这套测试用例是无效的。我们对测试用例有效性的理论建模是：>>测试有效性=发现问题的数量/问题总数我们为什么要评估测试用例的有效性？如何评估测试用例的有效性？模式成本太高，我们希望能够主动创建问题来评估测试用例的有效性。我们找到了一种衡量“测试有效性”的方法，变异测试：变异测试的一个例子我们使用了一组测试用例（3）来测试一个判断分支。为了证明这组测试用例的有效性，我们在业务代码中注入突变。我们把b<100的条件改成了b<=100。我们认为：一组成功的测试用例在被测对象发生变化后（注入突变后）应该至少有一次失败。如果这组测试用例还是全部Success，那么这组测试用例的有效性是不够的。通过变异测试：让注入的业务代码作为“测试用例”来测试“测试代码”。我们已经实现了多种可以主动注入以下突变的规则：如何优雅地评估测试有效性？为了完全自动化评估测试有效性，我们创建了一个变异机器人，其主要操作是：向被测代码中写入一个BUG（即：变异）；执行测试；将测试结果与没有突变的测试结果进行比较，以确定是否有新的用例失败；重复1-3几次，每次注入不同的Bug；计算系统的“测试有效性”。变异机器人的优势：防错上线：变异是单独拉代码分支，代码分支永远不会上线，不影响生产。全自动：只需要给出系统代码的git地址，即可进行评估，得到改进报告。高效：数小时内即可完成系统的测试有效性评估。扩展性：该模式可以支持JAVA和JAVA以外的多种语言。适用性：该方法不仅适用于单元测试，也适用于其他自动化测试，如接口测试、功能测试、集成测试等。使用突变机器人的门槛：测试成功率：只有通过率为100%的测试用例才会被选中，并注入相应的业务代码突变。测试覆盖率：只注入测试代码覆盖的业务代码。测试覆盖率越高，评估越准确。变异机器人高端版我们正在打造的变异机器人高端版具有三大核心竞争力：分钟级系统评估效率。大痛点。高端变异机器人给出的解决方案：并行注入：基于代码覆盖率，识别UT之间的代码覆盖依赖关系，将独立的变异合并到一个自动化测试中。热部署：基于字节码更新，减少变异和部署过程。精准测试：根据UT代码覆盖率信息，只运行与本次突变相关的UT（此方法不仅适用于UT，也适用于其他自动化测试，如接口测试、功能测试、集成测试等）。学习注射经验库为避免“农药”效应，需要不断完善注射规则。变异机器人高阶版给出的解决方案：故障学习，基于故障学习算法，不断学习历史代码bug，转化为注入经验。可学习经验库目前覆盖蚂蚁金服代码库，明年将覆盖开源社区。兼容不稳定环境集成测试环境在一定程度上会不稳定，很难判断用例失败是因为“发现突变”还是“环境有问题”，导致评估出错的测试有效性。变异机器人高阶版给出的解决方案：高频运行：将同一个变异运行10次，并对多次结果进行统计分析，减少环境问题导致的偶发问题。环境问题自动定位：接入附属日志服务，根据用例日志/系统错误日志构建的异常场景，自动学习“环境问题导致的用例故障”，准确区分是否发现用例突变。落地效果如何？我们在蚂蚁金服的一个部门做了一个实验，得到了如下数据：也就是说，几个系统的测试效率是：系统A72%，系统B56%，系统C70%。测试有效性(%)=1-未发现的注入次数/注入次数代码注入：在代码中注入突变，看测试用例能不能发现问题内存注入：修改API接口的返回内容，看测试用例能不能找到问题静态扫描：扫描测试代码进行Assert等判断，看Assert场景和被测代码分支的关系……还有更多其他的衡量方式。再次遇见测试用例测试的有效性可以作为推动很多事情向好的方向发展的基石：让测试用例更能发现问题。让无效的用例被识别和清理。创建一种质量文化，让技术人员真正思考如何编写好的TestCase。测试左移和敏捷性的先决条件。……写到最后，想起同事告诉我的一段有趣的人生经历：“大二的时候，我在一家出版社的编辑部实习，工作内容是校对各类错误在稿件中，编辑部考核校对质量的方式是提前人为的在稿件中加入各类错误，然后根据你的错误发现率来衡量，并计算出实习工资。”“你好吗？”“我学习了他们的规则，写了一个程序来检查错误，得到了第一个满分”“太神奇了......”“第二个月没有成功，他们没有't错别字了，语法、语义、中心思想错误一堆……我只是专心工作。”“……”殊途同归，结果是一样的。
