漫谈测试覆盖率

写这篇文章的动力其实源自昨晚饭后在马路上散步时的一些想法，要谈的内容如标题所述：测试覆盖率。

我在之前的文章，写过对质量保障体系建设的一些思考，也写过对质量度量的一些看法，所谓测试覆盖率这个词，大多源于质量度量的一个指标或者说维度。因为要度量，要可量化，才有了覆盖率这一维度。

当然，由于是漫谈，本篇文章不会有很立体的结构和清晰的逻辑，我尝试通过对几个问题的思考，来谈测试覆盖率。

需求是什么

在聊测试覆盖率之前，我们先回到测试工作最初的对象：需求。

需求是什么？广义来说，所有来自于用户的不满和痛点，能直接或间接带来商业价值的诉求都是需求。

如果要仔细定义的话，那么来自于产品经理详细描述的 PRD 和原型图，就是需求的具象化呈现。

需求是测试工作的本质对象，所有测试工作都是围绕需求来展开，当然也会有同学说测试的对象是业务，其实两者本质没差，业务是抽象的定性的，而需求是对业务的具象化定义和描述。

而测试的第一对象，则是产品（软件系统 APP 都可），它将需求进行了实质性转化，变成了一个可观测可度量的东西。

质量度量的意义

聊完需求接着聊质量度量，先说质量。

最初软件测试工程师的岗位，业内称之为 QC，即 Quality Control（质量控制），指的是对产品进行质量检验、发现问题并进行分析、改善不合格问题的人员。记得我刚入行做软件测试时，很多公司内部都是统称为 QC。

后来对软件测试工程师的定义，逐渐变成了 QA，即 Quality Assurance（质量保障），通过建立和维持质量保障体系来确保产品质量没有问题。QA 不仅要知道问题出在哪里，还要知道这些问题解决方案如何制订，今后如何预防，QC 仅仅是有问题就去控制，但不一定要知道为什么要这样去控制。

这个演化的过程，有点像测试左移的概念，即：由事中检测逐渐移动到事前评估预防。

至于解决方案如何制定，其实就是将经验通过流程固化以及对风险的评估控制。

那如何定义问题确实得到了控制和预防并有效解决呢？这就是质量度量的意义。

质量度量的本质是将不确定性的问题，通过流控控制和前置的风险评估，转化为确定的可控制可量化的过程。

如何看待测试覆盖率

质量度量的本质是控制问题带来的风险并解决问题，通过量化手段评估最终质量的过程。

而测试覆盖率，就是质量度量过程中很重要的一个评估维度。

我的观点是：测试覆盖率和需求挂钩，高度依赖研发过程，需要分阶段执行不同粒度，最终结果和线上交付质量成比例。

测试的本质对象是需求，需求的定义是否明确，需求是否符合真实的业务场景和用户痛点，对最终交付质量影响很大。

在将需求转化为可观测可度量的产品过程中，研发构建的质量本身就决定了最终交付质量的好坏。

这里打个岔，并不是说构建的质量是唯一，而是软件工程本身的特性决定了质量、成本、时间三要素需要做平衡和取舍。

至于分阶段执行不同的测试覆盖粒度，则取决于产品的成熟度、用户量及用户类型、具备的商业价值以及企业发展阶段。

为什么说测试覆盖率和线上交付质量成比例呢？

我的观点是测试覆盖率是无法前置评估的，只能通过最终交付质量来度量。

简单理解就是，产品没上线前你不知道线上交付质量如何。只能通过上线后的质量来度量测试覆盖率做的怎么样。

线上没出 bug，没有客诉，带来了大量的订单，那就证明了这个阶段的质量没有问题，测试覆盖率做的好。

否则测试 case 设计的再严密，线上有 bug，有大量用户投诉，也没有达到预期的业务目标，你很难说测试覆盖率做的好。

核心内容总结和回顾

1. 业务是抽象和定性的；

2. 需求是对业务的具象定义和描述；

3. 测试工作的本质对象是围绕产品展开；

4. 产品研发是将需求转化为可观测可度量的产品的过程；

5. 质量度量的本质是控制问题带来的风险并解决问题，通过量化手段评估最终质量的过程；

6. 测试覆盖率和需求挂钩，高度依赖研发过程，需要分阶段执行不同粒度，最终结果和线上交付质量成比例；