发布质量检查要回答的是一个很具体的问题：这一次发布，是否允许放行。它围绕本次发布包含的变更，先确定要守住的质量目标，再把缺陷、测试执行、回归覆盖、变更影响等指标落到明确的分子、分母、时间窗和单位上，用阈值与证据逐项核对，最后记录例外和风险接受人。本文给出可直接套用的指标口径、取数规则、执行步骤和一个带计算的示例，并说明结论的适用边界。
要点总览（TL;DR）
- 发布质量检查只回答一个问题：这一次发布是否允许放行，结论分为允许、有条件允许、不允许三种，不替代组织级阶段评审和测试完成判断。
- 指标宜少而准，覆盖缺陷、测试执行、变更影响三类；每个指标写清分子、分母、时间窗和单位，缺陷密度要固定分母类型，通过率与执行率的分母不能互换。
- 取数来源覆盖缺陷库、测试执行记录和变更清单，三处数据通过同一发布标识关联；分母为零标记为不适用，数据缺失单列并说明补齐计划。
- 执行按四步推进：冻结变更清单、按口径取数核对、对照放行条件逐项判定、记录例外与风险接受人并签署结论。
- 检查通过不等于没有风险，指标达标与线上质量之间没有因果保证，阈值需按发布类型分档并定期回顾。
这次发布要检查到什么程度
发布质量检查的对象是某一次具体发布，以及这次发布所包含的全部变更。检查的产出是一个放行判断，通常落在三种结论之一：允许放行、有条件允许（附带必须完成的动作或监控要求）、不允许放行。判断依据是本次发布相对既定放行条件的满足情况，而不是团队整体质量水平。
把范围界定清楚，能避免检查被拉长成一次全面质量评估。建议在检查开始前写下一段范围说明，包含四项内容：
- 发布标识：版本号或发布单编号，以及计划上线时间窗。
- 变更清单：本次发布包含的需求、缺陷修复、配置变更、依赖升级，逐项列出并标注影响模块。
- 质量目标：本次发布重点守住什么，例如核心交易链路无严重缺陷、关键回归用例全部通过、数据库变更已回滚验证。
- 结论形式：明确输出允许、有条件允许或不允许，并写明条件与接受人。
需要区分三类容易混淆的判断。组织级阶段评审决定项目是否进入下一阶段，关注范围、资源与里程碑；测试完成判断回答测试工作是否做完、测试报告是否可出；发布质量检查只回答本次发布是否允许上线。三者可以共享数据，但结论各自独立，不能用一次检查替代阶段决策，也不能把测试报告结论直接当作放行结论。
检查哪些指标，各自怎么算
指标宜少而准。一次发布质量检查通常覆盖三类：缺陷、测试执行、变更影响。每类选一到两个指标，写清分子、分母、时间窗和单位，指标才有复算价值。以下口径可直接作为模板，阈值一列留空，由团队按发布类型填写。
| 指标 | 分子 | 分母 | 时间窗 | 单位 | 用途 |
|---|---|---|---|---|---|
| 严重缺陷未关闭数 | 本次发布范围内、严重级别为致命或严重、状态非已关闭的缺陷数 | 无（计数指标） | 截至放行评审时点 | 个 | 判断是否存在阻断性缺陷 |
| 缺陷密度 | 统计期内本次发布相关模块新发现的缺陷数 | 同期该模块的变更规模（如千行代码变更、需求点数，二选一并固定） | 本次发布开发启动至放行评审 | 个/千行 或 个/需求点 | 观察缺陷相对变更量的集中程度 |
| 计划用例执行率 | 本次发布计划用例中已执行的数量 | 本次发布计划用例总数 | 截至放行评审时点 | 百分比 | 确认测试是否按计划铺开 |
| 用例通过率 | 已执行用例中结果为通过的数量 | 已执行用例总数（非计划总数） | 截至放行评审时点 | 百分比 | 观察执行部分的通过情况 |
| 回归覆盖率 | 本次发布受影响模块中已纳入并执行的回归用例数 | 受影响模块应覆盖的回归用例总数 | 本次发布回归测试期 | 百分比 | 确认变更影响面是否被验证 |
| 变更影响面 | 本次发布涉及的服务或模块数 | 无（计数指标） | 本次发布 | 个 | 决定检查深度与回归范围 |
口径中有几个容易出错的地方。缺陷密度必须固定分母类型，同一组织内混用代码行和需求点会让数据不可比；用例通过率的分母是已执行数，与执行率的分母是计划数，两者不能互换；回归覆盖率的分母只统计受影响模块，把全量回归用例都算进来会稀释结果。时间窗要写成具体起止点，例如“开发启动至放行评审时点”，而不是“近期”。
阈值不设通用达标线。面向内部用户的管理后台小版本，与面向外部客户的支付链路发布，可接受的严重缺陷数和回归覆盖要求本就不同。建议按发布类型分档设定，并在每次检查时记录所用档位，便于后续复盘时对照。
数据从哪里取，证据怎么留
取数来源应覆盖三处：缺陷库提供缺陷数量、级别与状态；测试执行记录提供计划用例、执行结果与执行时间；变更清单提供本次发布的范围与受影响模块。三处数据要能通过同一个发布标识关联起来，否则指标之间无法互相印证。
证据形式以可复核为准。常用做法包括：缺陷查询条件的截图或导出报表、测试执行汇总导出、变更清单评审记录、放行结论的签署记录。留存时同时记录取数时间与查询条件，因为缺陷状态会随修复变化，同一指标在不同时点取数结果可能不同。检查结论应绑定取数时点，避免事后争议。
缺失值和分母为零要单独处理，不能默认按零或满分计算：
- 分母为零：例如本次发布未涉及某模块，该模块回归覆盖率的分母为 0。此时该指标标记为“不适用”，不参与判定，并在结论中说明原因。
- 数据缺失：例如部分用例未录入执行结果。应把缺失数量单列，说明缺失原因与补齐计划；若缺失比例影响判定，结论按“有条件允许”处理，附补齐时限。
- 数据不可比：发布规模、变更类型差异较大时，缺陷密度等相对指标不宜直接横向比较。应在记录中注明分母类型、统计时间窗与发布类型，跨发布比较只作趋势参考。
按什么步骤完成一次检查
一次检查通常在两到四小时内可以完成，前提是数据已在日常工作中记录。按以下四步推进，每步都有明确产物。
- 确认发布范围与变更清单。从发布单取出本次发布的全部变更，逐项标注影响模块与变更类型（新功能、缺陷修复、配置、依赖升级）。产物是一份冻结的变更清单，作为后续取数的边界。
- 按口径取数并核对。依据上一节的指标表逐项取数，记录查询条件与取数时间。核对重点是分母是否与变更清单一致，例如计划用例是否覆盖了全部受影响模块。
- 对照放行条件逐项判定。把每个指标的实际值与本次发布适用的阈值比对，标记通过、不通过或不适用。对不通过项，判断是否属于可附带条件放行的情形。
- 记录例外、风险接受人与结论。写明例外内容、接受人、补偿措施（如灰度范围、监控加强、回滚预案）与验证时点，最后给出允许、有条件允许或不允许的结论并签署。
在工具层面，检查过程需要把缺陷、测试执行与变更记录归集到同一个发布对象上，才能保证取数边界清晰、证据可追溯。ONES 支持将缺陷、测试用例执行记录与需求、迭代等工作项关联，团队可以围绕一次发布建立对应的工作项或版本视图，把检查所需的记录集中在一处，减少跨系统核对。具体字段与视图配置以团队实际使用为准。
一个完整示例：这次发布能否放行
以下为演示情景，数据为虚构，用于说明计算与判定过程。
某内部管理系统发布 v3.4，变更清单包含 3 个新功能需求、5 个缺陷修复、1 次数据库字段变更，涉及订单、结算两个模块。放行条件按“内部系统常规版本”档位设定：严重缺陷未关闭数为 0；计划用例执行率不低于 95%；用例通过率不低于 90%；受影响模块回归覆盖率 100%。
取数结果与计算：
- 严重缺陷未关闭数：缺陷库中本次发布范围内致命或严重且未关闭的缺陷为 1 个，指标不通过。
- 计划用例执行率：计划用例 120 条，已执行 114 条，执行率 114 ÷ 120 = 95.0%，达到阈值；未执行的 6 条集中在结算模块的边界场景。
- 用例通过率：已执行 114 条中通过 105 条，通过率 105 ÷ 114 ≈ 92.1%，达到阈值；未通过的 9 条中 7 条为一般缺陷，2 条为界面文案问题。
- 回归覆盖率：受影响模块为订单、结算，应覆盖回归用例 80 条，已执行 74 条，覆盖率 74 ÷ 80 = 92.5%，未达 100%。
- 变更影响面：涉及 2 个模块、1 次数据库字段变更，字段变更已完成回滚脚本验证。
判定过程：严重缺陷未关闭数为 1，属于阻断项，按条件应判不允许。检查中发现该缺陷影响结算模块的对账导出，修复已完成待验证，验证用例恰在未执行的 6 条之中。经发布负责人与质量负责人确认，采取有条件允许：将发布范围限制为订单模块先行上线，结算模块延后至缺陷验证通过且剩余 6 条用例执行完毕后再放行；同时约定上线后 24 小时内对账导出功能每两小时抽查一次。风险接受人记录为发布负责人，补偿措施与验证时点写入结论。
这个示例说明两点：分母为零或指标不适用时要在结论中说明，本例中无此类情况；单项不通过不一定直接否决整次发布，但必须有明确的限制范围、接受人和补偿措施，且不能把“有条件允许”写成“通过”。
结论怎么解读，有哪些限制
检查通过只表示本次发布在既定指标和证据下满足放行条件，不表示没有风险。指标覆盖的是可度量部分，配置错误、环境差异、并发压力下的问题可能不在检查范围内。放行后仍应按计划观察关键指标，保留回滚预案。
指标达标与线上质量之间没有因果保证。缺陷密度低可能源于测试覆盖不足，用例通过率高可能因为用例本身偏简单。检查结论应结合变更影响面、历史缺陷分布和线上监控数据一起看，避免把单次检查结果当作质量结论或团队绩效依据。
阈值需要随发布类型调整。紧急修复、配置类变更与大型功能版本的检查深度不同，照搬同一套阈值会让检查要么形同虚设，要么阻碍正常交付。建议每季度回顾一次阈值与实际线上问题的对应情况，按发布类型分别修订。
检查记录的价值主要在复盘。每次检查留下的取数条件、例外内容与风险接受记录，可以在发布后问题复盘时回溯判断依据，也能为下一版阈值调整提供依据。把检查记录当作改进输入，比把它当作一次性审批材料更有用。
常见问题
发布质量检查和组织级阶段评审、测试报告结论有什么区别？
三者回答的问题不同。发布质量检查的对象是某一次具体发布及其包含的变更，结论只回答这次发布是否允许上线；组织级阶段评审决定项目是否进入下一阶段，关注范围、资源与里程碑；测试完成判断回答测试工作是否做完、测试报告能否出具。
三者可以共享缺陷、用例执行等数据，但结论各自独立。实际操作中常见两种误用：用一次发布检查替代阶段决策，或者把测试报告结论直接当作放行结论。建议在检查开始前就写明本次检查只输出放行判断，避免范围被拉长。
本次发布没有涉及某个模块，回归覆盖率的分母为零，这项指标怎么处理？
分母为零时，该指标标记为“不适用”，不参与放行判定，并在结论中说明原因，例如“本次发布未涉及支付模块，该模块回归覆盖率不适用”。
需要避免两种做法：把不适用按 0% 计算，导致结论被误判为不通过；或者按 100% 计算，让检查看起来全部达标。如果多个指标同时不适用，应在结论里列出不适用的指标清单，让阅读结论的人知道本次检查实际覆盖了哪些方面。
部分用例没有录入执行结果，数据缺失时还能给出放行结论吗？
可以给出结论，但要把缺失情况写清楚。建议把缺失用例数量单列，说明缺失原因与补齐计划。如果缺失比例不影响关键判定，可在结论中注明缺失范围后正常判定；如果缺失集中在受影响模块或关键链路，影响了对测试执行情况的判断，结论宜按“有条件允许”处理，并附上补齐时限和验证时点。
无论哪种情况，都不要把缺失数据默认当作通过，也不要在记录中省略缺失数量，否则复盘时无法还原当时的判断依据。
严重缺陷未关闭数为 1，是否一定不允许放行？
不一定，但需要有明确的限制和接受机制。严重缺陷通常被设为阻断项，出现未关闭的严重缺陷时，默认判定为不允许。如果缺陷修复已完成待验证，且影响范围可以隔离，可以采取有条件允许：缩小发布范围，把受影响模块延后放行，同时约定补偿措施（如灰度范围、监控加强、回滚预案）和验证时点，并记录风险接受人。
关键是不能把“有条件允许”写成“通过”。结论中要写明限制范围、接受人和补偿措施，后续按约定时点验证并补充记录。
不同发布之间缺陷密度差异很大，能直接横向比较吗？
不宜直接比较。缺陷密度是相对指标，受分母类型、统计时间窗和发布类型影响。同一组织内混用代码行和需求点作分母，数据就失去可比性；紧急修复版本与大型功能版本的变更规模差异大，密度高低也不能直接说明质量好坏。
跨发布比较只作趋势参考，比较时需同时注明分母类型、统计时间窗和发布类型。如果确实需要横向对比，先统一口径，再在相同发布类型内部比较。
