缺陷分类与分级由多个相互独立的维度组成：分类回答“属于哪一类问题”，分级回答“有多严重、多紧急、多难处理”。同一缺陷在每个维度上各取一个值，组合成一条完整记录，维度之间不互相替代，也没有固定换算公式。本文说明各维度的含义、正交组合关系，以及严重程度与优先级的区别和常见框架的组织方式。
要点总览（TL;DR）
- 缺陷分类与分级由多个独立字段组成：分类回答“是什么问题”，分级回答“有多严重、多急、多难处理”，同一缺陷在每个维度上各取一个值。
- 各维度之间是正交组合关系，一个维度的取值不决定另一个维度的取值；维度间的关联规则属于团队约定，不改变维度本身的独立性。
- 严重程度描述影响，优先级描述修复排期，两者可以不一致，常见做法是用映射表给出默认对应关系并保留例外调整空间。
- 常见框架按缺陷类型、严重程度、优先级、处理状态组织，引入阶段和复现概率作为可选维度，核心作用是把取值枚举固定下来。
- 缺陷分诊与责任分配解决“谁来处理”，工单优先级与 SLA 关注响应时限，它们与缺陷分级维度相关但口径不同，需要分别定义。
缺陷分类与分级到底包含哪些维度
缺陷分类与分级是两套并行的字段体系。分类维度回答“这是什么问题”，把缺陷归入可识别的类别；分级维度回答“这个问题有多严重、多急、多难处理”，为排期和资源投入提供依据。两者共同构成一条缺陷记录的描述信息，但各自承担不同的判断任务。
常见的分类维度包括：
- 缺陷类型：如功能错误、界面显示、性能问题、兼容性问题、数据错误、文案问题。它描述缺陷的性质，便于按类别统计和分派给对应角色。
- 所属模块：缺陷出现在哪个功能模块或系统组件中，用于定位影响范围和责任团队。
- 引入阶段：缺陷是在需求、设计、开发、测试还是上线后发现的，用于回溯质量问题和改进上游环节。
常见的分级维度包括：
- 严重程度：缺陷对业务、用户或系统造成的实际影响程度，通常分为致命、严重、一般、轻微等档位。
- 优先级：修复工作的排期先后，反映团队在多条缺陷之间分配资源的顺序。
- 复现概率：缺陷被稳定触发的可能性，如必现、高频、偶现、极难复现。它影响验证成本和修复难度判断。
需要强调的是，上述每一项都是一个独立取值的字段，而不是同一件事的不同叫法。缺陷类型为“界面”与严重程度为“高”描述的是两个不同事实，不能互相推导。团队在设计缺陷记录时，应把分类维度和分级维度分别定义为独立字段，各自维护取值枚举。
各维度之间是正交组合关系
正交在这里的含义是：一个维度的取值不决定另一个维度的取值。缺陷类型取“界面”，严重程度可以是高也可以是低；严重程度取“高”，优先级可以是高也可以是中。每个维度独立判断，互不替代，也不存在“类型确定后分级自动确定”的推导关系。
一条完整的缺陷记录，是各维度各取一个值后的组合。例如：类型=界面显示，所属模块=订单结算，引入阶段=测试，严重程度=高，优先级=中，复现概率=必现。这组取值共同描述了缺陷的性质、影响和处置顺序，缺少任何一个维度，记录的信息都不完整。
维度之间可以存在关联规则，但关联规则是团队约定，不是维度本身。比如团队可以约定“严重程度为致命的缺陷，优先级不得低于高”，这条规则约束的是两个字段取值之间的搭配，而不是把两个字段合并。规则可以调整，维度定义保持稳定。区分“维度”和“维度间的规则”，是设计缺陷字段时的关键一步：先把每个维度的取值枚举定清楚，再决定是否需要以及需要哪些关联规则。
严重程度与优先级为什么常被混为一谈
严重程度和优先级是最容易被合并的两个分级维度，因为它们在多数情况下同向变化：影响越大的缺陷，通常越早修复。但两者的判断对象不同。严重程度描述缺陷对业务或用户的影响，是一个相对客观的影响评估；优先级描述修复排期的先后，是一个资源分配决策，受版本计划、客户承诺、修复成本等因素影响。
两者可以不一致，常见情形包括：
- 严重程度高但影响面小：某个边缘功能完全不可用，但使用该功能的用户极少，优先级可以排在中位。
- 严重程度低但阻塞主流程：一个文案错误出现在核心下单页，影响用户理解和转化，优先级可能被提高。
- 严重程度高但修复成本极大：需要架构调整才能解决的性能问题，可能先安排临时规避方案，优先级分阶段处理。
常见做法是用映射表把严重程度与优先级关联，而不是合并成一个字段。映射表给出默认对应关系，例如严重程度为致命时默认优先级为高，严重程度为轻微时默认优先级为低，同时允许在具体缺陷上按实际情况调整。这样既保留了默认效率，也保留了例外空间。映射表属于团队约定，不同团队、不同产品阶段的映射可以不同，不存在统一标准。
常见的分类分级框架怎么组织这些维度
一个可参考的基础框架按四组字段组织：缺陷类型、严重程度、优先级、处理状态。前三组分别承担分类、影响评估和排期决策，处理状态记录缺陷在流转中的位置，如新建、已确认、修复中、待验证、已关闭、重新打开。状态字段与前三个维度正交，任何类型、任何严重程度的缺陷都会经历状态变化。
在这个基础框架上，引入阶段和复现概率作为可选维度加入。引入阶段适合希望做质量回溯的团队，复现概率适合缺陷量大、验证成本高的团队。可选维度的取舍标准是：该维度是否会产生团队实际使用的统计口径或决策依据。如果某个维度填了之后没有人看、没有报表使用，它只会增加录入负担。
框架的核心作用是把每个维度的取值枚举固定下来，减少各人理解差异。例如严重程度统一为致命、严重、一般、轻微四档，并为每一档写明判定说明；优先级统一为高、中、低三档，并说明对应的排期承诺。取值枚举一旦固定，缺陷记录之间才可比较，统计结果才有意义。
| 维度类别 | 字段 | 取值示例 | 回答的问题 |
|---|---|---|---|
| 分类 | 缺陷类型 | 功能错误、界面显示、性能、兼容性、数据错误 | 是什么问题 |
| 分类 | 所属模块 | 订单、支付、账户、搜索 | 出现在哪里 |
| 分类（可选） | 引入阶段 | 需求、设计、开发、测试、上线后 | 问题从哪来 |
| 分级 | 严重程度 | 致命、严重、一般、轻微 | 影响有多大 |
| 分级 | 优先级 | 高、中、低 | 先修哪个 |
| 分级（可选） | 复现概率 | 必现、高频、偶现、极难复现 | 多难触发和验证 |
| 流程状态 | 处理状态 | 新建、已确认、修复中、待验证、已关闭 | 现在到哪一步 |
当这些维度落到具体的工作项字段上时，工具承担的是字段定义、取值维护和状态流转的承载工作。ONES Project 适配缺陷管理等研发场景，提供缺陷跟踪管理，支持一键提交 Bug 至对应的项目或迭代中，记录和跟踪缺陷修复情况，并可统计缺陷状态分布。团队可以把上述维度作为缺陷工作项的属性字段维护，让分类分级从纸面约定变成记录中可查询、可统计的数据。字段的具体配置方式以团队实际使用的产品版本为准。
容易混淆的相邻概念：分诊、责任分配与工单优先级
缺陷分诊与责任分配解决的是“谁来处理”的问题，属于流程环节，不是分级维度。分诊通常在缺陷提交后进行，由负责人判断缺陷是否有效、归入哪个模块、交给哪位处理人。责任分配的结果是处理人和处理团队，它不改变缺陷的类型、严重程度或优先级取值。维度定义清楚是分诊和责任分配的前提：分诊人员需要依据类型和模块找到对应负责人，依据严重程度和优先级判断处理顺序，但分诊流程本身不在本文展开。
工单优先级与 SLA 管理关注响应时限，与缺陷优先级相关但口径不同。缺陷优先级服务于研发排期，工单优先级服务于服务响应承诺，两者的判断依据和考核对象不同。ONES Desk 支持评估和定义工单优先级，优先解决紧急事件，这里的优先级针对工单场景，与缺陷记录中的优先级字段不能直接等同。团队如果同时使用缺陷管理和工单管理，应分别定义两套优先级的含义，避免跨系统比较时产生歧义。
本文的边界是维度之间的关系：有哪些维度、如何组合、哪些维度容易混淆。分诊流程设计、责任分配规则、SLA 时限设定属于相邻主题，需要时另行讨论。
一个具体例子与常见误解
假设测试人员在订单结算页发现一个问题：点击“提交订单”后页面无响应，刷新后订单已生成但页面未跳转。按前述框架，各维度取值如下：
| 维度 | 取值 | 判断依据 |
|---|---|---|
| 缺陷类型 | 功能错误 | 核心操作未按预期完成 |
| 所属模块 | 订单结算 | 问题出现在结算页 |
| 引入阶段 | 开发 | 测试阶段首次发现，需求与设计评审未提及 |
| 严重程度 | 严重 | 影响下单主流程，用户可能重复下单 |
| 优先级 | 高 | 阻塞主流程，需在本次迭代内修复 |
| 复现概率 | 高频 | 多次操作可稳定触发 |
| 处理状态 | 已确认 | 开发已复现并确认 |
这组取值说明：这是一个影响主流程的功能错误，影响大、触发稳定、需要优先修复。每个维度的取值都提供了其他维度无法替代的信息。如果只保留类型和严重程度，就看不出它阻塞主流程；如果只保留优先级，就看不出问题性质，无法做类型统计。
常见误解有三个。误解一：严重程度高就等于优先级高。前文已说明，影响面、修复成本和版本计划都会让两者出现差异，映射表提供默认关系，具体缺陷仍需单独判断。误解二：分类确定后分级可以省略。分类只说明问题性质，不说明影响和排期，省略分级会让团队无法排序和分配资源。误解三：维度越多越好。维度增加会提高录入成本，取值枚举也容易失控，出现“其他”“待定”大量堆积的情况。每个新增维度都应有明确的使用场景和统计口径，否则应删减。
常见问题
严重程度和优先级可以合并成一个字段吗？
不建议合并。严重程度评估缺陷对业务或用户的影响，优先级决定修复排期，两者的判断依据不同：影响面、修复成本、版本计划和客户承诺都会让优先级偏离严重程度。合并后，团队无法区分“影响大但可以缓一缓”和“影响小但必须马上修”这两类情况。更稳妥的做法是保留两个字段，用映射表给出默认对应关系，例如严重程度为致命时默认优先级为高，再允许在具体缺陷上按实际情况调整。
团队规模小，是否可以把分类维度精简到只保留缺陷类型？
可以，前提是精简后仍能满足实际使用。分类维度的取舍标准是该维度是否产生团队真正使用的统计口径或分派依据。如果团队规模小、模块划分简单，只保留缺陷类型和所属模块通常够用；引入阶段这类维度适合需要做质量回溯的团队，没有相应分析需求时可以不设。需要注意的是，分类可以精简，分级不宜省略，否则团队缺少排序和分配资源的依据。
维度之间的关联规则应该由谁制定、多久调整一次？
关联规则属于团队约定，通常由缺陷管理流程的负责人牵头，与开发、测试负责人共同确认，并写入团队的缺陷管理规范。调整频率取决于产品阶段：版本节奏快、缺陷量大的阶段可以每季度回顾一次映射表是否仍然适用；流程稳定后可以按半年或更长的周期检查。调整时应同步更新字段说明和判定示例，避免同一档位在不同人手里理解不一致。
缺陷记录里的优先级和工单系统里的优先级需要保持一致吗？
不需要强行一致，但需要分别定义清楚。缺陷优先级服务于研发排期，判断依据是影响程度、修复成本和版本计划；工单优先级服务于服务响应承诺，判断依据是客户影响和响应时限。ONES Desk 支持评估和定义工单优先级，优先解决紧急事件，这里的优先级针对工单场景。团队如果同时使用缺陷管理和工单管理，应在两套系统中分别写明优先级的含义和档位说明，跨系统比较时以各自的定义为准。
新增一个分级维度前，应该先确认什么？
先确认三件事：这个维度是否会产生团队实际查看的报表或决策依据；取值枚举能否控制在有限档位内，避免大量落入“其他”“待定”；录入成本是否可接受。如果某个维度填了之后没有人使用，它只会增加提交缺陷时的负担，并让统计结果变得不可比。维度数量增加并不提升管理精度，取值枚举稳定、判定说明清晰才是可比较的前提。
