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

#1 楼

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


质量检查人员不会努力工作，除非他们知道每个人都在接受测试。一天（这对士气不利）
软件中没有足够多的无意引入的错误，可供质量检查人员发现
质量检查人员的工作是查找错误-不是；是确保软件具有生产质量。
开发和质量保证之间的这种斗智斗勇对公司来说是健康的-事实并非如此。所有员工都应该与公司的竞争对手而不是彼此对抗。

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


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

#2 楼

好吧，根据我所学到的知识：

这不是学校或工作面试；
测试员不是孩子；
这不是游戏；


QA不仅在这里查找错误，而且还担心系统的直观性，用户的学习曲线，可用性和可访问性一般。例如：“系统丑陋吗？”，“用户是否是色盲用户并且东西是红色和绿色？”他们也应该抱怨。
系统通过质量保证的最低要求通常是在用户故事中描述的特定功能，或者是PO希望系统掌握在他脑海中的神奇程度。
tl; dr
这不仅是bug，测试人员应该从这种狭view的视角中成长出来。

#3 楼

从测试人员的角度来看，这是个坏主意。

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

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

#4 楼

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


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




基于第一条语句，您实际上从未在这两个过程中真正测试过您想要的生产代码。
我想您会极大地增加在尝试匆忙进行更改时意外地在发布的生产代码中包含“故意”错误的可能性一个客户。在某些时候可能会引起一些面颊。
我想这只会训练您的测试人员像您的开发人员那样思考（例如，Tom在这里如何添加错误），这可能使他们不太可能找到Tom的错误。没想过。

#5 楼

编辑

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

结束编辑

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

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

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

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

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

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

#6 楼

老实说，我称这种行为公然不道德且不切实际。项目经理需要进行认真的重新培训，甚至还需要终止培训。




它表明，人们对质量保证的概念根本缺乏了解。测试人员不应该像开发人员那样思考：他们应该像最终用户那样思考。拥有质量检查团队的全部原因是，开发人员天生就太接近代码了。 QA应该与代码保持足够的距离，以使他们能够捕获开发人员错过的内容。

这浪费了QA的工作量。假设这些bug并非微不足道-何时出现-表示质量检查人员正在花费时间和资源来调查已知的事物，而他们可能会花精力去寻找未知的事物。

这浪费了开发人员的精力。为了使质量检查人员能够发现这些不重要的错误，开发人员必须首先编写它们。这需要进一步的努力，不仅花费在编写错误上，还花费在考虑软件需求和设计上。

使生产处于不必要的风险中。更改不能正确合并只是时间问题。

如果以上操作均不成功，则毫无意义。如果所有已知的错误都是微不足道的，那么它们将不会吸引不合格的工人：它们只会吸引根本不工作的人。有更好的方法可以做到这一点。

它毒化了工作环境。您的质量检查测试人员是专业人士。除非有真正的理由怀疑他们，否则应该相信他们是专业的。当有理由怀疑时，应该进行适当的调查，而不要进行这些心理游戏。其他任何事情都会扼杀士气。

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

#7 楼

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

与我有关的主要事情是插入故意错误的实用性。在我看来，这很难以可预见的方式做到。

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

此外，测试人员将浪费大量时间来测试不是实际上要被释放。我认为，一旦清除了故意的错误，就应该进行完整的重新测试。这就是测试的重点。某些事情发生了变化，您重新测试了所有内容。好的，我知道这在实践中永远不会发生，但这就是回归测试的全部内容。

因此，总的来说，我们并不确定。

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

#8 楼

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

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

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

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

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

这是一个度量标准，不应被劫持为管理激励工具。

#9 楼

馊主意。

这是开发人员经常采用的一种逻辑，二进制方法，但对于量化宽松政策却是不利的。它只是表明缺乏信任。量化宽松常常在没有太多投入的情况下被置于这种情况下，它认为它们可以接受，因此不建议这样做。

这种思维与量化宽松相结合仅测试人员，没有动力去理解要测试的实际代码。

我是一名高级QE，这是我工作过的大多数组织中的一个熟悉的问题。

#10 楼

我会说一个坏主意。

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

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

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

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

#11 楼

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


让质量检查人员尽一切可能对质量负责。例如，通过支持他们的责任。这将增加他们确保所运输产品具有更高质量的动力。自己发现不足之处（错误，明显缺少的功能，违反直觉的行为）之后，总是会花费较少的精力，然后尝试了解您的烦恼用户试图解释的内容。并且甚至将某些责任推给开发人员，可能会增加他们的动力，以帮助质量检查人员尽其所能。
拥有多个质量检查团队，可以相互竞争。您当然需要找到一个明智的指标。绝对不仅仅是问题的数量。考虑缺陷的严重性或提议的增强功能的业务价值（由利益相关者确定）应该会有所帮助。

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

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

#12 楼

正如其他人所说，开发人员不应故意在软件中添加错误，但是将测试中的错误添加到软件中作为测​​试过程的一部分，这是您的测试套件的合法策略。

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

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

更改为

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

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

#13 楼

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

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

从长远来看，发现更多无意的错误可能会为您节省更多的痛苦

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

#14 楼

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

阳性结果-质量检查团队会更加努力地发现错误。谁知道，也许他们认为这是一个挑战。这是一个友好的游戏。还是他们只是因为被监视而正在做这些事情（霍桑效应？）。

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

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

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

#15 楼

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

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

让每个系统的开发人员组件会产生有意的缺陷，处理其他组件的缺陷，并且总体上对它们的软件更具对抗性，这可能会大大改善软件的健壮性。即使是直接的好处也可能是显着的-我要求在每次此类新缺陷的注入期间（迄今尚未测试），开发人员应立即通过新的测试覆盖该缺陷，该测试将设置一个标志，该标志将允许该bug暂时保留在代码库中一小段时间，然后在交付之前将其打开（并消除了缺陷），以将其转变为常规测试，从而使测试套件更加全面。

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

#16 楼

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

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

#17 楼

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

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

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

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

#18 楼

还没有人提到过一件事：突变测试。

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

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


更改的内容无济于事。换句话说，您的代码已经失效。
更改引入了一个错误，您的测试套件无法捕获该错误。您需要更多测试。

请注意，与您的建议不同，上文所述的所有操作都是自动化的。您不会在浪费开发人员手动插入毫无意义的错误的时间。而且您不会浪费测试人员的时间来发现已知的错误。您唯一用尽的时间就是机器时间，这要便宜得多。 （机器不会对进行20,000次相同的测试感到无聊。人类会在一段时间后停止照顾！）

我建议自动突变测试比您手动进行的方法好得多。

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

#19 楼

尽管通常这是一个坏主意（其他答案可以很好地解释为什么），但在某些特殊情况下，有意以受控的临时方式向生产代码中注入错误是有道理的。

您重构测试代码-并且应该对测试代码和生产代码一样重视细节-您可能想知道测试代码是否仍在寻找应该发现​​的错误。

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

有多个级别可以实现：


开发人员可以刚刚重构过的某些单元测试可能会破坏生产代码，以验证该单元测试仍能找到应该找到的内容。
刚刚重构了某个验收测试的测试仪可能会破坏生产代码，以验证验收测试仍然验证应该验证的内容。
如果接口稳定且抢劫足够的灰尘（即该公司可能希望保留一组已知的错误产品版本并针对它们进行测试，以便对测试进行回归测试。

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

对于组织而言，保留已知的错误产品版本套件和测试所依赖的回归测试是否有意义。对于网上商店，我不会。对于汽车嵌入式，航空航天嵌入式，银行卡或付费电视卡，我可以。

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

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

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

#20 楼

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

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


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

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

（2）因为您没有，所以预期会失败的测试驱动程序。


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

#21 楼

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

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

如果他们发现比您所记录的更多的非正常工作的bug，肯定不是您的质量检查需要监督... ;-)