缺陷分级要解决的是同一个问题：一个缺陷被记录之后，团队如何快速判断它有多严重、应该多快处理。做法是把影响范围、功能阻断、数据与安全风险、可绕过性等维度写成可观察的判定条件，形成严重程度等级表，再明确谁在什么时点定级、改级需要什么证据。本文给出维度清单、等级表模板、定级与改级步骤、角色分工和上线校准方法。
要点总览（TL;DR）
- 缺陷分级先固定三到五个可观察维度（影响范围、功能阻断、数据与安全风险、可绕过性、复现稳定性），严重程度与优先级分开记录，前者描述影响，后者描述处理次序。
- 严重程度等级表按阻断、严重、一般、轻微四级编写，每级给出定义、典型场景和反例，并提前写明跨级争议、组合缺陷、环境相关问题的处理规则。
- 定级走提交人初判、复核会议裁决、改级附证据三步，改级结果写入缺陷记录，作为修复排期和发布准入的输入。
- 测试负责初判，开发补充根因与影响面，产品确认业务影响，分级责任人裁决争议，发布负责人按等级判断放行。
- 上线前用历史缺陷回测等级表，上线后按迭代或月度复盘等级分布与改级率，标准每次修订保留版本记录并通知提交人。
缺陷分级先定哪几个维度
分级维度决定了一张缺陷记录能承载多少判断信息。维度太少，等级只能靠感觉；维度太多，填写成本高，团队很快会敷衍。比较稳妥的做法是先固定三到五个核心维度，每个维度给出可观察的判定条件，再根据业务风险补充一两个专项维度。
严重程度与优先级要分开记录
严重程度描述缺陷造成的影响，回答“坏了多严重”；优先级描述处理次序，回答“先修哪一个”。两者相关但不相等：一个影响面很大的缺陷可能因为已有临时绕行方案而排在后面；一个影响面有限的缺陷可能因为卡住关键客户演示而优先处理。把两者合并成一个字段，排期时就没有调整空间。建议在缺陷记录中保留两个独立字段，严重程度由影响判定，优先级由发布负责人结合排期和资源确定。
常用维度与判定条件写法
每个维度都应写成可以对照事实回答的问题，避免“严重”“较严重”这类形容词。下面是一份可直接落成字段的维度清单示例：
| 维度 | 判定问题 | 可观察条件示例 |
|---|---|---|
| 影响范围 | 受影响的用户、租户或业务模块有多少？ | 全部用户 / 单租户 / 单角色 / 个别配置组合 |
| 功能阻断程度 | 核心流程是否无法继续？ | 主流程中断且无替代入口 / 主流程可继续但结果错误 / 非主流程异常 |
| 数据与安全风险 | 是否造成数据错误、丢失或越权访问？ | 数据写入错误且不可恢复 / 数据展示错误可修正 / 无数据影响 |
| 可绕过性 | 用户是否有可接受的替代操作？ | 无替代方式 / 有替代方式但成本明显 / 有等价替代方式 |
| 复现稳定性 | 按给定步骤能否稳定复现？ | 每次复现 / 特定条件下复现 / 仅出现一次且无法复现 |
复现稳定性单独列出，是因为它影响定级的可信度。无法复现的缺陷不宜直接定为最高等级，可以先按影响范围给出暂定等级，并标注“待补充复现信息”，等证据补齐后再确认。这样既不会漏掉真实风险，也避免因一条模糊描述阻塞整个修复队列。
维度数量控制在可维护范围
等级过细会带来两个问题：相邻等级之间难以区分，评审时反复争论；填写人需要记忆大量规则，实际执行时退回主观判断。一般建议严重程度分为四到五级，核心维度控制在五个以内。如果业务存在强合规或强安全要求，可以增加一个专项维度，但应明确它只影响特定类型缺陷，不要求所有缺陷都填写。
严重程度等级表怎么编写
等级表是把多个维度的判定结果组合成单一结论的规则表。编写时先确定等级数量和命名，再为每一级写出定义、典型场景和反例，最后补齐边界情形和字段填写规则。
等级命名与各级定义
常见的四级命名为阻断、严重、一般、轻微。命名本身不重要，重要的是每级定义能对应到维度条件。下面是一份可填写的空白等级表结构：
| 等级 | 定义（影响描述） | 典型场景 | 反例（不应定为此级） | 处理要求 |
|---|---|---|---|---|
| 阻断 | 核心业务流程无法继续，且无替代方式；或造成不可恢复的数据错误、安全越权 | 登录失败导致全部用户无法进入系统；订单金额写入错误且已产生实际扣款 | 仅某个非核心页面样式错位；有明确替代入口的功能异常 | 当日响应，修复前评估是否暂停发布 |
| 严重 | 核心功能结果错误或主流程明显受阻，存在成本较高的替代方式 | 报表统计口径错误但可手工核对；批量导入部分失败可重试 | 提示文案错误；个别浏览器下的显示差异 | 当前迭代内修复 |
| 一般 | 非核心功能异常，或核心功能存在等价替代方式 | 辅助查询页面筛选条件失效；导出格式与预期不符但数据完整 | 导致主流程中断的问题；数据错误 | 纳入近期排期 |
| 轻微 | 不影响业务操作的体验、文案、样式问题 | 按钮间距不一致；帮助文本错别字 | 任何影响操作结果的问题 | 批量处理或随版本优化 |
边界情形怎么处理
等级表最容易失效的地方在边界。以下三类情形应提前写明规则：
- 跨级争议：当两个维度指向不同等级时，按“数据与安全风险优先于功能阻断，功能阻断优先于影响范围”的顺序取较高者，并在记录中注明依据的维度。
- 组合缺陷：多个缺陷由同一根因引起时，按合并后的整体影响定级，并在各条记录中互相引用，避免重复计算修复工作量。
- 环境相关问题：仅在特定环境、特定版本或特定配置下出现的问题，先按受影响范围定级，同时标注环境条件；如果该环境是生产主路径，按实际影响定级，不因“环境特殊”降级。
必填字段与选填字段
必填字段保证定级可复核，建议包括：严重程度、优先级、影响范围、复现步骤、环境信息、定级人、定级时间。选填字段用于补充判断依据，例如可绕过性说明、关联缺陷、根因初判、客户影响描述。必填项过多会拖慢提交，过少则评审时缺少依据，可以按缺陷来源区分：测试提交的缺陷要求完整复现信息，线上反馈的缺陷允许先记录现象、后补细节。
定级、复核与改级的操作步骤
分级不是提交时填一个字段就结束，而是一组有输入、有输出、有完成标志的动作。下面按缺陷流转顺序说明。
提交人初判
输入是复现步骤、环境信息、实际结果与预期结果。提交人对照等级表给出初始严重程度，并填写影响范围。输出是一条带初始等级和判定依据的缺陷记录。完成标志是：另一名团队成员能按记录中的步骤复现问题，或能理解无法复现的原因。初判不要求绝对准确，但要求依据可查。
复核与争议裁决
复核通常在缺陷提交后的首次处理会议上完成，参与人包括测试负责人、对应模块的开发负责人和产品负责人。复核的动作是逐维度核对初判依据，重点检查影响范围是否被低估、是否存在未记录的数据风险。争议由事先指定的分级责任人裁决，裁决结果和理由写入记录。完成标志是缺陷进入待修复状态，且等级字段不再处于“待确认”。
改级的触发条件与证据
改级应基于新信息，而不是基于排期压力。常见触发条件包括：补充了稳定的复现步骤、影响面扩大到更多用户或租户、根因定位后发现涉及数据写入或权限逻辑、临时绕行方案失效。每次改级需要附上对应证据，并记录改级人、时间和原因。允许降级的场景同样要写清楚，例如确认问题只影响测试环境且生产配置不同。
分级结果进入排期与发布准入
分级结果写入缺陷记录后，作为两个下游动作的输入：修复排期按优先级排序，发布准入按未关闭的阻断和严重缺陷数量判断是否放行。完成标志是缺陷记录中的等级、优先级与排期结果一致，发布检查时可以直接按等级筛选出阻塞项。
角色分工与各环节交付物
分级权责分散是等级漂移的主要原因：测试定得高、开发改得低、产品临时插队，最后没人说得清某条缺陷为什么被降级。解决办法是把定级、复核、改级和裁决分别落到角色，并明确每个角色的交付物。
| 角色 | 分级职责 | 交付物 | 交接时点 |
|---|---|---|---|
| 测试 | 提交时初判严重程度，提供复现步骤与环境信息 | 带初始等级和判定依据的缺陷记录 | 缺陷提交时 |
| 开发 | 核对技术影响，补充根因初判，提出改级证据 | 影响范围说明、根因分析、改级申请 | 复核会议前或根因定位后 |
| 产品 | 确认业务影响与用户范围，参与边界争议讨论 | 业务影响说明、优先级建议 | 复核会议中 |
| 分级责任人 | 裁决跨级争议，确认改级是否成立 | 裁决结论与理由 | 争议发生时 |
| 发布负责人 | 按等级判断发布准入，确认阻塞项处理状态 | 发布检查结论 | 发布评审时 |
分级责任人宜由测试负责人或质量负责人担任，保持相对固定，避免每次争议临时找人。改级的后果由提出改级的一方承担说明责任：开发提出降级，需要给出影响面收窄的证据；产品提出升级，需要说明业务影响的变化。这样等级变动始终有据可查，而不是随排期压力浮动。
当缺陷记录需要在测试与研发之间流转时，工具承载的是记录、状态和留痕。以 ONES 为例，ONES TestCase 支持将未通过的用例快速创建为缺陷任务，缺陷任务在测试与研发团队间流转；ONES Project 适配缺陷管理场景，支持一键提交 Bug 至对应项目或迭代，并记录和跟踪修复情况。分级字段的具体配置方式、改级历史的呈现形式，需要在实际环境中核验后再确定落地细节。
一个完整分级示例
以下为演示情景，用于说明规则如何应用，不代表真实项目数据。
缺陷描述：某后台管理系统中，运营人员批量导入商品价格后，部分商品价格显示为原价，实际下单仍按新价格计算。提交人初步判断为“严重”，理由是价格展示错误可能引起运营误操作。
逐维度对照：影响范围为部分商品，涉及使用批量导入功能的运营角色；功能阻断程度为展示错误但下单流程正常；数据与安全风险为展示层错误，未发现写入错误；可绕过性为可逐条核对修正；复现稳定性为按给定导入文件每次复现。按等级表，展示错误且可绕过、无数据写入风险，应定为“一般”。
复核分歧与裁决：产品负责人认为价格展示错误会影响运营决策，主张维持“严重”。分级责任人核对后确认：下单金额正确，错误仅存在于列表展示，且运营可通过导出核对。裁决为“一般”，同时要求在记录中注明“若后续发现价格写入错误，立即升级”。
后续改级：开发定位根因时发现，展示错误源于价格字段的缓存更新逻辑，同一逻辑也影响促销价写入。补充证据后，缺陷升级为“严重”，记录中写明改级原因、证据和改级人。修复排期随之调整，发布检查时将关联的促销价写入问题一并列为阻塞项。
分级标准的上线检查与持续校准
等级表写完不等于可用。上线前需要用历史缺陷验证它能否给出与实际情况一致的结论，上线后需要定期检查等级分布是否失真。
上线前检查清单
- 等级表是否覆盖了近半年出现频率最高的缺陷类型，每类都能找到对应等级；
- 每一级是否都有典型场景和反例，反例能区分相邻等级；
- 跨级争议、组合缺陷、环境相关问题的处理规则是否写明；
- 必填字段是否足以支撑复核，是否存在无人填写的冗余字段；
- 分级责任人、复核时点和改级证据要求是否已通知到所有提交人。
用历史缺陷回测
抽取一批已关闭的历史缺陷，隐去原等级，让测试、开发、产品分别按新等级表重新定级，再与实际影响和处理过程对照。重点看两类偏差：新标准定得比实际影响高，说明维度条件过严；定得比实际影响低，说明遗漏了风险维度。回测结果用于修订等级表，而不是用于评价个人判断。
定期复盘等级分布与改级率
建议每个迭代或每月复盘一次：各等级缺陷的数量占比、改级次数占总缺陷数的比例、改级方向分布。阻断和严重等级长期占比过高，可能说明标准过松或团队把等级当作争取资源的工具；改级率持续偏高，说明初判依据不足或复核环节形式化。复盘结论应落到具体修订动作，例如调整某个维度的判定条件、补充某类缺陷的示例。
标准变更的记录与通知
等级表每次修订都应保留版本记录，写明修改的等级、修改原因和生效时间。变更后通过团队例会或文档公告通知提交人和复核人，并在缺陷记录中标注适用的标准版本。这样在回溯历史缺陷时，能区分“当时按旧标准定级”和“定级错误”，避免用新标准否定过去的判断。
缺陷状态分布和缺陷分布统计可以作为校准的输入数据。ONES Project 可统计缺陷状态分布，ONES TestCase 支持项目缺陷分布统计，用于沉淀问题和经验；按严重程度细分的统计口径需要在具体配置中确认。分级标准本身仍要靠团队对判定条件的持续对照和修订来维持有效性。
常见问题
缺陷分级和缺陷分诊有什么区别，应该先做哪一个？
分级回答“这个缺陷有多严重”，产出的是严重程度和优先级字段；分诊回答“这条缺陷交给谁处理、排在哪个队列”，产出的是处理归属和排队顺序。两者顺序上通常先分级再分诊：等级确定后，分诊才有依据把阻断级缺陷直接送到对应模块负责人，把轻微缺陷放进批量处理队列。
如果团队目前连等级字段都没有，先建立分级标准；如果等级已有但经常出现缺陷在多个团队之间来回转，问题更可能出在分诊规则上，需要另行梳理责任分配和排队规则。
无法稳定复现的缺陷应该怎么定级？
建议先按已知的影响范围给出暂定等级，并在记录中标注“待补充复现信息”，等证据补齐后再确认。不要因为无法复现就直接定为最高等级，这会让修复队列被模糊描述阻塞；也不要直接降为轻微，可能漏掉真实风险。
暂定等级需要设定确认时限，例如在下一次复核会议前补齐日志、录屏或环境信息。超时仍无法复现的，可以由分级责任人决定转为观察项，并记录当时的判断依据，便于后续同类问题出现时对照。
开发认为测试定级过高，改级流程应该怎么走？
改级应基于新信息，而不是基于排期压力。开发提出降级时，需要给出影响面收窄的具体证据，例如确认问题只影响测试环境、生产配置不同，或存在等价的替代操作路径。改级申请提交给分级责任人，由其在复核时点裁决，裁决结论和理由写入缺陷记录。
为了让这条规则可执行，团队需要事先约定分级责任人由谁担任并保持相对固定，同时明确改级记录的必填项：改级人、改级时间、触发原因、支撑证据。缺少任一项的改级申请可以退回补充，避免等级随沟通中的口头判断浮动。
等级表上线后，怎么判断标准是过松还是过严？
看两个指标：等级分布和改级率。阻断与严重等级长期占据过高比例，可能说明标准过松，或者团队把高等级当作争取修复资源的工具；改级率持续偏高，说明初判依据不足或复核环节流于形式。改级方向分布也能提供线索，集中出现降级往往指向初判偏严。
复盘结论要落到具体修订动作，例如调整某个维度的判定条件、补充某类缺陷的典型场景和反例。仅统计数字而不改标准，下一轮复盘会看到同样的分布。
缺陷分级结果如何与发布准入衔接？
把等级作为发布检查的筛选条件：发布评审时按严重程度筛出未关闭的阻断和严重缺陷，逐条确认修复状态或临时方案，再决定是否放行。这要求缺陷记录中的等级、优先级与排期结果保持一致，否则筛选出来的阻塞项与实际处理情况对不上。
具体到工具层面，ONES Project 支持一键提交 Bug 至对应的项目或迭代中，记录和跟踪缺陷修复情况，可统计缺陷状态分布；ONES TestCase 支持项目缺陷分布统计。按严重程度细分的统计口径和发布门禁的具体配置方式，需要在团队实际环境中确认后再写入流程。
