错误播种的最佳实践是什么？

Question

在我工作的地方，我们使用一家离岸公司来增加几个内部部门。我在QA团队工作，并且已经表达了我们对我们分配给这家公司员工的测试工作的信心水平的担忧。

我建议使用误差播种来获得该公司测试过的代码的可信度，并将其与内部使用的相同度量进行比较，这可能是个好主意。

这是我在ISEB测试课程中学到的一种技术，但是我还没见过很多在现实世界中使用过它的人，所以我想了解一下什么是最佳实践。以下是我所想过的一些事情，但很明显，从以前尝试过的人的经验中学习会更好。

• 让开发人员在每个可测试项中培育多个bug
• 让开发人员在QA无法访问的系统中跟踪这些bug
• 提醒测试人员注意所述的可测试项目，n有多大(大约？绝对的？)
• 对于测试人员所引发的每一个bug，都要提醒他们该bug是否已播种。

我的推理是，如果我们让这个度量可见和透明，它也会给测试人员反馈他们的测试有多严格。

我欢迎就任何可能使这一问题难以或甚至不可行的实际问题提出意见。如果这一做法得到实施，我将留下一个答复，更新每个人在这方面的经验。

Answer 1

我同意Joe的说法，即度量标准可能被严重滥用并产生反作用。

尽管如此，错误播种可能是回答正确问题的有用方法。

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

1. 测试计划不太可能发现系统中的每一个错误。(如果系统庞大而复杂，我们可以假设一些未被发现的错误仍然存在。)
2. 不过，测试计划应该能够发现系统中的许多错误。(否则，这不是一个设计得很好的测试计划。)

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

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

一些注意事项和陷阱：

• 此方法旨在收集运行预先编写的测试计划的有意义的数据。它们提供了一个指示，说明这些计划是否有可能发现错误，或者仅仅是诱骗测试人员产生错误的安全感。
• 这将只有当种子错误是可信的，并在隐藏良好和可探测到的两者之间取得平衡时才能起作用。如果错误太容易查找(或太难找到)，则结果数据既不准确，也不有用。因此，需要相当多的专门知识才能产生错误。(一种可能性是去掉一张除以零的支票。如果测试计划中没有测试用例找到错误，那么这可能指向一个可以改进测试计划的区域)。
• 注入故障的人应该不熟悉测试计划。此外，如果还没有编写测试计划，那么编写测试计划的人应该完全不知道注入的bug。否则，这两个小组将进行某种“棋局”，而数据将无法准确地显示测试计划的有效性。
• 这并不意味着这是一个持续的练习，所以您不必担心测试人员在发现种子错误之后“停止”。该技术不用于测试系统，而是用于测试测试计划。

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

Answer 2

我还没有参加过一个使用故障播种的项目。

然而，我是引入新度量的项目的一部分--这基本上就是您在这里提议的。如果我的经验是任何预测，你应该期望人们会变得更好，特别是无论你衡量它，而牺牲了其他一切。

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

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

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

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

如果这一做法得到实施，我将留下一个答复，更新每个人在这方面的经验。

我很想看看这是怎么回事。

Answer 3

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

研究人员(例如马里兰大学的阿蒂夫·梅蒙 )使用故障播种来衡量测试技术的有效性。在这种情况下，这种做法是有意义的。我想你建议把播种作为一个实验，而不是一个正在进行的过程.

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

编辑

除了测量发现的bug和漏掉的bug的数量之外，还可能感兴趣的是度量错误阳性的数量，即被证明不是错误的报告的数量。