如果有充足的时间设计和进行测试，你总是可以找到更多的bug。然而，如果那个bug好像对你的客户影响不大，那就不值得花时间和精力去找到它。去搜索每一个可能导致系统在5,000年发生一次故障的bug是没有意义的，因为那可能需要你花5,000年去运行所必要的测试。花时间去找出哪里可能藏有真正有影响的bug，并将测试集中于那些地方，会好很多。
理解客户究竟会怎样去使用产品
之前，我间接提到了通过直接接触实际用户或者通过你公司用户服务部门去了解用户需求的重要性。通过同样的渠道，你也应该确认你的测试计划是否反映了你用户的系统配置，特殊需求以及吞吐/系统能力需求。
这也需要了解你的客户的条件限制，这些限制将直接影响用户怎样使用你的产品。在我加入Rational之前，我的工作是有关一个Internet防火墙，它能够支持常被称之为“split-brained DNS”功能网络配置功能。这个功能使用户能够在他们的防火墙后面维护一个私有的DNS服务器。然而我们发现，一些内部DNS服务器被错误的配置了，在我们没有更正他们的DNS 配置之前，无法使防火墙正常工作。最后我们不得不更改我们的安装工具使得即使在用户的内网断了的情况下防火墙仍能够正常运行。这样我们就可以把修理他们的网络当做一个独立的(收费的)任务。
现在让我们转到第二个误解。如果我们接受了bug-free软件真的是不存在的这一观念，我们可以通过运行测试找到故障，那么我们要测试到出故障，对吗?但是如果测试中出故障是一个好事情，那么我们是否能够把它叫做“失败”呢?
误解2：软件测试的目的是为了验证软件能够正常运转
和第一个误解一样，这个说法也反映了一个对软件测试完全乐观的观点。在我们一生的活动中，我们尽力去创造和建造能够正常运行的事物，我们尽我们最大的努力去避免故障。然而，软件测试人员必须有不同观念：为了能够成功，我们必须有意地尽量去促使故障的产生。
如果我们不采用“不正当的”方法会发生什么?如果我们设计避免故障的测试，那么将会使我们的客户失望。当你开发一个软件应用程序的时候，你会清楚地了解应用程序所使用的数据类型，配置以及它能运行所需要的环境。你也知道程序的局限性。如果你的目标是验证应用程序能够工作，你就会限制你在数据、配置和应用程序最初设计所支持环境的边界处测出故障的可能。如果你这样做，你有较大的机会通过你所有的测试。然而在现实世界中，你的客户很有可能会超越这些边界并遇到你测试中没有测出来的bug。
下面是一些要成为一个好的测试者所需要的可以使用的建议。
如果产品出现了故障，你就进行了一个成功的测试。
如果你在头脑中保持测试的目标是为了发现一个bug这一观念，那么你就可以开始考虑一个“成功”的测试就是让软件运行出现故障。不论你只是运行了一个测试还是运行了成千上万次测试，即使你没有发现bug，你的软件仍然不能说没有bug。bug仍然潜伏在测试没有覆盖到的领域。换句话说，要证明没有bug是一件非常困难的事情，并且，我们前面提到过，你必须集中力量去找到产品中危险最大的领域中的bug。
不久前，我接受了一个产品的测试任务，在我之前这个产品已经经过了成百上千次测试。产品出来以后，他们所有人对产品的一些过去投入了几年的工作的组件进行测试。然而，他们的测试很少甚至没有涉及到感兴趣的测试领域。虽然这种回归测试有利于验证新代码的变更没有导致一些旧的函数无法运行，但是我不得不在可能导致麻烦的区域设计新的测试。在 软件测试的艺术， 一书中，Glenford Myers用了一个医学上的类比，如果你觉得不舒服去医院检查，但检查的结果并不足以诊断病因，那能够说这个检查是“成功”的吗?不!你还是有病，你的医生必须再进行正确的检查。
所有的使用者都会犯错误
在测试一个新的软件应用程序的时候，看到不好的测试结果的人肯定要反对你的测试场景。“没有人会那样做!”。不要相信没有这个。一些用户会那样做，或者做一些更糟的事情，并且他们不是有意那样。你的工作就是在产品运送到客户手里以前，考虑用户会犯的错误中最坏的情况，并且确认你的产品仍然能够安然无恙，没有崩溃或者丢失数据。再说一遍，你要寻求的是那些能够发现危险bug的测试故障。
让我们再看一下我们之前讨论的简单程序，那个需要6,000次测试才能包括所有可能的程序。如果你要设计只在合法的输入，环境，操作等情况下的测试，那么你的测试只涵盖了对你系统运行来说最好的场景。但是，如果有些地方出错会怎样?如果用户手指滑了一下，或者错误的配置了什么，或者删除了非常重要的信息，你的软件会怎样表现?或者当一个系统/服务器出现挂起，或者出现达到一些资源的上限(比如内存，磁盘空间，数据库记录的ID等)，会发生什么?当一些应该被标识为损坏的数据进入或者通过系统会怎么样?如果操作中断，系统处于含糊不清的状态?或者如果太多的人在同样的时间做同样的事情?潜在错误的列表是无限的，并且如果你只想确认“它可以工作”的话，你可能就会忽略掉这些场景中的大部分。
结论
我希望这篇文章可以让你确信软件测试的真正目标是寻找bug。即使是在交付时间表很紧的情况下，采取一个步骤来想一下从哪里开始着手，你的测试将会是最有效率的。但即使在时间非常充足的情况下，你也不可能测试出每一个bug，所以你必须将你的测试划分优先级，划分的根据是基于产品目前的状态(新的，修改的或者只是纯漏洞)和对客户的可能影响而进行的最诚实的评估。避免采用你知道软件可以处理的测试数据和操作;你的任务是在测试中扩大软件的边界。在你设计自动化测试时，也要避免“踩灭”失败条件的误区。你的任务不是创造大量的总是可以干净的成功运行的测试。你需要去寻找和理解故障条件。不要浪费时间去想你的软件产品中是否存在bug。它肯定有bug，并且你不可能全部找出它们。你的组织和你的顾客指望你找出那些最有影响的bug。你必须要做的是，你要从消极的角度考虑这些问题。
文章来源于领测软件测试网 https://www.ltesting.net/
