发布审批要回答的问题很具体：这个版本现在能不能发。要让判断站得住，审批单上需要同时挂接测试结果摘要、风险清单和回滚方案三类材料，审批人按事先约定的规则逐项核对，再给出放行、有条件放行或暂缓的结论。本文给出三类材料的字段、五步操作流程、角色分工、判定规则和完成检查清单，可直接用于搭建或修订团队的发布门禁。
要点总览（TL;DR）
- 发布审批单固定挂接三类材料：测试结果摘要（通过率、未关闭缺陷分布、关键路径结论、遗留问题说明）、风险清单（描述、等级、触发条件、影响范围、应对措施与责任人）、回滚方案（触发条件、步骤与责任人、数据与配置处置、回滚后验证）。
- 审批按五步走：提交申请并附测试结果、填写风险清单并写明定级依据、提交回滚方案并确认可执行、审批人按规则核对给出结论、记录决策依据并在发布后回填结果。
- 判定规则把三类输入组合成放行、有条件放行、暂缓三种结论；阈值事先约定，审批时只核对，不临时改口径。
- 有条件放行的附加条件要写成可执行动作，如限定发布窗口、缩小灰度范围、安排双人值守、明确触发回滚的观察指标。
- 发布结束后用检查清单核对材料齐备、结论有依据、结果已回填，确保审批可追溯。
发布审批要核对的三个输入
发布审批单承担的是证据汇总和判断留痕的作用。测试结果说明版本质量现状，风险清单说明已知不确定性及应对安排，回滚方案说明出问题时能否退得回来。三类材料缺一类，审批就只能凭印象拍板。建议在审批单上为每类材料设置固定栏目，由对应角色提交、确认，审批人逐栏核对。
测试结果摘要
测试结果摘要由测试负责人提交，面向放行判断组织信息，避免直接附一份完整测试报告让审批人自行翻找。最小字段包括：
- 用例通过率：本次发布范围内测试计划的执行进度与通过率，注明统计口径和截止时间。
- 未关闭缺陷分布：按严重级（如致命、严重、一般、轻微）列出未关闭缺陷数量，并标注其中属于本次变更范围的数量。
- 关键路径用例结论：核心业务流程、支付、登录、数据迁移等关键路径用例的通过情况，逐项给出结论。
- 遗留问题说明：每个遗留缺陷的影响范围、规避方式、计划修复版本，以及测试团队对是否影响放行的意见。
风险清单
风险清单由研发负责人提交，覆盖本次变更引入的技术与业务不确定性。每条风险至少写清五项内容：风险描述、等级、触发条件、影响范围、应对措施与责任人。等级判定依据要写在条目里，例如“涉及数据库结构变更，回滚需恢复备份，判定为高”，避免只写一个等级字母。触发条件尽量写成可观察的信号，如错误率超过某比例、某接口超时、某类订单失败，便于发布期间值守人员判断风险是否发生。
回滚方案
回滚方案由运维或发布负责人提交，审批时核对的是可执行性，而非方案是否存在。需要包含：回滚触发条件（与风险清单的触发条件对应）、回滚步骤与每步责任人、数据与配置处置方式（数据库变更如何回退、配置项如何还原、缓存与消息队列如何处理）、回滚后的验证方式（用哪些检查项确认服务恢复）。方案还应注明所需环境、权限和备份是否已就绪。
三类材料与审批单的挂接关系
| 材料 | 提交人 | 确认人 | 审批人核对栏目 |
|---|---|---|---|
| 测试结果摘要 | 测试负责人 | 测试负责人自检，研发负责人知悉遗留缺陷 | 通过率、未关闭缺陷分布、关键路径结论、遗留问题影响判断 |
| 风险清单 | 研发负责人 | 研发负责人与运维负责人共同确认应对措施可执行 | 风险等级、触发条件、应对措施与责任人是否齐全 |
| 回滚方案 | 运维/发布负责人 | 运维负责人确认环境、权限、备份就绪 | 触发条件、步骤与责任人、数据处置、验证方式 |
三类材料都应与本次发布版本号绑定，审批单上记录版本标识和材料提交时间，后续追溯时能确认审批针对的是哪个版本、依据的是哪一版材料。
按步骤完成一次发布审批
把审批拆成五步，每步都有明确输入、动作、输出和完成标志，可以减少审批会上的来回追问。以下步骤适用于常规版本发布，紧急修复发布可压缩时间，但材料要求不减少。
步骤一：提交发布申请并附测试结果摘要
输入是本次发布范围、版本号和测试计划执行结果。发布负责人发起申请，测试负责人填写测试结果摘要，明确测试结论（建议放行、有条件放行或建议暂缓）和遗留缺陷说明。完成标志是审批单上测试栏目填写完整，且摘要中的统计时间与发布版本对应。
步骤二：填写风险清单并给出等级判定依据
输入是变更内容清单和影响面分析。研发负责人逐项识别风险，填写描述、等级、触发条件、影响范围、应对措施与责任人，并在每条风险后写明定级理由。完成标志是本次变更涉及的每个高风险模块都有对应风险条目，且每条风险都有责任人和可观察的触发条件。
步骤三：提交回滚方案并确认可执行性
输入是本次变更涉及的部署项、数据库变更和配置变更。运维/发布负责人编写回滚方案，并核对回滚所需的环境、权限和备份是否就绪；有条件时附上回滚演练或验证记录。完成标志是方案中每一步都有责任人和预计耗时，数据处置方式明确，回滚后验证项可执行。
步骤四：审批人按判定规则核对并给出结论
输入是前三步形成的完整审批单。审批人对照判定规则表逐项核对，给出通过、有条件通过或暂缓的结论；有条件通过时写明附加条件。完成标志是审批单上有明确结论、结论对应的规则条目，以及附加条件的具体内容。
步骤五：记录决策依据并形成可追溯记录
输入是审批结论和讨论中的关键判断。发布负责人整理审批记录，写明决策依据、附加条件和后续动作；发布完成后回填实际结果，包括是否触发风险、是否执行回滚、回滚耗时与验证结果。完成标志是审批记录可被未参与审批的人读懂，且发布后回填已完成。
角色分工与各自交付物
发布门禁失效的常见原因是审批人替提交人补材料，签字变成走过场。明确每个角色交付什么、何时确认，能让审批人只做核对与判断。
| 角色 | 交付物 | 确认时点 |
|---|---|---|
| 测试负责人 | 测试结果摘要、遗留缺陷说明及测试结论 | 发布申请提交时，最迟在审批会前 |
| 研发负责人 | 风险清单、变更影响说明、风险等级判定依据 | 测试结果提交后、审批会前 |
| 运维/发布负责人 | 回滚方案、环境与备份就绪确认、回滚演练或验证记录 | 审批会前，与风险清单的应对措施对齐 |
| 审批人 | 审批结论、附加条件、决策依据记录 | 审批会上或书面审批时 |
| 发布负责人 | 放行条件执行记录、发布后结果回填 | 发布执行期间及发布后 |
职责边界上，测试负责人对测试结论负责，不对风险等级做最终判断；研发负责人对风险识别完整性负责；运维负责人对回滚可执行性负责；审批人对是否放行负责。出现材料争议时，回到字段和判定规则讨论，避免在审批会上临时调整阈值。
当团队使用ONES承载发布流程时，测试结果摘要可以基于测试计划的进度与通过率、缺陷分布统计和测试报告形成，测试用例与需求、任务关联，未通过用例可直接创建缺陷任务在测试与研发之间流转，减少摘要手工汇总的工作量。风险清单、回滚方案和审批记录可以作为发布工作项下的文档或子项与版本绑定，审批结论和附加条件随工作项留痕，发布后在同一处回填结果。
判定规则：什么情况放行、什么情况暂缓
判定规则应在发布前由团队约定并写入流程文档，审批时只做核对。规则的核心是把测试结果、风险等级和回滚准备状态组合起来看，任何单一维度都不能单独决定放行。
| 条件组合 | 结论 | 附加要求 |
|---|---|---|
| 关键路径用例全部通过；无高严重级未关闭缺陷；风险均在可接受范围且有应对措施；回滚方案已确认可执行 | 放行 | 按常规值守执行，发布后回填结果 |
| 关键路径用例通过；存在少量一般级遗留缺陷且已说明影响；存在中等级风险但触发条件可监控、应对措施明确；回滚方案可执行 | 有条件放行 | 限定发布窗口、缩小灰度范围、安排专项值守、明确触发回滚的观察指标 |
| 关键路径用例失败；存在高严重级未关闭缺陷且无规避方式；高风险项无应对措施；回滚方案缺失或无法验证 | 暂缓或拒绝 | 补齐材料或修复问题后重新提交审批 |
有条件放行的附加条件要写成可执行的动作，例如“先发布至内部环境观察两小时，错误率低于约定阈值后再扩大至全量”“发布窗口限定在业务低峰期，发布后两小时内安排研发与运维双人值守”“若支付失败率超过约定比例，立即执行回滚方案第三步”。附加条件与风险清单中的触发条件保持一致，值守人员才能据此判断。
阈值由团队事先约定，例如关键路径用例通过率要求、可接受的遗留缺陷严重级上限、风险等级的可接受范围。审批时发现材料超出阈值，结论是暂缓或有条件放行，不在会上临时放宽标准；确需调整阈值，应走流程变更并记录原因。
示例：一次带风险的发布审批记录
以下为演示情景，用于说明三类材料如何汇入审批单并得出有条件放行的结论，数据为示意。
示例背景
某版本计划在周四晚间发布，涉及订单结算逻辑调整和一项数据库字段新增。测试结果摘要显示：本次测试计划用例通过率98%，关键路径用例全部通过；未关闭缺陷中严重级1个、一般级4个，严重级缺陷为结算页在特定优惠券组合下金额展示错误，已有规避方式（该券组合暂停使用），计划下个版本修复。测试结论为建议有条件放行。
风险清单示例
- 风险一：数据库字段新增在旧版本服务读取时可能报错。等级：高。触发条件：发布后监控到旧版本实例报字段不存在错误。影响范围：订单查询接口。应对措施：发布前完成全量实例升级检查，发布后十分钟内观察错误日志；责任人：研发负责人。
- 风险二：结算逻辑变更影响优惠券叠加计算。等级：中。触发条件：结算失败率超过约定阈值。影响范围：下单转化。应对措施：灰度期间对比新旧逻辑计算结果；责任人：研发负责人。
- 风险三：发布窗口与业务高峰重叠。等级：低。触发条件：发布期间订单量高于日常水平。应对措施：调整至低峰窗口；责任人：发布负责人。
回滚方案示例
回滚触发条件：结算失败率超过约定阈值，或订单查询接口错误持续超过约定时长。回滚步骤：停止灰度流量、回退应用版本、执行数据库回滚脚本恢复字段变更、还原相关配置项，每步注明责任人。数据处置：发布期间产生的订单数据保留，回滚脚本只回退结构变更，执行前完成备份确认。回滚后验证：检查订单查询、结算、支付三条关键路径，确认错误日志恢复常态。
审批结论示例
审批人核对后给出有条件放行：同意发布，附加条件为——发布窗口限定在业务低峰期；先灰度少量流量观察约定时长，结算失败率低于阈值后再扩大；发布后两小时内研发与运维双人值守；若触发回滚条件，按回滚方案执行并在审批记录中登记。决策依据写明：关键路径用例通过，严重级遗留缺陷有规避方式，高风险项有监控手段和应对措施，回滚方案已确认可执行。
发布后回填
发布完成后，发布负责人回填：灰度期间结算失败率在阈值内，未触发回滚；值守期间发现一次旧版本实例报错，按预案完成升级后恢复；严重级遗留缺陷按计划在下个版本修复。回填内容与审批记录关联，形成完整闭环。
完成检查：审批记录是否合格
发布结束后，可用以下清单核对本次审批是否做完整、可追溯。任一项不满足，应在下一次发布前修正流程或补齐记录。
- 测试结果摘要、风险清单、回滚方案三类材料齐备，且版本号与本次发布一致。
- 测试结论明确，遗留缺陷写明了影响范围和规避方式，审批人能据此判断。
- 每条风险都有等级、判定依据、触发条件、影响范围和责任人。
- 回滚方案写明了触发条件、步骤与责任人、数据与配置处置方式、回滚后验证方式，环境与备份就绪情况有确认记录。
- 审批结论写明了依据的规则条目，有条件放行时附加条件具体可执行。
- 发布后已回填实际结果，包括风险是否触发、回滚是否执行及验证结果。
- 审批记录可被未参与审批的人读懂，材料提交时间与审批时间可查。
这份清单也可以反过来用于事前准备：提交审批前由发布负责人自查一遍，能明显减少审批会上的返工。团队可将清单固化为审批单的必填项或检查项，让门禁判断有稳定的证据基础。
常见问题
紧急修复发布时，能不能简化发布审批的材料？
可以压缩时间，材料要求不减少。常见做法是并行准备：测试负责人先给出关键路径用例结论和遗留缺陷说明，研发负责人同步填写风险清单，运维负责人确认回滚方案中环境、权限与备份是否就绪，审批人按同一套判定规则核对。紧急发布的风险往往更集中，回滚触发条件和值守安排更需要写清楚，否则出问题时没有可执行的退路。
团队还没有约定判定阈值，第一次做发布审批从哪里入手？
先选一个近期版本做试点，把本次实际使用的判断标准记录下来，例如关键路径用例通过情况、可接受的遗留缺陷严重级、风险等级的可接受范围、回滚方案需确认的要素。试点结束后由测试、研发、运维和审批人共同复盘，把大家实际认可的口径固化为规则条目，下一次审批直接对照。阈值可以随团队成熟度调整，调整时走流程变更并记录原因，避免每次审批临时商量。
回滚方案写到什么程度，审批时才算可执行？
审批时至少核对四点：回滚触发条件是否与风险清单的触发条件对应且可观察；每一步是否有责任人和预计耗时；数据库变更、配置项、缓存与消息队列等数据与配置的处置方式是否明确；回滚后用什么检查项确认服务恢复。此外还要确认所需环境、权限和备份已就绪，有条件时附上回滚演练或验证记录。只写“可回滚”三个字，无法支撑审批判断。
审批人给出有条件放行后，附加条件由谁跟踪落实？
附加条件由发布负责人跟踪执行，并在发布后回填实际结果。写法上要落到具体动作和观察指标，例如限定在业务低峰期发布、先灰度少量流量观察约定时长、发布后两小时内研发与运维双人值守、结算失败率超过约定比例即执行回滚。发布结束后，发布负责人把是否满足附加条件、是否触发风险、是否执行回滚及验证结果填回审批记录，形成闭环。
用ONES承载发布审批时，测试结果摘要和审批记录怎么关联？
ONES测试管理支持测试计划与迭代关联、未通过用例快速创建缺陷任务，并提供测试情况概览和测试报告，测试结果摘要可以基于这些信息形成，减少手工汇总。风险清单、回滚方案和审批记录可以作为发布工作项下的文档或子项与版本绑定，审批结论和附加条件随工作项留痕，发布后在同一处回填结果。具体字段与流程配置方式需结合实际环境确认。
