在开始正文之前，我们先做道语文题：

如何通过测试，________软件质量？

A.  保证

B.  保障

保证，担保负责做到。

保障，保护(权利、生命、财产等)不受侵害，或某种意义上的有限支撑和支持。

在软件开发的过程中，能“担保负责做到”质量的，是需求、设计和开发；而“保护软件质量不受侵害，或有限支撑和支持质量的”才是测试。套用一句改编的广告语：我们不生产质量，我们只是质量的检测员。测试找出质量的缺陷，但不负责修复。这就好比体检找出健康的问题，但不能医治。因此，在谈测试之前，首先要明确质量保证和质量保障的主次关系。用保障质量的视角，来看待测试。

通常，我们把测试出的问题称为bug🐞。当一个程序员说“就剩几个bug🐞了”，听起来是很轻松的，分分钟完活下班的感觉。可试想一下，如果你的体检报告里，赫然写着“高血压”，你觉得它是个bug🐞，还是个bomb💣？软件中，即使再小的bug🐞，只要到了客户眼皮子底下，统统都是bomb💣。因为软件的不可见，会让客户失去安全感，从而变得小心谨慎，甚至吹毛求疵。

既然要保障质量得到改善，我们就应该在测试过程中，用对待bomb💣的心态，对待每一个bug🐞。在交付之前，将bomb💣的隐患控制在最合理的范围之内。

1.  测试的广度

也就是我们到底做哪些测试，几轮测试？下面是Myers, G. J.的《The Art of Software Testing》里，关于测试类型的归纳：

这里我想特别说明一下，无论什么管理方法论，融入企业的过程中，都需要根据实际情况进行“裁剪”。这个过程必不可少，是管理落地的重中之重。这听起来很是废话🤷。显然谁也不会傻兮兮的在所有项目中，都用上所有的测试类型。那么为了找到自己的“最好”，企业在进行裁剪的时候，可以参考以下三个原则：

• 进度和成本的压力；

• 质量要求；

• 不同的软件生命周期；

比如A公司的客户对质量的要求很高，且经常变更。基于此，A公司直接由需求进行开发，把集成测试合并到单元测试中去，裁掉了安装测试，设计了一个新的测试的流程：

2.   测试的深度

比如一个对10个字母进行组合的程序，那么可能性就有26¹⁰种，就算测试一种组合需要1微妙，那么全覆盖就需要测试450万年。所以规模再小的程序，也不可能全覆盖测试，需要多方权衡测试的覆盖率。（By the way，这也是上文我们说“将bomb的隐患控制在最合理的范围之内”，而非排除bomb的原因。）

以上面说的这个程序为例。首先，要考虑客户碰到缺陷的概率，可以从两个维度来推断：

a. 比如100个类似项目中，有19个项目客户都反馈了缺陷，那么客户遇到缺陷的概率就可以推断为19%；

b. 如果没有累积那么多类似项目，就可以根据该项目组的历史项目数据来推断，比如说该项目组总共完成了32个项目，其中8个项目的客户反馈了缺陷，那么这个程序，客户遇到缺陷的概率可以推断为25%。

其次，考虑缺陷对客户的影响，假定这个小程序是个核心程序，那么就要考虑覆盖率更深的测试。

最后，考虑成本和进度。

你可能会觉得，对于这么一个简单的程序来说，无论是19%还是25%的缺陷率,都还是太高了。那么考虑到成本和进度，又该将缺陷率控制到多少呢？

我只能说，在寻找“最好”的路上，没人能给你答案。不过解题思路总还是有的——就是要积累丰富的工作过程数据。

德鲁克说过：“可度量，才能被管理。”这句话，在测试这个环节，格外好用。即使我们开篇就在强调，测试对质量只有保障作用，而非保证作用。但按照行业内的固有思维，只要测试过了，再有bug🐞就要Bomb💣测试了。作为产业链的下游，总是有那么多不得已的锅，要不得已的被扛在肩上。所以咱们测试，为了将bomb💣的隐患控制在合理的范围之内，才更要管理，更要度量，更要利用数据的客观性，为自己代言。

最后，套用一下能跟灭霸叫板的惊奇队长的名言：“我不是来杀虫🐞的，我要打破测试偏见。”