coverage report 显示 94%，打开明细发现测试代码自己贡献了 12 个点。真正被覆盖的业务类只有 82%，退款分支一次没执行。第一次遇到会往复杂处想，其实漏掉的多是个小前提。
coverage run --source=app -m pytest coverage report --omit='tests/*' --fail-under=85
统计范围把 tests 目录算了进去，测试类自己执行自己，分子被抬高。报告只看总数，没人往下翻到包级别。这一点先确认清楚，后面就不用反复试。
「覆盖率统计范围」这类改动最怕改一半，回滚脚本先准备好，再动生产。临时改动用注释写上日期和原因，过两周自己都记不清为什么这么写。
动手前把原文件复制一份带时间戳，出问题立刻换回去，比现场分析快得多。一次只改一处，改完立刻验证，几个改动叠在一起，出问题就说不清是谁导致的。
具体做法是，配置里排除 test 目录 只统计主代码；按包看覆盖率 找出低于阈值的模块；退款这类核心分支单独补 case 别靠总数交差；行覆盖和分支覆盖两个数并排看。
改完照着核一遍，总数回落到 82% 左右 退款分支补完后行覆盖和分支覆盖都过 85。