Python 自动化测试覆盖率的量化指标

覆盖率数字量的是源代码中可执行行被测试执行的比例，仅反映代码是否运行过，不检验逻辑分支完整性、断言合理性或函数模块是否漏测。

覆盖率数字到底在量什么

python 测试覆盖率工具（比如 coverage.py）默认统计的是「行覆盖」——即源代码中哪些 executable line 被测试执行过。它不关心逻辑分支是否走全，也不检查断言是否合理，更不会发现漏测的函数或模块。一个 95% 的覆盖率可能只是因为所有 if 分支都进了第一层，但 elif 和 else 块压根没触发。

• coverage.py 把 def、if、for、return、赋值语句等算作可执行行；空行、注释、纯 pass 不计入分母
• 函数定义本身算一行，但函数体为空时，这行会被标记为「已覆盖」，哪怕内部逻辑完全没测
• try/except 中的 except 块只有在异常实际抛出并被捕获时才算覆盖，靠 pytest.raises 模拟还不够，得真进那个分支

怎么跑出可信的覆盖率数据

直接用 coverage run -m pytest 很常见，但容易漏掉关键配置，导致结果虚高或遗漏：

• 必须加 --source=.（或具体包名），否则 coverage 可能只扫描当前目录下非安装包的文件，跳过已安装的本地包（比如用 pip install -e . 装的）
• 避免用 python -m pytest 再套一层，会干扰 coverage 的路径追踪；坚持用 coverage run -m pytest
• 如果项目有 C 扩展或 Cython 模块，coverage.py 默认不支持，需要额外编译插件或改用 pytest-cov 并启用 --cov-branch
• .coveragerc 里建议显式写上：

  [run] source = mypackage omit = <em>/tests/</em>,<em>/test_</em>.py,<em><strong>pycache</strong></em>,<em>/venv/</em>

分支覆盖比行覆盖更值得盯住

行覆盖容易刷高，但真正暴露逻辑漏洞的是分支覆盖（branch coverage）。比如这个函数：

def is_valid(x): if x > 0: if x < 10: return "small" else: return "big" return "invalid"

行覆盖可能显示 100%，但若测试只喂了 5 和 -1，那 x > 0 and x >= 10 这个分支就永远没走。

• 启用分支覆盖：运行时加 --cov-branch 参数，或在 .coveragerc 的 [run] 段写 branch = True
• coverage report -m 输出里会多一列 Branch，数值低于行覆盖就说明有 if/while/except/finally 的某些出口没测到
• 注意：and/or 短路逻辑不算独立分支，coverage.py 目前不支持 MC/DC 级别覆盖

CI 里设阈值要防「假达标」

在 github Actions 或 gitlab CI 里加 coverage report --fail-under=80 看似稳妥，但实际容易绕过：

• 没排除生成代码（如 proto 文件编译出的 _pb2.py）会导致分母虚大，拉低百分比，反而让团队去补无意义的测试
• 单测和集成测试混跑时，如果集成测试启动慢、失败率高，可能被跳过，但覆盖率仍按成功部分计算
• 更可靠的做法是：用 coverage xml 输出 cobertura.xml，再由 CI 工具解析，同时配合 coverage debug sys 定期抽检路径是否真包含目标模块

覆盖率不是质量担保书，它只回答「代码有没有被执行过」。真正难的是设计能掀开边界条件、状态组合和时序问题的测试用例——而这些，数字根本不会告诉你。

立即学习“Python免费学习笔记（深入）”；