测试风险清单是一张按风险逐条登记的表，用来在测试计划阶段把可能影响进度、质量和交付的问题提前写清楚，并指定应对方式和责任人。一张可用的清单通常包含风险编号、类别、描述、触发条件、影响范围、可能性、影响程度、风险等级、应对策略、责任人、验证方式和关闭状态。本文提供可直接复制到表格工具的空白模板、逐字段填写口径、必填与选填对照，以及一条完整示例，方便测试负责人、项目经理和开发负责人按同一口径填写。
要点总览（TL;DR）
- 模板包含一张12列的风险登记主表和一张可能性×影响程度的等级判定辅助表，复制后即可逐条填写。
- 必填字段为风险编号、类别、描述、影响范围、可能性、影响程度、风险等级、责任人和关闭状态；触发条件、应对策略、验证方式可先登记，在风险升级或进入处理中前补齐。
- 风险等级由可能性和影响程度交叉判定，不单独手填；高等级风险在测试计划评审时逐条讨论应对方案。
- 风险描述回答“可能出什么问题”，触发条件回答“怎么知道它正在发生”，两者分开填写才能支撑值班判断。
- 清单由测试负责人整体维护，责任人更新各自条目，每日检查高等级风险、每周复核全部风险，版本结束后随测试报告归档。
可复制空白测试风险清单模板
下面两张表可以直接复制到 Excel、在线表格或项目管理工具中。主表用于逐条登记风险，辅助表用于统一风险等级的判定口径。复制后建议先完成三项格式设置：风险编号设为文本并保持唯一；可能性、影响程度使用下拉选项；风险等级用公式或条件格式根据前两项自动计算，避免人工填写不一致。
主表：测试风险登记
| 风险编号 | 风险类别 | 风险描述 | 触发条件 | 影响范围 | 发生可能性 | 影响程度 | 风险等级 | 应对策略 | 责任人 | 验证方式 | 关闭状态 |
|---|---|---|---|---|---|---|---|---|---|---|---|
| R-001 | |||||||||||
| R-002 | |||||||||||
| R-003 | |||||||||||
| R-004 | |||||||||||
| R-005 |
辅助表：风险等级判定
可能性与影响程度各分三档，交叉得到风险等级。团队可以按项目实际调整阈值，但同一项目内应保持同一套口径。
| 可能性 \ 影响程度 | 低（局部功能受影响，可绕过） | 中（核心功能受影响，有替代方案） | 高（阻塞发布或造成数据问题） |
|---|---|---|---|
| 高（大概率发生） | 中 | 高 | 高 |
| 中（有条件发生） | 低 | 中 | 高 |
| 低（偶发或依赖外部） | 低 | 低 | 中 |
等级为“高”的风险应在测试计划评审时逐条讨论应对方案；“中”等级风险明确责任人和观察节点；“低”等级风险可合并登记，按周检查。
字段说明：每个字段填什么、怎么判断
字段口径统一，清单才能在不同角色之间传递而不失真。下表逐字段说明含义、填写口径和常见错误。
| 字段 | 含义 | 填写口径 | 常见错误 |
|---|---|---|---|
| 风险编号 | 风险的唯一标识 | 按 R-001 递增，删除记录后编号不复用 | 重复编号或按行号临时编，后续引用混乱 |
| 风险类别 | 风险来源的分类 | 常用类别：需求、环境、数据、进度、人员、依赖、质量 | 类别写得过细，导致统计时无法归并 |
| 风险描述 | 可能发生的问题本身 | 写“什么对象在什么情况下可能出现什么问题”，一句话说清 | 写成解决方案或任务，如“需要增加测试人员” |
| 触发条件 | 判断风险已经发生或即将发生的信号 | 写可观察的事件或阈值，如“提测延迟超过 2 天”“测试环境连续不可用 4 小时” | 与风险描述重复，或写成模糊的“情况不好时” |
| 影响范围 | 风险发生后波及的功能、模块或交付节点 | 写具体模块、接口、版本或里程碑 | 只写“影响项目”，无法判断严重程度 |
| 发生可能性 | 风险发生的概率档位 | 按高、中、低三档，结合历史数据和当前条件判断 | 凭感觉填，缺少判断依据 |
| 影响程度 | 风险发生后的后果档位 | 按低、中、高三档，对照辅助表的定义判断 | 把发生概率当成影响程度 |
| 风险等级 | 可能性与影响程度的综合结果 | 查辅助表得出，不单独主观指定 | 直接手填等级，与两列判断矛盾 |
| 应对策略 | 对风险采取的处理方式 | 四类：规避、转移、减轻、接受，并写明具体动作 | 只写“关注”“跟进”，没有实际动作 |
| 责任人 | 负责推动应对和更新状态的人 | 写具体姓名或角色，一条风险对应一个主责人 | 写团队名或多人并列，无人真正负责 |
| 验证方式 | 如何确认应对措施生效或风险已消除 | 写可执行的检查动作，如“回归用例全部通过”“环境连续 3 天可用” | 写“已处理”“已确认”这类结论词 |
| 关闭状态 | 风险当前处理阶段 | 待处理、处理中、已缓解、已关闭、已发生 | 长期停留在“处理中”，没有复核节点 |
风险描述与触发条件的区别需要特别注意：描述回答“可能出什么问题”，触发条件回答“怎么知道它正在发生”。例如描述写“第三方支付接口联调延迟”，触发条件写“联调环境在计划开始日期后 2 天仍未开通”。两者分开填写，值班人员才能据此判断是否需要启动应对。
应对策略的四种类型对应不同动作：规避是调整计划或方案绕开风险源；转移是把影响转给外部方或通过约定分担，如与供应商约定交付节点；减轻是降低发生概率或缩小影响，如提前准备测试数据；接受是记录在案并准备应急方案，适用于低等级或成本过高的风险。
必填与选填：哪些字段不能空
必填字段保证风险可被识别、分派和跟踪；选填字段用于补充信息，不影响清单的基本流转。建议在表格工具中把必填列标色，并在评审时逐列检查。
| 类型 | 字段 | 缺失时的处理 |
|---|---|---|
| 必填 | 风险编号、风险类别、风险描述、影响范围、发生可能性、影响程度、风险等级、责任人、关闭状态 | 不允许提交评审；已在执行中的风险缺失责任人时，由测试负责人当天指定并补录 |
| 选填 | 触发条件、应对策略、验证方式 | 可先登记，但在风险升级为“高”等级或进入“处理中”状态前必须补齐 |
必填缺失的处理规则可以分两步：登记环节阻断，即缺少必填字段的记录不进入正式清单，只在草稿区保存；流转环节补录，即风险状态变化时检查对应字段，例如从“待处理”变为“处理中”必须有应对策略，从“处理中”变为“已关闭”必须有验证方式。这样既不会因为字段过多阻碍早期登记，也能保证关键节点信息完整。
填写示例：一条完整风险记录
以下示例为演示情景，用于说明字段之间的对应关系，不代表真实项目数据。
| 字段 | 示例取值 |
|---|---|
| 风险编号 | R-007 |
| 风险类别 | 环境 |
| 风险描述 | 性能测试环境与生产环境配置差异较大，压测结果可能无法反映真实容量 |
| 触发条件 | 压测环境数据库版本或节点数与生产不一致，且差异在压测开始前未确认 |
| 影响范围 | 订单服务的容量评估结论，影响版本 2.4 上线决策 |
| 发生可能性 | 中 |
| 影响程度 | 高 |
| 风险等级 | 高 |
| 应对策略 | 减轻：压测前由运维提供环境差异清单，对差异项在报告中标注；关键接口补充生产环境小流量验证 |
| 责任人 | 测试负责人（性能方向） |
| 验证方式 | 环境差异清单完成评审，压测报告包含差异说明，关键接口小流量验证通过 |
| 关闭状态 | 处理中 |
逐项看取值理由：类别选“环境”，因为风险源是测试环境而非需求或人员；描述写的是配置差异带来的结论偏差，属于问题本身；触发条件写成可检查的比对动作，便于在压测前判断；影响范围落到具体服务和版本，才能支撑“高”等级的判断；可能性为“中”、影响程度为“高”，查辅助表得到“高”；应对策略选择“减轻”，因为环境无法完全对齐，但可以通过差异标注和小流量验证降低误判；验证方式写成三个可核对的产物，关闭时逐项确认；状态为“处理中”，表示措施已启动但尚未完成验证。
对照字段说明可以发现，这条记录没有把解决方案写进风险描述，也没有用“关注一下”代替应对策略，责任人是单一角色，验证方式是动作而非结论。填写其他记录时可以按同样方式自查。
调整与维护：按项目规模裁剪字段并定期更新
模板需要随项目类型调整，但调整应有原则，避免每个项目各写一套导致无法横向比较。
字段裁剪与增补原则
- 小型项目可合并“发生可能性”和“影响程度”为一列“风险等级”，但需在表头注明判定口径；必填字段中的风险描述、影响范围、责任人、关闭状态保留。
- 涉及外部供应商或跨团队依赖的项目，建议增加“依赖方”和“约定交付时间”两列，便于跟踪转移类策略。
- 安全、合规相关项目可增加“合规影响”字段，但不替代影响程度，两者分别判断。
- 裁剪只减少选填字段或合并判断列，风险编号、描述、责任人、状态四类信息不建议删除。
维护责任人与复核节奏
清单由测试负责人整体维护，每条风险的责任人负责更新自己那条记录的状态和验证结果。建议在测试计划评审时建立初始清单，每日站会检查高等级风险，每周复核全部风险一次；版本发布前做一次集中复核，确认已关闭风险的验证方式是否完成、已发生风险是否转入缺陷跟踪。
风险状态流转与归档
状态按“待处理→处理中→已缓解或已发生→已关闭”流转。已缓解表示应对措施生效但风险源仍可能存在，需保留观察；已发生表示风险已转化为实际问题，应关联对应的缺陷或变更记录。版本结束后，清单随测试报告一并归档，保留风险编号和最终状态，供后续版本复用和复盘。
当风险条目需要在测试计划、用例执行和缺陷跟踪之间流转时，可以把清单登记在项目管理工具中，让风险责任、状态更新和验证结果与测试活动保持在同一处。ONES 支持测试计划与迭代关联、用例分配执行人，未通过的用例可快速创建缺陷任务并在测试与研发团队间流转，测试报告和缺陷分布统计也可自动生成；风险关闭时对应的验证结果可以借助这些记录核对。具体字段和流程需按团队实际配置，官网资料未提及风险清单专用模板。
常见问题
小项目人手少，风险清单能不能只填描述和责任人？
可以简化，但建议保留四类信息：风险编号、风险描述、责任人和关闭状态。这四项保证风险能被识别、分派和跟踪。发生可能性与影响程度可以合并为一列“风险等级”，但需在表头注明判定口径，例如“高=可能阻塞发布”。简化后仍应在测试计划评审时过一遍清单，避免风险登记变成事后补录。
风险已经发生，清单里应该关闭还是保留？
建议把状态改为“已发生”，并关联对应的缺陷或变更记录，而不是直接关闭。已发生表示风险已转化为实际问题，需要跟踪处理结果；待问题解决、验证通过后再改为“已关闭”。这样版本复盘时能区分“提前识别并缓解的风险”和“实际发生的问题”，为后续版本的等级判定提供依据。
风险等级判定表和团队实际感受不一致时怎么办？
先检查可能性和影响程度两列的填写依据是否一致，常见原因是有人凭印象填可能性、有人按历史数据填。可以约定可能性参考近几个版本的实际发生次数，影响程度对照辅助表中的定义逐条判断。若团队认为矩阵阈值不适合当前项目，可整体调整辅助表并在表头注明，但同一项目内保持一套口径，避免同一风险在不同人手里得出不同等级。
风险清单和缺陷跟踪是什么关系，需要合并吗？
两者跟踪的对象不同：风险清单记录尚未发生、可能影响测试和交付的问题；缺陷跟踪记录已经出现的功能或质量问题。建议分开维护，在风险状态变为“已发生”时关联对应缺陷。若团队使用项目管理工具，可以把风险条目和缺陷任务放在同一项目中，通过关联字段互相引用，风险关闭时核对缺陷处理结果。ONES 支持未通过用例快速创建缺陷任务并在测试与研发团队间流转，可作为衔接参考，具体字段配置按团队实际设置。
跨团队或供应商依赖的风险，模板需要额外加什么字段？
建议增加“依赖方”和“约定交付时间”两列。依赖方写具体团队或供应商名称，约定交付时间写明确日期而非“尽快”。这类风险通常采用转移或减轻策略，应对策略中写明对方承诺的节点和己方的备用方案，验证方式写成可核对的交付物，例如“接口文档在约定日期前完成评审”。增加字段后仍保留原有的影响范围和责任人，避免依赖方与责任人混淆。
