缺陷分级是按缺陷对业务和用户造成的影响程度，把缺陷划入若干等级的过程，常见序列为致命、严重、一般、轻微，或用P0到P3表示。它回答“这个缺陷有多严重”，与回答“这个缺陷属于哪一类”的缺陷分类互为补充。实际分级通常综合影响范围、业务与用户影响、复现稳定性、出现阶段与紧迫性等维度判断，再以影响程度为主、其余维度作修正，合成一个可复核的等级。
要点总览（TL;DR）
- 缺陷分级是按缺陷对业务和用户的影响程度划入等级的过程，常见序列为致命、严重、一般、轻微或P0–P3，回答的是“有多严重”。
- 分级与分类分工不同：分类决定缺陷进入哪条流程、由谁处理，分级决定修复先后与投入力度，两者在流程上互补。
- 分级通常依据影响范围、业务与用户影响、复现稳定性、出现阶段与环境、紧迫性与时效五个维度判断。
- 多维度合成等级时，以影响程度定基础等级，其余维度作修正；任一维度达到致命条件可直接定为最高等级。
- 常见误解包括把分类当分级、只按复现率定级、等级划分过细以及分级后不再更新。
缺陷分级是什么：先给一个可用的定义
缺陷分级（Defect Severity Classification）是缺陷管理中的一项判断动作：依据缺陷已经或可能造成的后果，把缺陷归入事先约定的若干等级，使团队对“严重到什么程度”形成一致口径。一个可用的定义包含三个要素：判断对象是单个缺陷；判断依据是影响程度，包括对用户、业务数据和系统运行的影响；判断结果是有限等级序列中的一个值。
常见等级序列有两类表达方式。一类用文字描述，如致命、严重、一般、轻微；另一类用编号描述，如P0、P1、P2、P3。两套表达可以对应，也可以按团队习惯单独使用，关键是同一团队内部口径统一。等级数量通常为三到五级，足以区分处理先后，又不至于让判定者频繁犹豫。
分级结果直接服务于资源分配：致命和严重缺陷优先修复，可能阻塞发布；一般缺陷排入正常迭代；轻微缺陷可以合并处理或延后。分级不描述缺陷的技术成因，也不决定由谁修复，它提供的是处理先后与投入力度的依据。
分级与分类的边界：回答的是两个不同问题
缺陷分级与缺陷分类经常被混用，两者回答的问题不同。分级回答“有多严重”，输出一个严重程度等级；分类回答“属于哪一类”，输出功能模块、缺陷类型、发现阶段等归属信息。分类的结果决定缺陷进入哪条处理流程、由哪个角色接手；分级的结果决定它在队列中排多前、投入多少修复资源。
| 对照项 | 缺陷分级 | 缺陷分类 |
|---|---|---|
| 回答的问题 | 这个缺陷有多严重 | 这个缺陷属于哪一类、归谁处理 |
| 典型输出 | 致命、严重、一般、轻微，或P0–P3 | 功能模块、缺陷类型、发现阶段、责任团队 |
| 主要用途 | 确定修复先后与投入力度 | 确定处理流程、责任人与统计口径 |
| 判断依据 | 影响范围、业务影响、复现情况等 | 缺陷特征与归属关系 |
两者在流程上互补：一个支付相关的缺陷，分类把它归入交易模块并指派给交易团队，分级则告诉团队它是否需要立即停下其他工作来处理。分类正确但分级缺失，缺陷会进入正确的队列却排不出先后；分级正确但分类缺失，优先级再高也可能找不到接手的人。
本文聚焦分级维度与等级合成机制。缺陷提交后如何分诊、责任如何分配、工单紧急性与SLA如何设定，属于相邻主题，本文不展开。
分级通常依据哪些维度
分级没有唯一标准，但业界常用的判断维度相对稳定。下面五个维度覆盖了大多数分级场景，团队可以按业务特点取舍或增加，但应保持维度定义稳定，避免同一类缺陷在不同时间得到不同等级。
| 维度 | 看什么 | 对等级的影响 |
|---|---|---|
| 影响范围 | 缺陷波及单点、局部功能、核心链路还是全站 | 范围越大，等级越高 |
| 业务与用户影响 | 是否造成数据错误、资金损失、隐私泄露或体验明显受损 | 涉及数据与资金通常直接进入高等级 |
| 复现稳定性 | 必现、偶现，还是特定条件下才出现 | 必现缺陷更易确认和修复，偶现缺陷需结合影响判断 |
| 出现阶段与环境 | 开发自测、测试、预发布还是生产环境发现 | 越接近生产，修复窗口越短，等级通常上调 |
| 紧迫性与时效 | 是否有临时绕行方案、是否阻塞发布或上线 | 无绕行方案且阻塞发布时，等级上调 |
影响范围是最直观的维度。只影响某个页面的个别展示问题，与导致核心交易链路不可用，后果差距明显。判断时可以先问：受影响的用户占比多大，是否涉及主流程。
业务与用户影响关注后果的性质而非数量。金额计算错误、订单状态错乱、用户数据丢失，即使只发生在少数场景，也往往需要高等级处理；纯展示文案错误影响面再广，通常也停留在较低等级。
复现稳定性影响的是确认成本与修复确定性。必现缺陷容易定位，偶现缺陷可能需要多轮排查，但偶现本身不自动等于低等级——一个偶发的支付失败同样可能造成资金问题，需要结合业务影响判断。
出现阶段与环境决定修复的时间压力。测试阶段发现的缺陷还有较长的修复窗口，生产环境发现的缺陷往往需要立即响应。同一缺陷在不同环境被发现，等级可以不同。
紧迫性与时效看的是处置条件：是否存在可用的临时绕行方案，是否卡住发布节点。有绕行方案且不影响发布的缺陷，可以在等级上适度下调；无绕行且阻塞发布的缺陷，应上调。
维度如何合成一个等级：机制与权重
多个维度不会各自给出一个等级，而是共同支撑一个最终判断。常见做法是以影响程度为主维度，先按影响范围和业务影响确定基础等级，再用复现稳定性、出现阶段、紧迫性等维度做修正。这样做的原因是：影响后果最能反映缺陷的实际危害，其余维度更多影响处置节奏。
合成机制通常包含三条规则。第一，主维度定基础等级：按影响范围和业务影响对照等级定义，得到初始等级。第二，修正维度上下调整：生产环境发现、无绕行方案、阻塞发布等情况可以上调一级；有绕行方案、影响可忽略等情况可以下调。第三，一票升级：任一维度达到致命条件，例如造成资金损失或核心链路完全不可用，可以直接定为最高等级，不再逐项加权。
规则形式有两种常见选择。判定表把维度组合与等级一一列出，适合等级少、场景稳定的团队，判定结果一致性好；打分法给每个维度的取值赋分再汇总，适合场景复杂、需要细分的团队，但需要定期校准分值，防止分数与直觉脱节。无论采用哪种形式，分级结果都应可复核：记录判定时依据的维度取值，让其他人能看懂为什么定这个等级，出现争议时可以回到依据上讨论。
分级维度最终要落到缺陷记录上。团队在缺陷工作项中维护严重程度字段，并在提交、评审、修复各环节保持字段更新，分级才有实际作用。以ONES为例，ONES Project 适配缺陷管理等场景，支持一键提交 Bug 至对应项目或迭代并跟踪修复情况，也可统计缺陷状态分布；ONES TestCase 支持未通过的用例快速创建缺陷任务，使缺陷在测试与研发团队间流转。这些能力承载的是缺陷记录与流转，分级标准本身仍需团队自行约定并写入判定规则。
具体例子与常见误解
下面用一个示例演示分级过程。某电商系统在预发布环境测试时发现：用户提交订单后，订单列表偶发不显示最新订单，刷新后恢复，发生频率约为每二十次一次，不影响支付和库存。
按维度逐项判断：影响范围限于订单列表展示，不涉及核心交易链路；业务影响是用户可能重复下单或产生疑虑，但不造成资金和数据错误；复现稳定性为偶现；出现阶段为预发布，尚未影响生产；紧迫性上存在刷新这一临时绕行方案，不阻塞发布。综合判断，基础等级为一般，考虑到可能引发重复下单，可维持一般或上调至严重，由团队按自身口径确定。这个例子说明，分级是把多个维度的取值放在一起权衡，而非套用单一条件。
实际工作中，以下误解较常见：
- 把分类当分级。把缺陷归入“支付模块”或“界面问题”就认为完成了定级，实际上这只回答了归属，没有回答严重程度。分类完成后仍需单独判定等级。
- 只按复现率定级。认为偶现缺陷一律是低等级，忽略其业务后果。偶发的数据错误同样可能造成损失，复现率只是修正维度之一。
- 等级划分过细。设置七八个等级，判定者难以区分相邻两级，同一缺陷不同人给出不同结果。等级数量应与团队判定能力匹配，通常三到五级足够。
- 分级后不再更新。缺陷在修复过程中影响范围可能扩大或缩小，等级应随新信息调整，否则优先级依据会失真。
把分级维度、判定规则和等级字段固定下来，并在缺陷流转中持续维护，团队才能对“先修哪个”形成稳定共识。
常见问题
缺陷分级和缺陷分类可以只做其中一个吗？
两者回答不同问题，缺一项都会影响处理效果。只做分类，缺陷能进入正确的流程和责任人，但队列里排不出先后；只做分级，优先级明确却可能找不到接手团队。实际执行中，提交缺陷时同时填写分类归属和严重程度，后续流程才能顺畅衔接。
偶现缺陷是否一律定为低等级？
不一定。复现稳定性只是修正维度之一，判断时仍需看业务后果。偶发的支付失败、数据错乱同样可能造成资金或数据损失，这类缺陷应结合业务与用户影响上调等级。复现率低增加的是排查成本，并不自动降低危害程度。
同一缺陷在测试环境和生产环境发现，等级应该一样吗？
可以不同。出现阶段与环境是分级维度之一，越接近生产，修复窗口越短，等级通常上调。测试阶段发现的缺陷还有较长修复周期，生产环境发现的同类缺陷往往需要立即响应。团队应在判定规则中写明环境对等级的调整方式，避免同一缺陷因发现环境不同而产生争议。
等级数量定几级比较合适？
常见做法是三到五级，足以区分处理先后，又不至于让判定者在相邻两级之间反复犹豫。等级过多会拉高判定成本，同一缺陷不同人给出不同结果；等级过少则难以体现影响差异。团队可以先用三到五级运行一段时间，再根据实际争议情况调整。
分级结果确定后还需要更新吗？
需要。缺陷在排查和修复过程中，影响范围可能扩大或缩小，绕行方案可能出现或失效，等级应随新信息调整。若分级后长期不更新，优先级依据会失真，团队可能把资源投在已经缓解的缺陷上，而遗漏影响扩大的问题。
