你有变异测试的现实应用的例子吗?它比简单的测试覆盖工具更好吗?还是没用?
在现实世界中,突变测试有哪些优点/缺点?
不再讨论单元测试的有用性.它们对于高质量应用的构思至关重要.但是,我们如何评估其相关性?代码覆盖率指标高达100%并不意味着代码经过100%测试.这只是在单元测试执行期间执行代码的视图.变异测试将使您对测试更有信心.
这是一个两步过程:
生成突变体.
检查测试是否发现了突变.
我写了一篇关于这个过程的整篇文章,包括一些具体案例.
我前段时间看过变异测试作为检查自动回归测试脚本功效的方法.基本上,许多这些脚本都缺少检查点,因此在他们正在运行正确测试的应用程序时,他们没有根据基线数据验证结果.我发现比更改代码更简单的方法是编写另一个应用程序来引入对基线副本的修改,并针对修改后的基线重新运行测试.在这种情况下,任何传递的测试都是错误的或不完整的.
这不是真正的突变测试,而是使用类似范例来测试测试脚本功效的方法.它很容易实现,IMO做得很好.
我为最细小的人为应用而苦苦挣扎:
http://pitest.org/
这是一个Java工具,可以自动生成突变体。您可以针对您的测试套件运行它,它将为您生成HTML报告,指示杀死了多少个突变体。看起来很有效,不需要太多的努力来设置。实际上,Java世界中有很多不错的工具可用于此类事情。也可以看看:
http://www.eclemma.org/
为覆盖。
我认为突变测试背后的概念是合理的。这只是工具支持和意识的问题。您正在权衡传统代码覆盖率指标的简单性和该技术的额外复杂性之间的权衡-实际上,这只能归结为工具。如果你能产生突变体,那么它将会帮助暴露在你的测试用例的弱点。在您已经进行的测试上付出一点点努力值得吗?怀着深深的兴趣,我的确发现它带来了似乎不太明显的测试用例。
变异测试是一个与单元/功能/集成测试方法完全不同的攻角。
您测试您的测试套件-这是整个测试程序的元测试。
它激发了您可能没有考虑的其他测试用例。
我知道这是一个古老的问题,但是最近Bob叔叔(Uncle Bob)写了一篇关于变异测试非常有趣的博文,可以帮助您了解这种测试的有用之处:
Bob叔叔变异测试博客文章