[ 专家观点 ] 第10期 2009年11月
正确理解测试的目的
作者：成都杰华科技公司张隆伟
关于测试的目的，业界最经典也最古老的两种答案是：
第一种：测试是为了验证软件的正确性。
第二种：测试是为了证明软件是错误的。
通常，一个产品在经过完整的测试流程之后，项目经理会要求测试经理给出一个定论，该产品是否可以发布。测试经理组织测试架构师和有经验的高级测试工程师对该产品的缺陷评审之后，通常的结论都是一句话：没有三级以上的缺陷，剩下的这些缺陷不是很严重，软件可以放行。
我相信，这种情况在大多数测试团队上都有发生。这似乎给我们职业测试者传递了一个信息：测试是为了验证软件是可行的。
但是，真的可行吗？
理论上更多的倾向于第2种答案----测试是证明软件是错误的。除非产品仅处理有限种情况，但实际上是不可能的，因此要证明软件的正确性，理论上是不可能实现的。
是哪儿出了问题，是我们做的不够专业？还是我们认识有误区？
不要小看这个问题，如果一个团队的负责人，在这个问题有分歧，势必会造成测试团队的不同走向。
如果测试团队负责人认为测试是为了验证软件是正确的，可能会只紧扣用户需求进行测试，然后频繁进行回归测试，测试者经常性的陷于重复而单调的测试。
如果团队负责人认为测试是为了证明软件是错误的，那么与项目组的分歧肯定少不了，特别是做产品测试的，你老想着发现缺陷，而集成组合的可能又是无限种。在制定测试策略时，重心可能会偏向发现缺陷，从而导致偏离测试宗旨。因为回归性的测试风险较小，也会导致测试人员基本上都不太去做，万一基本功能出现个严重缺陷，那算怎么回事儿？
迷茫了很久，对于测试目的的理解，有没有第三种思路？
我认为，对于测试目的的升华理解应该是：测试的直接目的是为了证明软件是错误的，但测试的潜在作用恰恰证明了软件的部分可行性。
我们应该围绕测试的直接目的，以客户需求为基础，展开测试用例的覆盖性测试、发散思维进行探索性测试、结合不同的测试类型利用多样的测试方法，以求发现更多的缺陷。
基于此观点，相应的测试流程基本上可划分为两个阶段：
第一阶段的重点在于发现缺陷，由测试架构师划分测试范围，制订测试策略，进行多样的测试，以便尽早地发现缺陷。
第二阶段在第一阶段，即风险最大的项目模块风险减少后进行回归测试(一般是缺陷数量曲线收敛并趋于平稳后)。通过这种方式来提升测试效益，最大限度的保证产品质量。