测试缺陷的成本

嗨，我是Marina Polishchuk，VC++编译器前端团队的SDET。 最近，我一直在调查Orcas测试通过结果，包括验证和复制结果，研究失败的原因，并在适当的时候归档bug。 在我们产品周期的后期阶段，这是SDET的一个典型活动，此时我们最关注的是在我们支持的特性/场景中发现任何遗留的产品问题。 事实上，bug在源代码中持续的时间越长，成本就越高：因此，在Beta测试期间尽早发现bug是非常重要的，这样可以及时修复它们。 然而，检测产品缺陷的能力关键在于拥有准确的测试结果，这就带来了经常被忽视的缺陷类型：测试缺陷。 测试缺陷的成本，很像产品缺陷的成本，很大程度上取决于它被发现之前的持续时间，例如，它是在真实产品回归发生之前还是之后被发现的，并且没有被捕获，因为相关的测试用例是有缺陷的。在这篇博文中，我将讨论我遇到的几种测试缺陷，确保产品问题不会隐藏在失败的测试背后的步骤，以及如何更好地检测某些类型的测试缺陷的想法。

要面对的一个“简单”测试bug是由于编译器中预期的行为改变而不再工作的测试。 我称这个bug为“简单”，因为它很容易检测到：“回归”测试（通过从一个编译器版本到下一个版本开始失败的测试）将由一个人检查，他将确定原因是良性的，测试需要更新。 理想情况下，测试会立即进行修补，以说明新的行为；如果受影响的数量很大，我们可能会允许它们失败，直到可以应用修复程序，并将跟踪系统中的测试错误与失败关联起来，以便团队中的每个人都知道失败是预期的。

在beta测试中经常看到的另一种测试结果是假阳性：一种“失败”的结果，并不表示编译器行为不正确。 误报可能源于不正确的机器或产品配置、对其他失败测试的依赖性、在用户权限不足的情况下运行的测试命令等。 通过检查日志或在日志不足时重新运行测试来诊断误报。 重新创建原始的测试环境是非常重要的，而且对于诸如全套运行期间的机器压力或在多个处理器上并发执行测试时的非确定性等因素通常是不可行的。 如果我不能重新创建失败，一般的做法是等待，看看它是否在后续的测试运行中以相同的参数出现，可能会扩展它的日志输出以简化配置失败诊断。 在我看来，假阳性对于产品质量来说也是良性的，当然，除非人们考虑到在调查虚假错误时发现真正的缺陷所花费的时间。

最后，一种非常令人不安的测试结果是一个假阴性：在编译器中执行一个bug的测试的通过结果，但是没有报告它。 由于编译器的代码覆盖率是相同的，无论测试最后报告的是“1”还是“0”，而且测试人员通常不会对通过的结果进行太多的调查，这样的测试失败通常会在很长一段时间内未被发现。 我发现关于bug查找工具的一个有趣现象是，它们通常会丢弃与肯定结果相关的信息。 在我们的测试控制中，我们避免记录默认情况下报告“通过”的测试的测试执行细节。 考虑到当前的实践，这是非常合理的：没有人会调查通过的测试结果，那么为什么要保留没有人会查看的日志呢？ 然而，当一个人仅仅从日志信息中解释失败的原因时，测试最后如何通过的细节就变得很重要了。 特别是，无论结果类型如何保存测试跟踪都为更好地诊断假阴性提供了机会：更高级的工具可能会考虑以前的结果，而不是每次测试运行都报告孤立的测试结果，从而将测试结果从一个运行到另一个运行。 仅以“通过”和“失败”结果为例，通过考虑结果对，可以导出六种新的结果类型，如下所示：

结果类型（i）和（vi）不需要检查，因为它们肯定没有相关的产品行为变化（推测，（vi）以前已经调查过）。 结果类型（ii）是一种回归，通常会进行调查。 结果类型（iii）可用于验证新的通过结果是否对应于产品中的bug修复，而不是测试bug的表现。 结果（iv）可以用来检查一个测试用例是否覆盖了几个编译器错误：它可能已经由于错误1而失败了，但是由于错误2而开始以不同的方式失败。 目前，这个测试用例并不能有效地检测到Bug#2，因为Bug#1已经作为其失败的原因与之关联，认为它是一个“预期的失败”，不需要重新分析。 结果（五）是最值得注意的，因为它可以用来发现假阳性。 例如，几个月前，我们的一小部分测试被发现返回“pass”，即使编译器没有安装。 无论结果是（iii）还是（v），这个bug都会在第一次配置失败时被发现，而不是在以后偶尔出现。 结果（v）也可能暴露逻辑错误：如果一个测试在一次运行中打印“Value=4”，在下一次运行中打印“Value=2147942402”，两者都通过了，那么它的行为可能值得再次检查。 当然，日志信息的设计必须考虑到差异，特别是处理特定于运行的值（如指针值和计时信息）。 如果有人尝试过这种测试结果分析，我很想听听你的经验。

如果您对本博客中的讨论有任何反馈、评论或问题，请在此处发布！

谢谢，

玛丽娜·波利什丘克

Visual C++编译器前端QA团队