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