测试的目的

干了这么多年测试，实际上没有仔细想过这个问题，今天看到一个文章主张测试的目的是验证需求，而不是发现缺陷以保证软件的可靠性。我认为，这种看法有失偏颇。这种观点把验证需求和发现缺陷对立了起来。

那么什么是缺陷(bug)？

在我们的实践中，我们最主要的bug来自与设计文档(Design Specification)描述不符，也就是说，设计文档讲，用户使用某一个功能的时候，软件应该如何响应，而实际上开发人员交付的软件并没有按照设计文档所描述的那样响应，也许是响应方式没有遵循设计文档，也许是响应时间没有遵循设计文档，也或许是响应内容没有遵循设计文档。比如说圣经(specification)要求：有人打你的右脸，连左脸也转过来由他打(马太福音).但是实际上有人打你右脸时，你立刻回击，我们称之为bug.

但是这只是bug中的一种。实践中我们不仅仅根据需求 - 我们把Design Specification认为是需求的书面表达 - 来找实现中的缺陷，我们也要根据我们的经验，常识和习惯等去寻找需求描述也就是Design Specification中的问题。Design Specification会有很多问题，尤其是这个文档形成的初期。

为什么Design Specification也会有bug呢？难道它不是用户意思的真实表示吗？也许是，也许不是，我们常常可以发现，在软件实现之前，用户实际上并不真正了解自己的需求，所以我们有了快速原型法，去帮助用户了解自己的需求，去正确表达自己的需求。举个例子，在iPhone问世之前，绝大部分人不知道原来“生活可以更美的”。即便是它是用户意思的真实表示，但用户并不只有一个，所谓众口难调，往往收集需求一圈下来，就会发现有几个用户的需求是矛盾的，这个矛盾有时候就会被带入到Design Specification. 这也是bug. 这个bug也许开发人员可以发现，也许发现不了。而且，理论上测试人员与开发人员应该是同时拿到Specification的，因此，测试人员有责任发现这个bug并敦促PM改正这个设计上的问题。除此之外，Design Specification也会有遗漏，测试人员也应该可以发现一些这样的bug。

总结一下，我们说了两种类型的bug:

1) 实现与设计不符

2) 需求描述（设计）错漏

在我们如此定义bug的外延的情况下，前文所说的对立的两个测试目的就统一了起来，也就是说保证软件的可靠性和验证需求都是测试的目的，不可偏废。或者说是在满足需求的前提下保证质量，不满足需求当然不行，我想要个缸，你给我个框，肯定是不行的。但是你给我一个四处漏水的破缸，或者容量，材质都不符的缸也不行。

我觉得该文后面的一个评论说的好“软件测试的目的就是为了能让用户使用起来更加方便”，不管你是保证质量还是满足需求，以用户为中心总是没错的。