覆盖率、测试金字塔与 CI 门禁：哪些证据足以阻止发布

高谷深陵大约 10 分钟约 2939 字

覆盖率、测试金字塔与 CI 门禁：哪些证据足以阻止发布高清原图

从覆盖率局限、Mutation、测试组合、反馈预算、变更选择和发布阻断建立可运营验证体系。

JaCoCo 的官方文档定义指令、分支与复杂度计数；PIT 的 Mutation Testing 用变异存活检查断言敏感度，但两者都不能单独证明业务正确。

覆盖率只回答代码是否被执行

行覆盖 100% 的测试可以没有任何断言；分支覆盖经过 true/false，也可能没验证副作用；低覆盖则明确提示大量路径完全没有证据。覆盖适合发现空白和观察趋势，不适合用一个全局 80% 判断发布。Generated code、DTO 和核心结算的风险完全不同。

门禁同时看新代码与整体趋势，防止大仓库历史覆盖稀释新变更。关键不变量直接映射测试清单：权限拒绝、事务回滚、重复消息、Schema 兼容、迁移回滚。即使覆盖率达标，缺少关键契约也必须阻断。

Mutation 检查测试是否会对错误敏感

变异工具替换条件、返回值或算术，若测试仍绿，说明断言、输入或可达性不足。Mutation score 比行覆盖更接近测试敏感度，但等价变异、性能成本和工具支持决定它适合核心模块或增量运行，不应全仓每次执行。

存活变异先判断代码不可达、测试缺边界还是变异等价，再补最小业务断言。为杀变异而验证私有实现同样会制造脆弱测试。变异结果按模块、规则和风险解释，不把数字竞赛当质量。

金字塔是反馈结构而不是固定比例

大量快速单元证明规则，较少组件/集成证明装配和真实协议，契约证明跨服务兼容，少量端到端证明关键旅程。消息、数据库驱动系统可能需要更多集成；复杂纯算法需要更多性质测试。合理组合由失败成本与替身可信度决定，不是照搬 70/20/10。

每层设置反馈预算：提交前秒级，PR 在数分钟，合并后扩展套件，发布前环境验证。慢测试先按耗时、独特证据和失败率分析；重复覆盖同一行为且成本高的用例可下沉或删除，独有高风险证据不能因慢而取消。

CI 门禁必须可解释且不可绕过

门禁输入包括编译、静态检查、单元、集成、契约、迁移、安全、覆盖变化、Mutation 和 flaky 状态。每个失败显示 owner、证据、日志与重跑入口；允许重试时仍记录首次失败，不能用三次取一次绿掩盖随机性。

按变更路径选择测试能提速，但选择器本身也要验证依赖图和漏测率。共享库、构建配置、数据库 migration 与契约变化通常扩大范围；夜间全量套件检测选择器遗漏。紧急旁路需要审批、范围、到期、补跑和回滚条件，不能让“管理员点一下”成为常态。

发布结论来自证据矩阵

EvidenceGateDemo 中行覆盖很高，但 Mutation 与关键契约缺失，仍拒绝发布。团队为每类变更定义最低证据：纯规则需边界与 Mutation，Repository 需真实数据库，API 需契约回放，消息消费者需重复/乱序，安全策略需拒绝路径。

门禁治理观察失败原因、平均修复时间、逃逸缺陷对应的缺失测试层、套件反馈时间和 flaky 比率。每次生产缺陷反向补一条最小回归证据并更新矩阵，测试体系才随系统演进。

风险矩阵把代码变化映射到证据

规则变化要求边界/性质和 Mutation；SQL/migration 要求目标数据库与回滚；API Schema 要求消费者契约和提供者回放；消息处理要求重复/乱序/失败窗口；安全策略要求允许与拒绝；线程同步要求固定交错和放大搜索。变更分类来自依赖图、文件路径与显式标签，并允许评审者提升风险级别。

选择执行若漏掉测试，夜间全量或生产缺陷要反向标记依赖边，计算 selector recall。只宣传节省多少分钟而不测漏选率，会把速度优化变成未知风险。构建脚本、共享 Fixture、BOM 和测试框架升级默认触发广泛套件。

覆盖数据也会失真

多模块合并遗漏 exec 文件、fork JVM 未采集、动态代理与生成类重复计数、仅运行部分测试却发布全量报告，都会制造假数字。报告关联精确 commit 和已执行 test plan，合并前检查 class id 一致。排除规则只针对生成或不可行动代码并入库审查，不能按低覆盖包随意排除。

Diff coverage 防止新代码借历史高覆盖过关，但重构移动行会产生噪声。关键模块同时看分支、复杂度和未覆盖路径，抽样阅读断言质量。覆盖率下降门禁允许有理由例外，但关键证据缺失不允许用整体数字补偿。

门禁本身需要高可用与降级策略

测试平台、契约 Broker、镜像仓库或覆盖服务故障时，区分可重试基础设施与不可验证。没有验证结果不能等价为通过；低风险文档变更可按策略继续，高风险代码保持阻断或使用受控离线证据。旁路审批记录精确检查、commit、期限和补跑结果。

门禁时延超过开发反馈预算时，先优化缓存、并行、测试选择和重复证据，不把关键层永久移到无人看的夜间。夜间失败要自动关联引入提交并阻止继续发布，否则延迟反馈等于无门禁；补跑结果必须回写原始发布记录并形成可追溯证据。

先写证明对象，再选择测试层

测试替身越多，速度越快但与真实运行的距离越大；真实依赖越多，协议证据越强但状态和资源更难隔离。组合策略应让同一高风险结论至少由两种不同失败模式的证据支持，例如单元验证版本条件，真实数据库验证条件更新确实只影响一行。

失败必须保存成可重放状态

失败包至少包含测试 id、代码提交、依赖版本、seed、时钟、Locale、执行顺序、资源标识、容器日志、线程信息和业务见证。结果未知与产品断言失败分开统计；基础设施掉线不能自动归为产品缺陷，产品超时也不能全部甩给 CI。

可维护测试也需要性能、数据和安全边界

套件容量模型包含用例数、上下文/容器启动、数据初始化、并发 worker、日志与制品体积。并行度超过数据库连接、CPU 或容器资源只会增加尾延迟和 flaky；先量测各阶段临界路径，再决定共享、分片或下沉。

演进遵循“读取端先兼容、写入端后切换、旧证据归零再删除”。框架升级先固定当前发现数、执行顺序、上下文 key 和报告格式，再迁移版本；不能把升级造成的少跑测试误当提速。

用两个 Java 17 模型固定测试见证

模型不依赖测试框架或外部服务，只把边界输入、状态转换和期望见证压成确定输出；真实项目再用 JUnit、Mockito、Spring、容器或 WireMock 驱动同一不变量。

javac --release 17 -Xlint:all -Werror examples/backend-development/testing/coverage-pyramid-ci/EvidenceGateDemo.java examples/backend-development/testing/coverage-pyramid-ci/PyramidBudgetDemo.java
java -cp examples/backend-development/testing/coverage-pyramid-ci EvidenceGateDemo
java -cp examples/backend-development/testing/coverage-pyramid-ci PyramidBudgetDemo

lineCoverage=92 mutationScore=61 criticalContract=false releaseAllowed=false reasons=[MUTATION, CONTRACT]
unit=1200 component=180 integration=40 contract=25 e2e=8 feedbackSeconds=420 budgetMet=true

实际测试若改变输出，必须解释是业务规格、测试层、Fixture、调度还是门禁发生变化；禁止用放宽断言或无限重试吸收差异。