软件测试的目标：失败等于成功[2] 软件测试
理解产品是如何工作的--和为何可能出故障
对一些测试者来说，第一个想做的就是看产品外在的可见的“行为”--将精力集中在他们的产品客户将看到的部分。这样做效力有限，因为他们没有清楚的理解产品程序的逻辑，数据流等等，这些是用户不可见的。为了能够理解产品是如何工作的，以及怎样会出故障，你必须看“罩子下面”并且在你的测试中用到你看到的东西。
例如，如果你只看一个GUI，你可能看到程序通过一个格式化的HTML表格显示一个特定的数据库查询的结果。然而，除非你知道这个表格的表示是一个Java数组对象，从服务器传到客户端，然后转化为一个HTML表格，否则你就不会知道这里存在一个潜在的一个客户端性能瓶颈的危险。如果一个用户运行一个查询，返回的记录太多，就会导致客户端在处理表格的时候像死机一样。(我在几年前是通过这样的方法解决这个问题的：每次让客户端只接收一部分结果数据，并且明确地告诉用户还有其他的数据未传过来。)
如果有充足的时间设计和进行测试，你总是可以找到更多的bug。然而，如果那个bug好像对你的客户影响不大，那就不值得花时间和精力去找到它。去搜索每一个可能导致系统在5,000年发生一次故障的bug是没有意义的，因为那可能需要你花5,000年去运行所必要的测试。3 花时间去找出哪里可能藏有真正有影响的bug，并将测试集中于那些地方，会好很多。
理解客户究竟会怎样去使用产品
之前，我间接提到了通过直接接触实际用户或者通过你公司用户服务部门去了解用户需求的重要性。通过同样的渠道，你也应该确认你的测试计划是否反映了你用户的系统配置，特殊需求以及吞吐/系统能力需求。
这也需要了解你的客户的条件限制，这些限制将直接影响用户怎样使用你的产品。在我加入Rational之前，我的工作是有关一个Internet防火墙，它能够支持常被称之为“split-brained DNS”功能网络配置功能。这个功能使用户能够在他们的防火墙后面维护一个私有的DNS服务器。然而我们发现，一些内部DNS服务器被错误的配置了，在我们没有更正他们的DNS 配置之前，无法使防火墙正常工作。最后我们不得不更改我们的安装工具使得即使在用户的内网断了的情况下防火墙仍能够正常运行。这样我们就可以把修理他们的网络当做一个独立的(收费的)任务。
现在让我们转到第二个误解。如果我们接受了bug-free软件真的是不存在的这一观念，我们可以通过运行测试找到故障，那么我们要测试到出故障，对吗?但是如果测试中出故障是一个好事情，那么我们是否能够把它叫做“失败”呢?
误解2：软件测试的目的是为了验证软件能够正常运转
和第一个误解一样，这个说法也反映了一个对软件测试完全乐观的观点。在我们一生的活动中，我们尽力去创造和建造能够正常运行的事物，我们尽我们最大的努力去避免故障。然而，软件测试人员必须有不同观念：为了能够成功，我们必须有意地尽量去促使故障的产生。4
如果我们不采用“不正当的”方法会发生什么?如果我们设计避免故障的测试，那么将会使我们的客户失望。当你开发一个软件应用程序的时候，你会清楚地了解应用程序所使用的数据类型，配置以及它能运行所需要的环境。你也知道程序的局限性。如果你的目标是验证应用程序能够工作，你就会限制你在数据、配置和应用程序最初设计所支持环境的边界处测出故障的可能。如果你这样做，你有较大的机会通过你所有的测试。然而在现实世界中，你的客户很有可能会超越这些边界并遇到你测试中没有测出来的bug。
下面是一些要成为一个好的测试者所需要的可以使用的建议。
如果产品出现了故障，你就进行了一个成功的测试。
如果你在头脑中保持测试的目标是为了发现一个bug这一观念，那么你就可以开始考虑一个“成功”的测试就是让软件运行出现故障。不论你只是运行了一个测试还是运行了成千上万次测试，即使你没有发现bug，你的软件仍然不能说没有bug。bug仍然潜伏在测试没有覆盖到的领域。换句话说，要证明没有bug是一件非常困难的事情，并且，我们前面提到过，你必须集中力量去找到产品中危险最大的领域中的bug。
不久前，我接受了一个产品的测试任务，在我之前这个产品已经经过了成百上千次测试。产品出来以后，他们所有人对产品的一些过去投入了几年的工作的组件进行测试。然而，他们的测试很少甚至没有涉及到感兴趣的测试领域。虽然这种回归测试有利于验证新代码的变更没有导致一些旧的函数无法运行，但是我不得不在可能导致麻烦的区域设计新的测试。在 软件测试的艺术，5 一书中，Glenford Myers用了一个医学上的类比，如果你觉得不舒服去医院检查，但检查的结果并不足以诊断病因，那能够说这个检查是“成功”的吗?不!你还是有病，你的医生必须再进行正确的检查。
文章来源于领测软件测试网 https://www.ltesting.net/