编写测试代码时，不知不觉就会开始执着于覆盖率数字。
“既然都做了，就应该补到 100%”的心情，我非常理解。
先说结论，**代码覆盖率保持在 70%～80% 是实践中最现实的目标，100% 并不等于代码没有 bug。**下面结合我的经验说明原因。
先看核心总结
为了方便忙碌的读者，先整理本文结论。
- 覆盖率 100% 只表示“每一行都执行过”，并不表示“所有情况都经过验证”。
- 实践中的建议值通常在 70%～80% 左右。
- 对于支付、身份验证等重要核心逻辑，可以争取达到 90% 以上。
- 比起数字，更重要的是知道“哪些内容还没有测试”。
代码覆盖率 100% 就没有 bug 了吗？
这是最常见的误解。
覆盖率 100% 只表示测试“至少执行过代码中的每一行一次”。
这并不表示已经验证每一行是否正确运行。
举个例子。下面的函数就是测试只执行代码，却没有正确检查结果的情况。
func divide(_ a: Double, _ b: Double) -> Double {
return a / b // b如果是 0？测试会执行，但
}
// 这个测试有覆盖率 100%，但
@Test func divide_只执行_代码() {
_ = divide(10, 2) // 不验证返回值(#expect)!
}这段代码达到了 100% 覆盖率。
但由于没有通过 #expect确认结果，实际上什么也保证不了。
覆盖率衡量的是“执行了多少”，而不是“验证得有多好”。
这正是不能只看数字就放心的原因。
那么多少百分比才合适？
我把辗转多个团队后感受到的现实标准整理成了表格。（截至 2026 年的一般实践建议值）
| 代码区域 | 建议覆盖率 | 原因 |
|---|---|---|
| 核心业务逻辑 | 90% 以上 | 支付、身份验证等出错时后果严重 |
| 一般服务代码 | 70~80% | 成本效益最好的区间 |
| UI・视图层 | 50~60% | 变更频繁，测试维护成本高 |
| 自动生成・配置文件 | 排除测量 | 测试意义较小 |
Google 也曾公开表示，在内部将 60% 视为“可接受水平”、75% 视为“建议值”、90% 视为“最佳实践”。
虽然没有绝对正确的答案，但可以把 80% 左右视为大多数团队合理的目标。
为什么坚持 100% 反而会吃亏？
补齐最后 20% 所需的努力，远远大于补齐前 80%。
如果要测试所有异常处理、难以到达的分支和防御性代码，所需时间会呈指数增长。
更大的问题还在后面。
为了填满数字，会出现专门用来“展示”的测试。
不进行实际验证、只提高覆盖率的测试，之后修改代码时只会成为阻碍。
每次重构都要花时间修复没有意义的测试。
常见问题（Q&A）
问：那么，测量覆盖率本身没有意义吗？
不是。覆盖率非常适合用来找出“测试完全没有触及的区域”。
不要把数字当成目标，而要利用覆盖率报告检查红色部分（未执行代码）。
问：可以在 CI 中强制设置覆盖率标准吗？
可以，但建议采用“新代码至少达到 80%”这样的方式。
如果对全部代码统一设置较高标准，团队会因为既有代码而疲惫不堪。
问：覆盖率好像有好几种？
除了行覆盖率，还建议同时查看分支覆盖率。
因为 if/else 等条件分支是否经过充分测试，更接近实际质量。
不要被数字牵着走，先问问自己：“这个测试真的在保护什么吗？”
覆盖率 80% 但扎实的测试，比覆盖率 100% 却空洞的测试可靠得多。希望你今天也能写出优秀的测试代码！