最近，我的一个同事在走廊里拦住我，很骄傲和热情地给我描述了她为一套自动测试程式进行的设计和采用的技术。她说：“最妙的是他们都能够很顺利、漂亮的运行”。在我走开的时候我在想怎样采取最温和的方式告诉她，她已“迷失了方向”。虽然她尽了很大的努力去建立一套成功的测试，但是她没有认清软件测试的真正目的。

　　软件测试的真正目标是什么?为了研究这个问题，我随机问了一些软件研发和测试工程师、管理人员。其中一些说目标是验证软件是否满足用户和产品的需求。其他的人给出了更简单的回答，例如：“确认软件没有Bugs”连同“为了验证软件能够正常运转”。 就我看来，这些说法都不准确。简单来说，软件测试的真正目的是找到以前没有发现的bug。下面我将从我对软件测试目标的看法出发，剖析我同事关于软件测试的主要目标的误解，并给测试人员一些建议。

　　误解1：软件测试的目的是为了确保没有Bug

　　这种看法反映了一种对于软件本质的乐观但从根本上错误的观点。一个简单的事实就是不存在“bug-free”的软件。

　　为什么是这样呢?首先，在等式的研发一边，您必须面对时刻在变化的技术，一个复杂的而且经常有缺陷的应用设计，集成新的已存在的系统带来的困难，等等。人本身的错误也是个很大的因素。虽然现代思维应用研发工具能够自动生成代码，但是在有些地方人必须参和到研发过程中，而人是会犯错误的。

　　而在等式的测试这一边，不可能让您的产品在送到您的用户以前运行任何可能的测试来检测出每一个可能的bug。让我们来看一个简单的假定的例子。比如说您要测试一个这样的程式：

　　接受3个整型的数值作为输入，每一个数值的范围在0到9之间。在2种操作系统下运行。能够访问存储在3个不同厂商中任何一个提供的数据库中的数据。我们计算一下，我们有1,000种可能的排列作为测试输入。为了测试在每个操作系统上的每种排列，我们需要2,000个测试用例，另外再考虑到每种输入在每个支持的数据库运行一遍，我们需要6,000个测试用例。这个数字还没有考虑到其他的测试情况，例如网络故障，磁盘空间不足连同内存耗尽等等。所以实际上我们需要测试用例的数目要更大一些。

　　无疑，我们不得不接受这样一个事实：我们只能生活在一个任何的软件都有bug的世界当中。然而，我们没有必要绝望。经过精心的计划，我们能够选择性地找出产品中最多出现危险连同对我们的用户最重要的部分中的bug。下面是我发现的有效的一些步骤。

　　在您的计划当中加入风险分析

　　正确理解您的客户需求文档本身就是一门科学(后面将会周详讲到)。假如您不能直接接触到您的用户--例如，通过客户焦点小组，那么您就应该和您的客户支持部门一起商讨您的测试计划，因为他们直接接触到最终用户。

　　要明白您的产品哪些部分处于危险当中同样需要分析。变更是危险的主要来源;假如您引入了一个变更，您可能不注意地引入了一个新的bug或发现一个已存在的bug。因此，支持新功能的代码一直是个寻找危险的好地方。为了修正一个bug而修改的代码也是这样。而且，假如您在某个地方发现了bug，那么在附近潜藏着其他bug的可能性就很大。虽然您可能认为经过多年修正了很多bug的地方最后“清除干净了”，这种想法只是在修正时发现了bug的根源的情况下才是正确的。假如bug的根源是糟糕的设计，而进行的修正只是个简单的补丁而不是从根本上解决这个问题，那么这个修正实际上可能引入了新的bug。另外，记住：即使是基于“根本原因”的修正也有可能会引发基础性变更，暴露其他严重bug。