写这篇文章的灵感源自昨晚饭后在马路上散步的一些想法，内容如标题所述：测试覆盖率。
我在之前的文章，写过对质量保障体系建设的一些思考，也写过对质量度量的一些看法，所谓测试覆盖率这个词，大多源于质量度量的一个指标或者说维度。因为要度量，要可量化，才有了覆盖率这一维度。
当然，由于是漫谈，本篇文章不会有很立体的结构和清晰的逻辑，我尝试通过对几个问题的思考，来谈测试覆盖率。
需求是什么
在聊测试覆盖率之前，我们先回到测试工作最初的对象：需求。
需求是什么？广义来说，所有来自于用户的不满和痛点，能直接或间接带来商业价值的诉求都是需求。如果要仔细定义的话，那么来自于产品经理详细描述的PRD和原型图，就是需求的具象化呈现。
需求是测试工作的本质对象，所有测试工作都是围绕需求来展开，当然也会有同学说测试的对象是业务，其实两者本质没差，业务是抽象的定性的，而需求是对业务的具象化定义和描述。
而测试的第一对象，则是产品（软件系统APP都可），它将需求进行了实质性转化，变成了一个可观测可度量的东西。
质量度量的意义
聊完需求接着聊质量度量，先说质量。
最初软件测试工程师的岗位，业内称之为QC，即Quality Control（质量控制），指的是对产品进行质量检验、发现问题并进行分析、改善不合格问题的人员。记得我刚入行做软件测试时，很多公司内部都是统称为QC。
后来对软件测试工程师的定义，逐渐变成了QA，即Quality Assurance（质量保障），通过建立和维持质量保障体系来确保产品质量没有问题。QA不仅要知道问题出在哪里，还要知道这些问题解决方案如何制订，今后如何预防，QC仅仅是有问题就去控制，但不一定要知道为什么要这样去控制。
这个演化的过程，有点像测试左移的概念，即：由事中检测逐渐移动到事前评估预防。
至于解决方案如何制定，其实就是将经验通过流程固化以及对风险的评估控制。
那如何定义问题确实得到了控制和预防并有效解决呢？这就是质量度量的意义。
质量度量的本质是将不确定性的问题，通过流控控制和前置的风险评估，转化为确定的可控制可量化的过程。
如何看待测试覆盖率
质量度量的本质是控制问题带来的风险并解决问题，通过量化手段评估最终质量的过程。而测试覆盖率，就是质量度量过程中很重要的一个评估维度。
我的观点是：测试覆盖率和需求挂钩，高度依赖研发过程，需要分阶段执行不同粒度，最终结果和线上交付质量成比例。
测试的本质对象是需求，需求的定义是否明确，需求是否符合真实的业务场景和用户痛点，对最终交付质量影响很大。
在将需求转化为可观测可度量的产品过程中，研发构建的质量本身就决定了最终交付质量的好坏。这里打个岔，并不是说构建的质量是唯一，而是软件工程本身的特性决定了质量、成本、时间三要素需要做平衡和取舍。
至于分阶段执行不同的测试覆盖粒度，则取决于产品的成熟度、用户量及用户类型、具备的商业价值以及企业发展阶段。
为什么说测试覆盖率和线上交付质量成比例呢？
我的观点是测试覆盖率是无法前置评估的，只能通过最终交付质量来度量。
简单理解就是，产品没上线前你不知道线上交付质量如何。只能通过上线后的质量来度量测试覆盖率做的怎么样。
线上没出bug，没有客诉，带来了大量的订单，那就证明了这个阶段的质量没有问题，测试覆盖率做的好。否则测试case设计的再严密，线上有bug，有大量用户投诉，也没有达到预期的业务目标，你很难说测试覆盖率做的好。
核心内容总结和回顾
- 业务是抽象和定性的；
- 需求是对业务的具象定义和描述；
- 测试工作的本质对象是围绕产品展开；
- 产品研发是将需求转化为可观测可度量的产品的过程；
- 质量度量的本质是控制问题带来的风险并解决问题，通过量化手段评估最终质量的过程；
- 测试覆盖率和需求挂钩，高度依赖研发过程，需要分阶段执行不同粒度，最终结果和线上交付质量成比例；
往期精彩内容推荐
