测试覆盖率有什么意义？是不是越高越好？

简化版

测试覆盖率表示代码被测试执行到的比例，它能发现明显未测试区域，但不能证明代码没有 bug。覆盖率不是越高越好，关键是覆盖核心业务、边界条件和异常分支，并保证断言有效。

详细版

常见覆盖率指标包括：

• 行覆盖率：哪些代码行被执行过；
• 分支覆盖率：if/else 等分支是否都执行过；
• 函数覆盖率：哪些函数被调用过。

Python 常用 coverage.py 或 pytest-cov：

pytest --cov=app --cov-report=term-missing

覆盖率的价值：

1. 发现完全没有测试的模块；
2. 辅助团队设定质量门禁；
3. 帮助识别风险代码；
4. 防止新增代码长期无测试。

但覆盖率只能说明“执行过”，不能说明“断言正确”。没有断言的测试也能提高覆盖率。

完整版教学

一、覆盖率到底衡量什么

测试覆盖率衡量的是测试运行过程中，代码被执行到的程度。最常见的是行覆盖率：如果一个模块有 100 行可执行代码，测试跑到 80 行，行覆盖率就是 80%。

但这个指标有一个关键限制：它只关心代码有没有被执行，不关心结果有没有被正确验证。

例如：

def test_create_user():
    create_user("Tom")

这个测试可能执行了很多代码，提高了覆盖率，但没有任何断言。它没有验证用户是否真的创建成功、字段是否正确、异常是否处理。这样的覆盖率很虚。

二、行覆盖率和分支覆盖率的区别

行覆盖率只看代码行是否执行。分支覆盖率会进一步检查条件分支是否都走到。

例如：

def discount(price, vip):
    if vip:
        return price * 0.8
    return price

如果测试只覆盖 vip=True，行覆盖率可能看起来不低，但 vip=False 的分支没有验证。分支覆盖率能暴露这种问题。

复杂业务中，分支覆盖比行覆盖更有意义，因为 bug 常出现在边界和异常分支。

三、Python 项目如何查看覆盖率

Python 常用 coverage.py，pytest 项目常用 pytest-cov 插件：

pytest --cov=app --cov-report=term-missing

term-missing 会在终端展示哪些行没有覆盖。也可以生成 HTML 报告：

pytest --cov=app --cov-report=html

然后打开 htmlcov/index.html 查看每个文件覆盖情况。HTML 报告对排查遗漏分支很直观。

四、覆盖率门禁怎么设置

团队可以在 CI 中设置最低覆盖率：

pytest --cov=app --cov-fail-under=80

这表示覆盖率低于 80% 时 CI 失败。门禁能防止测试长期缺失，但阈值要合理。新项目可以逐步提高，老项目可以先对新增代码设置要求。

盲目要求 100% 容易带来形式主义。某些简单配置文件、框架胶水代码、难以稳定测试的系统边界，不一定值得强行覆盖。更重要的是核心业务逻辑、金额计算、权限判断、状态流转、数据一致性。

五、覆盖率高但质量低的情况

覆盖率可能被“刷”出来。比如测试只调用函数，不验证结果；大量 mock 掉真实逻辑；只测正常路径，不测异常路径；断言写得太宽松。

例如：

assert result is not None

如果业务要求返回具体字段，这种断言就太弱。更好的断言应该验证关键字段、状态变化、副作用和错误处理。

覆盖率报告应该和测试评审结合使用。看到覆盖率高，还要看测试是否覆盖了重要场景。

六、哪些代码优先补覆盖

优先覆盖高风险、高价值、高变化的代码。比如：

• 金额计算；
• 权限校验；
• 订单状态机；
• 数据迁移逻辑；
• 复杂解析器；
• 重要 API 的异常分支；
• 曾经出过 bug 的模块。

低风险代码可以适度放宽。例如简单 DTO、常量配置、框架入口文件，覆盖率收益有限。

七、常见误区与追问

指标	说明	局限
行覆盖率	代码行是否被执行	不知道断言是否有效
分支覆盖率	if/else 分支是否走到	仍不能证明业务正确
核心模块覆盖率	关键代码覆盖情况	需要结合风险人工判断

100 行代码执行了 85 行 -> 行覆盖率 85%
一个 if 有 True/False 两个分支，只测 True -> 分支覆盖不足
覆盖率达 90%，但没有断言关键字段 -> 质量仍然可能很低

易错点：覆盖率是雷达，不是安全证书；它告诉你哪里没跑到，不保证跑到的地方测对了。

第一个误区是把覆盖率当质量本身。覆盖率是信号，不是质量保证。

第二个误区是只看总覆盖率。总覆盖率可能掩盖关键模块没有测试。核心模块覆盖率更值得关注。

第三个误区是忽略分支覆盖。很多线上 bug 来自未覆盖的 else、异常、空数据、边界值。

第四个误区是为了达标写无意义测试。这会增加维护成本，还让团队误以为系统很安全。

• 误区：覆盖率越高代码质量一定越好。 覆盖率只能说明执行过，不能说明断言有效、场景关键或业务规则正确。
• 误区：只看项目总覆盖率。 总覆盖率可能被低风险代码拉高，核心金额、权限、订单状态机模块仍然缺测试。
• 误区：为了过门禁写空断言测试。 只调用函数、不验证结果的测试会制造虚假安全感。
• 追问：为什么分支覆盖率常比行覆盖率更有价值？ bug 常藏在 else、异常、空数据、边界分支里，行被执行不代表所有决策路径都被验证。
• 追问：覆盖率门禁设多少合适？ 常见起点如 70% 或 80%，但要结合项目历史和风险；老项目更适合先管新增代码和核心模块。
• 追问：哪些代码优先补覆盖？ 金额计算、权限判断、状态流转、数据迁移、复杂解析和曾经出过 bug 的模块优先级最高。

八、加强记忆

记覆盖率：它告诉你代码有没有被测试跑到，但不告诉你断言有没有验证对。覆盖率适合作为质量雷达和 CI 门禁，真正有价值的是覆盖核心业务、边界条件、异常分支，并写出能发现错误的断言。