测试覆盖率低于80%怎么办

测试 覆盖率低于80%怎么办

项目上线前跑完一轮自动化测试，结果报告弹出一行红字：「测试覆盖率 72%」。团队一下子安静了。有人开始翻测试用例，有人盯着 CI/CD 流水线发呆。这种情况太常见了，尤其在迭代快、需求多的项目里，测试往往被压缩成“能跑就行”。

但覆盖率掉到 80% 以下，风险就藏不住了。不是说非得卡死 80% 这条线，而是它像一个警报灯——说明有相当一部分代码长期没人碰、没人验，万一出问题，排查成本会很高。

打开覆盖率报告，通常能看到按文件或模块划分的明细。你会发现，有些核心业务逻辑可能覆盖得很好，反而是工具类、异常处理分支、边界条件这些地方一片红色。比如一个数据备份工具里的压缩模块，正常流程测了，但磁盘满、权限不足、路径不存在这些异常场景压根没写断言。

这时候不要一上来就让所有人补测试，先分类。把低覆盖的文件分成三类：一类是关键路径但漏测的，必须优先补；一类是历史遗留、已经没人维护的冷代码，可以标记为待下线；还有一类是第三方封装或配置相关，其实不需要测。

与其全盘重写测试，不如结合最近的提交记录。哪个文件最近改得多，就在提 PR 时强制要求补齐对应测试。比如上周刚修了一个备份失败重试三次的 bug，那就趁热打铁，把这块的单元测试和集成测试补上，确保类似问题不会再冒出来。

这种“借势补测”的方式阻力小，开发也愿意配合，毕竟改代码的时候顺手加几行测试，比隔一个月再回头啃旧逻辑轻松多了。

光靠提醒没用，得上机制。在 CI 流程里加一条规则：如果新增代码的测试覆盖率低于 85%，直接拒绝合并。可以用 Jest、JaCoCo 或者 Istanbul 配合 CI 工具实现。

jest --coverage --coverage-threshold '{
  "global": {
    "statements": 85,
    "branches": 85,
    "functions": 85,
    "lines": 85
  }
}'

这样新代码不会继续拉低整体水平，老代码可以慢慢还债，而不是一边补一边破。

有时候覆盖率低，是因为测试太难写。比如一个备份服务强依赖外部存储接口，每次测都要起 mock，写五段 setup 才能进正题。开发者自然绕着走。

这时候不如重构一下代码结构，把可测性提上去。比如把网络请求抽成独立函数，把配置项注入出去，测试时直接替换。甚至可以在关键路径埋点，方便断言执行流程。

测试写得顺了，覆盖率自然就上来了。不是靠压指标，而是让写测试变得比跳过它还简单。

建议每个月跑一次全量覆盖率分析，导出长期低于 60% 的文件清单，组织一次小型“清扫行动”。几个人花半天时间集中攻坚，顺便理清这些模块的设计意图。有些可能是废弃功能，删掉反而更安全。