缺陷分类与分级要做成两套字段：分类回答“缺陷属于哪类问题”，分级回答“这个缺陷有多严重、多急”。把类型、严重程度、优先级塞进同一个下拉框，团队很快会遇到两个麻烦：统计时无法按模块或阶段聚合，排期时又分不清“影响大但不紧急”和“影响小但卡住发布”。本文按字段设计、判定表编写、角色分工、填写示例和验收检查的顺序展开，帮助团队建立一套可直接用于缺陷提交与确认环节的规则；缺陷归属与排队、SLA 时限设定不在本文范围内。
要点总览（TL;DR）
- 缺陷分类与分级要拆成两组字段：分类用缺陷类型、发生阶段、影响模块、触发条件打标签，分级用严重程度和优先级两个独立字段表达。
- 严重程度由业务影响、数据影响、可绕过性决定，优先级由修复窗口与阻塞范围决定；排期变化只改优先级，严重程度保持稳定。
- 判定表每级都要写判定条件并配一条边界示例，示例优先取自团队过去争议最多的缺陷，让相邻等级有可对照的判例。
- 提交人填现象与初步分类，测试或模块负责人确认严重程度，复核人定期抽样校准；规则发布后一个月内做首轮一致性检查。
- 验收看三件事：枚举值互斥且覆盖主要类型、两人独立定级结果基本一致、每次等级调整都有理由记录可回溯。
先分清分类与分级：两组字段各管什么
分类与分级服务于不同决策。分类用于检索、统计和趋势分析，回答“问题出在什么地方”；分级用于判断处理顺序和投入程度，回答“先处理哪个、需要多快处理”。两组字段分开设计，才能让缺陷列表既可按模块筛选，又可按严重程度排序。
分级内部还要再拆一层：严重程度由影响决定，描述缺陷对业务、数据、用户的实际损害；优先级由排期决定，描述在当前版本和资源条件下何时修复。一个影响很大的缺陷可能因为触发条件罕见而排在后面，一个影响有限的缺陷也可能因为阻塞测试而优先处理。两者独立填写，排期调整时只改优先级，严重程度保持稳定，历史统计才不会被排期动作污染。
常见错误是用“严重、一般、轻微”一个字段同时承担类型与等级。这样做的直接后果是：提交人按主观感受选等级，测试确认时再改一次，统计报表里既看不出缺陷集中在哪个模块，也看不出严重缺陷的比例变化。更隐蔽的问题是，当“严重”既表示业务影响大、又表示要马上修时，团队无法区分“影响大但可延后”和“影响小但必须今天修”两类缺陷。
| 字段组 | 回答的问题 | 典型字段 | 主要用途 | 变更频率 |
|---|---|---|---|---|
| 分类 | 缺陷属于哪类问题 | 缺陷类型、发生阶段、影响模块、触发条件 | 检索、聚合统计、根因分析 | 确认时校正，之后基本稳定 |
| 分级—严重程度 | 影响有多大 | 严重程度（如致命、严重、一般、轻微） | 质量评估、发布门槛判断 | 随影响认知更新，调整需留记录 |
| 分级—优先级 | 何时修、多快修 | 优先级（如立即、本迭代、下迭代、待排期） | 排期、资源分配 | 随版本计划和资源变化调整 |
分类维度怎么定：枚举值与打标规则
分类字段的设计目标是“同一缺陷，不同人打出的标签基本一致”。做到这一点，维度数量要克制，枚举值要互斥且可判定。建议从四个维度起步，团队规模扩大或缺陷量上升后再增补。
- 缺陷类型：描述问题性质，如功能实现错误、界面显示异常、性能问题、兼容性问题、数据错误、文档与提示信息错误。枚举值按团队实际缺陷分布裁剪，保留出现频率高的类别。
- 发生阶段：描述缺陷在哪个环节被发现或被引入，如需求评审、开发自测、测试执行、上线后。该维度用于分析缺陷逃逸情况，枚举值应与团队实际流程阶段对应。
- 影响模块：描述缺陷所在的业务模块或系统组件。模块清单应来自产品结构或代码仓库划分，避免提交人自行命名导致同义不同名。
- 触发条件：描述缺陷在什么条件下出现，如特定操作路径、特定数据状态、特定设备或浏览器、并发场景。该维度可用枚举加补充说明的方式，枚举覆盖常见条件类别，细节写在描述里。
枚举值定义要满足三条：互斥，即一个缺陷只能落入一个值；可判定，即提交人依据现象就能选，不需要猜测开发实现；覆盖主要缺陷类型，“其他”类占比控制在较低水平。定期查看“其他”的分布，把高频项提升为正式枚举值，是保持分类体系可用的常规动作。
打标发生在两个时点，责任人不同。提交时，提交人根据可观察现象填写初步分类，重点是现象层面的类型、模块和触发条件；确认时，测试或模块负责人核对分类是否准确，修正误标并补齐发生阶段等信息。两个时点分开，既保证提交环节足够轻，又保证进入统计的数据经过确认。
| 分类字段 | 取值来源 | 提交人动作 | 确认人动作 |
|---|---|---|---|
| 缺陷类型 | 预定义枚举 | 按现象选择 | 核对是否误标，必要时改类 |
| 发生阶段 | 预定义枚举 | 可留空 | 按发现环节补齐 |
| 影响模块 | 模块清单 | 选择最直接相关模块 | 核对模块归属 |
| 触发条件 | 枚举加描述 | 选择条件类别并写清复现路径 | 补充遗漏条件 |
分级标准怎么定：严重程度与优先级的判定表
分级定义表的质量取决于两点：每级有可判定的条件，每级有边界示例。只写“严重影响业务”这类描述，不同人理解不同，定级结果自然分散。
严重程度建议按三个角度划分：业务影响，即缺陷是否导致核心流程不可用、结果错误或用户无法完成关键操作；数据影响，即是否造成数据丢失、错乱、泄露或不可恢复；可绕过性，即用户是否有替代路径完成目标。三个角度组合成等级，例如：核心流程中断且无替代路径，定为最高级；核心流程结果错误但有临时替代方案，定为次高级；非核心功能异常且影响有限，定为一般；显示或文案问题不影响操作，定为轻微。等级数量和名称可按团队习惯设定，关键是每个等级都写明判定条件。
优先级按修复窗口与阻塞范围划分：是否阻塞当前版本的测试或发布，是否阻塞其他团队的工作，是否已有用户投诉或线上影响。优先级取值建议与时间窗口挂钩，如立即处理、本迭代内、下迭代、待排期，避免使用“高、中、低”这类无法对应排期的表述。
| 等级 | 判定条件 | 边界示例 |
|---|---|---|
| 严重程度—致命 | 核心业务流程中断，无替代路径；或造成数据丢失、错乱且不可恢复 | 下单提交后订单未生成，用户无法通过其他入口完成购买 |
| 严重程度—严重 | 核心流程结果错误，存在临时替代方案；或重要数据展示错误 | 订单金额计算错误，用户可联系客服人工改单 |
| 严重程度—一般 | 非核心功能异常，影响部分用户，有明确绕过方式 | 消息通知延迟，用户可在站内查看最新状态 |
| 严重程度—轻微 | 显示、文案、样式问题，不影响操作与数据 | 按钮文案错别字，功能行为正确 |
| 优先级—立即 | 阻塞当前版本测试或发布，或线上已产生用户影响 | 测试环境登录失败，全部用例无法执行 |
| 优先级—本迭代 | 不阻塞发布，但影响本迭代验收范围 | 本迭代新增功能的次要路径报错 |
| 优先级—下迭代 | 影响有限，可随下个版本修复 | 旧版本页面的兼容性显示问题 |
| 优先级—待排期 | 触发条件罕见，暂无用户反馈，修复成本待评估 | 特定旧设备上的偶发样式错位 |
边界示例的作用是处理相邻等级之间的模糊地带。编写时优先收集团队过去争议最多的缺陷，把争议结论写成示例附在对应等级下。示例积累后，判定表就从抽象描述变成了可对照的判例集。
角色与交付物：谁提交、谁定级、谁复核
规则要落到人。缺陷分类分级涉及三类角色，各自的动作和产出应写清楚，避免出现“提交人随手选、确认人不核对、没人看统计”的情况。
| 角色 | 主要动作 | 交付物 | 完成标志 |
|---|---|---|---|
| 提交人 | 填写可观察现象、复现路径、初步分类 | 一条信息完整的缺陷记录 | 现象可复现，分类字段已选，描述不含猜测性结论 |
| 测试或模块负责人 | 确认分类，判定严重程度，提出优先级建议 | 确认后的分类分级字段 | 严重程度有判定依据，与判定表条件对应 |
| 复核人 | 定期抽样检查等级一致性，维护判定表与示例 | 抽样复核记录、判定表修订记录 | 抽样结果形成一致性结论，争议项有处理意见 |
提交人的职责边界是“把看到的说清楚”，不要求判断根因或技术原因。测试或模块负责人掌握更多上下文，负责把现象映射到严重程度，并在优先级上与产品、开发对齐。复核人通常由测试负责人或质量角色承担，按固定周期抽取已确认缺陷，检查同一类现象是否被打成不同等级，把分歧整理成判定表的补充示例。
分类分级字段需要承载在缺陷工作项上，字段配置、必填规则和状态流转会直接影响填写质量。以 ONES 为例，可以在缺陷工作项上配置缺陷类型、发生阶段、影响模块、严重程度、优先级等字段，设置提交时必填与确认时必填的差异，并通过工作流状态区分“待确认”和“已确认”，让分类分级动作对应到具体环节。字段选项的维护和判定表版本可以随复核记录同步更新。
完整示例：一条缺陷从提交到定级
以下为演示情景，用于说明字段如何填写与判定，不代表真实项目数据。
现象描述：用户在结算页选择优惠券后点击“提交订单”，页面提示“系统繁忙”，订单未生成；取消优惠券后可以正常下单。复现路径为：登录—加入商品—进入结算页—选择满减券—提交订单。浏览器为当前主流版本，测试环境与预发环境均可复现。
分类打标：缺陷类型选“功能实现错误”；发生阶段选“测试执行”；影响模块选“订单结算”；触发条件选“特定数据状态”，并在描述中注明“使用满减券时触发”。
严重程度判定：核心流程“提交订单”中断，但用户取消优惠券后可完成下单，存在替代路径；未造成数据丢失。对照判定表，符合“核心流程结果错误、存在临时替代方案”的条件，定为“严重”。若确认该问题导致已支付订单状态异常，则影响升级为数据错乱，应调整为“致命”。
优先级判定：该缺陷阻塞本迭代优惠券功能的验收，但不阻塞整体发布，定为“本迭代”。若临近发布且优惠券是本次主推功能，可上调为“立即”，调整理由记录在缺陷评论中。
边界调整：确认过程中发现该问题仅在特定券类型下出现，触发条件收窄，严重程度维持“严重”，优先级可下调为“下迭代”，并在复核记录中注明调整依据。这类调整正是判定表边界示例的来源。
完成检查：分级规则是否可用的验收项
分类分级机制是否达到可用状态，可以用一组可核对的检查项判断。建议在规则发布后一个月内完成首轮检查，之后按季度复查。
- 枚举值互斥性：随机抽取若干条已确认缺陷，检查是否存在同一缺陷可同时落入两个枚举值的情况；存在则合并或改写定义。
- 覆盖度：统计“其他”类占比，查看高频未覆盖类型，决定是否新增枚举值；同时检查是否存在长期无人使用的枚举值。
- 定级一致性：由两名熟悉判定表的人员对同一批缺陷独立定级，比较结果；分歧集中的等级需要补充边界示例或改写判定条件。
- 判定表完整性：每个等级是否都有判定条件和至少一条边界示例；示例是否来自真实争议，而非凭空编写。
- 调整记录：严重程度或优先级的每次调整是否有理由记录，复核人能否据此回溯。
- 字段必填与流程匹配：提交环节必填字段是否足够轻，确认环节是否补齐了发生阶段等关键信息；状态流转是否区分待确认与已确认。
- 统计可用性：按模块、阶段、严重程度生成的报表能否直接回答“缺陷集中在哪”“严重缺陷比例是否上升”等问题。
检查结果不达标时，优先修判定表和示例，再考虑增加字段。字段越多，填写负担越重，一致性反而下降。规则稳定后，分类分级数据才能支撑缺陷趋势分析和质量改进决策。
常见问题
团队缺陷量不大，还需要单独设“发生阶段”这个分类维度吗？
缺陷量较小时，可以先保留缺陷类型和影响模块两个维度，把发生阶段暂缓。是否增补的判断依据是：团队是否需要分析缺陷逃逸，即有多少缺陷在测试执行之后才被发现。如果当前阶段主要关注缺陷集中在哪个模块，模块维度足够支撑统计；等到需要回答“哪类问题漏到了上线后”，再补发生阶段，并同步明确各阶段与团队实际流程的对应关系。
同一个缺陷，两个人定出的严重程度不一样，应该怎么处理？
先把分歧记录下来，判断属于哪种情况。如果两人对现象的理解不同，说明缺陷描述不够完整，应补充复现路径和影响范围；如果现象一致但结论不同，说明判定表在该处缺少边界示例，把这条缺陷作为示例补进相邻等级之间，并写明判定理由。分歧集中的等级要优先修订，修订后重新抽样验证。这类争议本身就是判定表逐步完善的来源。
严重程度定下来之后，还能改吗？
可以改，但要留下记录。常见需要调整的情形有两种：确认过程中发现影响范围比提交时判断的更大或更小，例如从存在替代路径变为数据错乱；或者触发条件收窄，实际影响用户范围有限。调整时在缺陷记录中写明原等级、新等级和依据，复核人据此回溯。严重程度频繁变动通常说明提交环节的现象描述不足，应从描述规范入手，而非反复改等级。
优先级和严重程度能否合并成一个字段，减少填写负担？
合并会丢失排期信息与影响信息的区分。严重程度反映缺陷造成的实际损害，随认知更新但相对稳定；优先级反映当前版本和资源条件下的处理顺序，会随发布计划变化。合并后，一旦为了排期调整等级，历史统计中的严重缺陷比例就会失真。字段数量确实需要控制，但这两个字段承担不同决策，建议保留独立，通过必填规则和默认值降低填写成本。
分类分级字段在工具里怎么落地，才能保证提交时不漏填？
思路是把字段配置与流程状态对应起来：提交环节只要求填写现象层面容易判断的字段，如缺陷类型、影响模块；确认环节再要求补齐发生阶段、严重程度和优先级。以 ONES 为例，可以在缺陷工作项上配置这些字段，按状态区分提交时必填与确认时必填，并用工作流状态区分待确认与已确认。字段选项和判定表版本随复核记录同步维护，避免规则更新后工具里的枚举值仍是旧版。
