缺陷分类与分级要落成一套可执行的机制：先确定分类维度（来源、模块、缺陷类型、严重程度、优先级），再为每个维度定义互斥且可判定的取值和判定依据，然后规定谁在什么时点填写、如何复核与调整，最后用抽样一致率和分级分布检查执行效果。其中最关键的一条是严重程度与优先级分开定义：严重程度看缺陷对系统的影响，优先级看修复排期的先后，两者各有判定人。
要点总览（TL;DR）
- 缺陷分类分级从五个字段起步：来源、所属模块、缺陷类型三个分类字段，严重程度、优先级两个分级字段，每个字段的取值要互斥且能用一句话判定。
- 严重程度与优先级分开定义：严重程度由测试或质量角色按影响范围、功能可用性、数据与安全判定，优先级由产品/业务角色按业务影响、发生频率、规避方案确认。
- 执行流程覆盖提交、严重程度判定、优先级确认、复核、变更记录五步，复核按周抽查致命与严重两档，定级调整保留原档位、新档位与变更理由。
- 落地效果用字段完整率、取值合规、定级一致率、分级分布和变更记录五项检查，不通过时对准具体环节调整，例如一致率低就补充判定标准的边界条件。
先定维度：缺陷分类分级要建哪几个字段
字段是整套机制的骨架。字段过多会让提交人负担过重、填写流于形式；字段过少则无法支撑后续的统计与排期。建议按“三个分类字段＋两个分级字段”起步，先保证每个字段都能被稳定判定，再按团队实际需要增补。
分类字段回答“这个缺陷是什么、从哪里来、落在哪里”，分级字段回答“它有多严重、该多快修”。分类字段通常由提交人填写，分级字段由具备判断能力的角色填写，这一分工在字段设计阶段就要确定下来。
| 字段名 | 取值方向 | 判定依据 | 填写人 |
|---|---|---|---|
| 缺陷来源 | 建议4–6个取值，如：内部测试、用户反馈、线上监控、回归验证、验收发现 | 缺陷首次被发现的渠道，以发现时的场景为准 | 提交人 |
| 所属模块/功能 | 按产品功能结构划分，取值数量与模块清单一致 | 缺陷影响的功能归属，跨模块时选主要受影响模块 | 提交人 |
| 缺陷类型 | 建议5–8个取值，如：功能错误、界面显示、性能问题、兼容性、数据问题、安全漏洞、文档错误 | 缺陷的表现形态，按主要表现归类 | 提交人 |
| 严重程度 | 建议4档：致命、严重、一般、轻微 | 缺陷对系统功能、数据和安全的影响程度 | 测试或质量角色 |
| 优先级 | 建议4档：紧急、高、中、低 | 缺陷对业务的影响、发生频率与是否有规避方案 | 产品/业务角色 |
取值设计有两条硬要求。一是互斥：同一缺陷在任一字段上只能落入一个取值，取值之间不能出现“既算A又算B”的模糊地带，例如“功能错误”与“数据问题”要在定义里划清边界，数据计算错误归数据问题，功能入口不可用归功能错误。二是可判定：每个取值都要能用一句话说清“什么情况下选它”，避免出现“其他”“ miscellaneous”这类兜底取值被大量使用。
严重程度与优先级必须分开，原因在于两者回答的问题不同。一个缺陷可能严重程度很高（核心支付链路不可用）但优先级中等（该功能处于灰度阶段、仅少量用户可见）；也可能严重程度一般（某页面文案错别字）但优先级很高（面向监管披露的页面）。若合并成一个字段，排期时要么牺牲业务判断，要么牺牲技术判断。分开定义后，严重程度由测试或质量角色判定，优先级由产品/业务角色确认，各自对判断结果负责。
判定标准怎么写：严重程度与优先级的定级规则
判定标准的作用是把等级从形容词变成可对照的条件。写法上，每一档都要给出正向判定条件和一个典型例子，让判定人对照条件选择，而不是凭感觉排序。条件描述应指向可观察的事实：影响哪些用户、哪些功能不可用、数据是否受影响、有无临时规避手段。
严重程度分档
严重程度按影响范围、功能可用性、数据与安全三个角度分档，取三者中最严重的一条作为定档依据。
| 档位 | 判定条件 | 典型例子 |
|---|---|---|
| 致命 | 核心功能完全不可用，或造成数据丢失、数据错误、安全漏洞，且无规避方案 | 支付下单接口持续报错，所有用户无法完成支付 |
| 严重 | 主要功能不可用或结果错误，影响较大范围用户，规避成本高 | 订单列表加载失败，用户无法查看历史订单 |
| 一般 | 次要功能异常或主要功能存在可规避的缺陷，影响范围有限 | 某类优惠券在特定条件下不显示，用户可换用其他入口 |
| 轻微 | 界面显示、文案、体验类问题，不影响功能使用 | 按钮文字与设计稿不一致，功能正常 |
优先级分档
优先级按业务影响、发生频率、有无规避方案三个因素综合判断。业务影响看缺陷涉及的功能对当前业务目标的重要程度，发生频率看触发条件的普遍性，规避方案看用户或运营是否有可用的替代路径。
| 档位 | 判定条件 | 典型例子 |
|---|---|---|
| 紧急 | 影响核心业务收入或合规要求，发生频率高，无规避方案，需立即安排修复 | 大促期间支付失败率上升，直接影响成交 |
| 高 | 影响重要业务流程，发生频率较高，规避成本明显 | 退款申请入口偶发无响应，客服需人工代提 |
| 中 | 影响一般业务功能，有可用规避方案，可纳入近期迭代 | 报表导出格式错位，可手工调整后使用 |
| 低 | 影响体验或非关键路径，可随版本批量处理 | 帮助页文案表述不准确 |
定级争议的复核方式要事先约定。常见做法是：当提交人与判定人对档位有分歧时，由质量负责人组织一次短会，对照判定条件逐条核对事实，形成结论并记录理由；同类争议重复出现时，说明判定条件本身需要修订，应回到标准文本补充边界说明，而不是每次靠个案裁决。
执行步骤：从提交到复核的分级流程
流程设计的目标是让每个关键动作都有明确的输入、动作、输出和完成标志，避免定级停留在“提交时随手选一个”的状态。下表给出一个可直接采用的流程框架，团队可按规模裁剪复核环节的频次。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 | 负责人 |
|---|---|---|---|---|---|
| 1. 提交 | 缺陷现象、复现步骤、环境信息 | 填写来源、模块、缺陷类型等分类字段，描述现象与复现路径 | 一条待定级的缺陷记录 | 分类字段填写完整，现象可复现 | 提交人 |
| 2. 严重程度判定 | 缺陷记录、判定标准 | 对照严重程度分档条件，确认影响范围与数据安全情况 | 严重程度档位及判定理由 | 档位已填写，理由可对照标准条款 | 测试或质量角色 |
| 3. 优先级确认 | 严重程度、业务背景 | 结合业务影响、发生频率、规避方案确认优先级 | 优先级档位及排期建议 | 优先级已确认，与严重程度的关系有说明 | 产品/业务角色 |
| 4. 复核 | 已定级缺陷清单 | 按周期抽查或集中评审定级结果，核对判定依据 | 复核结论与调整意见 | 抽查记录留存，分歧项有结论 | 质量负责人 |
| 5. 变更记录 | 调整意见 | 修改档位并记录变更原因、变更人与时间 | 带变更历史的缺陷记录 | 每次档位变化均可追溯 | 原判定人或复核人 |
流程中有两个容易被省略的环节值得单独强调。其一是复核：复核不必每次全量，可按周抽取一定比例的缺陷，重点看致命、严重两档和发生过变更的记录，用较小成本发现系统性偏差。其二是变更记录：定级调整在缺陷生命周期中很常见，例如缺陷修复过程中发现影响面比初判更大，此时应保留原档位、新档位、变更理由三项信息，否则后续统计分级分布时会失真。
当团队使用缺陷管理工具承载这套流程时，可以把上述字段配置为缺陷工作项的固定属性，把严重程度与优先级设为必填，并通过状态流转把“待定级—已定级—复核中—已关闭”串起来，变更历史由系统自动留痕。ONES 的缺陷管理工作项支持自定义字段与状态流转，定级调整会记录在操作历史中，便于按周导出复核清单。工具承载的是记录与流转，判定标准本身仍需团队在文档中维护并定期修订。
角色与交付物：谁填、谁判、谁复核
职责划分的核心是让每个字段都有唯一的第一责任人，同时避免同一人既判定又复核。下表按角色列出分工与对应交付物。
| 角色 | 主要职责 | 交付物 |
|---|---|---|
| 提交人 | 填写来源、模块、缺陷类型等分类字段，提供可复现的现象描述 | 分类完整的缺陷记录 |
| 测试或质量角色 | 判定严重程度，核对影响范围与数据安全情况 | 严重程度档位及判定理由 |
| 开发 | 提供技术影响判断，修复后反馈实际影响面是否与初判一致 | 影响面说明、修复说明 |
| 产品/业务角色 | 确认优先级，结合业务节奏给出排期建议 | 优先级档位及排期意见 |
| 质量负责人 | 组织复核、裁决定级争议、维护判定标准文本 | 复核记录、争议裁决结论、标准修订记录 |
定级争议的裁决角色建议固定为质量负责人，而不是由提交人与判定人自行协商。裁决的依据是对照判定标准核对事实，而不是比较谁的职级更高。裁决结论应回写到缺陷记录中，并在标准文本需要补充边界时同步更新，使同类争议下次可以直接按标准处理。
示例：一个支付失败缺陷如何完成分类与分级
以下为演示情景，用于说明字段填写与定级判断的过程，不对应真实系统数据。
某电商系统在版本发布后，部分用户在提交订单时支付接口返回超时，订单停留在待支付状态，用户重复点击后出现重复扣款提示。提交人按字段逐项填写：来源为线上监控，所属模块为支付，缺陷类型为功能错误，现象描述包含触发条件、影响用户范围和复现步骤。
测试角色对照严重程度标准判定：支付是核心功能，当前部分用户无法完成支付，且存在重复扣款提示涉及资金数据准确性，属于核心功能不可用并伴随数据风险，定为致命。判定理由记录为“核心支付链路部分不可用，存在资金数据异常风险”。
产品角色确认优先级：该缺陷直接影响成交，发生频率随流量上升而增加，暂无可靠规避方案，定为紧急，并建议当日安排修复与回滚评估。此处严重程度与优先级恰好同为最高档，但判断依据不同，前者看系统影响，后者看业务影响与规避方案。
复核环节中，质量负责人抽查该记录，确认判定理由与标准条款对应，同时发现同类支付超时缺陷在近一周内出现多次，建议在标准中补充“同一模块同类缺陷短时集中出现时，按最高档处理并触发专项排查”的说明。修复完成后，开发反馈实际影响范围为部分支付渠道，未发生真实重复扣款，严重程度维持致命不变，变更记录中注明影响面核实结论。
完成检查：分级机制是否真正跑起来
机制是否落地，不能只看规则文档是否写完，而要看字段是否被稳定填写、判定是否一致、分布是否合理、变更是否可追溯。建议按季度做一次检查，用下表逐项核对。
| 检查项 | 通过标准 | 证据 | 负责人 |
|---|---|---|---|
| 字段填写完整率 | 分类字段与分级字段的填写完整率达到团队约定阈值，无长期空值 | 缺陷字段完整率统计 | 质量负责人 |
| 取值合规 | 各字段取值均来自预定义选项，兜底取值占比处于低位 | 字段取值分布报表 | 质量负责人 |
| 定级一致率 | 抽取一定数量缺陷由第二人独立重判，严重程度一致率达到约定阈值 | 抽样重判记录与一致率计算 | 测试负责人 |
| 分级分布合理性 | 各档位分布与业务实际相符，无某档位长期为零或异常集中 | 按模块、按周期的分级分布图 | 产品负责人 |
| 定级变更记录 | 每次档位调整均有原因、变更人与时间 | 缺陷变更历史 | 质量负责人 |
检查不通过时，调整动作应对准具体环节。字段完整率低，通常是必填设置或提交表单设计问题，应收紧必填项并简化表单；一致率低，说明判定标准存在模糊表述，应补充边界条件和示例，并组织一次判定校准；分布异常集中，可能是判定人习惯性选择中间档，应通过复核和案例讨论纠偏；变更记录缺失，则需要在工具中把变更原因设为调整档位时的必填项。每次调整后保留修订记录，下一轮检查时对照验证效果。
常见问题
团队规模小，严重程度和优先级可以由同一个人判定吗？
可以，但要保留两个独立的判断动作和判断依据。同一人操作时，先按影响范围、功能可用性、数据与安全写出严重程度档位和理由，再单独按业务影响、发生频率、规避方案写出优先级档位和理由，两条理由分别记录在缺陷记录中。
这样做的目的是让两个判断在记录上可区分，复核时能看出是技术影响判断偏了，还是业务排期判断偏了。团队规模扩大后再把两个角色拆开，判定标准不需要重写。
缺陷修复过程中发现影响面比初判更大，档位怎么调整？
按变更记录的要求处理：保留原档位、新档位、变更理由、变更人与时间四项信息，由原判定人或复核人操作。例如初判为严重，修复时确认涉及资金数据错误，应调整为致命，并在理由中写明核实到的影响面。
调整后不需要追溯修改历史统计，但下一轮分级分布检查时应把这类变更单独看一下，如果同一模块频繁出现初判偏低，说明判定标准在该模块的边界描述需要补充。
定级一致率抽样具体怎么抽、抽多少？
抽样方法建议按周期分层抽取：每周或每两周从当期新增缺陷中抽取一定数量，重点覆盖致命、严重两档以及发生过档位变更的记录，再由未参与原判定的第二人对照判定标准独立重判。
一致率按严重程度单独计算，分子为两人判定相同的条数，分母为抽样总条数。抽样数量没有统一标准，团队可以先按固定条数起步，稳定后再调整。一致率偏低时优先检查判定标准中模糊的表述，补充边界条件和示例，并组织一次判定校准讨论。
分类字段里的兜底取值应该保留吗？
可以保留一个兜底取值，但要控制使用比例。兜底取值长期占比偏高，说明前面的取值设计没有覆盖真实场景，或者提交人不清楚该选哪个。
处理方式是定期查看兜底取值的实际内容，把高频出现的场景提炼成新的正式取值，同时检查提交表单是否给出了每个取值的判定说明。兜底取值本身不必取消，它是发现取值设计问题的入口。
判定标准文档由谁维护、多久修订一次？
建议由质量负责人维护判定标准文本，修订触发条件主要有三类：复核中发现同类争议重复出现、抽样一致率低于约定阈值、业务或系统结构发生较大变化导致原有档位不再适用。
修订不必按固定周期强制进行，但每次修订要保留修订记录，写明改了哪条、为什么改，下一轮落地检查时对照验证效果。判定标准与缺陷记录中的判定理由应能互相对应，方便复核时逐条核对。
