我们需要什么样的测试？
测试是为质量服务的，测试活动围绕质量进行。这个定义是我们今天讨论的出发点。ISO 9126模型给出了一个多层次的质量模型定义，该定义包括了各个正交维度的质量属性，这些质量属性中既有面向用户的，也有面向开发的。但在实际的测试工作 中，一旦提到产品质量，大部分人更容易将其理解成“用户质量”，也就是“最终用户所能感受到的软件的质量（例如，软件的功能性、性能、安全性等等）”。 “用户质量”是用户所能够直接感受到的产品的“好坏”，也是用户是否愿意为产品付钱的主要原因。因此，在测试中重视“用户质量”是必然的。设想一下，如果 A公司要为B客户开发一个软件，只要该软件最终能够达到B用户的要求，A公司就能拿到钱，通常这也就意味着A公司“成功的完成了该软件的开发”。从这个角 度来说，“用户质量”就是软件开发是否成功的标准。
然 而，如果深入看待整个软件开发过程，事情就没有这么简单了。A公司为客户B开发的软件并非是一锤子买卖，而是需要不断的维护和升级的，B用户不断提出新的 需求，而这些新的需求都要被加入到软件中去。在这种情况下，从效益出发，A公司就不能仅仅考虑最终的产出是否能够满足B客户的要求了，而是必须想办法保证 产品在持续演进的过程中始终保持好的可维护性和可测试性，这样A公司才能以较低的成本让这个产品持续成功。因此，如果不把软件开发看成一锤子买卖，而将该 软件的生命周期的维护过程考虑进去，我们就不得不关注“用户质量”之外的“开发质量”，这里的“开发质量”就是指产品内在的，是否容易被修改、是否容易被 移植、是否容易被验证的特点。
1. “用户质量”和“开发质量”就是我通常用来分析一个产品究竟需要什么样的测试的第一个因素。
在 这个维度下，我们可以很容易地理解，如果一个产品仅仅是 “一次性”的产品（也即，开发后不再需要维护和持续演化），那么测试的重点一定就是“用户质量”（只需要关心该产品是否在用户面前表现得够好就可以了）； 代码是不是够烂，设计是不是不合理并不重要。而如果一个产品是需要持续演进较长时间的，那就必须关心代码和设计的质量（“开发质量”）。例如，一个采用付 费下载方式进行销售的小游戏，开发团队通常不会花太多的时间和精力在保证产品具有良好的“开发质量”上，而宁愿花更多的时间去调整外部的细节表现，音效， 图像上。
2. 另一个直接决定了产品需要什么样的测试的纬度是“产品对缺陷的容忍程度”。
测 试工程师有时候喜欢把“零缺陷”作为标榜测试工作的口号（我在很长一段时间内也是如此），但，仔细想想，如果发现一个缺陷的成本比让这个缺陷留在产品中带 来的损失更大，那是否还值得去发现这个缺陷？我想，从项目的角度来说，答案是不言而喻的。测试是一个资源权衡的活动，也是一个基于风险的活动，因此，产品 的缺陷带来的影响越小，影响越容易被消除（修复），这个缺陷的价值就越小，值得投入用来发现缺陷的资源也就越少。
拿 互联网产品和传统的桌面产品来比较，对桌面型产品来说，缺陷的修复成本足够高（只能通过软件召回或是发布补丁的方式），因此对缺陷的容忍度就低；而对于互 联网产品来说，由于其产品的修复成本足够低（对一个已知的缺陷，可能只需要花上几分钟到几十分钟就能完全修复了），因此相对而言，其对缺陷的容忍程度更高 （当然，对于那些会导致用户数据损失或是带来其他不可逆破坏的缺陷，那又另当别论了），对互联网产品开发来说，及时识别缺陷（发现那些用户已经遇到的缺 陷），快速定位缺陷和快速修复缺陷的能力往往要比在系统测试阶段发现缺陷的能力更重要。而要能有强大的识别缺陷和定位缺陷的能力，就必须依靠产品内建的 “开发质量”了。
再以医疗行业的某些软件为例，对涉及到医疗器械的控制软件（如自动注射器，心脏起搏器等），其对缺陷的容忍程度就非常低，原因很简单，因为这类缺陷可能带来的后果太严重。
3. 第三个因素是“有效的测试方式”。
对 互联网产品来说，最有效的测试方式也许并不是找一堆专职的测试工程师在公司内部尽可能地覆盖每一个功能细节，让真正的用户来对产品进行测试在很多情况下也 许是更好的选择。无论是FB，Google等公司提倡的dog food（让全部员工来进行测试），还是在实际产品上进行的a/b testing, 或是游戏公司通常喜欢采用的内测方式，甚至是直接找像 TestBird 这样的第三方做真人测试等，都是典型的让用户参与测试的方法。另外，根据产品不同的特性，适合采用手工测试还是自动化测试的方式来进行测试也是 一个值得考虑的点。
4. 第四个因素则是“产品的开发团队所处的状况”，因此，对同一个组织来说，在组织发展的不同阶段，所需要的测试也是不同的。
“苦逼的团队是做不出有爱的产品的”，自然，“苦逼”的团队也不可能达成好的测试。因为让每个人疲于奔命的是总也无法完成的任务和无止境的加班，恐怕都没有停下来思考如何改进的机会。
