缺陷影响评估要回答的是“这个缺陷影响多大”，依据应围绕六类信息组织：影响范围、业务后果、触发条件与可复现性、发生频率与时间窗口、数据与合规风险、恢复代价。把这些依据落到可填写的字段和可核对的证据上，再由提交人提供复现与影响证据、评估人按统一口径判定等级、复核人确认高等级结论，评估结果才能支撑后续处理。评估环节只负责定影响大小，处理归属与排队交给分诊环节。
要点总览（TL;DR）
- 缺陷影响评估围绕六类依据展开：影响范围、业务后果、触发条件与可复现性、发生频率与时间窗口、数据与合规风险、恢复代价，每类都对应可填写的字段和可核对的证据。
- 等级判定按固定顺序执行：先看业务后果与数据合规风险，再看影响范围与发生频率，最后结合恢复代价校准，避免同一缺陷不同人判出不同等级。
- 提交人负责提供复现与影响证据，评估人按统一口径判定等级并写明理由，复核人确认严重、高等级或暂定等级的结论。
- 证据不足时可给暂定等级并标注待补证据，判定理由为必填项，评估记录与缺陷同源存放，便于复核与复盘。
- 评估只回答影响多大，结论交接给分诊环节决定处理归属与排队顺序，工单紧急性交由优先级与 SLA 管理。
缺陷影响评估要收集哪六类依据
评估依据的价值在于可填写、可核对、可追溯。六类依据分别回答不同问题，缺一类就可能让等级判定失去支撑。建议在缺陷工作项上为每类依据设置独立字段，证据以附件、截图、日志片段或链接形式随缺陷留存。
| 依据类别 | 回答的问题 | 提供人 | 证据形式 |
|---|---|---|---|
| 影响范围 | 哪些用户、功能、模块、环境受到影响，范围边界在哪里 | 提交人（测试或业务方） | 受影响功能清单、环境说明、用户群体描述、影响面截图 |
| 业务后果 | 流程是否中断、数据是否出错、对外服务是否受损，损失表现是什么 | 提交人，必要时由业务负责人确认 | 业务场景描述、错误结果截图、受影响订单或记录样例 |
| 触发条件与可复现性 | 在什么条件下出现，复现步骤是什么，复现概率多高 | 提交人 | 复现步骤、复现次数与尝试次数、录屏或日志 |
| 发生频率与时间窗口 | 偶发还是必现，是否集中在高峰时段或特定周期 | 提交人，监控或运维补充 | 发生次数统计、时间分布、监控告警记录 |
| 数据与合规风险 | 是否造成数据错误、泄露，是否影响审计与合规要求 | 提交人初判，数据或合规责任人确认 | 受影响数据范围说明、合规条款对照、审计影响描述 |
| 恢复代价 | 回滚、修复、临时绕行各需要多少工作量与协调成本 | 评估人会同研发负责人 | 回滚方案与耗时估计、临时绕行方案、修复涉及模块清单 |
六类依据中，影响范围与业务后果决定缺陷的严重程度，触发条件与发生频率决定它出现的可能性，数据与合规风险往往单独抬高等级，恢复代价则影响处置的紧迫感。收集时允许某类依据暂时缺失，但必须在字段中标注缺失原因和补证计划，不能留空默认按低影响处理。
把依据转成影响等级：字段与判定口径
同一缺陷由不同人评估得出不同等级，通常源于判定口径不统一。解决办法是固定影响等级字段的取值、每级的判定条件，以及判定的先后顺序。
| 影响等级 | 判定条件 | 典型证据 | 判定顺序 |
|---|---|---|---|
| 严重 | 核心业务流程中断，或造成数据错误、数据泄露、对外服务不可用，且无临时绕行方案 | 流程中断截图、错误数据样例、合规影响说明 | 第一步：业务后果与数据风险 |
| 高 | 主要功能受损但有临时绕行，或影响较大用户群体，或必现且集中在高峰时段 | 受影响用户范围、绕行方案、复现记录 | 第二步：影响范围与发生频率 |
| 中 | 局部功能异常，影响有限用户，存在可接受的绕行方式 | 功能范围说明、复现步骤 | 第二步：影响范围与发生频率 |
| 低 | 体验或展示类问题，不影响业务流程与数据正确性 | 界面截图、影响描述 | 第三步：恢复代价与整体判断 |
判定按固定顺序执行：先看业务后果与数据合规风险，只要命中严重条件即定为严重，不再因影响范围小而下调；未命中时再看影响范围与发生频率，确定高或中；最后结合恢复代价做整体校准。这个顺序的作用是让数据风险和业务中断优先于用户数量，避免“只有少量用户遇到”掩盖严重后果。
证据不足时，评估人可以给出暂定等级，并在字段中标注“暂定”和待补证据清单，例如缺少复现录屏或缺少业务方确认。暂定等级需要进入复核，补证后重新判定。无论等级高低，判定理由为必填项，写明命中了哪条判定条件、依据了哪些证据，使结论在缺陷关闭后仍可追溯。
评估流程中的角色与交付物
评估要形成可执行的交接，需要明确三类角色各自的动作、输入和输出。角色可以由不同岗位承担，但职责边界要在流程中写清楚。
| 角色 | 动作 | 输入 | 输出 | 交接时点 |
|---|---|---|---|---|
| 提交人 | 填写复现步骤、影响范围与业务后果证据，标注发生频率与数据影响初判 | 测试执行结果、用户反馈、监控告警 | 六类依据中可获取部分的字段与证据附件 | 缺陷提交时同步完成，缺失项标注原因 |
| 评估人 | 按判定顺序核对依据，确定影响等级并写明判定理由 | 提交人填写的依据与证据 | 影响等级、判定理由、暂定标注（如有） | 缺陷进入评估队列后的约定时限内 |
| 复核人 | 对严重、高等级或暂定等级的缺陷复核证据与理由，确认或调整结论 | 评估人的判定记录与原始证据 | 复核结论与复核意见 | 评估完成后、交接分诊前 |
交接的关键节点有两个：提交人向评估人交接时，依据字段应达到可判定的完整度；评估人向复核人交接时，判定理由必须能对应到具体证据。复核通过后，评估结论随缺陷一并交给分诊环节，由分诊决定处理归属与排队顺序。评估记录与缺陷同源存放，后续复盘时可以直接回看当时的依据和理由，不必另行翻找文档。
在工具承载上，ONES Project 支持缺陷跟踪管理与自定义属性，可以把六类依据和影响等级配置为缺陷工作项的字段，判定理由写在描述或评论中，使评估记录与缺陷本身保持在同一处。ONES TestCase 支持由未通过的用例快速创建缺陷任务，让测试执行中发现的缺陷带着用例上下文进入评估。具体字段配置与流程控制方式，可在试用或演示中结合实际流程确认。
示例：一个支付失败缺陷如何定级
以下为演示情景，用于说明依据如何支撑等级结论。
背景与已知证据：某电商系统在促销活动期间，部分用户提交订单后支付环节返回失败，订单状态停留在待支付。测试人员复现三次均失败，客服收到若干用户反馈，监控显示失败集中在活动开始后的两小时内。
六类依据逐项填写：
- 影响范围：支付功能整体受影响，涉及活动期间下单的全部用户，生产环境，移动端与网页端均出现。
- 业务后果：下单流程在支付环节中断，订单无法完成，用户可能重复下单；对外支付服务表现为不可用。
- 触发条件与可复现性：活动价商品下单后进入支付即失败，复现三次全部失败，复现概率为必现。
- 发生频率与时间窗口：活动开始后两小时内集中出现，与流量高峰重合，监控告警记录可查。
- 数据与合规风险：订单状态停留在待支付，暂未发现扣款成功但订单未生成的情况，数据一致性风险待确认。
- 恢复代价：临时绕行方案为引导用户稍后重试，修复需排查支付网关调用链路，回滚涉及活动配置，工作量中等偏上。
依据到等级的映射：按判定顺序，先看业务后果——核心下单支付流程中断且对外服务受损，命中严重条件；数据一致性风险尚未排除，进一步支持严重判定。影响范围覆盖活动期间全部下单用户，发生频率为必现且集中在高峰时段，与严重结论一致。恢复代价中等偏上，不作为下调等级的理由。最终影响等级定为严重，判定理由写明“支付环节必现失败导致下单流程中断，影响活动期间全部下单用户，数据一致性风险待确认”。
复核结论与交接：复核人核对复现录屏、监控告警与订单样例后确认严重等级，并备注数据一致性需在修复过程中同步排查。评估结论连同证据交接给分诊环节，由分诊确定处理归属与排队顺序，评估环节不再介入。
评估完成检查清单
一次影响评估达到可交付状态，可以逐项核对以下内容：
- 六类依据是否均有记录；缺失的类别是否标注了缺失原因与补证计划。
- 影响等级是否已填写，且与判定顺序的核对结果一致。
- 判定理由是否写明命中的判定条件与所依据的证据，而非只写结论。
- 暂定等级是否标注“暂定”并列出待补证据，是否已安排补证。
- 严重与高等级缺陷是否经过复核人确认，复核意见是否留存。
- 评估结论与证据是否已交接给分诊环节，交接时点是否可查。
- 评估记录是否与缺陷同源存放，后续复盘能否直接回看依据与理由。
清单全部通过，说明这次评估已经回答了“影响多大”的问题，可以把缺陷交给分诊继续处理；存在未通过项时，应先补齐依据或完成复核，再进入下一环节。
常见问题
某类依据暂时拿不到，评估还能继续吗？
可以继续，但要把缺失显性化。在对应字段中标注缺失原因和补证计划，例如缺少复现录屏、等待业务方确认影响范围，同时给出暂定等级并标注“暂定”。暂定等级需要进入复核，补证后重新判定。关键是不能留空默认按低影响处理，否则缺失会被误读为结论。
影响范围很小但后果严重，等级应该怎么定？
按判定顺序，先看业务后果与数据合规风险。只要命中严重条件，例如核心流程中断、数据错误或泄露、对外服务不可用且无临时绕行，就定为严重，不因影响用户数量少而下调。影响范围与发生频率在第二步用于区分高与中，不用于推翻第一步的严重结论。
评估人和复核人能否由同一人承担？
小团队中角色可以由同一岗位兼任，但建议在流程中保留复核动作，尤其是严重、高等级和暂定等级的缺陷。复核的重点是核对判定理由能否对应到具体证据，而不是重新走一遍评估。团队规模扩大或缺陷量上升后，再把复核职责拆到独立岗位，交接物仍是判定记录与原始证据。
评估结论出来后，和分诊环节怎么衔接？
评估结论随缺陷一并交给分诊，交接内容包括影响等级、判定理由和支撑证据。分诊据此决定处理归属与排队顺序，评估环节不再介入。交接时点要可查，便于后续复盘时区分“当时判定影响多大”和“后来如何安排处理”两件事。
评估记录放在哪里，后续复盘才方便回看？
建议与缺陷同源存放：六类依据和影响等级用工作项字段承载，判定理由写在描述或评论中，证据以附件或链接随缺陷留存。这样缺陷关闭后仍能直接回看当时的依据和理由，不必另行翻找文档。ONES Project 支持缺陷跟踪管理与自定义属性，可以把这些依据配置为缺陷工作项的字段；ONES TestCase 支持由未通过的用例快速创建缺陷任务，让缺陷带着用例上下文进入评估。具体字段配置方式可在试用或演示中结合实际流程确认。
