缺陷分级要先把“影响范围、功能受损程度、有无绕行方案、数据与安全风险”四个判断项写成可勾选的判定表，再据此映射到固定等级，并规定每级的响应时限、升级路径和复核人。执行时由提交人先按判定表自评，测试负责人或缺陷管理员复核定级；修复过程中若发现影响扩大，可申请改级并留记录。分级只解决“严重程度”，处理归属与排队顺序交给分诊环节，工单紧急性交给优先级与SLA管理。
要点总览（TL;DR）
- 缺陷分级先定四个判断项：影响范围、功能受损程度、绕行方案、数据与安全风险，逐项勾选后分级才有可复核的依据。
- 等级建议四到五级，用“任一命中即升级”的映射规则，并预先规定多维度冲突时的优先顺序：数据与安全风险优先，其次功能受损程度、影响范围、绕行方案。
- 流程分六步：提交人自评、测试负责人或缺陷管理员复核、记录定级依据、进入响应流程、改级申请、改级审批，定级完成以五项字段齐全且响应要求生效为标志。
- 提交人只做自评，复核人负责确认与调整，开发可申请改级但不能自行改级，项目负责人裁定争议与发版影响。
- 机制是否落地看两件事：同类缺陷不同人定出相同等级，定级结果能驱动响应时限与发版决策；按季度或触发条件复盘修订判定表。
先定判定项：缺陷分级的四个判断维度
分级争议通常来自判断依据不统一：有人按“用户会不会投诉”定，有人按“改起来麻不麻烦”定。把判断依据拆成四个可勾选的维度，分级就从主观印象变成可复核的判断。四个维度分别回答：影响多大、功能坏到什么程度、用户能不能绕过去、有没有数据与安全后果。
每个维度只设少量取值，取值之间要有明确分界。下表可直接作为判定表的底稿，提交缺陷时逐项勾选，并在备注中写一句依据。
| 判断维度 | 取值与说明 | 勾选方式 |
|---|---|---|
| 影响范围 | 单点：个别用户、个别设备或个别数据；模块：某个功能模块内的多条路径；全局：主流程、多模块或全部用户受影响 | 三选一，按已确认受影响的最大范围勾选 |
| 功能受损程度 | 不可用：功能无法完成；部分可用：主路径可走但分支、边界或特定条件下失败；体验问题：结果正确但提示、文案、样式、性能感受不佳 | 三选一，以用户能否完成目标任务为准 |
| 绕行方案 | 无绕行：没有替代路径；有绕行但代价高：需换设备、换入口、人工补录或等待较长时间；有低成本绕行：换个操作顺序或入口即可 | 三选一，写明绕行方式和代价 |
| 数据、安全与合规风险 | 无：不涉及数据错误、越权、泄露或合规要求；有数据风险：数据错误、丢失、重复或对账不平；有安全或合规风险：越权访问、敏感信息暴露、违反约定流程 | 三选一，涉及风险时补充影响的数据对象或规则条款 |
勾选规则有三条。第一，按已确认的事实勾选，不按猜测的最坏情况勾选；无法确认时先按当前证据定级，并在记录中标注待确认项。第二，影响范围以受影响的最大范围为口径，例如单点复现但同一模块多处出现，按模块勾选。第三，绕行方案要写清代价，因为“能绕过去”和“绕过去要人工补三天数据”对严重程度的含义完全不同。
四个维度勾完后，一条缺陷就有了完整的分级依据。判定表的价值在于：两个人对同一条缺陷勾出不同结果时，可以逐项对照分歧点，而不是争论“我觉得很严重”。
把判定结果映射成等级：分级表怎么设计
等级数量建议四到五级。四级的命名可用致命、严重、一般、轻微，含义直观、便于沟通；团队已有五级习惯时，可在严重与一般之间增加“较高”一级，但每一级都必须有独立的判定组合，避免出现两级定义几乎相同、只能靠感觉选的情况。
映射规则用“任一命中即升级”的方式写，比逐条穷举组合更好执行。下表是一份可直接落地的分级表。
| 等级 | 判定条件（满足任一即可） | 典型情形 |
|---|---|---|
| 致命 | 存在安全或合规风险；或全局范围且功能不可用；或数据风险已造成错误数据扩散 | 越权查看他人订单；主流程整体不可用；批量数据错乱 |
| 严重 | 模块范围且功能不可用；或全局范围且部分可用；或数据风险限于局部且可修复；或无绕行方案 | 某模块无法提交；部分用户登录失败且无替代入口 |
| 一般 | 单点范围且功能不可用；或模块范围且部分可用；或有绕行但代价高 | 个别账号无法导出；某类条件下计算错误，可人工补录 |
| 轻微 | 体验问题；或有低成本绕行；且不涉及数据、安全与合规风险 | 提示文案错误；样式错位；低频路径的显示问题 |
多维度不一致时，需要预先规定以哪项为准。常用顺序是：数据、安全与合规风险优先，其次看功能受损程度，再看影响范围，最后看绕行方案。例如一条缺陷影响范围只是单点，但涉及敏感信息暴露，应按致命处理；反过来，全局范围的样式错位仍可定为轻微。这个优先顺序要写进分级表，避免每次临时讨论。
等级定义里应写清三件事：判定条件、典型情形、以及该等级对应的响应要求（如首次响应时限、是否阻断发版）。不应写清的是具体修复工时和责任人姓名，这两项属于排期与分派，放进分级定义会让等级随人员变动而失真。等级定义保持稳定，响应要求可以按团队节奏调整，但调整要同步更新分级表并通知所有提交人。
分级操作步骤：从提交到定级确认
分级是一次有明确起止的动作，不是提交时随手选一个下拉框。下面六步给出每步的输入、动作、输出与完成标志，测试负责人或缺陷管理员可据此建立流程。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 1. 提交自评 | 缺陷现象、复现步骤、环境与截图 | 提交人按四维度判定表逐项勾选，填写自评等级和一句依据 | 带判定项与自评等级的缺陷记录 | 四个维度均有勾选，依据可读 |
| 2. 复核定级 | 自评记录与复现信息 | 测试负责人或缺陷管理员逐项核对勾选，必要时补充复现 | 确认或调整后的等级 | 复核人签署定级结论 |
| 3. 记录定级依据 | 复核结论 | 在缺陷记录中填写定级等级、各维度取值、判定说明、复核人与定级时间 | 可追溯的定级记录 | 字段完整，后续人员可据此复现判断 |
| 4. 进入响应流程 | 定级结果 | 按等级触发对应响应时限与升级路径，交分诊环节确定处理归属 | 带响应要求的待处理缺陷 | 响应时限已生效，责任人已明确 |
| 5. 改级申请 | 修复中发现的新证据 | 开发或测试提交改级申请，说明影响变化与对应维度调整 | 改级申请记录 | 申请中写明原等级、新等级与理由 |
| 6. 改级审批 | 改级申请 | 原复核人或缺陷管理员审批，确认后更新等级并保留历史 | 更新后的等级与改级记录 | 新旧等级、审批人与时间均可查 |
定级完成的标志是：等级、四维度取值、判定说明、复核人、定级时间五项齐全，且该等级已触发对应的响应要求。缺少任一项，后续复盘时无法解释“当时为什么这么定”。
改级的常见触发情形有三类：修复时发现影响范围比提交时更大；绕行方案被证实行不通或代价远超预期；排查中发现数据或安全影响。改级不改变缺陷本身，只修正对它的判断，因此每次改级都要留下原等级、新等级、依据和审批人，便于统计定级准确率。
角色与交付物：谁定级、谁复核、谁改级
分级责任要落到具体角色，否则容易出现“提交人随手选、没人复核、开发自行降级”的情况。下表给出四个角色的职责与权限边界。
| 角色 | 分级职责 | 权限边界 | 交付物 |
|---|---|---|---|
| 提交人（测试、客服、业务方等） | 按判定表逐项勾选，给出自评等级与依据 | 可提交自评，不能最终定级 | 带判定项的自评记录 |
| 测试负责人或缺陷管理员 | 复核定级，维护判定表与分级表，审批改级 | 可确认或调整等级，调整需写理由 | 定级记录、改级审批记录、规则修订记录 |
| 开发 | 修复中提供影响变化的事实，发起改级申请 | 可申请改级，不能自行修改等级 | 改级申请及证据 |
| 项目负责人 | 确认致命与严重缺陷对发版的影响，裁决定级争议 | 可对争议定级做最终裁定 | 发版影响结论、争议裁定记录 |
分级结果要与响应机制衔接：每个等级对应首次响应时限、是否阻断发版、升级到哪一层。例如致命缺陷要求立即通知项目负责人并阻断发版，严重缺陷要求当日响应，一般与轻微按迭代排期处理。这些要求写在分级表旁边，定级完成后自动生效，分级才有实际作用。
当分级结果需要记录在缺陷工作项上，并与判定依据、改级历史一起进入流转时，可以用ONES的工作项管理来承载：在缺陷工作项上设置等级字段、判定项字段和定级说明，改级时通过状态流转保留历史记录，评审与发版判断直接引用这些字段。这样定级记录和后续响应在同一处可查，复盘时不必再到聊天记录里找依据。
示例：一条支付失败缺陷如何定级
以下为演示情景，用于说明判定与映射过程，不代表真实项目数据。
缺陷现象：某电商应用在提交订单后调用支付接口时返回失败，用户看到“支付失败，请重试”，重试仍失败。经排查，失败集中在使用某一家银行卡支付的用户，其他支付方式正常；已有一笔订单在失败后状态显示为“待支付”，但库存已扣减。
四维度勾选：
- 影响范围：模块。使用该银行卡支付的用户在该支付模块内均受影响，其他支付方式不受影响。
- 功能受损程度：不可用。该支付方式下用户无法完成支付这一目标任务。
- 绕行方案：有绕行但代价高。用户可更换其他支付方式，但已扣减的库存需要等待释放或联系客服处理。
- 数据、安全与合规风险：有数据风险。支付失败后订单状态与库存不一致，存在对账不平的可能。
映射过程：按“任一命中即升级”的规则，模块范围且功能不可用命中“严重”；同时存在数据风险，按优先顺序数据风险优先，需评估是否升为致命。复核人核对后确认：数据不一致仅影响失败订单且可通过脚本修复，未扩散到其他数据，因此定为严重，并在定级说明中写明数据风险的范围与修复方式。
复核确认理由：影响范围未达全局，数据问题可定位、可修复，绕行方案存在但代价高，综合定为严重；响应要求为当日响应并评估是否阻断当次发版。
改级情形：修复过程中发现同一问题还导致部分成功支付的订单被重复扣款，涉及资金数据且影响范围扩大到多个支付方式。开发提交改级申请，附上复现记录与受影响订单数量，复核人审批后由严重改为致命，改级记录保留原等级、新等级、依据与审批时间。
完成检查：分级机制是否可用的核对项
规则写完不等于落地。下面清单用于定期核对分级机制是否真正在用，建议在机制运行一个月后做首次检查，之后按季度或按触发条件复查。
- 判定表与分级表覆盖了近期出现的主要缺陷类型，包括功能、数据、安全、兼容性与体验类问题；抽查近二十条缺陷，均能对应到明确等级。
- 每条缺陷的定级依据可追溯：四维度取值、判定说明、复核人与定级时间齐全，第三人依据记录能得出相同结论。
- 改级有申请、有审批、有历史记录；抽查改级记录，能说清影响变化与对应维度调整。
- 分级结果被后续流程实际使用：响应时限按等级触发，致命与严重缺陷进入发版评估，升级路径有人响应。
- 定级争议有裁定记录，争议集中在哪些维度、哪些类型，能作为修订判定表的输入。
- 定期复盘有触发条件：出现定级争议、改级比例明显偏高、新业务类型上线、响应时限多次未达成时，启动规则修订并更新版本。
检查中发现的问题要回到具体环节修正：判定项勾选不一致，就补充取值说明和示例；改级频繁，就检查提交时的信息是否足够；分级结果没人用，就检查响应要求是否与等级真正绑定。分级机制的有效性最终体现在两件事上：同类缺陷能被不同的人定出相同等级，定级结果能驱动后续的响应与发版决策。
常见问题
团队刚开始做缺陷分级，等级设几级比较合适？
建议从四级起步：致命、严重、一般、轻微。四级命名直观，判定组合容易拉开差距，团队沟通成本低。已有五级习惯的团队可以在严重与一般之间加一级，但要保证每一级都有独立的判定组合，避免两级定义几乎相同、只能靠感觉选。等级数量不是关键，关键是每级都能对应到判定表里的具体勾选结果。
提交人和复核人对同一条缺陷定级不一致，怎么处理？
先回到判定表逐项对照，看分歧出在哪个维度：是影响范围口径不同，还是绕行代价判断不同。多数分歧在对照取值说明后可以消除。仍无法一致的，按分级表预先规定的优先顺序裁定，即数据与安全风险优先，其次功能受损程度、影响范围、绕行方案。涉及致命与严重缺陷、影响发版判断的争议，由项目负责人做最终裁定并留下记录，这些记录可以作为后续修订判定表的输入。
缺陷修复到一半发现影响比提交时更大，等级怎么改？
由发现变化的人（通常是开发或测试）提交改级申请，写明原等级、建议的新等级、影响变化的事实和对应调整的判定维度，附上复现记录或受影响范围的数据。由原复核人或缺陷管理员审批，确认后更新等级并保留历史记录。常见触发情形有三类：影响范围扩大、绕行方案被证实行不通或代价远超预期、排查中发现数据或安全影响。改级只修正对缺陷的判断，不改缺陷本身，因此每次都要留原等级、新等级、依据和审批人。
分级做完之后，怎么和响应、发版这些后续动作接上？
在分级表旁边写清每个等级对应的响应要求：首次响应时限、是否阻断发版、升级到哪一层、由谁决策。定级完成后这些要求自动生效，分级才有实际作用。例如致命缺陷立即通知项目负责人并阻断发版，严重缺陷当日响应并评估发版影响，一般与轻微按迭代排期。处理归属和排队顺序交给分诊环节，工单紧急性交给优先级与SLA管理，分级只负责严重程度判断，三者衔接但不混在一起。
分级机制运行一段时间后，怎么判断它是否真的有效？
建议运行一个月后做首次检查，之后按季度或触发条件复查。核对几件事：抽查近二十条缺陷，是否都能对应到明确等级；定级依据是否齐全，第三人能否依据记录得出相同结论；改级是否有申请、审批和历史记录；响应时限是否按等级实际触发，致命与严重缺陷是否进入发版评估。出现定级争议集中、改级比例明显偏高、新业务类型上线、响应时限多次未达成时，启动规则修订并更新判定表版本。
