作为一名测试人员我知道我不可能找到每一个错误。但即便如此，当一个问题从你眼前溜过，跑向生产这一本垒时，我经常会问自己，我怎么就漏过了这个问题呢？有什么是我可以做得更好的？我能做些什么来防止未来这种情况的再次发生？

这些都是很好的问题，但更实际的来说，我们需要认识到一点，错误往往会偷偷溜过而未被我们发现。有一些方法可以帮助我们减少这些未被发现的bug数量，但我明白没有任何办法能够保证产品完全无缺陷。

当我刚开始做测试时我总是对别人在我测试过的产品的部分发现bug非常敏感。我常听到办公室回响着可怕的句子——“谁测试过这个？为什么没有发现这个错误？”那时我还没有足够的经验可以通过合理的方式来争论，为什么不是任何产品在任意给定时间段中都可以找到所有的bug。

虽然在某些方面，这些经历帮助我使我的测试方法更完备。

所以，我列出了一些你可以尝试一下的事情，以限制未被检测到的bug的数量，我有几个故事分享给大家，关于那些像夜晚的忍者那样悄悄溜过而未被我发现的错误。这些故事表明，即使最明显的错误（一旦知道就觉得很明显），可能发生也将发生。

我们怎么会错过呢？

在一个项目中，一个网站，正在一些关键部分，如注册和产品选择进行了重新设计并添加了一些额外的功能，我花了大约两个月进行各种测试活动。在这段时间内熟悉设置的各种变化和改进，我们都知道危险，并试图减少它们，我们找了一些人来进行用户支持测试以帮助测试。不幸的是，这些主要覆盖在验证bug修复或者专门针对测试网站的某些部分。

在产品环境中启动网站的第一分钟，一个问题被确定。这是非常明显的bug，也产生了一些相当大的混乱，它是怎么能够被错过的。这个问题并不是说需要任何除了会拼写之外的特殊的技能才能找到的。在该网站的首页（它通常被称为商店橱窗），客户登陆后看到的你的网站的第一页，在屏幕中间非常大的字体，写着“BRAODBAND“而不是“BROADBAND”。 “这是一个非常明显的错误拼写，但不知何故，每个人都错过了发现它，直到这个网站开始使用，然后由于某种原因，这个错误立即被所有人发现了。

它是活的！

我现在受到了“它还活着”，在1931年的老电影科学怪人中那句台词的启发。当产品处于成熟状态，我用这句话来慢慢的推进我的想法，为了能够看到那些可能被我错过的东西。在这种情况下，问题是那么明显它造成了混乱的奇怪的氛围，而且可能因为修补程序过于简单而无从指责。然而，这很清楚地表明了，即使是最公然明显的错误也很容易被很多人错过。

本应该，早该，早可以。

这些错误不一定在测试过程中由于没有找到他们而被错过，而是因为测试者没有考虑如果X事件发生了，在整个开发周期中将会或者可能会发生什么错误。当在当天晚些时候发现或者当产品在生产过程中发现这些bug时，常常招来了一句“是啊，我就觉得这可能会发生”或“我就知道会发生这个问题。”

这些方案有时被称为边缘情况（极限测试情况下）或边角情况（非常具体的，很少发生的情况下）。后者常常使我感到惊讶，因为它们可能很早就在项目中被定义为边角情况，可是后来发现实际上是一些经常发生的情况。这主要是由于不理解系统以及其相互作用够好才能够使得最初做出这样的判断。

我曾有过此类的经历，测试一个新的需要处理成千上万的客户记录的应用程序。在测试过程中，我问了一个问题：“是否进行过负载测试？”对此的答复是“哦，这不是问题，它可以轻松地处理高达一百万条记录的负载。”然而，当推出了这个改变后，在前几分钟有显著的负载，经过观察其证明之后会导致严重的问题并且对应的代码会被还原。在那段时间，我并没有完全理解所涉及的技术，并假定了开发人员比我知道得更清楚，可能已经考虑过这个潜在的问题。从那天起我才知道，当我有直觉某处可能有问题，我不应该认为别人快速而简单的答案就是真理。我应该从别处寻求可以支持的资料以证实或反驳我的假设。

我的第六感正在提醒！

我把这称为我的“第六感”启发，当我对某些东西有一种感觉，比如我不能完全的理解或我所得到的信息看来可疑的情况下，我不愿意就此忽略它并继续下一步除非我对其有一个合理的认识。在这种情况下，我会让参与该项目的每个人都知道，我对这部分有所顾虑。这通常会有所帮助因为其他人会开始质疑为什么我会有顾虑;无论是由于我缺乏相关知识使得我的假设是错误的，或我的假设是正确的，对我而言都没关系。重要的是，我明白如果我忽视自己的直觉进行测试，我不认为自己能有效地做好工作。

容易复制。不容易找到。

通常如果测试需要涵盖产品或系统的各个方面，其场景数量会高得难以负担。即使对于看来可以相对简单的进行测试的系统也可以有数以百万计的排列。有些办法可以处理这样的问题，其中之一被称为成对（或组合）的测试，我不会在这里来详述这个方法，但如果你想了解更多，可以看看Michael Bolton所著的对于这个方法的优秀的处理方式。

我对于这一类的问题的经历是个标准的负面答案，当发现一个问题时，这是100％可复制的。由于只要通过5个简单的步骤，就次次都可复制，并最终导致“怎么又没发现这个bug？”的指责。

问题是这样，基于一个复制系统，该系统有多个文件夹，每一个文件都具有三个不同的使用权限，仅读取，读或写以及拒绝。在每个文件夹中，每个文件都可以有相同的三个文件权限。

我现在更有经验并愿意挑战回复其他人提出的意见，如“你为什么没有发现错误？”因此，我设计了一个简单的场景，说明给定变量的数量有限的测试，测试所有排列所需的时间是巨大的。该方案是这样的：

• 三个文件夹的层次结构
• 每个文件夹包含四个文件
• 文件夹和文件都可以有不同的权限

覆盖这个相对简单情况下所有排列的测试次数为14348907。这是3^15（15个实体与3种状态）。很明显，这么大的数字显示了你是无法在可行的时间内测试完所有排列的。当然，你可以创建一个自动化的测试，以更迅速地完成，但这里的问题是，这种情况甚至不是一个现实世界中真正存在的情况。我仅仅是创建了一个简单的练习，以显示要测试这个看似简单的可复制问题是有多么困难。要知道在现实世界中的客户会有几百个文件夹，包含数百或上千个文件的大层次结构。通过交流关于这个简单的场景很快使我能够说明为何测试无法发现每一个漏洞，无论在事后它是多么的明显。

还有什么？

正如已经叙述的这三个真实世界的故事，即使你认为你已经完成了测试而实际你还没有。有许多原因可以停止测试，但其中并没有你已完成了所有测试这一理由。我觉得思考我是否错过了什么是非常宝贵的。有什么是我没有想到的？有什么是我觉得太明显了，就对其忽视或认为是不值得考虑？我一般尽量记录这些问题。有些会得到答案，有些则没有;但是这并不会阻止我思考具有启发性的“还有什么？”。

避免令人尴尬的错误！

• 命名您的启发式方法，让你可以在未来轻松地回忆起来。
• 如果你要问如何做，你才可以进行测试，当心——无论是与你的理解还是所给的答案都可能有问题。
• 创建许多测试的想法。你真的不应该有没有想法的时候。
• 想想“假设？”
• 请注意你的情绪。他们会告诉你一些事情
• 有新的眼光来看待变化，而不要指示它们要测试的内容。
• 意识到“没有人会这么做”的声明。
• 与其他测试人员，开发人员，产品经理，市场营销——所有可用的并有意愿的人合作测试！

在测试中，我们需要大量的实用主义。不管我们使用什么样的方法来帮助防止检测失误，bug总会被漏过。使用启发方式可以帮助减少总数。

给启发方式命名或助记符可以帮助您同时记住并利用它们来帮助你早期识别错误和防止明显的错误。命名您的启发方式可以根据自己的个人喜好来完成，因此，如果以上任何一个方法对你有用，请随意命名并利用它们来帮助你找到那些所谓明显的错误。

作者简介

Stephen Blower 已经作为测试员在不同的机构工作了18年。目前，身为Ffrees家庭财务的测试经理，他有令人羡慕的位置，能够从头开始创建一个测试团队。他职位的重要部分是激发测试者，而不仅仅是创建流程。Stephen大力鼓励互动和反馈，并让测试者获得控制权，使他们成为发展具有价值的发展团队的成员。

【英文原文：http://www.ministryoftesting.com/2014/07/didnt-find-bug/】

{测试窝原创译文，译者：大头}

译者简介：大头，在读日本九州大学修士，计算机专业，主研究方向为文本挖掘，及自然语言处理。