目录

引言

什么是增量覆盖率

增量覆盖率有啥用途

1、对不同角色同学的用途

2、对不同规模的业务需求的用途

增量覆盖率的适用人员

增量覆盖率不太适用的情况

引言

        有些质量团队，有时会拿「增量覆盖率」做出测试的准出卡点。 但在实际的使用过程中，由于业务特点不同、对应迭代的需求也不同， 这个指标或带来了不少好处，抑或增加了不少额外工作量。 这里针对增量覆盖率适用场景、不适用场景来做讨论，欢迎补充交流。 

什么是增量覆盖率

增量覆盖率，顾名思义就是代码增量中的覆盖程度，增量指 代码新增、代码修改等信息。 

增量覆盖率有啥用途

说起用途，可分以下角度来谈：

1、对不同角色同学的用途

对于具体角色而言，作用不一：

  • 对一线黑盒测试的QA同学： 通常对于偏黑盒测试的QA同学来说，可以查漏补缺， 如 补充测试用例、反向评估场景覆盖是否全面、对不太熟悉业务本身同学辅助了解场景覆盖等。

        黑盒测试同学而言， 本身测试场景评估与 代码「脱钩『， 就这种作用而言， 属于测试后期， 通过看「增量覆盖率」来评估是否需要补充case。

        偏黑盒测试同学； 如 客户端测试人员，在执行业务测试时属于黑盒测试，对于开发实现的代码分支处理逻辑并不了解，只能根据产品需求和开发的技术文档进行测试用例的编写，但是测试用例难免有遗漏或者开发为实现功能影响其他模块需要进行回测的case，如果RD忘记同步，QA很大程度会遗漏此部分的覆盖，导致测试不完整。

        新增补充测试用例情况的例子：

RD修改公共函数，影响其他模块，忘记同步QA
测试方案遗漏异常边界业务场景

  • 对一线研发同学： 查漏补缺，研发同学需要看冒烟覆盖了什么分支代码等、对不太熟悉业务本身同学辅助了解场景覆盖等
  • 对非一线同学(管理人员)： 属于纯管理手段之一，只能对最低要求的测试准出进行评估，可以设计成准出卡点的一个环节。 

         ps: 这种情况下，可能需要调研该指标是否真的对一线同学的工作起到了作用，否则可能沦为自嗨指标

  • 对一线白盒测试的QA同学：由于QA本身就是白盒测试(如codediff、模块测试等等)，增量覆盖率起到的作用可能比较有限，甚至可能浪费了一点时间来统计增量覆盖率而已。

         具体依赖QA自身的具体测试手段， 白盒、还是黑盒。 对偏黑盒、纯黑盒测试的QA来说，可能用途比较大。 偏白盒测试，甚至某些改动而言， 反而是「累赘」。 

  • 对应一线产品同学： 由于产品同学验收偏黑盒的功能验证， 也可以作为评估场景覆盖是否全面的手段。

        总之， 本质上来说， 作用大小、甚至有无作用， 是根据具体同学而言的， 进一步说是根据具体的QA/研发的个人能力而言的。 同样一个需求改动， 偏黑盒测试的QA， 与精通白盒测试(codediff)的QA， 对 增量覆盖率的诉求肯定是不一样的。 

        根据自己在实际项目中的经验来看，如果一线的QA还需要依赖「增量覆盖率」才能评估自己覆盖是否全面，测试是否充分， 这本身就可能比较危险。 因为增量覆盖率只代表了分支代码覆盖情况，与业务场景的覆盖充分度 并不直接相关。 如果对业务、技术实现本身不熟悉，不能够全面把控，那么即便「增量覆盖率」是100%，也很有可能遗漏了某些业务场景。

2、对不同规模的业务需求的用途

        对于具体业务而言 ，作用不一。具体来说，就是对不同量级、改动特点的需求而言， 作用也会非常不一。比如：

  • 偏小的底层逻辑改动， 比如， 代码cr，改动一个方法。 方法被引用多处， 但实际上只需要覆盖一个入口即可。

        当从增量覆盖率角度来评估时， 可能多个入口均需要覆盖。 这其实是增加了「测试工作量」，但对实际质量并没有显著提升。

  • 非逻辑层面改动。有的甚至纯格式化、 添加一行log日志，打印字符串(不可能存在空指针)， codediff下代码就能上线的。 

        当从覆盖率角度来评估时， 你不得不执行业务操作，来做覆盖。 甚至， 有时 log涉及业务场景复杂时， 可能要花不少时间。

  • 当整体改动量比较大、整体测试偏黑盒时， 增量覆盖率不失为一个辅助评估场景覆盖的手段。
  • 当工程中冗余代码、已废弃代码过多时，改动底层方法， 可能连带很多废弃代码需要覆盖，才能达到一定覆盖率。 这是 增量覆盖率可能就不大能准备评估代码覆盖度了。 

ps: 需要从工程中将废弃代码移除后，增量覆盖率评估才会比较准确。

增量覆盖率的适用人员

  • 偏黑盒测试的QA同学
  • 对业务场景、实现本身不太熟悉的QA同学、研发同学(对整体业务、技术实现全貌了解不充分)
  • 产品同学进行验收时，辅助看覆盖情况

增量覆盖率适用的情况

  • 偏白盒测试(codediff/模块测试等)的QA同学，主要通过codediff等手段就能上线的情况；
  • 需求整体改动不大，操作业务场景本身比较耗时，通过codediff就能评估充分的情况；

        白盒测试的QA同学，个人理解帮助不大，而且codediff 、 白盒能力越强，可能越不需要这个指标数据。即 codediff（静态分析）越适用的地方，增量覆盖率可发挥空间就越小，甚至可能成为「累赘」。