跳至主要內容

测试覆盖率的真相——什么是好的覆盖率，JaCoCo 配置与解读

老张2026/4/30大约 6 分钟

测试覆盖率的真相——什么是好的覆盖率，JaCoCo 配置与解读

适读人群：被覆盖率指标困扰、不知道多少覆盖率算够用、或者覆盖率很高但 Bug 还是很多的工程师 | 阅读时长：约12分钟 | 核心价值：理解覆盖率的真实意义，学会用 JaCoCo 配置有价值的覆盖率质量门禁

那场关于覆盖率的争论

2021年，我在一家公司做代码审查，技术总监要求所有模块的代码覆盖率不低于 80%。

结果团队里有工程师写出了这样的测试：

// 为了刷覆盖率，给所有 getter/setter 写测试
@Test
void testUserGettersAndSetters() {
    User user = new User();
    user.setId(1L);
    user.setName("test");
    user.setEmail("test@test.com");
    user.setAge(25);
    user.setCreateTime(LocalDateTime.now());

    assertEquals(1L, user.getId());
    assertEquals("test", user.getName());
    assertEquals("test@test.com", user.getEmail());
    assertEquals(25, user.getAge());
    assertNotNull(user.getCreateTime());
}

覆盖率报告：82%。达标了。

但那周的 Code Review 里，核心的订单状态机逻辑，覆盖率是 12%。

这就是覆盖率数字游戏的本质问题：数字可以达标，质量却一文不值。

覆盖率的几种类型

不同覆盖率指标，衡量的是不同的东西：

行覆盖率（Line Coverage）

最基础，最常用，也最容易被误导。统计有多少行被执行了。

public String getStatus(int code) {
    if (code == 1) return "active";    // 行1
    if (code == 2) return "inactive";  // 行2
    return "unknown";                   // 行3
}

如果只测试 code=1，行覆盖率只有 33%。

分支覆盖率（Branch Coverage）

每个条件的 true/false 分支是否都被执行。比行覆盖率更严格。

public double calculateDiscount(User user, double amount) {
    if (user != null && user.isVip()) {  // 4个分支：null/非null × vip/非vip
        return amount * 0.9;
    }
    return amount;
}

只测 VIP 用户，行覆盖率 100%，但 user=null、user.isVip()=false 的分支没覆盖到。

方法覆盖率（Method Coverage）

有多少方法被调用了。粗粒度，但快速发现"这个类完全没被测试"。

指令覆盖率（Instruction Coverage）

JaCoCo 的默认维度，比行覆盖率更精确，按字节码指令统计。

多少覆盖率才算够？

这是高频问题。我的明确立场：没有一个放之四海而皆准的数字。

但可以给一些参考：

按代码类型分：

代码类型建议覆盖率理由
核心业务逻辑（金融计算、状态机、权限校验）分支覆盖 > 80%出错代价高
普通 Service 层行覆盖 > 60%重要但可以接受部分不测
Controller 层关键接口 100%接口契约要保证
Repository 自定义查询每个 @Query 都要测SQL 容易出 bug
POJO（DTO、VO、Entity）不需要测 getter/setterLombok 生成的无需测
框架生成代码不测MyBatis CRUD、Spring 配置

我的实际建议：

  1. 不要设全局覆盖率门禁（容易被刷）
  2. 设按模块/包的分支覆盖率，对业务核心包要求更高
  3. 关注覆盖率趋势，不允许新提交导致覆盖率下降
  4. Code Review 时人工检查关键逻辑的测试质量

JaCoCo 配置实战

基础配置

<plugin>
    <groupId>org.jacoco</groupId>
    <artifactId>jacoco-maven-plugin</artifactId>
    <version>0.8.11</version>
    <executions>
        <!-- 测试前：初始化 JaCoCo agent -->
        <execution>
            <id>prepare-agent</id>
            <goals>
                <goal>prepare-agent</goal>
            </goals>
        </execution>
        <!-- 测试后：生成报告 -->
        <execution>
            <id>report</id>
            <phase>test</phase>
            <goals>
                <goal>report</goal>
            </goals>
        </execution>
        <!-- 质量门禁：低于阈值则构建失败 -->
        <execution>
            <id>check</id>
            <goals>
                <goal>check</goal>
            </goals>
            <configuration>
                <rules>
                    <rule>
                        <element>BUNDLE</element>
                        <limits>
                            <limit>
                                <counter>BRANCH</counter>
                                <value>COVEREDRATIO</value>
                                <minimum>0.60</minimum>
                            </limit>
                            <limit>
                                <counter>LINE</counter>
                                <value>COVEREDRATIO</value>
                                <minimum>0.70</minimum>
                            </limit>
                        </limits>
                    </rule>
                </rules>
            </configuration>
        </execution>
    </executions>
</plugin>

排除不需要覆盖的代码

<configuration>
    <excludes>
        <!-- 排除生成的代码 -->
        <exclude>**/generated/**</exclude>
        <!-- 排除配置类 -->
        <exclude>**/*Config.class</exclude>
        <!-- 排除 DTO/VO（纯数据对象） -->
        <exclude>**/dto/**</exclude>
        <exclude>**/vo/**</exclude>
        <!-- 排除启动类 -->
        <exclude>**/*Application.class</exclude>
        <!-- 排除常量类 -->
        <exclude>**/constant/**</exclude>
    </excludes>
</configuration>

代码里也可以用注解排除：

// 排除整个类
@Generated("lombok")
public class UserDTO { ... }

// 排除特定方法（JaCoCo 识别 @Generated 注解）
@Generated("IDE")
@Override
public String toString() { ... }

按包设置不同覆盖率要求

<rules>
    <!-- 核心业务包：高要求 -->
    <rule>
        <element>PACKAGE</element>
        <includes>
            <include>com/example/service/core/**</include>
        </includes>
        <limits>
            <limit>
                <counter>BRANCH</counter>
                <value>COVEREDRATIO</value>
                <minimum>0.80</minimum>
            </limit>
        </limits>
    </rule>
    <!-- 通用工具包：中等要求 -->
    <rule>
        <element>PACKAGE</element>
        <includes>
            <include>com/example/util/**</include>
        </includes>
        <limits>
            <limit>
                <counter>LINE</counter>
                <value>COVEREDRATIO</value>
                <minimum>0.60</minimum>
            </limit>
        </limits>
    </rule>
</rules>

解读 JaCoCo 报告

运行 mvn test 后，报告生成在 target/site/jacoco/index.html。

报告里几个关键颜色：

  • 绿色：被测试覆盖的代码
  • 红色：未被覆盖的代码
  • 黄色：分支部分覆盖（一个 if 只测了一个分支）

看报告时，我关注的不是总覆盖率，而是：

1. 找红色最多的类：直接看哪个类覆盖率最低，那里最可能藏着隐患。

2. 重点看分支覆盖（黄色）：黄色意味着有分支没测到。复杂的业务逻辑里，每一个黄色背后都可能是一个潜在的 Bug。

3. 忽视 POJO 类：DTO、VO、Entity 类的覆盖率低是正常的，不要被这些数字干扰。

踩坑实录三则

踩坑一：覆盖率报告显示很高，但关键代码没被测到

现象：覆盖率 80%，但订单金额计算的核心方法几乎没有测试覆盖。

原因：项目里有大量简单代码（Controller、DTO、配置类），这些代码虽然没测，但因为复杂的 Service 逻辑有测试，整体覆盖率被"稀释"了。

解法：看包级别的覆盖率，而不是项目级别。在 JaCoCo 报告里，点击具体包，看核心业务包的覆盖率是多少。

踩坑二：JaCoCo 和 Kotlin 的 data class 结合，覆盖率虚高

现象：Kotlin 项目里，data class 生成的 equals、hashCode、copy 方法被 JaCoCo 统计进去，但这些方法实际上是编译器生成的，不应该计入。

解法：JaCoCo 0.8.x 对 Kotlin 有一定支持，但建议在 JaCoCo 配置里排除 data class 相关代码，或者使用 @Generated 注解标记。

踩坑三：集成测试和单元测试的覆盖率合并计算

现象：项目里单元测试覆盖率 70%，加上集成测试覆盖了很多场景，但 JaCoCo 报告只反映了单元测试的覆盖率。

原因：默认配置下，maven-surefire-plugin（单元测试）和 maven-failsafe-plugin（集成测试）分开运行，JaCoCo 的数据文件需要合并。

解法：

<!-- 合并单元测试和集成测试覆盖率 -->
<execution>
    <id>merge-results</id>
    <phase>verify</phase>
    <goals>
        <goal>merge</goal>
    </goals>
    <configuration>
        <fileSets>
            <fileSet>
                <directory>${project.build.directory}</directory>
                <includes>
                    <include>*.exec</include>
                </includes>
            </fileSet>
        </fileSets>
        <destFile>${project.build.directory}/jacoco-merged.exec</destFile>
    </configuration>
</execution>
<execution>
    <id>post-merge-report</id>
    <phase>verify</phase>
    <goals>
        <goal>report</goal>
    </goals>
    <configuration>
        <dataFile>${project.build.directory}/jacoco-merged.exec</dataFile>
        <outputDirectory>${project.reporting.outputDirectory}/jacoco-merged</outputDirectory>
    </configuration>
</execution>

最终观点：覆盖率是结果，不是目标

我见过覆盖率 90% 的项目出了严重的线上事故，也见过覆盖率 50% 的项目稳定运行多年。

覆盖率只能告诉你"这行代码被执行过"，不能告诉你"这行代码在所有应该被测的条件下都被测过了"。

真正重要的是：关键业务逻辑的分支都被覆盖了吗？异常路径被测了吗？边界条件被测了吗？

这些问题，覆盖率报告可以提示你，但最终要靠工程师的判断力去回答。

编辑此页
最近更新:
贡献者: xiaozhangge