测试风险说明用于记录当前测试或版本结论中尚未消除的风险，让评审人员能判断影响、核对证据并跟踪关闭。本文提供一张可直接复制填写的空白表，逐项说明字段口径，并给出一条完整示例，适合测试负责人、开发负责人和版本评审参与者共同使用。
要点总览（TL;DR）
- 空白表按“一条风险一行”组织，包含风险描述、影响范围、可能性、严重程度、风险等级、证据、应对措施、责任人、关闭条件与状态等字段，复制即可填写。
- 风险等级由发生可能性与严重程度分别评估后查表得出，同一份说明内使用同一套判定口径。
- 最小必填集为风险描述、影响范围、可能性、严重程度、风险等级、证据、责任人、关闭条件与状态；措施类型、序号、更新日期可按场合选填。
- 填写示例展示证据与关闭条件的对应关系：用例通过、缺陷关闭即风险解除，状态随之更新。
- 模板可按项目规模裁剪字段，增删需记录版本；风险状态在每轮测试结束与版本评审前复核。
可复制空白测试风险说明表
下表按“一条风险一行”组织，复制到文档或表格工具后即可填写。表头与后文字段说明一一对应，空白单元格保留原样，便于直接录入。填写前先确定本次说明对应的测试轮次或版本范围，再逐条登记风险。
| 序号 | 风险描述 | 影响范围 | 发生可能性 | 严重程度 | 风险等级 | 证据 | 应对措施 | 措施类型 | 责任人 | 关闭条件 | 状态 | 更新日期 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
风险等级由发生可能性与严重程度共同决定，建议先分别评估两项，再查下表得出等级，避免凭整体印象直接定级。
| 发生可能性 \ 严重程度 | 轻微 | 一般 | 严重 | 致命 |
|---|---|---|---|---|
| 高 | 中 | 高 | 高 | 高 |
| 中 | 低 | 中 | 高 | 高 |
| 低 | 低 | 低 | 中 | 高 |
等级判定表可按团队习惯调整阈值，但同一份测试风险说明内应使用同一套判定口径，并在表头或表下注明所采用的版本。
字段说明：每个字段填什么、怎么判断
字段说明解决“不同角色填出来不一致”的问题。以下逐项给出含义、填写口径与判断依据，填写时以本说明为准，模板、说明与示例使用同一套用词。
| 字段 | 含义 | 填写口径 | 判断依据 |
|---|---|---|---|
| 序号 | 风险条目的唯一编号 | 按登记顺序编号，后续引用不改号 | 与测试报告、缺陷单互相引用时能对应 |
| 风险描述 | 说明什么条件下会出现什么现象 | 写“触发条件＋现象”，一句话说清，不写笼统的“可能有风险” | 读者能据此判断该风险是否与当前版本相关 |
| 影响范围 | 风险一旦发生波及的对象 | 写明版本、模块、用户群体或业务流程，可多项并列 | 能定位到具体功能或使用场景，而非“全系统” |
| 发生可能性 | 风险在现网或后续使用中出现的概率 | 按高、中、低三档评估，附一句判断理由 | 依据测试覆盖情况、缺陷复现频率、代码改动范围 |
| 严重程度 | 风险发生后造成的后果大小 | 按轻微、一般、严重、致命四档评估 | 依据对用户业务、数据、流程中断的影响程度 |
| 风险等级 | 可能性与严重程度的组合结果 | 查等级判定表得出，不单独主观指定 | 与判定表口径一致 |
| 证据 | 支撑该风险成立的依据 | 写可复核的用例编号、日志片段、缺陷单号或测试数据 | 他人按证据能自行复现或核对 |
| 应对措施 | 针对该风险采取的动作 | 写具体动作与预期效果，如补充用例、加开关、限制入口、延后上线 | 措施与风险描述对应，能降低可能性或严重程度 |
| 措施类型 | 措施的性质 | 从规避、缓解、接受、转移中选择 | 规避指绕开触发条件；缓解指降低影响；接受指已知并承担；转移指由其他环节或方承担 |
| 责任人 | 推动措施落实的人 | 写具体姓名或角色，一名主责 | 该人能调动所需资源并更新状态 |
| 关闭条件 | 判定风险解除的标准 | 写可验证的结果，如“补充用例全部通过”“缺陷修复并回归通过” | 条件达成时可客观判断，无需再讨论 |
| 状态 | 风险当前处理阶段 | 按待处理、处理中、已缓解、已关闭、已接受流转 | 状态变化须有对应证据或措施进展 |
| 更新日期 | 最近一次修改时间 | 每次变更状态或内容时更新 | 用于复核节奏与版本追溯 |
可能性与严重程度分开评估是关键。可能性回答“会不会发生”，严重程度回答“发生了有多糟”，两者混在一起容易把低频高损风险低估，也容易把高频低损风险高估。证据字段则把风险从主观判断变成可复核的事实，缺少证据的条目应在评审前补齐或降级处理。
必填与选填：哪些字段不能空
模板字段较多，但并非每次评审都需要全部填满。最小可用集保证风险可判断、可跟踪、可关闭；其余字段按场合补充，避免模板过重导致填写流于形式。
| 字段 | 必填/选填 | 缺失后果或适用场景 |
|---|---|---|
| 风险描述 | 必填 | 缺失则无法判断风险内容，条目无效 |
| 影响范围 | 必填 | 缺失则无法评估波及对象，评审无法决策 |
| 发生可能性 | 必填 | 缺失则等级无法判定 |
| 严重程度 | 必填 | 缺失则等级无法判定 |
| 证据 | 必填 | 缺失则风险不可复核，易被视为主观判断 |
| 责任人 | 必填 | 缺失则无人推动，状态无法更新 |
| 关闭条件 | 必填 | 缺失则风险无法判定何时解除 |
| 状态 | 必填 | 缺失则无法跟踪处理进展 |
| 风险等级 | 必填 | 由可能性与严重程度推出，评审排序依赖此字段 |
| 应对措施 | 测试结论评审必填 | 版本结论评审可先写“待定”，但须在结论前补齐 |
| 措施类型 | 选填 | 需要区分接受与缓解、向上汇报时填写 |
| 序号 | 选填 | 条目较多或需跨文档引用时填写 |
| 更新日期 | 选填 | 需要复核节奏管理或版本追溯时填写 |
测试结论评审关注“当前测试是否充分”，应对措施与证据是重点；版本结论评审关注“能否发布”，风险等级、应对措施与关闭条件是重点。状态流转至少需要风险描述、责任人、关闭条件与状态四项同时存在，否则状态变化缺少依据。选填字段可以后补，但补填时应同步更新日期，保持记录可追溯。
填写示例：一条完整测试风险记录
以下示例为演示情景，用于说明字段如何配合，不代表真实项目数据。
| 字段 | 填写内容 |
|---|---|
| 序号 | R-03 |
| 风险描述 | 订单导出在单次超过5000条时，导出任务偶发超时且无明确失败提示，用户可能重复提交 |
| 影响范围 | V2.4版本订单管理模块，使用批量导出的运营人员 |
| 发生可能性 | 中：压测中5000条以上场景复现2次，日常导出量多数低于该阈值 |
| 严重程度 | 一般：导出失败可重试，不造成数据错误，但影响运营效率 |
| 风险等级 | 中 |
| 证据 | 用例TC-ORDER-118执行记录、压测日志片段、缺陷单BUG-2261 |
| 应对措施 | 增加导出超时提示与失败重试入口；对超过5000条的导出改为异步任务并提示进度 |
| 措施类型 | 缓解 |
| 责任人 | 订单模块开发负责人 |
| 关闭条件 | 异步导出改造完成，TC-ORDER-118及新增超时提示用例全部通过，BUG-2261关闭 |
| 状态 | 处理中 |
| 更新日期 | 填写当日日期 |
逐项看，风险描述写清了触发条件（超过5000条）与现象（超时、无提示、可能重复提交）；影响范围定位到版本、模块和用户群体；可能性与严重程度分别给出档位和理由，等级由判定表得出为中；证据列出用例、日志和缺陷单，均可复核；应对措施是具体动作，措施类型为缓解；关闭条件与证据形成对应——用例通过、缺陷关闭即风险解除，状态“处理中”与措施尚未完成一致。
调整与维护：按团队情况改字段并持续更新
模板拿到后不必原样照搬。调整的原则是：字段服务于判断和跟踪，新增字段要有明确填写口径，删除字段不能破坏“可判断、可跟踪、可关闭”这条主线。
按项目规模裁剪。小型项目可合并“措施类型”与“应对措施”，保留必填集即可运转；跨团队或对外交付的项目建议保留序号、更新日期，便于跨文档引用和复核。按风险类型增补。涉及数据迁移、第三方依赖或合规要求的项目，可增加“依赖方”“合规影响”等字段，并在字段说明中同步补充口径。任何增删都应记录在模板变更记录中，注明版本号、变更内容和生效范围。
维护节奏上，风险状态应在每次测试轮次结束、缺陷修复回归后更新，版本结论评审前做一次全量复核。复核检查项包括：状态为“处理中”的条目是否有进展记录；关闭条件达成的条目是否已改为“已关闭”并附证据；超过约定时间未更新的条目是否仍有效；已接受的风险是否经责任人确认。测试风险说明与测试报告对应，报告中的结论应能追溯到具体风险条目；与缺陷记录对应，证据字段引用缺陷单号，缺陷关闭时同步检查风险关闭条件是否满足。
当风险条目需要在测试过程中由多人持续更新、并与缺陷和测试报告保持对应时，可以把每条风险登记为工作项，用状态字段承载“待处理、处理中、已缓解、已关闭、已接受”的流转，把证据和关闭条件写入描述或关联记录。ONES 支持工作项状态流转与文档记录，测试负责人可在同一处查看风险进展并完成评审交接，减少表格多版本并存带来的口径不一致。是否采用工具承载，取决于团队规模与协作频率；条目少、参与人固定的团队继续使用本文表格也能满足要求。
常见问题
测试风险说明和缺陷记录有什么区别，需要重复登记吗？
两者记录对象不同。缺陷记录描述已发现的、可复现的问题及其修复过程；测试风险说明记录尚未消除、可能影响当前测试或版本结论的风险，包括发生条件尚不确定或影响面较广的情况。实际操作中不必重复登记：风险条目在证据字段引用缺陷单号，缺陷关闭时检查风险关闭条件是否满足，两者保持对应即可。
风险等级判定表和团队已有的定级标准不一致时怎么办？
以当前测试风险说明内注明的判定口径为准，并在表头或表下写明所采用的版本。若团队已有定级标准，可将其阈值映射到本文的可能性与严重程度两维表，但同一份说明内不要混用两套标准。跨团队评审时，提前说明所用口径，避免对“高”“中”的理解出现分歧。
评审时风险条目还没定好应对措施，可以先提交吗？
测试结论评审中，应对措施属于必填，缺失会使评审无法判断测试是否充分。版本结论评审可先写“待定”，但须在结论形成前补齐，并同步更新日期。若风险处于已接受状态，应在措施类型中注明接受，并由责任人确认承担后果。
风险条目较多时，用表格还是用工具管理更合适？
取决于参与人数和更新频率。条目少、参与人固定、更新集中在评审前后的团队，用本文表格即可满足跟踪要求。条目多、需要多人持续更新、且要与缺陷和测试报告保持对应时，可把每条风险登记为工作项，用状态字段承载流转，把证据与关闭条件写入描述或关联记录。ONES 支持工作项状态流转与文档记录，便于在同一处查看风险进展并完成评审交接；是否采用工具承载，按团队规模与协作频率决定。
已关闭的风险还需要保留在说明里吗？
建议保留。已关闭条目是版本结论的依据之一，评审时可据此说明风险已处理完毕。保留时确保关闭条件达成有对应证据，状态与证据一致；若后续版本再次出现同类风险，可引用原序号重新登记，避免编号混乱。
