行覆盖与分支覆盖
覆盖率回答的是哪些代码在测试中被执行过：行覆盖粗，分支覆盖细，路径覆盖成本更高。覆盖率高不代表测试好——可能缺少断言；覆盖率低也未必危险——生成代码与简单转发本来就少测。正确用法是发现未被测试触及的区域，而不是当作质量评分。
基本信息
| 口径层次 | 行覆盖、分支覆盖、路径覆盖（成本递增） |
|---|---|
| 常用工具 | JaCoCo、Istanbul、coverage.py、Go 内置覆盖 |
| 正确用法 | 看未覆盖区域找风险，而不是追数字 |
| 常见约束 | 新代码覆盖率设下限，存量只看趋势 |
| 固有局限 | 覆盖只说明执行过，不说明验证过 |
典型使用场景
- 提交前确认新分支是否都有用例覆盖
- 识别长期无人测试的核心模块
- 用补丁覆盖率约束新代码质量
- 重构前确认目标区域的测试覆盖情况
- 评估测试补写工作的优先级
常用命令
常用命令
go test ./... -coverprofile=cover.out # 生成覆盖率数据
go tool cover -html=cover.out -o cover.html # 可视化查看未覆盖行
# Java 项目常用 JaCoCo：构建时生成报告，按包与类看行覆盖与分支覆盖
# JavaScript 常用 Istanbul / c8：关注分支与函数覆盖率口径与含义
| 口径 | 含义 | 成本 |
|---|---|---|
| 行覆盖 | 每行是否被执行 | 低，最常用 |
| 分支覆盖 | 条件的每个分支是否走到 | 中，更有意义 |
| 路径覆盖 | 组合路径是否全部走到 | 高，通常不完全追求 |
常见做法是给新代码设覆盖率下限（例如补丁覆盖率要求），存量整体数字只做趋势观察，避免为了达标写空壳测试。
拿整体覆盖率考核团队，数字一定会被灌水：只调用不校验、删掉断言都能提高数字，最后指标上升而缺陷率不变。
覆盖数据要按模块看：整体数字掩盖局部差异，核心计费或权限模块零覆盖，比边缘脚本缺少用例危险得多；报告建议按目录与包分层呈现。