增量覆盖率是什么
增量代码覆盖率（New Code Coverage）只对本次变更新增或修改的代码统计覆盖率并设门槛：工具基于基线分支生成差异行集合，只算这些行的覆盖比例，低于门槛即失败。它解决老项目历史包袱压着新提交的问题：全库覆盖率 40% 的仓库若要求 80%，任何改动都无法推进；而「新代码必须达标」让治理从当下开始，存量随重构自然消化（SonarQube 的 Clean as You Code 就是这个思路）。常见实现有 SonarQube 的 New Code 周期、diff-cover、Codecov 的 patch 状态等，典型门槛在 80% 上下，按团队基线调整。
基本信息
| 范围 | 对比基线分支的差异行 |
|---|---|
| 工具 | SonarQube New Code、diff-cover、Codecov patch |
| 典型门槛 | 新增行覆盖率 80% 上下浮动 |
| 好处 | 存量与增量分开治理，反馈聚焦本次改动 |
| 注意 | 基线前进后差异集要重新计算 |
典型使用场景
- 老仓库治理启动：全量门槛达不到时，从增量门槛开始推进。
- 合并门禁：新增行覆盖率不达标的变更不允许合入。
- 趋势观测：全量指标看健康趋势，增量指标做日常门禁。
- 重构保护：重构改动强制被测试覆盖，防止静默行为退化。
- 评审评论：机器人把补差报告贴到合并请求里，评审时可见。
- 能力渐进：门槛按团队现状设定，达标后逐步上调。
diff-cover 示例
diff-cover 示例
coverage run -m pytest
coverage xml -o coverage.xml
diff-cover coverage.xml --compare-branch=origin/main --fail-under=80 # 新增行门槛指标口径
| 指标 | 统计对象 | 用途 |
|---|---|---|
| 全量覆盖率 | 整个代码库 | 健康趋势观测 |
| 增量覆盖率 | 变更行集合 | 合并门禁判定 |
| 补丁状态 | 平台对本次 diff 的结论 | 评审界面可见性 |
基线要对齐：目标分支前进后差异集合会变化，工具要取最新基线，否则判定结果忽严忽松。
行覆盖之外可以再要求分支覆盖：核心模块的分支覆盖能抓住被跳过的条件路径。
门槛是手段不是目的：为凑数字写的无断言测试没有价值，评审仍然要看断言质量。