发布决策会上的测试报告，风险信息部分至少要让人看清五类内容：未关闭缺陷与严重度分布、测试覆盖缺口、已知问题与规避方案、非功能与兼容性风险、发布后监控与回退预案。下面这份模板把上述内容拆成可填写的字段，先给空白表，再说明每个字段怎么填、哪些不能空，最后用一份完整示例演示填写效果，适用于常规迭代、紧急修复和大版本等不同发布场景。
要点总览（TL;DR）
- 发布决策用的测试报告，风险信息至少覆盖五类：未关闭缺陷与严重度分布、测试覆盖缺口、已知问题与规避方案、非功能与兼容性风险、发布后监控与回退预案。
- 模板分版本结论摘要区和逐条风险表两部分，风险表每行记录一个风险，字段包括风险编号、类别、描述、影响范围、严重程度、发生可能性、当前状态、责任人、规避措施与决策建议。
- 风险编号、类别、描述、影响范围、严重程度、发生可能性、责任人、决策建议为必填；决策建议为“有条件发布”时，规避或缓解措施转为必填。
- 高风险条目缺责任人、缺措施或缺决策建议，以及摘要区缺陷统计与风险表条目对不上时，应退回补充后再评审。
- 模板可按发布类型裁剪：常规迭代按默认规则，紧急修复精简字段，大版本增加覆盖缺口与外部依赖的必填要求，并每季度回看历史表校准判定口径。
可复制空白模板：发布风险信息表
模板分两个区域：上方是版本与测试结论摘要，供评审人快速了解本次发布的整体情况；下方是逐条风险信息表，一行记录一个风险。复制到文档或表格工具后，先填摘要区，再按行补充风险条目，条目数量以覆盖全部已知风险为准，不设固定行数。
版本与测试结论摘要区
| 字段 | 填写内容 |
|---|---|
| 版本号 | |
| 测试范围 | |
| 测试结论 | |
| 遗留缺陷统计（按严重度） | |
| 风险条目总数 | |
| 整体决策建议 | |
| 填表人与日期 |
风险信息表主体
| 风险编号 | 风险类别 | 风险描述 | 影响范围 | 严重程度 | 发生可能性 | 当前状态 | 责任人 | 规避或缓解措施 | 决策建议 |
|---|---|---|---|---|---|---|---|---|---|
| R-01 | |||||||||
| R-02 | |||||||||
| R-03 | |||||||||
| R-04 | |||||||||
| R-05 |
使用说明：复制表格后，摘要区的“遗留缺陷统计”按严重度分档填写数量，例如“致命 0、严重 2、一般 7、轻微 12”；风险主体每行只写一个风险，同一缺陷引发的多个后果合并为一行，在描述中说明。风险编号在同一版本内保持唯一，后续修订沿用编号，便于评审时对照上一版。
字段说明：每个风险字段记录什么
同一份模板由测试、开发、产品等不同角色填写时，最容易出现口径不一致的是严重程度和影响范围。下表给出每个字段的含义与填写口径，填写时以“评审人能否据此判断是否放行”为标准。
| 字段 | 含义 | 填写口径 | 示例取值 |
|---|---|---|---|
| 风险编号 | 风险条目的唯一标识 | 版本内唯一，修订时沿用 | R-03 |
| 风险类别 | 风险所属类型 | 从建议取值中选择，必要时新增 | 缺陷遗留 |
| 风险描述 | 风险是什么、在什么条件下触发 | 写清现象与触发条件，避免只写“有问题” | 批量导入超过5000行时偶发超时 |
| 影响范围 | 受影响的业务对象与用户群 | 写具体功能模块、业务对象和用户群体 | 订单导入功能，使用批量导入的运营人员 |
| 严重程度 | 风险发生后对业务的影响等级 | 按业务损失与用户影响判定，不按修复难度判定 | 严重 |
| 发生可能性 | 风险在发布后实际触发的概率 | 结合触发条件的使用频率与测试复现情况判断 | 中 |
| 当前状态 | 风险的处理进展 | 未处理、处理中、已缓解、已接受 | 处理中 |
| 责任人 | 对该风险跟进负责的人 | 写具体人名，不写团队名 | 张×× |
| 规避或缓解措施 | 降低风险影响或概率的动作 | 写清动作、完成时间点，与责任人对应 | 发布前将导入上限调整为3000行，下版本修复 |
| 决策建议 | 针对该风险给出的发布意见 | 可发布、有条件发布、不建议发布 | 有条件发布 |
风险类别的建议取值包括：缺陷遗留、覆盖缺口、性能与稳定性、兼容性、数据与安全、依赖与外部条件。缺陷遗留指已发现但未关闭的问题；覆盖缺口指测试范围未覆盖或覆盖不足的部分；性能与稳定性指响应时间、并发、长时间运行等表现；兼容性指浏览器、设备、操作系统或上下游系统的适配问题；数据与安全指数据迁移、权限、敏感信息相关风险；依赖与外部条件指第三方服务、配置、上线窗口等外部因素。
严重程度建议按三档判定：高，指核心业务中断、数据错误或安全事件，影响多数用户；中，指部分功能异常或体验明显下降，有替代操作路径；低，指边缘场景问题，影响范围小且有临时规避方式。发生可能性同样分高、中、低三档，依据是触发条件在真实使用中的出现频率和测试中的复现情况。两个字段组合后，高严重度加高可能性应优先处理，低严重度加低可能性可以记录后接受。
影响范围要写到业务对象和用户群，例如“结算页，使用优惠券下单的用户”，而不是“部分用户”。规避或缓解措施必须能落到人和时间点，例如“发布前由张××将导入上限调整为3000行，下个迭代修复”，这样评审时才能判断措施是否已经完成。决策建议字段只填三个取值之一，并在示例中说明理由，避免出现“看情况”这类无法执行的表述。
必填与选填：哪些字段不能空
模板被填成空壳，通常是因为字段没有区分优先级。以下规则把字段分为必填与选填两类，并给出空缺时的处理方式。
| 字段 | 类型 | 空缺时的处理 |
|---|---|---|
| 风险编号 | 必填 | 不允许空缺，缺失则条目无效 |
| 风险类别 | 必填 | 不允许空缺 |
| 风险描述 | 必填 | 不允许空缺，描述不清的条目退回补充 |
| 影响范围 | 必填 | 不允许空缺，写不出范围的按“影响范围待确认”标注并阻断评审 |
| 严重程度 | 必填 | 不允许空缺 |
| 发生可能性 | 必填 | 不允许空缺 |
| 责任人 | 必填 | 不允许空缺 |
| 决策建议 | 必填 | 不允许空缺 |
| 当前状态 | 选填 | 空缺时默认按“未处理”理解 |
| 规避或缓解措施 | 条件必填 | 决策建议为“有条件发布”时必填，其余情况可空缺 |
按风险类别与严重程度组合，最低填写要求如下：严重程度为高的风险，无论类别，规避或缓解措施与当前状态都必须填写；缺陷遗留、数据与安全两类风险，即使严重程度为中，也要填写规避或缓解措施；覆盖缺口类风险必须写清未覆盖的范围和原因，便于评审判断残余风险。其余组合可以只填必填字段。
以下情况应阻断发布评审：任一高风险条目缺少责任人、规避措施或决策建议；摘要区的遗留缺陷统计与风险表中的缺陷条目数量对不上；存在“影响范围待确认”的条目。阻断的处理方式是退回填表人补充，补齐后重新提交评审，而不是在评审会上口头说明。
填写示例：一个版本的完整风险信息表
以下示例为演示情景，版本背景为一次常规迭代：测试范围覆盖订单、结算、优惠券三个模块，测试结论为“主要流程通过，存在遗留问题”，遗留缺陷统计为致命 0、严重 2、一般 7、轻微 12，共记录 4 条风险。
| 风险编号 | 风险类别 | 风险描述 | 影响范围 | 严重程度 | 发生可能性 | 当前状态 | 责任人 | 规避或缓解措施 | 决策建议 |
|---|---|---|---|---|---|---|---|---|---|
| R-01 | 缺陷遗留 | 批量导入超过5000行时偶发超时，重试后可成功 | 订单导入功能，使用批量导入的运营人员 | 中 | 中 | 处理中 | 张×× | 发布前将导入上限调整为3000行，下个迭代修复 | 有条件发布 |
| R-02 | 覆盖缺口 | 优惠券叠加规则仅覆盖两种组合，其余组合未测试 | 结算页，使用多张优惠券下单的用户 | 中 | 低 | 已接受 | 李×× | 发布后一周内监控优惠券相关客诉，异常时关闭叠加入口 | 有条件发布 |
| R-03 | 兼容性 | 旧版安卓浏览器下结算页样式错位，不影响提交订单 | 结算页，使用旧版安卓浏览器的用户 | 低 | 中 | 未处理 | 王×× | 记录为已知问题，下个迭代修复 | 可发布 |
| R-04 | 依赖与外部条件 | 支付渠道对账文件延迟，可能影响当日对账 | 财务对账流程，财务人员 | 高 | 低 | 已缓解 | 赵×× | 发布当晚安排值班，延迟超过2小时切换手工对账 | 有条件发布 |
决策建议栏的填写理由：R-01 属于可规避的功能限制，调整上限后影响可控，因此为有条件发布；R-02 的覆盖缺口无法在发布前补齐，但影响面窄且有监控手段，同样为有条件发布；R-03 不影响核心流程，记录后即可发布；R-04 严重程度高，但已有明确的值班与切换方案，条件满足后可发布。四条风险与字段说明逐项对应：类别取自建议取值，严重程度按业务影响判定，措施均落到人和时间点。
风险表填写完成后，需要随版本流转并保留评审记录。在 ONES 中，测试报告可以关联到对应版本的工作项，风险条目以工作项或文档条目的形式记录状态与责任人，评审意见随版本留痕，后续修订沿用风险编号即可对照上一版。这样发布决策时看到的是一份有状态、有责任人的风险清单，而不是一份静态文档。
调整与维护：让模板适配不同发布类型
同一张表用于所有发布类型，容易出现两种偏差：常规迭代被要求填写过多字段，紧急修复又漏掉关键信息。建议按发布类型调整必填项，并定期维护模板本身。
| 发布类型 | 必填项调整 | 说明 |
|---|---|---|
| 常规迭代 | 按默认必填规则执行 | 覆盖全部风险类别，摘要区完整填写 |
| 紧急修复 | 保留风险描述、影响范围、严重程度、责任人、决策建议；当前状态与措施可简写 | 修复范围小，重点确认修复本身不引入新风险 |
| 大版本 | 在默认规则上增加覆盖缺口与依赖外部条件的必填要求 | 变更面大，需明确未覆盖范围与外部依赖 |
风险类别取值的增删原则：新增类别应能对应一类独立的处理动作和责任人，例如引入新的第三方服务时可以增加“第三方服务”类别；合并或删除类别时，先确认历史风险表中该类别的条目已归档，避免新旧版本对照时出现空类别。类别数量保持在六到八个，过多会导致填写时随意归类。
模板版本与评审记录分开维护：模板本身标注版本号和修订日期，字段增删在修订说明中记录；每次发布评审的风险表作为独立记录保存，不覆盖历史版本。建议每季度回看一次历史风险表，对照实际发布后发生的问题，校准严重程度与发生可能性的判定口径，例如把多次被判定为“低可能性”却实际触发的问题，在下一次评估中上调可能性档位。
常见问题
风险表里的严重程度和发生可能性，不同角色判断不一致怎么办？
先统一判定依据再讨论具体条目。严重程度按业务损失和受影响用户范围判定，与修复难度无关；发生可能性按触发条件在真实使用中的出现频率和测试复现情况判定。评审前由测试负责人把本次版本的高风险条目单独列出，请开发、产品各自给出判断，差异较大的条目当场对齐口径。长期做法是每季度回看历史风险表，对照发布后实际发生的问题，修正被反复误判的档位。
紧急修复发布时，风险表可以简化到什么程度？
紧急修复的修复范围小，重点确认修复本身不引入新风险。可以保留风险描述、影响范围、严重程度、责任人、决策建议这几项，当前状态与规避措施允许简写。但高风险条目仍需写清责任人和措施，摘要区的遗留缺陷统计也要与风险表条目对应。若修复涉及数据变更或外部依赖，覆盖缺口和依赖条件两类信息不能省略。
风险条目在评审后被接受，后续版本还要继续跟踪吗？
要跟踪。被接受的风险应保留原风险编号和状态，在后续版本的风险表中延续记录，直到关闭或转为已缓解。这样评审时能对照上一版，看出哪些风险长期未处理。若同一风险跨多个版本持续存在，建议在季度回看时重新评估严重程度和发生可能性，避免“已接受”变成默认忽略。
风险表填写完成后，如何保证评审意见和后续修订不丢失？
把风险表与版本绑定保存，每次评审的意见作为独立记录留存，不覆盖上一版。修订时沿用风险编号，新增条目另起编号，这样历史版本可以逐条对照。在 ONES 中，测试报告可关联到对应版本的工作项，风险条目以工作项或文档条目记录状态与责任人，评审意见随版本留痕，便于发布决策时查看完整的处理过程。
模板里的风险类别可以按团队情况增删吗？
可以，但要遵循两条原则：新增类别应能对应一类独立的处理动作和责任人，例如引入新的第三方服务时可增加“第三方服务”类别；合并或删除类别前，确认历史风险表中该类别的条目已归档，避免新旧版本对照时出现空类别。类别总数建议保持在六到八个，过多会导致填写时随意归类，反而降低可比性。
