我同意 Joe 的说法，即指标可能会被严重滥用并适得其反。

也就是说，错误播种可能是回答正确问题的有用方法。

在我们制定测试计划后，我们通常会假设两件事：

1. 测试计划不可能发现系统中的每一个错误。（如果系统又大又复杂，我们可以假设会保留一些未发现的错误。）

2. 尽管如此，测试计划应该能够发现系统中的许多错误。（否则，这不是一个精心设计的测试计划。）

令 E = 系统中的错误总数，D = 测试计划发现的错误数，U = 未发现错误的总数。我们知道 E = D + U，但我们永远无法确定 E 或 U 是什么。但是，我们认为 E/D 接近于 1。

那么，我们如何计算 E/D——我们的错误检测率？因为我们永远不会知道 E 或 U，我们不能！但是我们可以在代码中注入错误，然后运行测试计划。通过查看检测到多少已知错误，我们可以计算受控环境中的错误检测率。了解这种受控的错误检测率是高还是低可能是有益的。

一些注意事项和陷阱：

• 此方法旨在收集运行预先编写的测试计划的有意义的数据。它们提供了有关这些计划是否可能会发现错误或只是使测试人员陷入错误的安全感的指示。
• 这只有在种子错误是合理的并且在隐藏良好和可检测之间取得平衡时才有效。如果错误太容易找到（或太难找到），则生成的数据既不准确也不有用。因此，需要相当多的专业知识来播种错误。（一种可能性是删除除零检查。如果测试计划中没有测试用例发现错误，那么这可能指向可以改进测试计划的区域。）
• 注入故障的人应该不熟悉测试计划。此外，如果尚未编写测试计划，则编写测试计划的人应该完全不知道注入的错误。否则，两组将进行某种“象棋比赛”，数据将无法准确指示测试计划的有效性。
• 这并不是一个持续的练习，因此您不必担心测试人员会在发现种子错误后“停止”。这种技术不是用来测试系统的，它是用来测试测试计划的。

Joe 正确地指出，这种技术不值得做，除非它做得正确。也就是说，它仍然在软件测试领域占有一席之地，特别是在严重依赖预先编写或脚本测试的组织中。

我没有参与过使用故障播种的项目。

然而，我参与了引入新指标的项目——这基本上就是你在这里提出的建议。如果我的经验是任何预测指标，你应该期望人们会在你衡量的任何方面做得更好，而牺牲其他一切。

在这里，您可能期望测试人员会更好地发现种子错误，而在其他方面则更差。这些其他事情可能包括 - 帮助他人、文档、查找非种子错误、与开发人员合作等等。

您可能还会发现，一旦发现种子错误，测试人员就会停止测试。

您可能会发现测试人员（可能还有开发人员和其他人）的士气问题。

对于任何度量程序，请仔细考虑对测试人员、开发人员和其他人的意外后果和副作用。

如果实现了这一点，我将根据我自己的经验给每个人留下一个答案。

我很想看看结果如何。

免责声明：我对此没有任何直接经验。

研究人员（例如马里兰大学的Atif Memon ）使用故障播种来衡量测试技术的有效性。在这种情况下，这种做法是有意义的。我假设您建议将播种用作实验，而不是持续的过程。

你提到了严格的测试。在严格的实验中，您提前决定计划如何解释您的结果。参与此实验的每个人——你、你的 QA 团队、你的开发人员和外包团队——都会有自己的偏见，这些偏见会影响他们对实验测量结果的反应。您可以通过在开始实验之前就如何收集和分析测量结果达成一致来减少这些偏差的影响。这包括商定一个足够大以具有统计意义的样本量。

编辑

除了测量发现的错误和遗漏的错误的数量之外，测量误报的数量也可能很有趣，即被证明不是错误的报告数量。