正确理解测试的目的

恩，我知道，这问题极其古老，在写下这个题目时，我也不禁有点汗颜......

关于这个问题，测试者都知道最经典的也最古老的两种答案：

测试是为了验证软件是可行的，第一种。

测试是为了证明软件是错误的，第二种。

两位大师的回答。

说实话，我在这问题上思考了很久，因为我是做产品测试的，而且是做同一平台，同一业务。测试的进度压力极大。很多时候的评审，结论通常是一句话，这些BUG不是很严重，软件可以放行。

我相信，这种情况在大多数测试团队上都有发生，这给我带来了一种影响，测试是为了验证软件是可行的。

但是，理论上更多的倾向于第2种回答。

是哪儿出了问题，难道我们团队做的不是测试么？还是我们做的不够专业？

不要小看这个问题，作为团队的负责人，在这个问题上的分歧，会造成团队的不同走向。

如果团队负责人认为测试是为了验证软件是可行的，那么经常性的回归测试是少不了的，测试者经常性的陷于重复而单调的测试，我们团队就是这么走过来的。

如果团队负责人认为测试是为了证明软件是错误的，那么与项目组的分歧基本上少不了，特别是做产品测试的，你老想着发现BUG，那么在划分测试范围时，回归性的测试风险较小，基本上都不太去做，万一基本功能出现个严重BUG，那算怎么回事儿？

迷茫了很久，应该说，现在我找到了第3条思路（或者是哪位先哲的想法？）

测试是为了证明软件是错误的，但是它的副作用恰恰证明了软件的部分可行性。

现在我们的测试流程基本上划分为两个阶段，第1阶段的重点在于发现BUG，由测试负责人划分测试范围，制订测试策略，进行集中测试，以尽可能尽早的发现BUG。第2阶段在第1阶段，即风险最大的项目模块风险减少后进行回归测试。通过这种方式来减少回归测试的次数，提升测试效益。

还有一些关于测试目的的理解,例如我在参加微软培训时,微软对测试的理解就是"尽可能的保证有效代码的实现"。这个定义有点类似测试最终是为了预防。但是我认为这是过程管理去做的事，或者说，这是测试结果的二次应用。测试，最单纯，也是最重要的目的，就是为了发现BUG。