有人向我反馈了一个bug：常规的软件开发测试工作总体流程图

测试的定义意味着程序测试的过程是具有破坏性的，其程度甚至达到了不可容忍的地步。 会上大多数人的人生观是建设性的，而不是破坏性的。人们倾向于创造一个物品，而不是轻易毁坏—个物品。因此，程序测试的破坏性的定义使人们对程序测试工作望而生畏。程序测试定义还隐含着如何设计测试情况(测过数据)，以及应该由谁和不应由谁来测试一个给定程序等等观点。

另一个令人烦躁的问题是即使程序完成了预期要求，仍可能含有错误。也就是说，如果程序不按要求工作，它显然有错，但是如果程序做了不要它做的事，它也有错。

.“用户质量”和“开发质量”就是我通常用来分析一个产品究竟需要什么样的测试的第一个因素。在这个维度下，我们可以很容易地理解，如果一个产品仅仅是 “一次性”的产品(也即，开发后不再需要维护和持续演化)，那么测试的重点一定就是“用户质量”(只需要关心该产品是否在用户面前表现得够好就可以了);代码是不是够烂，设计是不是不合理并不重要。而如果一个产品是需要持续演进较长时间的，那就必须关心代码和设计的质量(“开发质量”)。例如，一个采用付费下载方式进行销售的小游戏，开发团队通常不会花太多的时间和精力在保证产品具有良好的“开发质量”上，而宁愿花更多的时间去调整外部的细节表现。

另一个直接决定了产品需要什么样的测试的纬度是“产品对缺陷的容忍程度”。

测试工程师有时候喜欢把“零缺陷”作为标榜测试工作的口 (我在很长一段时间内也是如此)，但，仔细想想，如果发现一个缺陷的成本比让这个缺陷留在产品中带来的损失更大，那是否还值得去发现这个缺陷?我想，从项目的角度来说，答案是不言而喻的。测试是一个资源权衡的活动，也是一个基于风险的活动，因此，产品的缺陷带来的影响越小，影响越容易被消除(修复)，这个缺陷的价值就越小，值得投入用来发现缺陷的资源也就越少。

互联 产品和传统的桌面产品来比较，对桌面型产品来说，缺陷的修复成本足够高(只能通过软件召回或是发布补丁的方式)，因此对缺陷的容忍度就低;而对于互联 产品来说，由于其产品的修复成本足够低(对一个已知的缺陷，可能只需要花上几分钟到几十分钟就能完全修复了)，因此相对而言，其对缺陷的容忍程度更高(当然，对于那些会导致用户数据损失或是带来其他不可逆破坏的缺陷，那又另当别论了)，对互联 产品开发来说，及时识别缺陷(发现那些用户已经遇到的缺陷)，快速定位缺陷和快速修复缺陷的能力往往要比在系统测试阶段发现缺陷的能力更重要，而要能有强大的识别缺陷和定位缺陷的能力，这就是测试的价值。

THE END

PS：如果你觉得我们彼此能提供的价值有交换的可能，欢迎给我发邮件。