“软件测试的目的是尽可能发现并改正被测试软件中的错误，提高软件的可靠性。”，这个定义听起来很正确，但用它来指导测试会带来很多问题。比如有的组织用发现的bug数来衡量测试人员的业绩，其实这就是这种测试目的论在后面作祟，其结果如何呢：其一，有一些不够敬业的测试人员会找来一些无关痛痒的bug来充数，结果许多时间会被浪费在这些无关痛痒的bug上（其实应该修复，何时修复，严重程度是什么，优先级是什么，等等）；其二，测试人员会花很大力气设计一些复杂的测试用例去发现一些迄今尚未发现的缺陷，而不关心这些缺陷是否在实际用户的使用过程当中是否会发生，从而浪费了大量的宝贵时间。究其根源，就是因为对测试目的的这种错误理解造成的，为什么这么说呢？因为软件里bug的数量是无从估计的，那么如果测试的目的是为了找bug，那么测试工作将变成一项无法完成也无法衡量进度而且部分无效的工作（因为有些bug在实际的运行过程当中根本不会发生）。
“测试的目的就是为了保证软件质量”，这个定义也是看似正确，但实际上，混淆了测试和质量保证工作的边界。软件质量要素有很多，包括：Understandability、Conciseness、Portability、Consistency、Maintainability、Testability、Usability、Structures、Efficiency、Security等等，所以，软件质量保证和测试其实关注的方向是不同的。
那么测试的目的应该是什么呢？IEEE在1983年提出了软件测试的定义：
“使用人工或自动手段来运行或测定某个系统的过程，其目的在于检验它是否满足规定的需求或是弄清预期结果与实际结果之间的差别。”
所以，简言之，测试的目的应该是验证需求，bug（预期结果与实际结果之间的差别）是这个过程中的产品而非目标。测试人员应该象工兵一样，在大部队（客户）预期前进的方向上探雷、扫雷（bug），而不需要去关心那些根本没有人会去碰的地雷。衡量一个测试人员应该去衡量他/她测试了多少需求（测试工作量），漏过了多少bug（测试有效性）。（在后面的博文里我们会进一步谈测试后评估的重要性）
因此，我们可以看到有好的需求文档/体系对测试工作的必要性，我们看到许多测试团队在业务需求/软件需求不完备的情况下，往往或重新编写测试需求。在未来的博文里，我们会在介绍为什么用例（Use Case）技术会有助于开发人员和测试人员的沟通。
来源：adwu73的专栏 - CSDNBlog
