缺陷影响评估清单用于在缺陷进入分级评审前，把“影响有多大、该定什么级别”拆成可逐项核对的检查项。清单围绕影响范围、业务后果、用户与数据风险、可恢复性、复现与暴露条件、时间与合规约束六个维度展开，按评估前准备、影响判定、级别确认三个阶段组织，每项写明通过标准、证据、负责人和检查时点，并单独标出阻断项。它只解决影响判断与级别确认，不决定缺陷派给谁、如何排队。
要点总览（TL;DR）
- 清单围绕影响范围、业务后果、用户与数据风险、可恢复性、复现与暴露条件、时间与合规约束六个维度组织，按评估前准备、影响判定、级别确认三个阶段逐项核对。
- 每个检查项都写明通过标准、证据、负责人和检查时点，通过标准要能指向具体产物、可由他人复核、能给出是或否的结论。
- 维度冲突时以最高影响维度定级，其余维度写入定级说明；级别倾向只是判断起点，最终级别需结合证据确认。
- 阻断项与普通检查项分开管理：核心链路不可用且无绕行、数据损坏或泄露范围未确认、定级依据缺失等情形未通过时，缺陷不进入修复排期。
- 评估完成需同时满足阻断项全部通过、定级依据与证据齐全、评审主持人与产品/业务代表确认三个条件，清单以固定字段形式嵌入缺陷记录和评审会。
谁在什么时点使用这份评估清单
这份清单在缺陷新建之后、进入分级评审之前启用，最迟应在修复方案确定前完成。评估放在修复之前，是因为修复方案本身依赖对影响的判断：一个被判定为严重的缺陷，修复范围、验证深度和发布安排都与一般缺陷不同。若等到修复完成再补评估，定级就变成对既成事实的描述，失去对资源投入的指导作用。
清单的使用者不止测试一方。提交人负责把缺陷描述清楚，模块负责人判断受影响功能与链路，测试提供复现与验证信息，产品/业务代表确认业务后果与用户范围，值班负责人对线上紧急情况给出初步判断。各角色在评估中提交或确认的内容如下：
| 角色 | 使用时点 | 提交或确认的内容 |
|---|---|---|
| 提交人 | 缺陷新建后 | 缺陷描述、环境与版本、复现步骤、初步现象 |
| 模块负责人 | 进入分级评审前 | 受影响功能与模块、是否存在绕行方案、修复复杂度初判 |
| 测试 | 进入分级评审前 | 复现结果、影响范围验证、回归风险点 |
| 产品/业务代表 | 级别确认阶段 | 业务后果、受影响用户或订单范围、时间窗口要求 |
| 值班负责人 | 线上缺陷发现时 | 紧急程度初判、是否启动临时处置、是否升级 |
需要明确边界：本清单输出的是影响结论与建议级别，不输出责任人指派和修复排期。缺陷派给哪个团队、在队列中排第几位、是否触发工单升级，属于缺陷分诊与责任分配、工单优先级管理的范围。把两件事混在一张表里，常见结果是评估被派单讨论打断，检查项填了一半就流转出去。
评估维度总览与分级映射
六个维度各自回答一个独立问题，合起来构成对缺陷影响的完整描述。影响范围回答“坏了多大一片”，业务后果回答“对业务意味着什么”，用户与数据风险回答“有没有人受损、数据是否安全”，可恢复性回答“能不能快速恢复”，复现与暴露条件回答“在什么条件下会发生、暴露面多大”，时间与合规约束回答“有没有必须赶上的时点和外部要求”。
| 维度 | 核心判断问题 | 级别倾向 |
|---|---|---|
| 影响范围 | 受影响的功能、模块、系统数量与关键程度 | 核心链路整体不可用倾向致命；核心链路部分受损倾向严重；边缘功能受影响倾向一般 |
| 业务后果 | 是否阻断交易、交付、结算等关键业务动作 | 关键业务中断倾向致命或严重；体验受损倾向一般；仅展示异常倾向轻微 |
| 用户与数据风险 | 受影响用户规模、数据是否损坏、泄露或错算 | 数据泄露或不可逆损坏倾向致命；可修复的数据错误倾向严重；个别用户受影响倾向一般 |
| 可恢复性 | 有无绕行方案、恢复所需时间与操作成本 | 无绕行且恢复时间长倾向严重及以上；有稳定绕行可下调一级 |
| 复现与暴露条件 | 复现概率、触发条件是否常见、是否已在生产暴露 | 生产环境高频触发倾向严重；特定条件偶发倾向一般；难以触发倾向轻微 |
| 时间与合规约束 | 是否临近发布、结算、申报等时点，是否涉及合规要求 | 卡住硬性时点或涉及合规风险倾向严重及以上 |
维度之间出现冲突时，以最高影响维度定级，其余维度写入定级说明，而不是相互抵消。例如影响范围只涉及一个边缘模块，但该缺陷导致用户数据错算，应按用户与数据风险维度定级，并在说明中注明范围有限这一事实。反过来，范围很大但仅影响展示样式，也不因范围广而拔高到严重。级别倾向是判断起点，最终级别仍需结合证据确认。
分阶段检查项与通过标准
检查项写成可观察、可判断完成与否的表述，避免“评估影响”“确认风险”这类无法核对的动词。以下三张表按阶段排列，每项都给出通过标准、所需证据、负责人和检查时点，可直接作为评审时的核对底稿。
准备阶段
| 检查项 | 通过标准 | 证据 | 负责人 | 检查时点 |
|---|---|---|---|---|
| 缺陷描述完整性 | 现象、预期结果、实际结果三项均已填写，无“待补充”占位 | 缺陷记录正文 | 提交人 | 缺陷新建后 |
| 环境与版本信息 | 写明环境类型、版本号或构建号，可定位到具体发布批次 | 环境标识、版本截图 | 提交人 | 缺陷新建后 |
| 复现步骤可执行 | 他人按步骤可复现，或已注明“不可稳定复现”及已尝试次数 | 操作步骤、复现录屏 | 测试 | 进入分级评审前 |
影响判定阶段
| 检查项 | 通过标准 | 证据 | 负责人 | 检查时点 |
|---|---|---|---|---|
| 受影响功能与模块 | 列出具体功能点与模块名，区分主链路与边缘功能 | 模块清单、链路说明 | 模块负责人 | 进入分级评审前 |
| 受影响用户范围 | 给出用户数、订单量或租户数等量化口径，或注明“范围待确认”及确认计划 | 查询结果、统计截图 | 产品/业务代表 | 级别确认阶段 |
| 数据是否受损或泄露 | 明确结论为“无数据影响”“数据错误可修复”“数据不可逆损坏或泄露”之一 | 数据核对结果、日志 | 模块负责人与测试 | 级别确认阶段 |
| 临时绕行方案 | 写明绕行操作、适用用户、预计可维持时长，或明确“无绕行” | 操作说明、业务方确认记录 | 模块负责人 | 级别确认阶段 |
级别确认阶段
| 检查项 | 通过标准 | 证据 | 负责人 | 检查时点 |
|---|---|---|---|---|
| 定级依据已写明 | 引用至少一个维度的判断结论，并说明为何未采用更高或更低级别 | 定级说明字段 | 评审主持人 | 分级评审会 |
| 与同类历史缺陷口径一致 | 检索同类缺陷并比对级别，差异处写明原因 | 历史缺陷记录、比对说明 | 测试 | 分级评审会 |
| 不确定项已记录 | 所有未确认项标注“待确认”、责任人和确认期限 | 待确认清单 | 评审主持人 | 分级评审会 |
通过标准的写法可以归纳为三条：能指向一个具体产物（字段、截图、记录），能由他人复核，能给出“是/否”或有限选项的结论。像“影响较大”这样的表述无法判断是否完成，应改为“受影响订单量已统计并写入记录”。
证据留存与负责人分工
证据的作用是让定级结论在事后可复核，而不是在评审会上重新争论一遍。每类检查项对应固定的证据类型和提供人，复核人与签字人分开设置，避免同一人既提供证据又确认结论。
| 证据类型 | 对应检查项 | 提供人 | 复核人 | 签字确认 |
|---|---|---|---|---|
| 日志与错误堆栈 | 复现步骤、数据影响判断 | 测试或模块负责人 | 模块负责人 | 评审主持人 |
| 截图或录屏 | 缺陷现象、绕行方案演示 | 提交人或测试 | 测试 | 评审主持人 |
| 影响用户数或订单量 | 受影响用户范围 | 产品/业务代表 | 模块负责人 | 产品/业务代表 |
| 数据核对结果 | 数据是否受损或泄露 | 模块负责人 | 测试 | 评审主持人 |
| 业务方确认记录 | 业务后果、时间窗口要求 | 产品/业务代表 | 值班负责人 | 产品/业务代表 |
证据缺失时，处理方式是标注“待补”并写明该缺口对定级的影响，例如“受影响用户数未确认，当前按已知范围暂定严重，若确认范围扩大需上调”。不能用默认值或经验估计代替确认，也不能因为证据暂时拿不到就把检查项直接勾选通过。待补项应带责任人和期限，进入下一次评审时优先核对。
阻断项与评估完成条件
阻断项与普通检查项分开管理：阻断项未通过，缺陷不进入修复排期；普通检查项未通过，标注待补后可以继续流转，但需记录对定级的影响。这样区分是为了让紧急缺陷在信息不全时仍能被处置，同时不让关键判断被跳过。
以下情形应设为阻断项：
- 核心链路不可用且无绕行方案，影响范围尚未确认。
- 存在数据损坏或泄露，但受损范围、涉及字段或用户群未确认。
- 定级依据缺失，缺陷记录中没有引用任何维度的判断结论。
- 复现步骤不可执行且未注明不可复现原因，导致影响无法验证。
非阻断但需记录的项包括：影响范围待确认、复现环境与生产环境不一致、同类历史缺陷口径尚未比对、业务方确认记录待补。这些项不阻止流转，但必须在缺陷记录中留下待补说明和责任人。
整份评估被视为完成，需同时满足三个条件：所有阻断项通过；定级依据与对应证据齐全；评审主持人与产品/业务代表完成确认。三个条件缺一，评估状态保持“进行中”，缺陷可以按临时级别处置，但需在记录中注明临时级别及复核时点。
把清单落到缺陷记录与评审流程中
清单要持续使用，需要把检查项变成缺陷记录中的固定字段，而不是每次评审临时拉一张表。建议在缺陷记录中设置以下字段：影响范围、受影响用户或订单量、数据影响结论、绕行方案、定级依据、阻断项状态、待确认项及责任人。字段值采用有限选项或结构化文本，便于后续统计和比对。
评审会上的核对顺序按阶段推进：先确认准备阶段三项是否齐全，再逐项过影响判定，最后确认级别与依据。主持人按表逐项点名，记录人同步更新字段状态，未通过项当场标注待补或阻断。会议结束前复述一遍阻断项和待确认项，避免散会后无人跟进。
评估结论发生变更时，需要重新核对受影响的检查项。级别上调通常意味着影响范围或数据风险有新证据，应重新确认受影响用户范围和数据影响结论；级别下调则需补充绕行方案或复现条件变化的证据。变更记录保留原结论、新结论和变更依据，便于后续同类缺陷比对口径。
在工具承载上，ONES 测试管理支持未通过的用例快速创建缺陷任务，缺陷任务在测试与研发团队间流转，评估所需的复现信息可以从用例执行结果带入缺陷记录。测试用例可与需求、任务关联，测试计划与迭代关联，缺陷也可关联至迭代，便于在评审时追溯缺陷对应的需求背景和发布批次。项目缺陷分布统计可用于比对同类缺陷的级别口径，沉淀问题与经验。需要说明的是，缺陷记录中评估字段的自定义范围和评审签字的留痕方式，需以实际产品配置为准；清单落地前应先确认字段配置能否覆盖上述检查项，再决定哪些项在工具内记录、哪些以附件形式留存。
常见问题
缺陷影响评估清单和缺陷分诊、工单优先级管理怎么衔接？
本清单只输出影响结论与建议级别，不输出责任人指派和修复排期。缺陷派给哪个团队、在队列中排第几位、是否触发工单升级，属于缺陷分诊与责任分配、工单优先级管理的范围。实际操作中，评估完成后把建议级别和定级依据交给分诊环节，分诊据此决定处理归属和排队顺序；两件事混在一张表里，常见结果是评估被派单讨论打断，检查项填了一半就流转出去。
证据暂时拿不到，能不能先按经验估一个级别继续流转？
不建议用默认值或经验估计代替确认。证据缺失时，处理方式是在缺陷记录中标注“待补”，写明该缺口对定级的影响，例如“受影响用户数未确认，当前按已知范围暂定严重，若确认范围扩大需上调”，并带上责任人和期限。若缺失的属于阻断项，缺陷不进入修复排期；若属于非阻断项，可以按临时级别处置，但需在记录中注明临时级别及复核时点，下一次评审时优先核对。
同一缺陷在多个维度上判断结果不一致，最终级别怎么定？
以最高影响维度定级，其余维度写入定级说明，而不是相互抵消。例如影响范围只涉及一个边缘模块，但该缺陷导致用户数据错算，应按用户与数据风险维度定级，并在说明中注明范围有限这一事实；反过来，范围很大但仅影响展示样式，也不因范围广而拔高到严重。定级说明中要写清为何未采用更高或更低级别，便于后续同类缺陷比对口径。
评估结论在修复过程中发生变化，需要重新核对哪些内容？
级别上调通常意味着影响范围或数据风险有新证据，应重新确认受影响用户范围和数据影响结论；级别下调则需补充绕行方案或复现条件变化的证据。变更记录保留原结论、新结论和变更依据。若变更涉及阻断项状态，需重新走一遍阻断判定，确认缺陷是否可以继续流转。
在缺陷管理工具中落地这份清单，需要先确认哪些配置？
先确认缺陷记录能否设置影响范围、受影响用户或订单量、数据影响结论、绕行方案、定级依据、阻断项状态、待确认项及责任人等字段，以及字段值能否采用有限选项或结构化文本。ONES 测试管理支持未通过的用例快速创建缺陷任务，缺陷任务在测试与研发团队间流转，评估所需的复现信息可以从用例执行结果带入缺陷记录；测试用例可与需求、任务关联，测试计划与迭代关联，缺陷也可关联至迭代，便于追溯需求背景和发布批次。项目缺陷分布统计可用于比对同类缺陷的级别口径。缺陷记录中评估字段的自定义范围和评审签字的留痕方式，需以实际产品配置为准，落地前先确认字段配置能否覆盖检查项，再决定哪些项在工具内记录、哪些以附件形式留存。
