一个团队自豪地报告了 95% 的代码覆盖率，然后在“覆盖”的行中发布了一个错误。这并不矛盾。覆盖率回答了一个狭隘的问题：测试是否执行了这段代码？他们是否检查结果完全是另一个问题。

我们使用带有coverage.py 7.17 和pytest 9.2 的Python。下面的每个数字和报告均来自我们自己的运行。这些想法适用于任何语言。

什么是代码覆盖率？

代码覆盖率是自动化测试运行时运行的代码的百分比。工具记录执行了哪些行，以及（可选）执行了哪些分支，然后报告遗漏的内容。

反向时最有用。某个区域的低覆盖率可以肯定地告诉您，测试没有发挥作用。高覆盖率告诉您的信息要少得多。

承保类型

每个级别都比其上一级更严格。大多数团队都会跟踪线路和分支覆盖范围。条件覆盖和 MC/DC 出现在航空和汽车标准中，其中工具支持是专门化的。

我们测量的代码

def shipping_fee(total, is_member, express=False):
    if total < 0:
        raise ValueError("total cannot be negative")
    fee = 0 if total >= 1000 else 50
    if is_member:
        fee = max(fee - 25, 0)
    if express:
        fee += 100
    return fee

我们的第一个测试文件有两个测试：

def test_regular_order():
    assert shipping_fee(500, False) == 50

def test_member_express():
    assert shipping_fee(500, True, express=True) == 125

我们在打开分支测量的情况下运行它：

coverage run --branch -m pytest test_shipping.py
coverage report -m

阅读报告

Name          Stmts   Miss Branch BrPart  Cover   Missing
---------------------------------------------------------
shipping.py       9      1      6      1    87%   3

• Stmts 9，Miss 1： 九个可执行语句，其中一个从未运行过。
• Branch 6，BrPart 1： 三个 if 决策给出了六种可能的结果。一项决定只能以一种方式进行。
• 缺少 3： 第 3 行，即 raise ValueError，从未运行过。没有测试通过负总数。

该修复是对错误路径的测试。我们还添加了针对大订单的测试：

def test_free_over_1000():
    assert shipping_fee(1000, False) == 0

def test_negative_total():
    with pytest.raises(ValueError):
        shipping_fee(-1, False)

对于这两个文件，报告显示 100%，并且没有丢失行或部分分支。错误路径是经典的间隙覆盖发现，这就是为什么使用 等价分区 等技术设计的无效输入测试与它配合得很好。

报告隐藏了什么

再看一下第一份报告。据说只有3号线缺失。但前两次测试总共使用了 500 个，因此 1000 个或以上订单的免费送货规则是从未测试过，报告也没有标记它。

原因是 fee = 0 if total >= 1000 else 50 位于一行。 coverage.py 测量行之间的分支，因此单行内的条件表达式算作一个执行的语句。如果该规则存在错误，例如 > 而不是 >=，则第一组仍会显示 87%，而没有任何提示。正如边界值分析中所述，边界本身的测试可以捕获它。

100% 覆盖，无需检查

接下来，我们故意编写了一个糟糕的测试，它调用每个路径但不声明任何内容：

def test_runs_everything_but_checks_nothing():
    shipping_fee(500, True, express=True)
    shipping_fee(1000, False)
    shipping_fee(500, False)
    try:
        shipping_fee(-1, False)
    except ValueError:
        pass

shipping.py       9      0      6      0   100%

达到了100%的线路和分支覆盖率。该函数可以返回任何数字，并且该测试仍然会通过。这是覆盖范围的核心限制：它衡量执行，而不是验证。

要衡量测试是否真正捕获错误，请使用突变测试。 Python 的 mutmut、Java 的 PIT 或 JavaScript 的 Stryker 等工具会对代码进行一些小更改，例如将 >= 翻转为 >，并检查测试是否失败。我们的无断言测试会让每个突变都存活下来。

设定什么目标

没有普遍正确的数字。实用指导：

• 不要追求 100%。 最后几个百分点通常意味着测试琐碎的代码或编写仅接触行的测试。
• 许多团队的总体目标是大约 70% 到 85%，对核心业务逻辑有更高的期望。
• 关注趋势，而不是数字。 每次发布的覆盖率下降是一个警告信号。
• 要求在拉取请求中覆盖新代码，而不是强制一次全部更新旧代码。
• 排除无关紧要的内容，例如生成的代码，具有明确的规则。

古德哈特定律适用：当一项措施成为目标时，它就不再是一个好的措施。硬目标鼓励像我们的无断言示例这样的测试。

按语言分类的工具

CI 的覆盖范围

将覆盖率作为 CI 管道 的一部分运行，并发布报告，以便审阅者可以查看哪些新行未经测试。对于coverage.py，coverage report --fail-under=80 构建失败低于阈值。保持适度的阈值并将其与新代码的规则结合起来，这样单个大型旧文件就不会阻止每个更改。

超出覆盖范围：要问更好的问题

• 测试是否涵盖了代码中存在风险、经常更改的部分？
• 是否测试了边界和错误路径，而不仅仅是快乐路径？
• 如果这条线错误，测试会失败吗？
• 测试是否足够快速和稳定，可以在每次更改时运行？

这些属于任何测试策略。报道只能帮助回答第一个问题。

排除代码并阅读 HTML 报告

有些代码不值得直接测试，例如调试助手或仅在手动启动脚本时运行的块。 coverage.py 允许您排除带注释的行：

if __name__ == "__main__":  # pragma: no cover
    main()

您还可以在配置中设置要测量的排除项和源文件夹，例如在 pyproject.toml 中：

[tool.coverage.run]
branch = true
source = ["shop"]

[tool.coverage.report]
show_missing = true
exclude_also = ["if TYPE_CHECKING:"]

谨慎使用排除项并像检查代码一样检查它们。每一个都是一个决定，有些行永远不会被检查。仅仅为了提高数字而排除难以测试的错误处理程序就达不到目的。

对于日常工作，HTML 报告比终端表更有用。运行 coverage html 并打开 htmlcov/index.html。每个文件都以绿色显示已执行的行，以红色显示错过的行，以黄色显示部分分支，因此您可以一目了然地看到哪个 if 从未采取其他路径。许多编辑器还可以在页边空白处显示覆盖范围，这使得在您编写代码时（而不是之后）可以看到间隙。

重构前的覆盖率

覆盖率也是重构前的安全检查。如果您打算重组模块，请先查看其报告。红色区域没有测试来警告您行为是否发生变化，因此在开始之前添加捕获当前行为的特征测试。通过这种方式，覆盖范围不再是一个目标，而是成为一个实用的规划工具。

当错误逃逸到生产环境时，相同的报告会有所帮助。找到错误所在的行并检查是否有任何测试运行了它。如果没有，您就发现了一个值得弥补的差距。如果测试确实运行了它，则问题是弱断言，这正是我们的无断言示例所显示的情况。这两个答案都告诉您如何改进套件。

最后的话

代码覆盖率是一个手电筒，而不是一个等级。使用分支覆盖率来查找没有测试涉及的代码，尤其是错误处理，然后编写做出真正断言的测试。如果您还记得我们运行的一个结果，请将其设为这个：通过一项未检查任何内容的测试达到 100% 的覆盖率。

常见问题

继续学习