缺陷分级表是一份把缺陷按严重程度归入固定等级、并规定如何判定的对照文档，通常由核心字段、等级定义和判定规则三部分组成。它回答的是“这个缺陷有多严重”，供测试、研发和业务人员在提缺陷、评审和排期时使用。本文只讨论分级本身，分诊与SLA另作处理。
要点总览（TL;DR）
- 缺陷分级表由三部分组成：核心字段、等级定义和判定规则，回答的是“这个缺陷有多严重”，不负责处理归属和排期。
- 核心字段至少包含等级名称、等级编码、严重程度定义、典型示例、判定依据、升级降级条件和确认责任人，优先级与响应要求可作为选填参考。
- 常见等级划分为四到五级，从致命到轻微，每级定义要写清影响对象、后果和可恢复性，等级数量应与缺陷量和团队规模匹配。
- 判定按固定顺序执行：先看影响范围，再看数据与业务后果，然后看可恢复性和触发频率，冲突时按就高不就低原则处理并留痕。
- 分级、分类、分诊、优先级各回答不同问题，混写会让分级随排期变化而失真，等级填错后缺少调整规则也会让统计结果失真。
缺陷分级表是什么：一句话定义与适用范围
缺陷分级表可以定义为：一份用固定等级描述缺陷严重程度、并给出可执行判定条件的团队对照文档。它的核心作用是让“严重”“一般”这类模糊说法变成可比较、可复核的结论，使不同角色对同一个缺陷的严重程度形成一致判断。
它覆盖的对象包括功能缺陷（功能未实现、结果错误、流程中断）、数据问题（数据丢失、数据错误、数据不一致）、界面问题（布局错乱、文案错误、交互异常）、兼容性与性能问题（特定环境不可用、响应超时）等。只要团队需要判断“这个问题有多严重”，就属于分级表的适用范围。
需要区分分级与分类。分类按缺陷的类型或来源划分，例如功能、界面、性能、安全、兼容性，回答的是“这是什么问题”；分级按影响程度划分，回答的是“这个问题有多严重”。一张表可以同时包含类型字段和等级字段，但两者承担不同职责，等级定义不应混入类型描述。
分级表也有明确的不覆盖范围：它不决定由谁处理、排在第几位、多久必须修复。这些分别属于分诊、优先级和SLA的范畴，本文在第五节做概念区分。
核心字段：一张分级表通常要写清哪些列
分级表的字段设计应保证两件事：一是每个等级能被完整描述，二是判定过程能被复核。下表列出常见字段及其填写要求，团队可按规模裁剪选填项。
| 字段名 | 含义与填写要求 | 必填/选填 |
|---|---|---|
| 等级名称 | 团队统一使用的等级叫法，如致命、严重、一般、轻微 | 必填 |
| 等级编码 | 用于工具字段取值的短编码，如S1、S2、S3、S4，便于统计和排序 | 必填 |
| 严重程度定义 | 用一两句话描述该等级的影响对象与后果，避免只写形容词 | 必填 |
| 典型示例 | 列出两到三个真实场景，帮助判定人对照 | 必填 |
| 判定依据/触发条件 | 写明满足哪些条件归入该级，如影响全部用户、核心数据错误 | 必填 |
| 优先级或响应要求 | 该等级对应的处理顺序或响应时限，作为参考信息 | 选填 |
| 升级与降级条件 | 出现新信息时如何调整等级，如影响范围扩大、找到临时规避方案 | 必填 |
| 责任人与确认方式 | 谁有权确认等级、争议由谁裁决、确认记录写在哪里 | 必填 |
字段填写有两个常见要求。等级编码要与等级名称一一对应，避免同一等级出现多种写法，否则统计时无法聚合。判定依据要写成可观察的条件，例如“影响全部付费用户且无法下单”，而不是“影响较大”。优先级字段如果保留，应注明它由分级结果推导而来，不参与等级判定本身。
等级定义：从致命到轻微如何划分
常见做法是四到五级。四级划分是致命、严重、一般、轻微；五级划分通常在两端各加一档，如阻塞级或提示级。等级数量取决于团队规模与缺陷量：缺陷量小、角色少的团队用三到四级即可维持判定一致性；缺陷量大、跨多个业务线的团队可增加到五级，但每增加一级都要补充清晰的判定条件和示例，否则会带来边界争议。
每一级的定义应包含三个要素：影响对象（单用户、部分用户、全部用户，或某个核心模块）、后果（业务中断、数据错误、体验受损）、可恢复性（能否自行恢复、有无规避方案）。只写“严重”而不写这三项，等级之间就无法区分。
| 等级 | 影响描述 | 典型示例 |
|---|---|---|
| 致命（S1） | 核心业务不可用，影响全部或大部分用户，无规避方案，可能造成数据丢失或资金损失 | 支付流程完全无法提交订单；登录服务整体不可用 |
| 严重（S2） | 核心功能受阻或结果错误，影响多个用户，存在有限规避方式 | 部分用户无法导出报表；订单金额计算错误 |
| 一般（S3） | 非核心功能异常或体验明显受损，影响范围有限，有可用替代路径 | 筛选条件偶发失效；页面提示文案错误 |
| 轻微（S4） | 界面细节、文案或低频场景问题，不影响业务完成 | 按钮间距不一致；帮助页链接文字有错别字 |
等级名称需要在团队内统一，包括中文叫法、英文缩写和工具中的取值。名称一旦确定，应在需求评审、测试用例和缺陷记录中保持一致，避免同一等级在不同项目里叫法不同。
判定规则：按什么条件把缺陷放进某一级
判定规则的作用是让不同的人对同一个缺陷得出相同结论。建议按固定顺序判断，先看影响范围，再看后果，最后看可恢复性与触发频率。
- 判断影响范围：确认问题影响单用户、部分用户还是全量用户，以及是否涉及核心业务模块。
- 判断数据与业务后果：确认是否造成数据丢失、数据错误、业务不可用，或仅影响展示与体验。
- 判断可恢复性：确认用户能否自行恢复、是否存在临时规避方案、问题是否持续存在。
- 判断触发频率：确认是必现、高频偶现还是低频偶现，频率影响实际影响面。
- 对照等级定义落级：按上述条件匹配等级表中的判定依据，得出初步等级。
判定中应遵循“就高不就低”原则：当一个缺陷同时满足两个等级的条件时，取较高的等级，并在记录中注明理由。出现争议时，由分级表中指定的责任人裁决，裁决结论和依据写入缺陷记录，作为后续同类问题的参考。升级与降级同样要有触发条件，例如影响范围从部分用户扩大到全量用户时上调一级，找到稳定规避方案后可下调一级，调整需留痕。
分级结果落到协作工具中，通常体现为缺陷工作项上的等级字段和后续流转。以ONES测试管理为例，未通过的用例可以快速创建缺陷任务，缺陷在测试与研发团队之间流转，并支持项目缺陷分布统计，便于团队按等级观察问题集中情况（来源：ONES官网测试管理页面）。分级字段的具体取值和流转规则需结合团队实际配置确定。
相邻概念区别：分级、分类、分诊与优先级
这四个概念经常被混写进同一张表，导致职责不清。下表按“回答什么问题、输出什么结果”做对照。
| 概念 | 回答的问题 | 输出结果 |
|---|---|---|
| 分级 | 这个缺陷有多严重 | 严重程度等级，如S1至S4 |
| 分类 | 这是什么类型的问题 | 类型标签，如功能、界面、性能、安全 |
| 分诊 | 由谁处理、归到哪个团队 | 处理归属与责任人 |
| 优先级与SLA | 先做哪个、多久内响应或修复 | 处理顺序、响应与解决时限 |
分级结果是后续流程的输入：分诊参考等级决定投入哪一级别的处理资源，优先级和SLA通常以等级为基础设定响应时限，统计报表按等级观察质量趋势。分级表本身只负责给出等级，不应把处理归属或时限写成等级定义的一部分。
具体例子与常见误解
假设一个缺陷：某电商系统的优惠券在部分安卓机型上无法领取，用户可改用其他机型或联系客服手动补发，问题每天出现数次。按判定顺序走一遍：影响范围为部分用户，未覆盖全量；后果是营销功能受阻，不涉及资金错误或数据丢失；存在规避方案；触发频率为高频偶现。对照等级定义，该缺陷落在“严重”一级，因为核心营销功能对部分用户不可用，但有规避路径。若后续确认所有机型均受影响且无替代方案，则按就高不就低原则上调为致命。
编写分级表时有几个常见误区值得注意。
- 等级越多越细越好：等级增加会抬高判定成本和争议概率，等级数量应与缺陷量和团队规模匹配，每级都要有可对照的示例。
- 把优先级写进等级定义：等级描述严重程度，优先级描述处理顺序，两者混写会让分级随排期变化而失真。
- 只写等级名不写判定依据：缺少影响范围、后果和可恢复性条件，判定只能靠个人经验，结论难以复核。
- 缺少升级降级与争议处理：没有调整规则，等级一旦填错就长期停留在记录里，统计结果失真。
维护上，建议在版本或业务重大变化后评审一次分级表，检查示例是否仍具代表性、等级边界是否出现集中争议。评审记录与调整理由一并保留，新成员入职时以分级表和典型争议案例作为判定培训材料，可以减少同一问题反复讨论。
常见问题
团队规模小、缺陷量不大，分级表可以只做三级吗？
可以。等级数量的取舍标准是判定一致性：如果团队角色少、缺陷量小，三级（如严重、一般、轻微）足以覆盖日常判断，每级配上两三个真实示例就能维持一致。等级增加会抬高判定成本和边界争议概率，每加一级都要补充可对照的判定条件和示例。等缺陷量增长、跨业务线协作增多后，再按实际争议情况拆分等级更稳妥。
同一个缺陷，测试判为严重、研发判为一般，分级表里应该怎么处理？
分级表需要预先指定裁决人，通常是测试负责人或质量负责人，并规定争议记录写在哪里。处理时先核对双方引用的判定条件是否一致，重点看影响范围和后果的事实描述，例如影响的是部分用户还是全量用户、是否涉及数据错误。裁决结论和依据写入缺陷记录，作为后续同类问题的参考。若同类争议反复出现，说明该等级边界定义不够清晰，应回到分级表补充示例或调整判定条件。
缺陷修复过程中影响范围变了，等级要不要跟着调整？
要调整，这正是升级与降级条件字段的作用。常见触发情形包括：影响范围从部分用户扩大到全量用户时上调等级；找到稳定规避方案或确认问题仅影响低频场景时可下调等级。调整需要留痕，写明调整前后的等级、依据和确认人，避免等级在记录中无声变化导致统计口径混乱。分级表应把这类触发条件写成可观察的描述，而不是留给个人临场判断。
分级表里的优先级字段和工单优先级是一回事吗？
两者相关但职责不同。分级表中的优先级或响应要求是选填参考项，由严重程度推导而来，用于提示该等级通常对应的处理顺序；工单优先级与SLA管理则决定实际排在第几位、多久内响应或修复，还会受合同约定、客户影响、发布窗口等因素影响。把优先级写进等级定义会让分级随排期变化而失真，建议在分级表中注明优先级字段仅作参考，实际排期由后续流程决定。
分级表落地到协作工具时，需要注意什么？
关键是让等级字段的取值与分级表一一对应，包括中文名称、编码和工具中的选项值，避免同一等级出现多种写法导致统计无法聚合。以ONES测试管理为例，未通过的用例可以快速创建缺陷任务，缺陷在测试与研发团队之间流转，并支持项目缺陷分布统计，便于按等级观察问题集中情况。分级字段的具体取值和流转规则需结合团队实际配置确定，配置前先确认工具中缺陷工作项的字段设置方式。
