缺陷分类要先把“类型”和“严重程度”拆成两套独立字段：类型回答缺陷属于哪类问题，用于归因和改进；严重程度回答影响有多大，用于决定修复顺序和评审门槛。落地时先定字段与取值，再定判定规则和角色分工，最后用抽样复核和指标验证分类是否稳定。本文给出可直接采用的字段定义表、严重程度判定规则清单、角色职责表，并用一条完整缺陷演示分类过程，最后附上线后的检查清单。
要点总览（TL;DR）
- 把“类型”“严重程度”“优先级”拆成三个独立字段：类型用于归因改进，严重程度用于决定修复顺序和评审门槛，优先级归工单优先级与SLA管理。
- 严重程度用条件式规则定义，按影响范围、可绕过性和数据风险判定；类型判定固定顺序，命中即停止，减少同一缺陷不同结论。
- 明确提交人初填、测试/模块负责人复核、开发负责人申诉、质量负责人维护规则与抽样复核，并约定时限和裁决人。
- 用一条支付失败缺陷演示从提交、复核、申诉到沉淀规则条目的全过程，争议裁决结果回写记录。
- 上线后按月核对字段完整率、抽样复核一致率、修复顺序合理性、返工率、规则版本与培训记录，用指标定位规则问题。
先定字段：缺陷分类要拆成哪几个维度
缺陷分类最常见的失败，是把“类型”“严重程度”“优先级”塞进同一个下拉框，导致同一个缺陷在不同人手里得到不同结论，统计时也无法区分问题性质和影响大小。合理的做法是拆成三个独立字段，各自承担不同职责。
类型字段回答“这是什么问题”，用于归因分析、模块质量趋势和改进方向；严重程度字段回答“影响有多大”，依据影响范围、可绕过性和数据风险判定，用于决定修复顺序和评审门槛；优先级字段回答“先做哪个”，由业务价值、发布节奏和资源情况共同决定，属于工单优先级与SLA管理的范畴，本文不展开。三个字段分开后，一个“界面文案错误但出现在支付确认页”的缺陷，可以同时被标记为界面类型、较低严重程度和较高优先级，信息不丢失。
下表给出可直接采用的字段结构，团队可按业务特点增删取值，但应保持字段职责不变。
| 字段名 | 取值 | 必填性 | 填写人 | 判定依据 |
|---|---|---|---|---|
| 缺陷类型 | 功能、界面、性能、兼容性、数据、安全、文档、其他 | 必填，单选 | 提交人初填，测试复核 | 缺陷表现出的主要问题性质，按固定判断顺序确定 |
| 严重程度 | 致命、严重、一般、轻微 | 必填，单选 | 提交人初判，测试/模块负责人复核 | 影响范围、是否存在绕过手段、是否涉及数据或安全风险 |
| 影响模块 | 按产品模块枚举 | 必填，单选 | 提交人 | 缺陷所在的功能模块，用于归因统计 |
| 复现环境 | 按环境枚举（开发、测试、预发、生产等） | 必填，单选 | 提交人 | 缺陷被观察到的环境 |
| 关联需求 | 需求编号 | 选填 | 提交人 | 缺陷对应的需求或用户故事，便于追溯 |
取值设置遵循几条原则：类型和严重程度保持单选，避免多选造成统计口径混乱；必填项只保留判定和统计真正需要的字段，字段过多会降低填写意愿；默认值只用于低风险字段，严重程度不设默认值，强制填写人主动判断。类型取值中的“其他”应设置使用上限，定期检查“其他”占比，占比过高说明类型枚举需要补充。
判定规则怎么写：让不同人给出同一结论
字段定义只解决了“填什么”，判定规则解决“怎么填才一致”。规则要用条件式语句描述，每条规则包含可观察的事实条件，避免“影响较大”“体验较差”这类无法核对的表述。
严重程度按四级设计，每级给出判定条件和典型样例，规则清单如下：
| 等级 | 判定条件 | 典型样例 |
|---|---|---|
| 致命 | 主流程完全阻断且无绕过手段，或造成数据丢失、数据错误、安全泄露 | 支付成功后订单状态未更新；用户数据被越权访问 |
| 严重 | 主流程受阻但存在明确绕过手段，或核心功能结果错误 | 批量导出失败但可分批导出；金额计算结果偏差 |
| 一般 | 非主流程功能异常，或主流程存在轻微体验问题但不影响结果 | 筛选条件重置后未清空；提示文案错别字 |
| 轻微 | 不影响功能使用的外观、文案、格式问题 | 按钮间距不一致；帮助文档链接文字与目标页不符 |
类型判定需要固定判断顺序，避免同一缺陷被归入多个类型。建议顺序为：安全、数据、性能、兼容性、功能、界面、文档、其他。判断时从顺序靠前的类型开始比对，命中即停止。例如一个缺陷既表现为页面报错又导致数据写入错误，按顺序归入数据类型，因为数据风险优先于界面表现。冲突处理的依据应写入规则文档，而不是每次临时讨论。
边界样例是规则稳定性的关键。复核中出现的争议缺陷，裁决后应沉淀为规则条目，写明“当……时，判定为……”，并附上原始缺陷编号。规则文档由质量或流程负责人维护，更新触发条件包括：新增业务模块、出现无法归类的缺陷、抽样复核一致率低于约定阈值、严重程度定义与业务风险标准发生变化。每次更新记录版本号和生效日期，旧版本保留可查。
角色与交付物：谁填、谁审、谁改
分类流程涉及四类角色，每个角色的动作和完成标志要写清楚，否则容易出现提交人随手填、开发不认可、测试两头协调的情况。
| 角色 | 动作 | 输入 | 输出 | 完成标志 |
|---|---|---|---|---|
| 提交人 | 填写类型、初判严重程度、影响模块和复现环境 | 缺陷现象、复现步骤、环境信息 | 字段完整的缺陷记录 | 必填字段无缺失，复现步骤可被他人按步骤重现 |
| 测试/模块负责人 | 复核类型与严重程度，修正明显偏差 | 缺陷记录、规则文档 | 复核后的定级结果 | 在约定时限内完成复核并留下复核记录 |
| 开发负责人 | 对定级有异议时提出申诉，说明技术依据 | 缺陷记录、影响分析 | 申诉意见或接受结论 | 申诉在约定时限内得到裁决并回写记录 |
| 质量或流程负责人 | 维护规则文档、组织抽样复核、统计分类指标 | 缺陷数据、复核记录 | 规则版本、复核报告、指标看板 | 按周期输出复核结果，规则变更完成版本记录 |
复核时限和申诉裁决人应在流程启动时明确，例如测试在缺陷提交后一个工作日内完成复核，申诉由测试负责人与开发负责人共同裁决，争议无法达成一致时由质量负责人裁定。裁决结果要回写到缺陷记录中，作为后续规则修订的依据。
当团队使用缺陷管理工具承载这套流程时，字段配置、必填校验和复核记录可以直接落在工作项上。ONES 支持在缺陷工作项中配置类型、严重程度等自定义字段并设置必填，状态流转可以对应“待复核—已定级—申诉中—已裁决”的过程，复核意见和裁决依据以评论或字段形式留痕，抽样复核时按字段筛选导出即可。这样规则文档与系统记录保持一致，减少线下表格和系统数据两套口径的问题。
完整示例：一个支付失败缺陷如何走完分类
以下为演示情景，用于说明规则如何被应用和修正。
提交人观察到：在测试环境下，用户点击支付后页面提示“支付失败”，但银行侧显示扣款成功，订单状态仍为“待支付”。提交人填写：类型初选“功能”，严重程度初判“严重”，影响模块“支付”，复现环境“测试”，复现步骤写明操作路径和账号信息。
测试复核时按规则逐条比对：该缺陷导致用户资金已扣但订单未更新，属于核心功能结果错误，且用户无法自行恢复，符合“致命”条件中“造成数据错误”的情形，将严重程度修正为“致命”。类型判定按固定顺序比对：不涉及安全泄露，不涉及性能指标，不涉及兼容性，表现为功能结果错误，归入“功能”类型，同时补充“数据”标签用于归因统计。复核记录中写明修正依据和对应规则条目。
开发负责人提出异议，认为该问题由银行回调延迟引起，属于外部依赖，建议降为“严重”。裁决依据为：无论根因在内部还是外部，用户侧表现为资金与订单状态不一致，且无绕过手段，维持“致命”。裁决结果回写缺陷记录，并将“外部依赖导致的数据不一致，按用户侧影响定级”沉淀为规则条目，附上该缺陷编号。
最终记录字段为：类型“功能”、严重程度“致命”、影响模块“支付”、复现环境“测试”、关联需求“订单支付流程”。这条记录同时成为后续同类缺陷的判定参照。
完成检查：分类机制是否真的跑起来了
规则写完不等于执行到位，需要用检查项和指标验证。以下清单可按月核对。
| 检查项 | 检查方法 | 判断标准 |
|---|---|---|
| 字段完整率 | 统计周期内缺陷记录中必填字段的填写比例 | 必填字段缺失率持续下降并稳定在低位；缺失集中在哪些字段要能说清原因 |
| 抽样复核一致率 | 随机抽取一定数量已定级缺陷，由未参与原判定的测试人员独立重判，计算结论一致的比例 | 一致率按类型和严重程度分别统计；一致率偏低时定位到具体等级或类型，补充规则条目 |
| 修复顺序合理性 | 对比高严重程度缺陷的实际修复顺序与定级顺序 | 致命和严重缺陷应优先进入修复队列，出现倒挂时核查是否存在定级偏差或资源冲突 |
| 返工率 | 统计因定级争议导致的重新评审次数和修复后重开次数 | 争议集中在少数规则条目时，优先修订这些条目而非反复个案裁决 |
| 规则文档版本 | 核对规则文档版本号、生效日期与变更记录 | 每次规则变更都有版本记录和对应缺陷样例，旧版本可追溯 |
| 培训记录 | 核对新成员和规则变更后的培训或宣贯记录 | 新加入的提交人和测试人员完成规则学习后再独立填写或复核 |
指标的作用是定位问题而不是考核个人。一致率下降通常指向规则表述模糊或新业务缺少样例，此时应补充边界样例并更新规则文档；字段缺失集中在某类提交人时，检查填写入口是否过长或必填项是否过多。分类机制运行一段时间后，类型分布和严重程度分布本身也是有用的信号：某类型缺陷持续高发，说明该模块需要专项改进；致命缺陷占比异常升高，需要核查定级是否过宽或质量标准是否松动。
常见问题
团队规模较小，是否也需要把类型、严重程度、优先级拆成三个字段？
字段拆分解决的是信息不丢失和统计口径问题，与团队规模关系不大。小团队同样会遇到“界面文案错误但出现在支付确认页”这类情况，拆开字段后可以同时记录问题性质和影响大小。如果填写负担确实较重，可以先保留类型和严重程度两个必填字段，优先级由迭代排期时再定，但不要把三者合并成一个下拉框。
严重程度复核一致率一直偏低，应该先改规则还是先培训？
先看分歧集中在哪些等级和类型。如果争议集中在少数几个等级，通常是规则表述缺少可观察条件，应补充边界样例并更新规则文档；如果分歧分散在多个等级，且新成员较多，则优先安排规则宣贯和样例练习。两种动作可以并行，但规则修订要留下版本记录和对应缺陷编号，便于后续核对。
开发负责人对定级有异议时，裁决结果应该记录在哪里？
裁决结果应回写到缺陷记录本身，写明维持或调整后的等级、裁决依据和对应的规则条目。这样后续同类缺陷可以直接参照，抽样复核时也能追溯。如果团队使用缺陷管理工具，可以把裁决意见放在评论或专门字段中，并保留申诉和裁决的时间点。
外部依赖导致的缺陷，严重程度按什么标准定？
按用户侧可观察到的影响定级，而不是按根因归属定级。例如银行回调延迟导致用户已扣款但订单状态未更新，用户侧表现为资金与订单不一致且无绕过手段，仍应按致命处理。裁决后把“外部依赖导致的数据不一致，按用户侧影响定级”写成规则条目，避免每次个案讨论。
分类机制运行一段时间后，类型分布数据可以用来做什么？
类型分布用于定位改进方向：某类型缺陷持续高发，说明对应模块需要专项治理；严重程度分布异常，例如致命缺陷占比突然升高，需要核查定级是否过宽或质量标准是否松动。“其他”类型占比过高时，说明类型枚举需要补充，应结合争议样例调整取值。
