3

目前我有一些测试被认为不能很好地捕捉错误。我想做突变测试以检测它们(并防止添加新的无用的),但没有时间效率低下的循环:更改代码->重新编译->运行测试->更改代码->重新编译->运行测试...等

最初我想以某种方式直接改变二进制 elf 文件(不重新编译),但正如后来的帖子所建议的那样,这没有任何意义。

4

2 回答 2

3

好的,我能够通过将突变测试分为 4 个主要阶段来部分解决它:

  • 使用 python/clang-tooling 检测所有突变中的代码(选定的 C++ 表达式包装在一个特殊的宏中,该宏将调用委托给突变类,该类为每个突变生成 ID,控制突变运算符的激活等)
  • 重新编译代码(仅一次
  • 并行运行测试,所有突变都处于非活动状态,并获取所有突变的 ID(如果有失败的测试,将它们放在忽略列表中),
  • 并行运行测试,同时在运行时切换突变(通过上一步中获得的 ID),并收集统计信息(突变杀死率等)

该实现是在 python 和 C++ 中完成的,大约 1700 行代码(带有测试)+ 生产代码(CMake 和 gtest main.cpp 文件)中的小修改。它只支持几个简单的突变,但它仍然很有趣:)

于 2015-06-17T09:39:10.397 回答
2

假设测试运行很快,并且运行次数足够大(~1M,~1k ??),我应该粗略估计潜在错误的命中率??

不,您的“elf 二进制文件中某处的一位错误”可能会损坏任何东西(从 elf 格式到数据段再到调用堆栈等等)。这样你不会得到任何关于错误数量的粗略估计,而是粗略估计损坏的可执行文件执行的可能性(这根本没有说明你的应用程序)。

目前我有很多测试被归咎于根本没有发现错误。

这是您必须直接解决的问题,并且没有捷径:您必须为测试建立新目标,重构代码以支持它们并实现它们。

于 2013-06-20T09:08:57.733 回答