多环境多需求并行下的代码测试覆盖率统计工具实现

马蜂窝技术原创内容，更多干货请关注公众号：mfwtech

测试覆盖率常被用来衡量测试的充分性和完整性，也是测试有效性的一个度量。「敏捷开发」的大潮之下，如何在快速迭代的同时保证对被测代码的覆盖度和产品质量，是一个非常有挑战性的话题。

在马蜂窝大交通、酒店等交易相关业务中，项目的开发和测试实践同样遵循敏捷的原则，迭代周期短、速度快。因此，如何依据测试覆盖率数据帮助我们有效判断项目质量、了解测试状态、提升迭代效率，是我们一直很重视的工作。

Part.1 测试覆盖率统计中的挑战

对于功能测试而言，通常可以通过充分了解需求、完善的测试用例、接口测试、Review 技术方案等来保证测试充分性。但随着业务规模快速发展，业务逻辑越来越复杂，系统级别交互越来越多，这些方法都不能保证所有的代码一定被全部测试过，也给测试人员带来极大挑战。

说到这儿和大家分享一个因为测试覆盖不充分，影响到线上业务的真实案例。事件起因是项目提测阶段一个微服务 Sonar 扫描没通过，开发同学为了修复 Sonar 发现的问题而重构了一部分历史代码，却导致一个原有发券需求的错误。当天下午运营触发发券后 Bug 出现直接导致生单不可用，并且持续了将近一个小时。这里的问题就是发券功能与此次需求无关，开发人员修改代码后测试人员不知道，也没有经过测试，但跟随本次需求一起上线了，测试用例无法覆盖到。

通过这个例子可以明显地看到正确统计被测代码覆盖率的重要性。当前市面上统计覆盖率的工具很多，但应用到我们的实际场景中通常存在以下问题：

1. 大部分第三方工具都是以支持提测前单元测试的覆盖率统计为主，而支持提测后测试覆盖率的工具则比较缺乏；

2. 第三方工具提供的覆盖率基本都是展示全量的，但大部分情况下，测试人员重点关注的应该是本次新增和修改的部分，而不是耗费过多精力在未修改的部分上；

3. 为了支持多需求并行测试，大交通后端服务采用 QA 隔离环境，而市面上还没有支持多需求隔离环境并行测试的测试覆盖率统计工具。

因此，大交通测试组决定自研工具进行被测代码的覆盖率统计，用代码覆盖结果反向地检查测试人员测试用例的覆盖度和开发人员代码的冗余度，更精准地定位和分析问题，保证产品质量。

Part.2 覆盖率统计工具设计

结合我们的实际场景，覆盖率统计工具的实现目标如下：

1. 大交通业务后端代码使用 Java 语言开发，主要的业务处理逻辑都在后端，所以工具要优先支持 Java 代码覆盖率统计

2. 可以统计提测后测试过程中不同类型测试的覆盖率，包括：手工测试、回归测试、接口测试、UI 自动化测试等等

3. 支持全量、增量覆盖率统计

4. 支持多需求多环境并行测试，同时统计覆盖率

5. 用户不局限于测试人员，而是所有有测试需求的人员࿰