突变测试在实践中有用吗？答案

【问题标题】：Is mutation testing useful in practice?突变测试在实践中有用吗？
【发布时间】：2010-09-19 13:12:03
【问题描述】：

您有任何突变测试在现实生活中应用的例子吗？它比简单的测试覆盖工具更好用吗？还是没用？

在现实世界中，突变测试的优点/缺点是什么？

【问题讨论】：

我不明白这与传统的测试驱动开发有何不同。根本没有办法涵盖所有数学可能性，我认为这甚至不值得。
是的，这是我的问题，是否值得在现实世界中付出努力。我知道有一些关于它的理论工作。但它在现实中有效吗？
重点不是突变测试实际上测试了测试吗？我的意思是，如果您可以更改源代码的逻辑并且仍然通过测试，那么测试肯定不是很正确吗？如果我遗漏了什么，请原谅我......
是的，像代码覆盖这样的突变测试会检查你的测试是否足够。
@Jon Limjap：1) 关于区别：传统的测试驱动开发只是尝试在编写软件的每个小迭代之前编写测试。变异测试试图通过修改源代码来检查测试用例是否“好”。它们是两个不同的概念。 2) 你是对的，没有办法涵盖所有的可能性，但是添加另一种不同的测试方式可以帮助增加测试覆盖率。

标签： unit-testing testing code-coverage mutation-testing

【解决方案1】：

单元测试的用处不再讨论。它们在质量应用程序的概念中是必不可少的。但是，我们如何评估它们的相关性？高达 100% 的代码覆盖率指标并不意味着代码经过 100% 的测试。这只是单元测试执行期间执行代码的视图。突变测试将使您对测试更有信心。

这是一个两步过程：

生成突变体。
检查是否通过测试发现了突变。

我写了一个完整的article关于这个过程，包括一些具体的案例。

【讨论】：

【解决方案2】：

前段时间，我将突变测试作为一种检查自动化回归测试脚本有效性的方法。基本上，这些脚本中有许多缺少检查点，因此当他们正确执行正在测试的应用程序时，他们并没有根据基线数据验证结果。我发现比更改代码更简单的方法是编写另一个应用程序来对基线副本进行修改，然后根据修改后的基线重新运行测试。在这种情况下，任何通过的测试要么是错误的，要么是不完整的。

这不是真正的突变测试，而是一种使用类似范例来测试测试脚本功效的方法。实现起来很简单，IMO 做得很好。

【讨论】：

编写一个单独的应用程序来验证您的测试有多昂贵？工具支持的变异测试不是更便宜吗？
不是特别贵，大约 2 天的时间都在写工具，我找不到现成的东西来做这项工作。这个想法很简单，对于所有通过的测试，更改基线数据会导致失败。如果没有，则表明测试用例有问题。对此的实际编码是特定于正在测试的应用程序的，但它的作用非常简单。

【解决方案3】：

我知道这是一个老问题，但最近 Bob 叔叔写了一篇关于变异测试非常有趣的博文，可以帮助理解这种测试的有用性：

Uncle Bob mutating testing blog post

【讨论】：

【解决方案4】：

我已经为一个小的、做作的应用程序玩过 Pitest：

http://pitest.org/

这是一个自动生成突变体的 java 工具。您可以针对您的测试套件运行它，它会为您生成 HTML 报告，表明有多少突变体被杀死。看起来很有效，不需要太多的努力来设置。实际上，Java 世界中有很多不错的工具可用于此类事情。另见：

http://www.eclemma.org/

为了覆盖。

我认为突变测试背后的概念是合理的。这只是工具支持和意识的问题。您在传统代码覆盖率指标的简单性和该技术的额外复杂性之间进行权衡 - 它实际上归结为工具。如果您可以生成突变体，那么它将帮助暴露测试用例中的弱点。与您已经进行的测试相比，是否值得稍微增加努力？使用pitest，我确实发现它出现了似乎不明显的测试用例。

突变测试是一种与单元/功能/集成测试方法完全不同的攻击角度。

您测试您的测试套件 - 它是您整个测试程序的元测试。
它激发了您可能没有考虑过的其他测试用例。

【讨论】：

【解决方案5】：

变异测试帮助我发现了测试用例断言的问题。

例如，当你得到一个报告说“测试用例 x 没有杀死任何突变体”时，你看一下，结果发现断言已经被注释掉了。

根据this paper，Google 的开发人员使用突变测试作为代码审查和拉取请求检查的补充。他们似乎对结果很满意：

开发人员已决定重新设计大量代码以使其可测试，以便可以杀死突变体，他们在查看突变体的复杂逻辑表达式中发现了错误，他们决定删除具有等效突变体的代码，因为他们认为过早的优化，他们声称突变体为他们节省了数小时的调试甚至生产中断，因为没有测试用例正确覆盖突变下的逻辑。突变测试被称为多年来代码审查验证中最好的改进之一。虽然这种反馈很难量化，但再加上成千上万的开发人员愿意在他们的代码更改上检查浮出水面的突变体，这就是一个声明。

【讨论】：

【解决方案6】：

我最近对突变测试进行了一些调查。结果在这里：

http://abeletsky.blogspot.com/2010/07/using-of-mutation-testing-in-real.html

简而言之：突变测试可以提供有关源代码和测试质量的一些信息，但它不是直接使用的东西。

【讨论】：

您的意思是“是”或“不是”易于使用？
被引用的博客已经不存在了。

【解决方案7】：

覆盖率与突变测试。一个老问题，但我最近遇到了有关该主题的最新博客。很有主见。但是覆盖率和变异测试之间的区别是明确的。

https://pedrorijo.com/blog/intro-mutation/

我自己的经验表明 Pitest 非常有用，但由于运行时爆炸，它只适用于一个非常快速的测试集。在实践中，这限制了我应用突变测试的地方。

【讨论】：

另一个有趣的比较是在se.ewi.tudelft.nl/ti3115tu-2018/resources/… 中将代码与城市、犯罪与错误、警察与单元测试以及假犯罪（测试警察）与突变测试进行比较。
以上评论链接失效。此外，Pedro 已经评论了他的博文under 的主要问题。

【解决方案8】：

由于上述突变，第一个测试用例的行为有所不同，现在引发了一个异常。所以它不会返回 {6,3} 的预期数组。但是，我们的第二个测试用例保持不变，因为它也包含正数。因此，它也对正数给出了例外。现在，如果我们必须编写一个成功的测试用例，那将是输入 ={-6,-6,-7,-3,-4} 预期 = {-6,-3}

【讨论】：

请edit您的答案以改进代码格式。见How to Answer。

【解决方案9】：

我使用 https://stryker-mutator.io/docs/stryker-js/guides/angular/ 在 Angular 上设置突变测试只是为了进行实验，并且花了 2 个小时来获得单个代码文件的报告。也就是说，我对在 .NET 中使用 Stryker 的体验非常满意。我必须承认我对突变测试还很陌生，可能有更好的工具可以与 Angular/karma 一起使用，但性能是需要牢记的，特别是如果你打算将它与 TDD 结合使用。

【讨论】：