我建议，使用错误种子获取该公司已测试过的代码的置信度的指标，并将其与内部使用的相同指标进行比较可能是个好主意。 。
这是我在ISEB测试课程中了解的一项技术，但是我没有遇到很多在实际环境中使用过该技术的人，因此希望获得一些有关最佳实践的意见也许。以下是我考虑过的事情，但是显然，从以前尝试过此操作的人的经验中学习会更好。可测试项目
开发人员是否已在无法通过质量检查的系统中跟踪这些错误
将每个可测试项目的测试人员提醒给n大小（大约是绝对值）
对于每个错误测试人员提出的问题，提醒他们该错误是否已播种
我的理由是，如果我们使该指标可见且透明，它还将为测试人员提供有关其测试严格程度的反馈。
我欢迎您提出任何可能使这一工作变得困难甚至不可行的实际问题。如果实现了这一点，我将留下一个答案，根据我的经验更新每个人。
#1 楼
我同意Joe的主张，即度量标准可能被严重误用和适得其反。测试计划，我们通常假设两件事：测试计划不太可能揭示系统中的每个错误。 （如果系统又大又复杂，我们可以假设仍会发现一些未发现的错误。）仍然，测试计划应该能够发现系统中的许多错误。 （否则，这不是一个设计合理的测试计划。）
让E =系统中的错误总数，D =测试计划中发现的错误总数，U =总数未发现的错误数。我们知道E = D + U，但我们永远无法确定E或U是什么。但是，我们想认为E / D接近于1。
那么，我们如何计算E / D-我们的错误检测率？因为我们永远不会知道E或U，所以我们不会！但是我们可以将错误注入代码中，然后运行测试计划。通过查看检测到多少个已知错误，我们可以计算出受控环境中的错误检测率。知道此受控错误检测率是高还是低可能会很有启发性。运行测试计划。它们提供了有关这些计划是否可能捕获错误的指示，或者只是使测试人员陷入错误的安全感。
仅当播种的错误是合理的，并且在隐蔽性和可检测性之间取得平衡时才起作用。如果错误太容易发现（或太难发现），则结果数据将既不准确也不有用。因此，需要大量的专业知识来播种错误。 （一种可能性是删除零除检查。如果测试计划中没有测试用例发现错误，则可能指向可以改进测试计划的区域。）故障应该不熟悉测试计划。此外，如果尚未编写测试计划，则编写测试计划的人员应该完全不了解所注入的错误。否则，这两个小组将进行“一次象棋比赛”，并且数据将无法准确表明测试计划的有效性。
这并不是要进行的练习，所以您发现种子错误后，不必担心测试人员会“停止”。这项技术不是用来测试系统的，而是用来测试测试计划的。也就是说，它仍然在软件测试领域中占有一席之地，特别是在严重依赖预写或脚本测试的组织中。
评论
欢迎来到JQ的SQA，除了D和U，了解误报的数量（证明不是错误的报告数量）也可能很有趣。据我了解，外包质量检查与漏洞检测率一样是一个大问题。
–user246
2012年3月19日在17:48
@ user246错误肯定是不好的，是的，但是它们中的许多不是不是应用程序预期行为的沟通不足或文档不足的症状吗？在我的整个职业生涯中，我与一些海外质量检查团队一起工作，我发现可以提供更好的文档，而给您带来更少的误报（在这方面重复是一个大问题）。此外，如果问题不在沟通或文档中，那么现在不该重新评估您的测试团队（这适用于本地和第三方测试团队）。
–丽贝卡·德森维尔（Rebecca Dessonville）
2012年3月19日在18:46
@Dez是的，我同意这是沟通问题的征兆。有时，当人们在附近时，沟通效果最好，而在团队偏远的地方，这当然是不可能的。这些问题可以通过适当的努力得到缓解。该组织会投入这种努力吗？有时是，有时不是。
–user246
2012年3月19日19:18在
@ user246但是，鉴于此问题的主题，组织愿意花费时间和精力将错误植入应用程序中，以测试团队测试的有效性。用于这项工作的资金是否可以更好地用于改善沟通和/或文档编制？
–丽贝卡·德森维尔（Rebecca Dessonville）
2012年3月19日19:22
@Dez欢迎来到BTW SQA。这可能是一个新问题的好话题。
–user246
2012年3月19日19:38在
#2 楼
我还没有参加过使用故障播种的项目。，但是我参加了引入新指标的项目，这实际上就是您在这里提出的。如果我的经验可以作为预测因素，那么您应该期望人们会在做任何事情上都变得更好，而在其他方面却要付出代价。
在这里，您可能希望测试人员在发现方面会变得更好种子错误，在其他方面更糟。这些其他内容可能包括-帮助其他人，提供文档，查找非种子错误，与开发人员合作等。
您还可能会发现，一旦发现了种子错误，测试人员就会停止测试。
您可能会在测试人员（甚至开发人员和其他人员）中发现士气问题。
在使用任何度量程序时，请仔细考虑意外的后果和副作用，
如果实现了这一点，我将留下一个答案，以我自己的经验更新每个人。
我很想看看效果如何。
评论
+1当您告诉测试人员发现的错误是故意用来“测试”测试人员时，会发生什么？
– Phil Kirkham
2012年3月19日在16:24
那么，您的观点是总体而言指标不好，或者我们需要更多指标，在这种情况下，最能补充这种技术以获取所需信息的是什么？问题在于，对公司外部同行所做的工作信心不足，但管理层坚持认为，与花相同的钱在内部增加员工人数相比，这种方法更为有效。没有某种度量标准，情况将保持不变，而我希望要么增加信心，要么我们可以证明转而使用更昂贵的内部资源是合理的
–扫帚的头
2012年3月19日下午16:31
我的观点是，很多时候度量程序会产生意想不到的后果。您的开发人员将注入错误，对吗？他们的动机是什么？如果他们想证明“那些愚蠢的外包测试人员找不到错误”，我敢打赌他们可以注入一些麻烦。
–乔·斯特拉泽（Joe Strazzere）
2012年3月19日17:54
该项目的目标是确定我们是否可以从外包中获得足够的收入，以至于与雇用更多内部资源相比，这样做是一种更便宜，更灵活的选择。开发人员可能会以他们试图让外包测试人员失败的态度，但是内部质量检查项目将使用相同的过程，并且通常直到工作准备好进行测试时才分配测试人员（对项目的内部和外部承诺）。
–扫帚的头
2012年3月20日上午11:08
该软件是Flash应用程序中的问题软件，在其中插入奇数个非致命堆栈跟踪或不对齐资源和不一一计数的情况并不困难-类似于常见的bug。
–扫帚的头
2012年3月20日上午11:09
#3 楼
免责声明：我对此没有任何直接经验。研究人员（例如，马里兰大学的Atif Memon）使用故障植入来衡量测试技术的有效性。在这种情况下，这种做法是有意义的。我假设您建议将播种用作实验，而不是正在进行的过程。
您提到了严格的测试。在严格的实验中，您需要提前决定计划如何解释结果。参与此实验的每个人-您，您的质量检查团队，开发人员和外包团队-都会有自己的偏见，这些偏见会影响他们对实验测量结果的反应。您可以在开始实验之前就如何收集和分析测量结果达成共识，以减少这些偏差的影响。这包括就样本量达成共识，该样本量应足够大以具有统计学上的显着性。衡量误报的数量很有趣，即证明不是错误的报告数量。
评论
为什么有理由对正在进行的测试没有信心？您是否有遗漏错误和/或测试不良的证据？遗漏错误的证据-是的，但是只有两个已知的错误。但是，两者都被遗漏了-我认为这看起来很糟糕，但实际上并没有任何意义-系统地向代码库中注入错误可以更准确地了解土地的地理位置，以及是否接近该土地的状况看起来，有改善的机会。
您是否考虑过在内部测试的项目上试行错误播种过程？这样，您将了解您的流程是否在对抗性较小的情况下产生了所需的指标。