在代码中留下故意的错误以供测试人员查找

我们在公司没有这样做，但是我的一位朋友说他的项目经理要求每个开发人员在产品进行质量检查之前添加故意的错误。它是这样工作的：

1. 在产品进行质量检查之前，开发团队在代码中的随机位置添加了一些故意的错误。他们适当地备份了原始的有效代码，以确保最终产品没有附带这些错误。
2. 测试人员也将被告知这一点。因此，他们将进行艰苦的测试，因为他们知道存在错误，并且未找到它们可能被认为是能力不足的标志。
3. 如果发现错误（故意的或其他），则将报告它们，以供开发团队修复。然后，在产品进入第二级质量保证之前，开发团队会在代码的相关部分中添加另一个故意的错误。项目经理说，测试人员应该像开发人员那样思考，并且他/她应该在进行更改的部分中期待新的错误。

好吧，这是怎么回事。他们说这种方法具有以下优点。

1. 测试人员将始终保持警惕，他们将疯狂地进行测试。这可以帮助他们发现隐藏的（非故意的）错误，以便开发人员可以对其进行修复。
2. 测试人员以错误为食。找不到任何错误会影响他们的士气。因此，给他们一个容易找到的人会帮助他们的士气。

如果您忽略了最终产品附带这些故意错误之一的情况，那么在考虑采用这种方法之前，我们还应考虑哪些其他缺陷？

一些说明：

1. 他们在源代码管理中正确备份了原始代码。
2. 当测试人员发现故意的错误时，开发团队将忽略它。如果测试人员发现了非故意（原始）错误，则开发团队首先检查该错误是否由任何故意的错误引起。也就是说，开发团队首先尝试在原始工作代码上重现该代码，并尝试对其进行修复。
3. 只需忽略质量检查和开发团队之间的关系问题。我是在程序员而不是在工作场所上专门问这个问题的。考虑到质量保证和开发团队之间的融洽关系，他们在下班后聚会。项目经理是一位很好的老绅士，他随时准备支持两个团队（Godsend）。

这听起来绝对是坚果。它花费了大量的精力来获得非常可疑的收益，这种做法似乎是基于一些错误的前提：

• 质量检查人员不会努力工作，除非他们知道每天都要接受测试（这对士气不利）

• 该软件中没有足够多的无意引入的错误可供质量检查人员发现

• 质量检查的工作是发现错误-不是。是为了确保软件的生产质量

• 开发和质量保证之间的这种斗智斗勇对公司而言是健康的-事实并非如此；所有员工都应与公司的竞争对手而不是彼此对抗。

这是一个糟糕的主意，所讨论的项目经理是个混蛋/白痴，对人和动力一无所知。这对业务不利。

为了进一步说明我对“ QA的工作”的描述，QA肯定应该在代码和测试套件中找到错误，以此作为完成工作的产物，但不应将角色定义为“您必须找到错误。” 应该是“您必须使测试套件保持最新以考虑新功能并确保所有高测试范围。如果这没有导致发现错误，则测试过程对于产品而言不够复杂。

好吧，根据我所学到的：

1. 这不是学校或工作面试；
2. 测试人员不是孩子。
3. 这不是游戏；
4. 这浪费了公司的钱。

质量检查不仅可以发现错误，还可以担心系统的直观性，用户的学习曲线，可用性和可访问性。例如：“系统丑陋吗？”，“用户是否是色盲用户并且东西是红色和绿色？” 他们也应该抱怨。

系统通过QA的最低要求通常在用户故事中针对该特定功能进行描述，或者在PO希望系统出现在其头脑中的神奇程度中描述。

tl; dr

这不仅是错误，测试人员还应从这种狭view的角度出发。

馊主意。

从测试人员的角度来看：“因此他们将进行艰苦的测试，因为他们知道存在错误，而未发现错误可能被认为是他们的无能。” 基本上，开发人员是在诱骗程序中捕获代码。很少有人喜欢做最终没有意义的工作（因为错误是事先知道的），但仍然会影响他们的看法。如果因为找不到诱杀装置而受到明显惩罚，那就更是如此。而且您知道测试人员能够在发现错误时壮成长吗？听起来像是一个有毒的对抗环境。如果他们正在检查的代码是高质量的，那么质量检查人员应该很高兴。尽管它们是由错误支付的... http://thedailywtf.com/articles/The-Defect-Black-Market

从开发人员的角度来看：激励QA来查找您知道的错误。这很可能会增加真正的错误出门的可能性；QA花费了至少一些时间来寻找易于植入的错误，而不是真正的错误。另外，诱捕装置极有可能将其带出室外。

我完全同意上述答案，这说明为什么这样做不利于动力，而且通常对人的管理不利。但是，可能有很好的技术原因也没有这样做：

在产品进行质量检查之前，开发团队在代码中的随机位置添加了一些故意的错误。他们适当地备份了原始的有效代码，以确保最终产品没有附带这些错误。

1. 根据第一条陈述，您实际上从未在这两次通过中实际测试您想要的生产代码。

2. 我想您会大大增加在为客户争取变更时意外地在发布的生产代码中包含“故意”错误的可能性。可能在某些时候造成一些红色的脸颊。

3. 我可以想象，这只会训练您的测试人员像开发人员那样思考（例如，汤姆将在这里添加错误），这可能会使他们不太可能发现汤姆未曾想到的错误。

编辑

我想清楚一点，这个答案只是在谈论测试您的质量检查流程的概念，我并没有为问题中描述的特定方法论辩护。

结束编辑

有充分的理由检查您的测试/检查是否确实有效。让我给您一个制造示例，但是原理是一样的。

通过机器进料时，进料器可能无法将物料推入足够的距离，这很典型。这被称为“短进纸”，为防止这种情况，我们可能会安装“短进纸传感器”（通常是被物料阻塞的对射型传感器）。当物料到达整个进给长度时，此传感器将检测物料的末端。在机器周期的某个时刻，我们检查传感器是否被阻塞，如果检查失败，则停止机器。

现在，您必须考虑测试本身如何失败。例如，一些灰尘或其他杂物可能会阻塞传感器，并且始终会报告“ OK”，并且永远不会停止机器。另外，传感器的性质是，当光束射到接收器上时，接收器会打开，因此，根据您安装的传感器的类型，在未阻塞传感器的情况下，会获得电气上的“ ON”输入。这意味着如果电缆被切断或该传感器断电，或者输入失败，则程序逻辑将显示为“ OFF”，这表示“阻塞”或“确定”。

为了赶上测试的这些失败模式，我们通常会插入第二个检查，以确保在周期的第二部分中传感器实际上未被阻塞。通过这种方式，我们检查测试实际上仍在运行（尽我们所能）。

同样，质量检查部门可能会通过多种方式失败。也许自动化测试没有运行，并且报告正在查看测试数据的旧副本。也许某人做得不好。对质量检查部门进行测试是一件合理的事情。

明显的缺点是，“测试错误”可能使其通过质量检查部门进入成品。在制造业中，有时会将已知的不良零件（有时称为“红兔”）插入到流程中（通常由QA的人员来进行），他们会观察该零件经过流程并测量所需的时间。找到零件并将其删除。通常，此部分被涂成鲜红色（或橙色），因此可以轻松对其进行跟踪。由于有人在测试过程中观察零件的加工过程，因此将其制成最终产品的机会几乎为零。当然，还有一些伪造的故事，说有人将一个已知的不良部分扔进了过程中，以“查看系统是否可以找到它”，

老实说，我称这种行为公然不道德且不切实际。该项目经理需要接受一些认真的重新培训，如果不终止的话。

• 它显示出对质量保证概念的根本缺乏了解。测试人员不应像开发人员那样思考：他们应该像最终用户那样思考。拥有QA团队的全部原因是，开发人员天生就太接近代码了。QA应该与代码保持足够的距离，以使他们可以捕获开发人员错过的内容。
• 这浪费了质量检查工作。假设这些bug并非微不足道（请参阅下文，以了解它们的出现时间），这意味着QA会花费时间和资源来调查已知的事物，而他们可能会花时间进行努力以寻找未知的事物。
• 这浪费了开发人员的精力。为了使质量检查人员能够发现这些不重要的错误，开发人员必须首先编写它们。这需要进一步的努力，不仅花费在编写错误上，还花费在考虑软件需求和设计上。
• 它使生产处于不必要的风险中。更改无法正确合并只是时间问题。
• 如果它不执行上述操作，则毫无意义。如果所有已知的bug都是微不足道的，那么它们将不会捕获不合格的工人：它们只会捕获根本不工作的人。有更好的方法可以做到这一点。
• 它毒害了工作环境。您的质量检查测试人员是专业人士。除非有真正的理由怀疑他们，否则他们应该被认为是专业的。当有是有理由怀疑，否则，应该有一个适当的调查，而不是这些智力游戏。其他任何事情都会扼杀士气。

说真的 即使在这种特定情况下，PM的偏执症被证明是有充分根据的，也不是拥有任何业务管理测试人员的人。

就个人而言，我对这种方法感到不舒服。

我最关心的是插入故意错误的实用性。在我看来，这很难以可预见的方式进行。

任何代码更改（有意或其他方式）都会产生副作用。这些副作用很可能在测试期间就被揭示出来了，但是根本原因（甚至对于植入该错误的开发人员而言）并不明显。如果您知道我的意思（我是从我的直觉出发），那并不觉得“安全”。

而且，测试人员将浪费大量时间来测试实际上不会发布的代码。我认为，一旦清除了故意的错误，就应该进行完整的重新测试。这就是测试的重点。有新的变化，什么，你重新测试一切。好的，我知道这在实践中永远不会发生，但这就是回归测试的全部意义。

因此，总的来说，不相信。

另一方面，我们倾向于让客户验证质量检查团队的工作，这可能不理想。但是，这是一个非常强大的反馈循环。

由于已经给出的所有原因，这是一个坏主意，但是错误植入是一个用于不同目的的有用工具。您可以使用它来粗略衡量质量检查流程的有效性。

在最简单的情况下，假设您播种了100个bug，它们代表了实际bug的全部范围（我知道，不太可能，但是我正在简化）。 您不会告诉质量检查人员这样做是为了避免破坏实验。在质量检查过程结束时，假设他们在100个种子错误（以及其他实际错误）中发现了60个。现在，您知道质量检查正在发现60％的错误。

您可以通过计算发现的质量检查的真实错误数并应用假错误率来进一步扩展此范围。在我们的示例中，如果质量检查人员发现了200个真正的错误，那么您可以得出结论，他们仅发现了60％的错误，因此还剩下133个。

当然，这只是带有巨大误差条的广泛估计。编写现实的，有代表性的错误很难。质量保证很容易找到您编写的错误，因为开发人员受过训练，不能编写错误。最好模拟一类错误，例如一次性错误，Unicode错误，缓冲区溢出等。

这应该应用于整个质量检查流程，包括开发人员单元测试，持续集成，以及（如果有）专门的质量检查团队。

这是一个指标，不应被劫持为管理动机工具。

馊主意。

这是开发人员经常采用的一种逻辑，二进制方法，但它对QE不利。它只是表明缺乏信任。量化宽松人员常常在没有太多投入的情况下陷入这些情况，并假设他们对此表示满意，因此不建议这样做。

这种想法与仅作为手动测试人员的QE结合在一起，并且没有动力去理解实际的测试代码。

我是资深量化宽松专家，这是我工作过的大多数组织所熟悉的问题。

我会说一个坏主意。

一：程序员将花费时间在代码中放置故意的错误，并付出一些努力来保存好的版本。虽然测试人员可能应该测试所有东西，包括带有已植入的bug的功能，但是当他们找到一个时，他们大概必须返回并重新运行该测试以验证这确实是bug（而不是使测试人员感到困惑）某种程度上来说）。至少，测试人员将花时间编写植入的bug。然后，程序员必须花时间修复他们植入的错误。这可能花费大量精力来尝试编写好的代码和编写实际的错误。

第二：它向测试人员发出明确的信息，即程序员和/或管理人员认为他们没有完成工作，必须将其视为孩子。我无法想象这对士气有好处。作为一名程序员，如果给我一个程序的模棱两可或相互矛盾的规范，并且不得不花大量时间弄清楚它们，然后在浪费了数小时或数天之后，我的老板告诉我：“哦，是的，我故意在文件中放入矛盾的陈述。这些规范只是为了确保您确实在阅读它们”，我想我真的会很恼火。如果那件事经常发生，那可能足以让我寻找另一份工作。

在现实生活中，除了最琐碎的代码更改之外，所有更改都会出现错误。我从来没有遇到过让测试人员感到沾沾自喜的问题，因为给出的初稿通常是100％完美的。我不得不与懒惰的测试人员打交道，他们没有做足够的工作，但是他们没有那样做，因为程序员是如此的完美。我曾经与过的最好的测试人员曾经告诉我，对于一个新的软件版本，他为自己设定了一个发现100个错误的目标。好的，100是一个实际数字取决于产品的规模和变化的范围，但是在我们的案例中，他几乎总是设法实现这一目标。有时他不得不做一些事情，例如在消息中称一个拼错的单词为“ bug”，但是嘿，它必须要解决。

脚本发布：如果您这样做，我敢打赌，程序员迟早会故意植入一个错误，测试人员找不到那个特定的错误，而程序员却忘记了将好的代码放回去。因此，现在将故意植入的错误发送给客户。

我真的不认为这是一个坏主意。我认为很多事情可以做得更好：

1. 尽一切可能使质量检查对质量负责。例如，通过支持他们的责任。这将增加他们确保所发货产品具有更高质量的动力。自己发现不足之处（错误，明显缺少的功能，违反直觉的行为）之后，总是花更少的精力，然后再尝试了解您的烦恼用户试图解释的内容。而且，即使将某些责任推给开发人员，也可能会增加他们的动力，以帮助质量检查人员尽其所能。

2. 拥有多个质量检查团队，可以相互竞争。您当然需要找到一个明智的指标。绝对不仅仅是问题的数量。考虑缺陷的严重性或提议的增强功能的业务价值（由利益相关者确定）应该会有所帮助。

很难说质量检查是否“足够好”。从长远来看，找到质量检查方法“不断改进”的方法更容易，甚至可能更好。

但是，如果引入了故意的错误，还有一个问题需要注意：首先您如何知道“正确的”代码实际上是正确的？在第二次质量检查之后，您将删除所有尚未发现的故意错误。无法得知您不是只是将它们替换为以其他方式破坏的代码，或者不是启用了以前无法实现的破坏行为（夸大的示例：某些对话框由于故意的错误而无法打开，但对话框本身已损坏-您只是找不到而已，因为测试人员看不到它）。

正如其他人所说，开发人员不应故意在软件中添加错误，但是将测试中的错误添加到软件中是测试套件的合法策略。

这就是所谓的变异测试。想法是使用软件自动在源代码中创建小的更改（称为突变体）。这些更改旨在创建不同的行为，例如，我们可以更改

if x < 10:
    print "X is small!"

进入

# we flipped the inequality operator
if x > 10:
    print "X is small!"

一个好的单元测试应该检测到突变体的代码片段不再能够正常工作并杀死突变体。当原始代码通过测试，并且所有变体（在功能上并不等效）均未通过测试时，您便知道您的代码和测试很强大。

我喜欢这个主意。是帕顿将军说的：“您在和平中出汗越多，在战争中流血就越少。”

放置故意的错误会“浪费时间”给测试人员。但这也使他们更加努力，这意味着他们在发现意外缺陷方面也将做得更好。（而且您有“原始”的副本，因此您不必继续自己所做的事情。）

从长远来看，发现更多无意的错误可能会为您节省更多的有意处理错误的费用。

另外，您可以了解测试人员的水平，这本身并不是一个小小的好处。

没有依据本身的优点进行奖励或惩罚的依据，而是基于您所针对的行为的结果。有时会产生意想不到的后果。目的是使质量检查团队不致懈怠，或者使一些经理觉得自己实际上在做出贡献，却没有意识到自己只是在妨碍自己。

积极成果-质量检查小组会更加努力地发现错误。谁知道，也许他们认为这是一个挑战。这是一个友好的游戏。或者他们只是因为被监视而正在做（霍桑效应？）。

负面结果-他们可能不会更加努力地工作，并且仍然发现错误。质量检查人员认为这是小事和对抗。因此，现在，他们开始寻找超级错误，并返回各种挑剔的小问题。当我截屏并将其转换为pdf并以500％的比例查看时，该字体无法正确呈现。

没有影响-对我来说听起来没什么区别，那么为什么要打扰呢？您只是冒着浪费时间和激怒他人的风险。

我们都可以同意这不会在90％的时间内奏效。这对其他10％并没有多大好处。自己测试一下。客户是否对具有故意的代码错误的发行版更满意？它会影响其他领域的员工士气和生产率吗？增加营业额？你告诉我们。

来自一个期望开发人员自己编写和运行测试的世界，您指的是这个“测试”“ QA”筒仓，这令我感到恐惧和困惑，因此，我将尝试从这个角度回答。顺便说一句，从我的角度来看，合格的QA工程师（如@SparK的答案中所述）应关注更大的问题，以确保软件完全满足用户需求并具有整体“质量”（软件所针对的域），而不是寻找错误。

在这里吸引我的是@JamesMcleod在对该问题的评论中提到“缺陷注入”。实际上，我认为让开发人员考虑如何将错误注入系统是针对深度防御概念的一个好主意。任何单个错误都不应以无法控制的方式关闭整个系统（没有清晰的可操作日志记录），导致任何数据损坏或本身暴露出安全漏洞。

让每个组件的开发人员制造有意的缺陷，处理其他组件的缺陷并总体上对他们的软件采取更具敌对性的思维方式，可能会大大提高软件的健壮性。即使是直接的好处也可能是显着的-我要求在每次此类新缺陷的注入期间（迄今尚未测试），开发人员应立即通过新的测试覆盖该缺陷，并设置一个标志，该标志将允许该错误在短时间内不受干扰地存在于代码库中，然后在交付之前将其打开（并消除了缺陷），以将其转变为常规测试，从而使测试套件更加全面。

一个相关的选项是使用功能标志来有意关闭特定组件中的功能，以检查其他组件如何处理该功能。我还强烈建议您阅读免费的书/文章“向第一响应者学习：当您的系统必须工作时”，其中描述了对奥巴马团队用于2012年大选的软件基础设施的广泛测试。

正如其他人已经说过的那样，仅查找错误并不是QA的工作。从技术上讲，我会进一步说这根本不是他们的工作。开发人员应负责保持自己的代码无错误。测试套件应该在甚至提交新代码之前就运行，并且如果测试套件失败，那么它就永远不应该首先进行质量检查。故意引入错误意味着您绝对不能通过测试套件，那么为什么您的代码要进行质量检查？

质量检查的工作是根据应用程序实现的用户案例来验证应用程序。他们应该测试流程，UI等，并确保用户能够以最可用和最易访问的方式完成用户应做的所有事情。当然，这样做的时候，他们可能会偶然发现bug，但这只是他们所做的事情的副作用，而不是他们所做的事情。请记住，质量检查意味着质量保证，而不是无缺陷的保证。

这不一定像听起来那样疯狂。而是取决于您的动力。如果你正在寻找一个棍子打你的测试团队，以及那将是疯狂的。另一方面，软件开发中最困难的事情之一就是要知道测试方法的有效性。

因此，如果结构正确，则可以使用此技术来估计要发布的产品中还剩下多少未发现的错误。因此，假设您在测试版本中人为地植入了100个bug，而测试人员发现了其中的50个。然后，您可以推断出，如果他们还发现了50个非种子错误，则很有可能还剩下50个。

当然，这充满了许多问题。您可以根据这些统计信息决定是否发货，但在现实生活中，您可能会发现一个非常讨厌的问题，或者一千个小麻烦。

仍然-知识就是力量，而没有这种技术，您对代码库质量的了解就更少了。如果您能够出于正确的理由而尊重地实施它，我会说“为什么不呢？”

尚无人提及的一件事：突变测试。

这是自动化工具获取源代码并故意在其中插入错误的地方。（例如，删除随机选择的语句，将AND更改为OR或其他。）然后，它将运行完整的测试套件，并检查测试是否通过。

如果所有测试均通过，则有两种可能性：

• 更改的内容不会执行任何操作。换句话说，您的代码无效。
• 所做的更改引入了您的测试套件无法捕获的错误。您需要更多测试。

请注意，与您的建议不同，我上面描述的一切都是自动化的。您不会在浪费开发人员手动插入毫无意义的错误的时间。而且您不会浪费测试人员的时间来发现已知的错误。您唯一用尽的时间就是机器时间，这要便宜得多。（机器不会因为进行相同的测试20,000次而感到无聊。过了一会儿，人类会停止关怀！）

我建议自动突变测试是一种比您正在谈论的手动方案更好得多的方法。

请注意，如果您要求开发人员手动插入错误，则您所得到的错误类型可能无法代表人类可能犯的意外错误。（例如，如果您还没有意识到可能存在竞争情况，那么您也不大可能插入故意的竞争条件。）当然，自动化工具是否能够达到更加客观的目标还有待观察……

尽管通常来说这是一个坏主意（其他答案完全可以解释原因），但在某些特殊情况下，有意以受控的临时方式向生产代码中注入错误可能是有意义的。

当您重构测试代码时（应该这样做），测试代码应与生产代码一样关注细节。您可能想知道测试代码是否仍在寻找应该发现​​的错误。

然后，您可以故意破坏生产代码，以验证测试是否仍然有效。

有多个级别可以实现：

• 刚刚重构了一些单元测试的开发人员可能会破坏生产代码，以验证该单元测试仍然可以找到它应该找到的内容。
• 刚刚重构了某些验收测试的测试人员可能会破坏生产代码，以验证验收测试仍在验证应验证的内容。
• 如果接口足够稳定且健壮（即基于协议），则公司可能希望保留一组已知的故障产品版本并对其进行测试，以便对测试进行回归测试。

这些事情是否有意义取决于。如果我是一名开发人员，而我只需要花一分钟时间注入一个bug，请测试单元测试，然后删除该bug-然后为什么不这样做。但是我应该让我的编辑器，我的周期和我的版本控制系统处于良好的控制之下，以免我意外地提交/交付/签入/推送错误。测试人员和验收测试也是如此。

对于组织而言，保留一组已知有故障的产品版本并进行回归测试是否有意义取决于测试。对于网上商店，我不会。对于汽车嵌入式，航空航天嵌入式，银行卡或收费电视卡，我会这样做。

这要付出多少努力，很大程度上取决于测试与生产代码之间的脱钩程度。测试与生产代码的分离程度越高，执行此操作所需的工作越少，则测试与生产代码的内聚性越高，则工作量就越大。

原因很简单：当您的测试和生产代码具有内聚性时，更改生产代码需要经常更改测试，这将破坏测试与错误的生产样本之间的依赖性。然后，您还必须维护有缺陷的生产样本。在极少数情况下，即使这样做也值得付出努力，并且版本控制系统的模拟以及智能使用可以显着减少工作量，但它需要远远超过熟练的开发人员。

在生产代码中有意注入故障的概念称为破坏活动，注入的故障称为破坏活动。

不直接从存储库获取待测试代码的测试人员做错了。（1）

将已知有故障的代码检入到存储库中的开发人员做错了。（2）

因此，在此阶段，如果没有任何一方或双方违反应该如何进行开发和测试的非常基本的前提，则该方案无法工作。

（1）因为您需要记录测试的版本。您可以测试带有Git哈希或SVN版本号标记的版本，而不能测试“ Joe给我的代码”。

（2）因为您不愿意，所以在预期失败的测试驱动程序之外。

这是出于最短的“电梯音调”原因而进行的尝试，对开发人员，测试人员和管理人员都应立即有意义。

我建议不要故意将错误注入您发送给质量检查的每个版本中。

假设您每年不时进行一次秘密的“质量检查”。采取“经过测试且有效”的代码库，并从Todo列表中获得尽可能多的小新功能。比平常更“草率地”实施它们。考虑一下边缘情况，将其写下来，但不要修改代码以考虑到它们。将其发送给质量检查。

如果他们发现比您写下来更多的无法正常工作的案例错误，那么肯定不是您的质量检查人员需要监督... ;-)