软件测试的目标：失败等于成功(2)

　　如果有充足的时间设计和进行测试，你总是可以找到更多的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的测试故障。

原文转自：http://www.uml.org.cn/Test/200803271.asp