测试风险清单的核心，是把“可能出问题的地方”变成一条条可跟踪的记录。一份可直接使用的清单通常包含风险描述、触发条件、影响范围、发生概率、影响程度、风险等级、应对措施、责任人、复查时点与状态。本文提供可复制的空白表格、逐字段填写口径、必填与选填规则、一条完整示例，以及清单在测试各阶段的维护方法。
要点总览（TL;DR）
- 测试风险清单以“一条风险一行”组织，核心字段包括风险描述、触发条件、影响范围、发生概率、影响程度、风险等级、应对措施、责任人、复查时点与状态。
- 风险编号、风险描述、触发条件、影响范围、概率、影响程度、风险等级、责任人和状态建议设为必填；应对措施与复查时点在计划阶段可暂空，进入执行阶段前补齐。
- 风险等级按“发生概率×影响程度”的二维矩阵判定，取值口径在建库时统一约定，避免不同人填出的“高”无法比较。
- 清单在计划评审前建库、执行阶段每轮更新、回归前复核、发布评审时关闭或接受，版本复盘后归档并提炼高频风险类型。
可复制空白测试风险清单模板
下表可直接复制到 Excel、在线表格或项目管理工具中。列顺序按“识别—评估—应对—跟踪”排列，填写时从左往右推进，便于评审时逐列检查。示例保留三行空白，实际使用时按风险数量增行。
| 风险编号 | 风险描述 | 触发条件 | 影响范围 | 发生概率 | 影响程度 | 风险等级 | 应对措施 | 责任人 | 复查时点 | 状态 | 关闭依据 |
|---|---|---|---|---|---|---|---|---|---|---|---|
| R-001 | |||||||||||
| R-002 | |||||||||||
| R-003 |
概率、影响程度与风险等级需要统一取值，否则不同人填出的“高”无法比较。建议在建库时确定下表口径，并附在清单表头或单独的工作表中。
| 取值维度 | 取值 | 判定口径 |
|---|---|---|
| 发生概率 | 高 | 在当前版本与测试范围内，已有迹象或同类问题反复出现 |
| 发生概率 | 中 | 存在明确触发路径，但尚未在测试中复现 |
| 发生概率 | 低 | 触发条件苛刻，或仅在极端场景下可能出现 |
| 影响程度 | 严重 | 导致核心业务流程中断、数据错误或无法发布 |
| 影响程度 | 一般 | 影响部分功能或体验，有可接受的替代路径 |
| 影响程度 | 轻微 | 仅影响提示文案、样式等非关键表现 |
| 风险等级 | 高 | 概率高且影响严重，或影响严重且无有效规避手段 |
| 风险等级 | 中 | 概率与影响组合处于中间区间，需要持续跟踪 |
| 风险等级 | 低 | 概率低且影响轻微，按常规回归覆盖即可 |
如果团队按测试阶段管理清单，可在上述固定列之后追加可选列：所属测试阶段（计划/执行/回归）、关联需求或测试计划编号、关联用例编号、备注。这些列不改变主表结构，只补充追溯信息。
每个字段记录什么：清单字段说明
字段说明的目的是让不同角色填出的记录可以互相对照。下表给出每个字段的含义、填写口径与常见错误，填写前建议先通读一遍。
| 字段 | 含义 | 填写口径 | 常见错误 |
|---|---|---|---|
| 风险编号 | 清单内唯一标识 | 按 R-001 递增，删除记录后编号不复用 | 多条记录共用编号，导致引用混乱 |
| 风险描述 | 一句话说明可能发生的问题 | 写“对象+问题+后果”，如“支付回调超时导致订单状态不一致” | 写成笼统的“系统不稳定” |
| 触发条件 | 风险在什么情况下会暴露 | 写具体场景、数据量、环境或操作路径 | 只写“测试时”，无法判断何时复查 |
| 影响范围 | 风险发生后波及的业务与用户 | 写模块、流程、用户群体或数据范围 | 只写“影响很大”，没有边界 |
| 发生概率 | 风险出现的可能性 | 按统一取值（高/中/低）填写，并简述依据 | 凭感觉填写，缺少依据 |
| 影响程度 | 风险发生后的损失程度 | 按统一取值（严重/一般/轻微）填写 | 把所有问题都标为严重 |
| 风险等级 | 概率与影响的综合结果 | 按约定矩阵判定，不单独凭印象定级 | 等级与概率、影响取值矛盾 |
| 应对措施 | 降低概率或影响的具体动作 | 写可执行动作，如“补充并发用例”“增加降级开关验证” | 写“加强测试”这类无法验收的表述 |
| 责任人 | 推动应对与复查的人 | 写具体姓名或角色，一名责任人对应一条风险 | 写“测试组”，无人真正跟进 |
| 复查时点 | 下次检查该风险的时间或节点 | 写日期或阶段节点，如“执行阶段第二轮”“回归前” | 留空或写“以后” |
| 状态 | 风险当前处理进度 | 按待处理/处理中/已关闭/已降级填写 | 长期停留在“处理中” |
| 关闭依据 | 关闭或降级的证据 | 写验证结果、测试报告或评审结论 | 无依据直接关闭 |
风险描述与触发条件要分开写。描述回答“可能出什么问题”，触发条件回答“什么时候会暴露”，两者合并会让复查时点失去依据。影响范围则决定这条风险需要通知哪些人，范围写得越具体，应对措施越容易落到具体用例或验证动作上。
必填与选填：哪些字段不能空
最小可用清单只需要保证风险能被识别、定级和跟踪。以下字段建议设为必填：风险编号、风险描述、触发条件、影响范围、发生概率、影响程度、风险等级、责任人、状态。理由是缺少其中任何一项，清单都无法支撑评审决策或后续复查。应对措施与复查时点在风险刚识别、尚未评估时可以先留空，但进入执行阶段前必须补齐。
| 字段 | 计划阶段 | 执行阶段 | 回归阶段 |
|---|---|---|---|
| 风险编号、风险描述、影响范围 | 必填 | 必填 | 必填 |
| 触发条件 | 必填 | 必填 | 必填 |
| 发生概率、影响程度、风险等级 | 必填 | 必填 | 必填 |
| 应对措施 | 可暂空，评审前补齐 | 必填 | 必填 |
| 责任人 | 必填 | 必填 | 必填 |
| 复查时点 | 可暂空 | 必填 | 必填 |
| 状态 | 必填 | 必填 | 必填 |
| 关闭依据 | 选填 | 关闭时必填 | 关闭时必填 |
| 关联需求/用例编号、备注 | 选填 | 选填 | 选填 |
选填字段主要服务于追溯与沟通：关联需求或测试计划编号便于从风险跳到具体验证范围，备注用于记录临时判断或待确认事项。字段留空时建议统一写“待补”并注明补齐节点，避免空白被误读为“无风险”。评审时按阶段检查必填项，比逐条追问更高效。
填写示例：一条完整风险记录
下面用一条已填写的记录示范字段之间如何互相支撑。示例为演示情景，不对应真实项目数据。
| 字段 | 示例取值 |
|---|---|
| 风险编号 | R-007 |
| 风险描述 | 订单导出在数据量超过十万条时超时，导致运营无法按时获取对账数据 |
| 触发条件 | 导出时间范围跨三个月且订单量超过十万条，在测试环境使用生产量级数据复现 |
| 影响范围 | 运营对账流程，涉及财务结算周期 |
| 发生概率 | 中：已有一次小数据量导出偏慢的记录，大数据量尚未验证 |
| 影响程度 | 严重：对账延迟会影响结算 |
| 风险等级 | 高 |
| 应对措施 | 补充十万条量级导出用例；与开发确认异步导出方案；准备手工导出兜底流程 |
| 责任人 | 测试负责人（用例与验证）、后端开发（方案确认） |
| 复查时点 | 执行阶段第二轮，异步方案提测后 |
| 状态 | 处理中 |
| 关闭依据 | 十万条量级导出在约定时间内完成，且兜底流程演练通过 |
等级判定过程可以按三步走：先看影响程度，示例中影响结算，定为严重；再看发生概率，已有偏慢迹象但大数据量未验证，定为中；最后按矩阵组合，严重加中概率落入高风险区间，因此定为高。若后续验证发现大数据量导出稳定，概率可下调为低，等级相应降为中或低，并在备注中记录降级依据。
应对措施与复查时点要一一对应。示例中的措施包括补用例、确认方案、准备兜底，复查时点因此设在“异步方案提测后”，此时三项措施都有可检查的产出。若措施只写“关注性能”，复查时就无物可查，这条风险容易长期停留在处理中。
调整与维护：让清单随测试推进保持可用
风险清单在建立后需要按测试节奏更新，否则会变成一份过期文档。维护的重点是明确时点、动作与责任人，让每条风险都有下一次被检查的机会。
| 时点 | 动作 | 责任人 | 产出 |
|---|---|---|---|
| 测试计划评审前 | 初始建库，识别需求、架构与历史缺陷中的风险，完成定级 | 测试负责人 | 首版风险清单 |
| 计划评审会 | 逐条确认描述、影响范围与等级，补齐应对措施与复查时点 | 测试负责人、开发、产品 | 评审通过的风险清单 |
| 执行阶段每轮测试结束 | 更新状态，记录新发现的触发条件，调整概率与等级 | 各风险责任人 | 更新后的清单与变更记录 |
| 发现新风险或缺陷集中出现时 | 即时新增记录，指定责任人与复查时点 | 发现人提交，测试负责人确认 | 新增风险条目 |
| 回归前 | 复核未关闭风险，确认应对措施是否已验证 | 测试负责人 | 回归关注清单 |
| 发布评审 | 关闭有依据的风险，对剩余风险给出接受或延期结论 | 测试负责人、项目负责人 | 风险关闭记录与遗留风险说明 |
| 版本复盘 | 归档清单，提炼高频风险类型，供下个版本复用 | 测试负责人 | 归档清单与风险类型沉淀 |
关闭与降级要有判断依据：应对措施已验证且结果符合预期，可以关闭；触发条件消失或影响范围缩小，可以降级并记录原因。仅因“本期不处理”而关闭的记录，应改为“已接受”并写明接受人和影响，避免在后续版本中被误认为已解决。
当清单需要多人同时填写、按状态流转并保留复查记录时，可以把风险条目放进项目管理工具统一承载。ONES 测试管理支持测试用例与需求、任务关联，测试计划与迭代关联，未通过的用例可快速创建缺陷任务并在测试与研发团队间流转；这些能力适合把风险对应的验证动作、缺陷与测试计划放在同一条流程里跟踪。风险清单本身仍建议保留固定字段与统一取值，工具承担的是记录、分配与状态更新的协作部分，具体配置以实际试用和官方帮助文档为准。
常见问题
风险刚识别出来、还没评估清楚，清单可以先不填等级吗？
可以分两步走。识别当天先把风险编号、风险描述、触发条件和影响范围填上，等级栏写“待评估”并注明评估节点，例如“计划评审会前”。进入计划评审时，概率、影响程度与风险等级必须补齐，否则这条风险无法参与优先级排序。把“待评估”当作一个临时状态管理，比留空更安全，因为留空容易被误读为“无风险”。
同一个风险涉及多个模块，应该拆成多条记录还是合并成一条？
看应对措施是否相同。如果各模块的触发条件、验证动作和责任人一致，可以合并为一条，在影响范围里列全模块；如果不同模块需要不同的验证用例或由不同人跟进，建议拆成多条，用风险编号区分，并在备注中标注关联关系。合并过度会让复查时点难以设定，拆分过度则会增加维护成本，判断标准是“一条记录能否对应一组可检查的动作”。
风险关闭后发现问题仍然存在，清单该怎么处理？
不建议直接改回“处理中”覆盖原记录，可以新开一条记录并在备注中引用原风险编号，说明复现条件和原关闭依据的偏差。同时回看关闭依据是否写得太宽泛，例如只写了“已验证”而没有写验证的数据量、环境和结果。关闭依据写得越具体，后续复核越容易判断是验证遗漏还是场景变化。
清单条目多起来以后，靠表格维护容易漏掉复查，有什么办法？
关键是让复查时点变成可被提醒的节点，而不是表格里的一列文字。可以把复查时点写成具体日期或明确的阶段节点，并在每轮测试开始前按该列排序检查。当清单需要多人同时填写、按状态流转时，也可以把风险条目放进项目管理工具承载，与测试计划和缺陷放在同一条流程里跟踪。ONES 测试管理支持测试用例与需求、任务关联，测试计划与迭代关联，未通过的用例可快速创建缺陷任务并在测试与研发团队间流转，适合承接风险对应的验证动作与缺陷跟踪；具体配置以实际试用和官方帮助文档为准。
不同项目复用同一份风险清单模板时，需要改哪些地方？
固定字段和列顺序建议保持不变，方便跨项目对照。需要按项目调整的是取值口径和必填规则：概率与影响的判定标准要结合该项目的业务影响重新约定，例如结算类项目对“严重”的定义会比内部工具更严格；必填项可以按项目阶段调整，探索性较强的项目在计划阶段允许应对措施暂空，交付压力大的项目则要求建库时一次填全。历史清单归档后提炼的高频风险类型，可以作为新项目建库时的起点参考。
