一、代码覆盖率是什么代码覆盖率Code Coverage不是玄学它是一个非常朴素的统计指标。打一个生活化的比方你请了一个私家侦探去跟踪某人侦探回来交了一份报告告诉你他跟踪到了哪些地方、哪些地方没跟到、哪些地方只跟了一半。代码覆盖率工具就是你的侦探——它会在测试运行时记录每一行代码有没有被执行到。代码覆盖率衡量测试用例执行了多少被测代码的指标通常按行、分支、方法等维度统计。你可以理解为测试用例的覆盖面地图。在我接触过的项目里代码覆盖率主要看四个维度指标含义举例行覆盖率有多少行代码被执行过一个 100 行的方法测试跑了 80 行 → 行覆盖率 80%分支覆盖率if/else、switch 的每个分支是否都被走过if (x 0)只测了 x1 的情况 → 分支覆盖率 50%方法覆盖率有多少方法被调用过10 个 public 方法只测了 7 个 → 70%类覆盖率有多少类被测试触及通常与项目结构有关不一定每个类都要直接测为什么需要代码覆盖率说真的没有覆盖率数据的时候你对测试质量的判断基本靠感觉。有了覆盖率报告之后这些事就变得清晰了一眼看出哪些代码完全没被测试碰过——这些就是潜在的 bug 温床发现单测的假覆盖——测试跑过了某个方法但只走了 happy path异常分支从没触发过给重构提供安全网——覆盖率达标了你才敢放心改代码可能有人会问代码覆盖率 100% 是不是就万事大吉了不是。100% 覆盖率只能说明每行代码都被执行过了不能说明所有边界条件都验证了。比如一个除法运算a / b你传了 b1这行被覆盖了但 b0 的异常分支你没测代码依然会炸。覆盖率是必要但不充分的质量指标。二、JaCoCo 是什么JaCoCoEclipse 基金会旗下的开源代码覆盖率工具通过字节码插桩技术在 JVM 层面收集执行数据。它是目前 Java 生态中覆盖率工具的事实标准没有之一。官网在 https://www.jacoco.org/jacoco/搜JaCoCo 官网。2009 年从 EclEmma 项目发展而来到现在已经迭代了十几年Spring Boot、Maven、Gradle 对它都有原生级别的支持。字节码插桩在不修改源码的前提下往编译后的.class文件里插入监控代码的技术。你可以理解为给代码装上隐形的计数器。JaCoCo 的核心原理就是字节码插桩。它不碰你的 Java 源码而是在编译之后的.class字节码中插入探针。运行时这些探针自动记录哪些指令被执行过最终收集成一份jacoco.exec数据文件再渲染成可读的 HTML 报告。和早期的 Cobertura、Emma 相比JaCoCo 有三个碾压级优势不需要改源码——字节码级插桩零侵入支持 on-the-fly 插桩——不用提前对 jar 包做处理运行时直接挂载报告可读性好——HTML 报告里绿/红/黄三色标记一眼看出哪行漏了三、Maven 插件配置3 步接入 Spring BootJaCoCo 最方便的接入方式就是 Maven 插件整个配置不超过 20 行的 pom.xml。当然JaCoCo 也支持本地命令行独立使用去官网下 jar 包java -javaagent:jacocoagent.jar手动挂载但 Maven 插件在构建流程里直接嵌入了覆盖率收集和报告生成对团队协作更友好。本文选 Maven 插件方案。在pom.xml的buildplugins中加入以下配置以 JaCoCo 0.8.15 为例2026 年 6 月最新稳定版plugingroupIdorg.jacoco/groupIdartifactIdjacoco-maven-plugin/artifactIdversion0.8.15/versionexecutionsexecutionidprepare-agent/idgoalsgoalprepare-agent/goal/goals/executionexecutionidreport/idphasetest/phasegoalsgoalreport/goal/goals/execution/executions/plugin这两个 execution 各司其职prepare-agent在 Maven Surefire 运行测试之前把 JaCoCo 的探针 Agent 挂载到 JVM。保证跑测试的时候覆盖率数据已经被悄悄记录了。report在test阶段测试跑完之后读取探针收集的jacoco.exec生成 HTML / XML / CSV 三种格式的报告。配置完这一步JaCoCo 就接入完成了。接下来写代码验证。四、示例代码一个简单的 User CRUD我这边用一个 Spring Boot 项目来演示代码尽量精简只保留能体现覆盖率差异的关键逻辑。User 实体——标准的 POJO不需要测试// src/main/java/.../model/User.javapublicclassUser{privateLongid;privateStringname;privateStringemail;publicUser(){}publicUser(Longid,Stringname,Stringemail){this.idid;this.namename;this.emailemail;}// getter / setter 省略}UserService——核心业务逻辑包含增删改查。注意findByName用了equalsIgnoreCasedelete返回 boolean 而非抛异常——这些细节在覆盖率报告里都会体现// 示例src/main/java/.../service/UserService.javaServicepublicclassUserService{privatefinalConcurrentHashMapLong,UserstorenewConcurrentHashMap();privatefinalAtomicLongidGennewAtomicLong(1);publicListUserfindAll(){returnnewArrayList(store.values());}publicOptionalUserfindById(Longid){returnOptional.ofNullable(store.get(id));}publicUsercreate(Useruser){user.setId(idGen.getAndIncrement());store.put(user.getId(),user);returnuser;}publicOptionalUserupdate(Longid,Userupdated){returnfindById(id).map(existing-{existing.setName(updated.getName());existing.setEmail(updated.getEmail());returnexisting;});}publicbooleandelete(Longid){returnstore.remove(id)!null;}publicListUserfindByName(Stringname){returnstore.values().stream().filter(u-u.getName().equalsIgnoreCase(name)).toList();}}五、写单元测试覆盖不是跑通就行测试代码决定了覆盖率的上限。我们用一个常见的分层写法——Service 层测逻辑Controller 层用WebMvcTest Mock 测路由。UserServiceTest——每个方法至少测两条路径正常情况 边界/异常情况// 示例src/test/java/.../service/UserServiceTest.javaclassUserServiceTest{privateUserServiceuserService;BeforeEachvoidsetUp(){userServicenewUserService();}TestDisplayName(findById should return user when exists)voidshouldFindUser(){UsercreateduserService.create(newUser(null,Alice,aliceexample.com));OptionalUserfounduserService.findById(created.getId());assertThat(found).isPresent();assertThat(found.get().getName()).isEqualTo(Alice);}TestDisplayName(findById should return empty for non-existent id)voidshouldReturnEmpty(){assertThat(userService.findById(999L)).isEmpty();}TestDisplayName(update should return empty when user not found)voidshouldReturnEmptyOnUpdate(){OptionalUserresultuserService.update(999L,newUser(null,Ghost,ghostexample.com));assertThat(result).isEmpty();}TestDisplayName(delete should return false when user not found)voidshouldReturnFalseOnDelete(){assertThat(userService.delete(999L)).isFalse();}TestDisplayName(findByName should be case-insensitive)voidshouldFindByNameCaseInsensitive(){userService.create(newUser(null,alice,aexample.com));userService.create(newUser(null,ALICE,a2example.com));ListUserfounduserService.findByName(alice);assertThat(found).hasSize(2);}}这里强调一点别只测 happy path。update和delete的 “不存在” 分支如果不写测试JaCoCo 的分支覆盖率会直接告诉你只走了一半。我见过不少团队覆盖率卡在 40% 左右上不去原因就是只测了正向逻辑。六、运行并看懂 JaCoCo 报告配置好了代码和测试也写好了跑一下mvn cleantest测试跑完后JaCoCo 报告生成在target/site/jacoco/index.html用浏览器打开这个文件你会看到一个彩色仪表盘。报告怎么看关键看这 5 列JaCoCo 默认用五种颜色区分覆盖程度颜色含义 绿色该行/分支被完整执行 黄色部分覆盖如 if 只走了 true 分支 红色完全未被覆盖盲区⚪ 无色不可执行代码方法签名、空行点进某个具体的类比如UserService会看到逐行的源码着色以我这边项目的UserService为例如果所有测试都写了包含空值分支和异常路径行覆盖率能到 100%分支覆盖率也能到 100%。但如果少写了delete的return false分支测试分支覆盖率就会掉到 80% 多。JaCoCo 不会骗人一目了然。行覆盖率 vs 分支覆盖率哪个更重要维度行覆盖率分支覆盖率计算方式执行过的行数 / 总可执行行数执行过的分支数 / 总分支数容易虚高吗容易——一行 if 走了 true 就计入不容易——两个分支都得走才算能暴露什么问题哪段逻辑完全没跑过哪些条件没验证过推荐关注度★★★★★★★★我的建议把分支覆盖率当作主要参考指标。一行代码被覆盖只能说明来过一个分支被覆盖才能说明所有可能性都考虑到了。很多 bug 就藏在那个你没有测到的 else 分支里。七、常见问题可能有人会问mvn test跑完了但target/site/jacoco/目录不存在报告没生成检查两件事第一prepare-agent和report两个 execution 是否都配了我见过只配了 agent 没配 report 的情况第二确认 Maven Surefire 插件确实执行了测试看终端有没有Tests run:字样。如果用了skipTeststrue/skipTests那肯定没有报告。有人会问多模块 Maven 项目怎么配在父 pom 的pluginManagement中声明 JaCoCo 插件子模块不需要重复配置。如果要生成聚合报告再加一个report-aggregategoal单独建一个coverage-report模块来汇总。覆盖率太低怎么办别一上来就追 80% 的硬指标那不现实。先让 JaCoCo 把报告跑出来按类排序看红色最多的几个类从风险最高的入手。通常一个项目最该优先补测试的是核心业务 Service、工具类中的复杂算法、Controller 的异常处理分支。POJO、配置类、启动类可以放最后。总结JaCoCo 是目前 Java 项目做代码覆盖率检测的首选工具。接入成本极低——pom.xml 加两段 execution跑mvn test就能出 HTML 报告。但工具的价值不在报告本身在于你看了报告之后做了什么补了哪些漏掉的测试、发现了哪些假覆盖、重构时有没有底气。如果你现在手上有一个 Spring Boot 项目花 10 分钟按本文配一下 JaCoCo 代码覆盖率跑一份报告出来看看——你可能会有惊喜或者惊吓。