您是否有任何突变测试的实际应用示例?它比简单的测试覆盖工具更好吗?或者它没用?
现实世界中突变测试的优点/缺点是什么?
答案 0 :(得分:16)
不再讨论单元测试的有用性。它们对于高质量应用的构思至关重要。但是,我们如何评估其相关性? 代码覆盖率指标高达100%并不意味着代码经过100%测试。这只是在单元测试执行期间执行代码的视图。 变异测试将使您对测试更有信心。
这是一个两步过程:
我写了一篇关于这个过程的整个article,包括一些具体案例。
答案 1 :(得分:9)
我前段时间看过变异测试作为检查自动回归测试脚本功效的方法。基本上,许多这些脚本都缺少检查点,因此在他们正在运行正确测试的应用程序时,他们没有根据基线数据验证结果。我发现比更改代码更简单的方法是编写另一个应用程序来引入对基线副本的修改,并针对修改后的基线重新运行测试。在这种情况下,任何通过的测试都是错误的或不完整的。
这不是真正的突变测试,而是一种使用类似范例来测试测试脚本功效的方法。它很容易实现,IMO做得很好。
答案 2 :(得分:4)
我为一个小小的,有人为的应用程序而玩弄了一下:
它是一个自动生成突变体的java工具。您可以针对您的测试套件运行它,它会为您生成HTML报告,指示已杀死的突变体数量。似乎非常有效,并且不需要花费太多精力来设置。对于这类事情,Java世界中实际上有很多不错的工具。另见:
覆盖范围。
我认为突变测试背后的概念是合理的。这只是工具支持和意识的问题。您正在努力在传统代码覆盖率指标的简单性与此技术的额外复杂性之间进行权衡 - 它实际上仅归结为工具。如果您可以生成突变体,那么将帮助揭示测试用例中的弱点。与您已经进行的测试相比,努力的边际增加是否值得?有了pitest,我确实发现它出现了似乎不明显的测试用例。
突变测试是一种攻击角度,与单元/功能/集成测试方法完全不同。
答案 3 :(得分:3)
我知道这是一个老问题,但最近鲍勃叔叔写了一篇非常有趣的关于变异测试的博客文章,可以帮助理解这种测试的有用性:
答案 4 :(得分:2)
我最近对突变检测做了一些调查。结果如下:
http://abeletsky.blogspot.com/2010/07/using-of-mutation-testing-in-real.html
简而言之:变异测试可以提供有关源代码和测试质量的一些信息,但它并不是直接使用的东西。
答案 5 :(得分:1)
突变测试帮助我确定了测试用例断言的问题。
例如,当您收到一个报告说“没有用测试用例x杀死任何突变体”时,您可以查看一下,结果断言已被注释掉。
根据this paper,Google的开发人员将Mutation测试用作代码审查和请求请求检验的补充。他们似乎对结果感到满意:
开发人员已决定重新设计大量代码,使其可测试,以便杀死突变体;他们发现了复杂的逻辑表达式中的错误,正在寻找突变体;他们决定删除等效突变体的代码,因为他们认为由于过早的优化,他们声称该突变体为他们节省了数小时的调试时间,甚至节省了生产中断的时间,因为没有测试用例正确地涵盖了突变体下的逻辑。变异测试被称为多年来代码审查验证中最好的改进之一。尽管这种反馈难以量化,但结合成千上万的愿意检查其代码更改中出现的突变体的开发人员,我们发表了自己的看法。
答案 6 :(得分:0)
覆盖率与突变测试。一个古老的问题,但是我最近遇到了一个有关该主题的博客。很固执。但是,覆盖率测试和突变测试之间的区别很清楚。
https://pedrorijo.com/blog/intro-mutation/
我自己的经验表明,Pitest非常有用,但是由于运行时爆炸,它只能运行一个非常快速的测试集。实际上,这限制了我进行突变测试的位置。
答案 7 :(得分:0)
由于上述突变,第一个测试用例的行为有所不同,现在引发了一个异常。因此,它不会返回预期的{6,3}数组。但是,我们的第二个测试用例保持不变,因为它也包含正数。因此,它也给出了正数的例外。现在,如果我们必须编写一个成功的测试用例,那就是 输入= {-6,-6,-7,-3,-4} 预期= {-6,-3}