覆盖率数字量的是源代码中可执行行被测试执行的比例，仅反映代码是否运行过，不检验逻辑分支完整性、断言合理性或函数模块是否漏测。
覆盖率数字到底在量什么
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免费学习笔记（深入）”；
