阿里妹导读:这么多的CASE,花了大量时间和资源去运行,真能发现BUG吗?CI作到90%的行覆盖率,能发现问题吗?测试用例愈来愈多,删一些,会不会就发现不了问题了?今天,咱们谈谈如何评估测试用例的有效性?
咱们的测试用例有两个比较关键的部分:git
1)调用被测代码:例以下面的RuleService.getLastRuleByClientId(ClientId)。
2)进行结果Check:例以下面的AssertEqual(OrderId,"ABCD1234")。算法
TestCaseA ... RuleService.createRuleByClientId(ClientId,RuleDO); StringOrderId=RuleService.getLastRuleByClientId(ClientId); ... TestCaseB ... RuleService.createRuleByClientId(ClientId,RuleDO); StringOrderId=OrderService.getLastOrderByClientId(ClientId); AssertEqual(OrderId,"ABCD1234"); ...
咱们但愿一组测试用例不只可以“触发被测代码的各类分支”,还可以作好结果校验。单元测试
咱们对测试用例有效性的理论建模是:学习
测试有效性 = 被发现的问题数 / 出现问题的总数
基于故障复盘的模式成本过高,咱们但愿可以主动创造问题来评估测试用例的有效性。测试
咱们找到了一种衡量“测试有效性”的方法,变异测试(mutation testing):spa
变异测试的例子3d
咱们用了一组测试用例(3个),去测试一个判断分支。
而为了证实这一组测试用例的有效性,咱们向业务代码中注入变异。咱们把b<100的条件改为了b<=100。日志
咱们认为:code
经过变异测试的方式:让注入变异后的业务代码做为“测试用例”,来测试“测试代码”。对象
咱们实现了多种规则,能够主动的注入下面这些变异:
为了全自动的进行测试有效性评估,咱们作了一个变异机器人,其主要运做是:
变异机器人的优势:
变异机器人的使用门槛:
咱们正在打造的高配版变异机器人拥有三大核心竞争力:
分钟级的系统评估效率
为了保证评估的准确性,100个变异将会执行全量用例100遍,每次执行时间长是一大痛点。
高配版变异机器人给出的解法:
学习型注入经验库
为了不“杀虫剂”效应,注入规则须要不断的完善。
高配版变异机器人给出的解法:故障学习,基于故障学习算法,不断学习历史的代码BUG,并转化为注入经验。可学习型经验库目前覆盖蚂蚁金服的代码库,明年会覆盖开源社区。
兼容不稳定环境
集成测试环境会存在必定的不稳定,难以判断用例失败是由于“发现了变异”仍是“环境出了问题”,致使测试有效性评估存在偏差。
高配版变异机器人给出的解法:
咱们在蚂蚁金服的一个部门进行了实验,得出了这样的数据:
换言之,几个系统的测试有效性为:系统A 72%,系统B 56%,系统C 70%。
测试有效性(%) = 1 - 未发现注入数 / 注入数
基于代码注入的测试有效性度量,只是其中的一种方法,咱们平常会用到的方法有这么几种:
测试有效性能够做为基石,驱动不少事情向好发展:
写到最后,想起了同事给我讲的一个有趣的人生经历:
“大二期间在一家出版社编辑部实习,工做内容就是校对文稿中的各类类型的错误。编辑部考核校对质量的办法是,人为的事先在文稿中加入各类类型的错误,而后根据你的错误发现率来衡量,并计算实习工资。”
“你干得咋样?”
“我学习了他们的规则,写了个程序来查错,拿到了第一个满分”
“厉害了...”
“第二个月就不行了,他们不搞错别字了,搞了一堆语法、语义、中心思想的错误... 我就专心干活儿了”
“...”
异曲同工,其致一也。
本文来自云栖社区合做伙伴“阿里技术”,如需转载请联系原做者。