测试风险清单是一张按风险逐条登记的表，用来在测试计划阶段识别可能影响进度、质量和交付的问题，并明确应对方式。核心字段包括风险编号、风险描述、所属测试范围、发生可能性、影响程度、风险等级、应对措施、责任人、触发信号与关闭标准。下文先给出可直接复制的空白表，再逐字段说明填写口径、区分必填与选填，并用一条完整记录示范字段之间的对应关系。
要点总览（TL;DR）
- 测试风险清单按风险逐条登记，核心字段为风险编号、风险描述、所属测试范围、发生可能性、影响程度、风险等级、应对措施、责任人、触发信号与关闭标准。
- 风险描述写成“条件+事件+后果”，可能性与影响程度用统一的三级口径，风险等级按团队约定的二维矩阵换算，保证清单内记录可横向比较。
- 必填项为风险编号、风险描述、所属测试范围、发生可能性、影响程度、风险等级、责任人、关闭标准；暂缺时用“待确认”加确认人和期限标记，不留空。
- 应对措施是提前做的准备动作，触发信号是风险已发生的观察依据，关闭标准要写成可核验的结果，并与应对措施一一对应。
- 清单在测试计划评审时建初版，执行中按例会节奏更新状态，版本结束后随测试报告归档，已关闭记录保留不删除。
可复制空白测试风险清单模板
下表为空白模板，复制到文档或表格工具后即可逐行填写。字段顺序与后文说明保持一致，便于对照填写。建议一行登记一条风险，同一测试范围内存在多条风险时分行记录，不合并到同一单元格。
| 风险编号 | 风险描述 | 所属测试范围 | 发生可能性 | 影响程度 | 风险等级 | 应对措施 | 责任人 | 触发信号 | 关闭标准 | 状态 | 更新日期 |
|---|---|---|---|---|---|---|---|---|---|---|---|
模板包含十二列，其中前十列是风险登记的主体内容，状态与更新日期用于日常维护。项目规模较小时可以删减列，但删除前需确认该列信息没有其他记录渠道，避免风险在流转中丢失关键信息。
每个字段填什么：字段说明
字段说明解决的是“同一列大家填法一致”的问题。风险清单最常见的失效原因，是不同人用不同口径填写可能性和影响程度，导致风险等级无法横向比较。下表给出每个字段的含义与填写口径，团队可在测试计划评审时据此约定本项目的具体分级。
| 字段 | 含义 | 填写口径 |
|---|---|---|
| 风险编号 | 风险的唯一标识 | 按“项目缩写-序号”编制，如 PAY-R03，编号一经分配不再复用 |
| 风险描述 | 风险是什么、会在什么条件下发生 | 写成“条件+事件+后果”的句式，如“第三方支付沙箱在联调期不稳定，导致支付链路用例无法按时执行” |
| 所属测试范围 | 风险影响的测试对象 | 填写模块、需求编号或测试阶段，如“支付模块-退款流程-系统测试” |
| 发生可能性 | 风险在测试周期内出现的概率 | 用高/中/低三级，并附一句判断依据，如“高：该接口近两个版本均出现过超时” |
| 影响程度 | 风险发生后对进度、质量或范围的损害 | 用高/中/低三级，按团队约定的口径判断，如“高：阻塞核心链路用例，影响发版” |
| 风险等级 | 由可能性与影响程度共同得出的优先级 | 按团队约定的矩阵换算，如高×高、高×中、中×高为高等级，其余组合依次递减 |
| 应对措施 | 为降低可能性或影响而采取的行动 | 写具体动作和完成时间，如“提前一周申请独立沙箱环境，由测试负责人跟进” |
| 责任人 | 负责跟进该风险的人 | 填到具体个人，不填团队名称；责任人负责更新状态和推动应对措施 |
| 触发信号 | 判断风险正在发生的可观察迹象 | 写成可观测的事件，如“联调环境连续两天出现超时告警” |
| 关闭标准 | 风险可以标记为关闭的条件 | 写成可核验的结果，如“退款链路用例全部执行通过且连续一个版本无超时” |
| 状态 | 风险当前处理阶段 | 使用待处理、应对中、已触发、已关闭等固定取值 |
| 更新日期 | 该条记录最近一次修改时间 | 每次修改状态或措施时同步更新 |
风险描述要避免只写结论。像“支付有风险”这样的表述无法指导行动，补上触发条件和后果后，责任人和应对措施才有明确指向。可能性与影响程度的分级标准应在测试计划中固定下来，同一项目内不随个人判断变化。
风险等级由可能性和影响程度共同得出，常见做法是建立二维矩阵：两个维度都为高时定为高等级，一高一中定为中或高等级，两个维度都为低时定为低等级。矩阵的具体切分由团队约定，关键是清单内所有记录使用同一套规则，并在评审时抽查换算是否正确。
应对措施与触发信号容易混淆。应对措施是提前做的准备动作，目的是降低风险发生概率或减轻后果；触发信号是风险已经发生的观察依据，用来决定是否启动预案。两者分开填写，才能在风险真正出现时快速判断该做什么。
关闭标准要与应对措施对应。措施解决的是“怎么防”，关闭标准回答的是“防到什么程度算结束”。关闭标准应可核验，例如用例执行结果、环境稳定性观察周期或缺陷收敛情况，避免写成“风险已处理”这类无法验证的表述。
必填与选填：哪些字段不能空
必填项保证一条风险记录具备基本的可跟踪性：知道是什么风险、影响哪里、由谁负责、什么条件下算结束。选填项用于补充上下文，在信息不足时可暂缺，但需按约定标记，避免被误认为遗漏。
| 类别 | 字段 | 空缺时的处理 |
|---|---|---|
| 必填 | 风险编号、风险描述、所属测试范围、发生可能性、影响程度、风险等级、责任人、关闭标准 | 不允许留空；信息暂缺时填写“待确认”并在备注中写明确认人和期限 |
| 选填 | 应对措施、触发信号、状态、更新日期 | 应对措施在风险识别初期可暂缺，进入应对阶段前补齐；触发信号可随监控手段明确后补充 |
必填项暂缺时，用“待确认”加确认人、确认期限的方式标记，比留空更利于后续跟进。例如风险描述尚不完整时，可先写已掌握的条件和后果，标注“待确认：影响范围”，并指定在测试计划评审前补齐。状态和更新日期虽列为选填，实际维护中建议每条记录都填写，否则清单难以判断哪些风险仍在处理。
裁剪字段时优先保留必填项。若团队已有缺陷管理或需求管理工具承载部分信息，可将所属测试范围与需求编号对应，减少重复录入，但风险编号、责任人、关闭标准仍应保留在清单内，保证风险有独立可查的记录。
填写示例：一条完整风险记录
以下示例为演示情景，用于说明字段之间的对应关系，不代表真实项目数据。示例覆盖全部必填字段，并展示风险等级的换算过程。
| 字段 | 填写内容 |
|---|---|
| 风险编号 | PAY-R03 |
| 风险描述 | 第三方支付沙箱在联调期不稳定，导致退款链路用例无法按时执行，影响系统测试进度 |
| 所属测试范围 | 支付模块-退款流程-系统测试 |
| 发生可能性 | 高：该沙箱近两个版本均出现过超时 |
| 影响程度 | 高：退款链路为核心用例，阻塞发版判断 |
| 风险等级 | 高（高×高，按团队矩阵换算为高等级） |
| 应对措施 | 提前一周申请独立沙箱环境；准备模拟支付服务作为备用验证手段；由测试负责人每周跟进环境状态 |
| 责任人 | 测试负责人（示例中以角色代称） |
| 触发信号 | 联调环境连续两天出现退款接口超时告警 |
| 关闭标准 | 退款链路用例在独立环境全部执行通过，且连续一个版本周期无超时告警 |
| 状态 | 应对中 |
| 更新日期 | 填写最近一次修改日期 |
这条记录中，可能性与影响程度都为高，按“高×高为高等级”的矩阵规则得出风险等级为高，与应对措施的投入程度相匹配。应对措施针对的是降低发生概率和准备替代手段，关闭标准则对应到可核验的执行结果，两者形成“防什么”和“防到什么程度”的对应关系。触发信号一旦出现，责任人即可判断风险已发生，启动备用验证手段并更新状态。
清单的调整与维护方法
清单的价值在于持续使用。测试风险清单通常在测试计划评审时建立初版，在测试执行过程中按固定节奏更新，在版本结束后归档。维护动作包括新增风险、更新状态、核对关闭标准和清理失效记录。
字段裁剪按项目规模和信息渠道决定。小型项目可保留风险编号、风险描述、可能性、影响程度、风险等级、责任人、关闭标准七列，把应对措施并入风险描述；中大型项目建议保留完整字段，尤其是触发信号和状态，便于多人协作时判断风险进展。裁剪的原则是：删掉的列，其信息要么已在其他工具中记录，要么对跟踪决策没有影响。
评审与更新时点建议固定在三个节点：测试计划评审时确认风险清单初版和分级口径；每日或每周测试例会上更新状态和触发信号；版本发布前复核高等级风险的关闭标准是否达成。风险状态发生变化时同步更新更新日期，保证清单反映当前情况。
风险关闭时，在状态列标记已关闭并写明关闭依据，例如对应的用例执行结果或观察周期。版本结束后，将清单随测试报告一并归档，保留风险编号和关闭结论，供后续版本参考。已关闭的风险不删除记录，避免同类风险在新版本中重复识别、重复讨论。
当风险清单需要与测试计划、用例和缺陷一起流转时，可以把清单作为测试计划文档的一部分维护，把需要持续跟踪的风险条目对应到工作项，由责任人更新状态。ONES 支持测试计划的规划和执行，可多维度概览全部测试计划，并支持用例分配执行人；未通过的用例可快速创建缺陷任务，缺陷任务在测试与研发团队间流转。风险触发后产生的验证工作和缺陷，可以沿这条链路承接，风险清单本身则保留识别、应对和关闭的记录。测试报告环节，ONES 支持自动生成测试报告并提供项目缺陷分布统计，也可自定义组装测试报告模板，便于在版本复盘中回看风险处理结果。
常见问题
风险清单里的可能性与影响程度，团队各人判断不一致怎么办？
在测试计划评审时把分级口径固定下来，写进测试计划或清单的说明页，例如可能性按“近两个版本是否出现过同类问题”判断，影响程度按“是否阻塞核心链路用例、是否影响发版判断”判断。评审时抽查几条记录，核对换算出的风险等级是否符合矩阵规则。口径一旦约定，同一项目内不随个人判断调整；项目类型差异较大时，可按项目分别约定，并在清单中注明适用口径。
风险识别初期信息不全，必填项可以先空着吗？
必填项不建议留空。信息暂缺时填写“待确认”，并在备注中写明确认人和确认期限，例如风险描述只掌握部分条件时，先写已确认的条件和后果，标注“待确认：影响范围”，指定在测试计划评审前补齐。这样清单能看出哪些记录还不完整，也便于按期限跟进。选填项中的应对措施可在识别初期暂缺，进入应对阶段前补齐。
风险一直没有触发，什么时候可以关闭？
关闭依据是关闭标准是否达成，而不是风险是否发生过。关闭标准写成可核验的结果，例如相关用例全部执行通过、环境连续一个版本周期无告警、缺陷收敛到约定水平。达成后在状态列标记已关闭并写明依据。风险始终未触发但观察周期已覆盖测试执行阶段，也可按关闭标准中的观察条件判定关闭，并在记录中说明判断依据，便于后续版本复盘时理解。
小项目字段太多填不过来，怎么裁剪？
裁剪时优先保留必填项。小型项目可保留风险编号、风险描述、可能性、影响程度、风险等级、责任人、关闭标准七列，把应对措施并入风险描述。触发信号和状态在多人协作、风险需要持续跟踪时建议保留。删除某列前确认该列信息要么已在其他工具中记录，要么对跟踪决策没有影响；风险编号、责任人和关闭标准建议始终保留，保证每条风险有独立可查的记录。
风险清单和测试计划、缺陷记录怎么衔接？
常见做法是把清单作为测试计划文档的一部分维护，需要持续跟踪的风险条目对应到工作项，由责任人更新状态。风险触发后产生的验证工作和缺陷，沿测试执行链路承接，清单本身保留识别、应对和关闭的记录。ONES 支持测试计划的规划和执行，可多维度概览全部测试计划，并支持用例分配执行人；未通过的用例可快速创建缺陷任务，缺陷任务在测试与研发团队间流转。测试报告环节支持自动生成测试报告并提供项目缺陷分布统计，也可自定义组装测试报告模板，便于在版本复盘中回看风险处理结果。
