缺陷等级确认的责任可以拆成四个动作：提交人提议初始等级，模块或技术负责人复核技术影响，测试或质量负责人拍板最终等级，流程负责人维护分级口径并记录争议。下面用一条“支付回调偶发失败”的演示缺陷，给出一份填好的分级确认记录，并逐项解释填写依据，方便你改造成自己团队的定级流程。示例为演示情景，非真实客户案例。
要点总览（TL;DR）
- 缺陷等级确认责任拆成四个动作：提交人提议初始等级，技术负责人复核技术影响，质量负责人拍板最终等级，流程负责人维护分级口径并记录争议。
- 示例中“支付回调偶发失败”初判为严重，技术复核后确认影响限于单一渠道、资金无损失且有兜底手段，最终由质量负责人定为一般，全过程在缺陷单上留痕。
- 初判与终判不一致时，保留初判理由、复核意见、终判依据和改判记录，让等级变化可追溯。
- 套用到自己团队时，按影响范围、风险类型、兜底手段的顺序定级，角色可合并但复核与拍板两个动作要分开，并约定争议升级时限和定期校准。
- 这套示例只覆盖缺陷分级，不涉及缺陷分诊、处理归属、修复排队与工单 SLA，也不作为认证或合规依据。
示例目标：这份分级责任范例要解决什么问题
这份范例要回答一个具体问题：一条缺陷从被提交到等级确定，中间经过谁、留下什么记录、依据什么改判。读者可以照着示例中的字段和角色顺序，在自己团队的缺陷单里填一遍，再对照本团队的组织方式替换角色名称。
示例把定级责任拆成四个动作，每个动作对应一个明确的责任人和一类记录内容：
| 责任动作 | 示例角色 | 在缺陷单上留下的内容 | 动作完成标志 |
|---|---|---|---|
| 提议 | 缺陷提交人（测试或业务一线） | 现象、影响范围、复现条件、初判等级 | 缺陷单提交，初判等级有填写 |
| 复核 | 模块负责人或技术负责人 | 技术影响判断、复核意见、是否同意初判 | 复核意见写入缺陷单 |
| 拍板 | 测试负责人或质量负责人 | 最终等级、定级理由 | 最终等级字段确定 |
| 记录 | 缺陷管理流程负责人 | 分级口径、争议与改判记录 | 改判原因可追溯 |
示例覆盖的缺陷单字段包括：标题、现象描述、影响范围、复现条件、初判等级、技术复核意见、最终等级、定级理由、改判记录。角色名称是示例设定，团队可以按自身组织方式替换，例如把“质量负责人”换成“测试经理”，不构成统一要求。
完整示例：一条支付回调缺陷的分级确认全过程
以下是一条演示缺陷的完整分级确认记录，从提交到定级归档，各字段内容自洽，可直接作为填写模板参考。
第一步：提交人填写初始信息
- 缺陷标题：支付回调偶发失败，订单状态未同步
- 现象描述：部分订单支付成功后，回调通知未到达业务系统，订单停留在“待支付”状态，用户重复支付后由客服手工退款。
- 影响范围：近一周观察到约十余笔订单受影响，集中在某一支付渠道；其他渠道未复现。受影响用户可正常下单，但订单状态需人工修正。
- 复现条件：使用该支付渠道下单并完成支付，在回调间隔超过设定阈值时出现；非必现，复现概率约十分之一。
- 初判等级：严重
- 初判理由：涉及资金相关流程，且需要人工介入修正订单状态。
第二步：技术负责人复核
- 复核意见：回调失败由该渠道回调重试机制与本地超时配置不匹配导致，影响限于单一渠道；订单资金本身无损失，人工修正可在当日完成。建议定为“一般”。
- 复核依据：受影响订单数量有限、资金无实际损失、存在人工兜底手段、修复方案明确且改动范围小。
- 是否同意初判：不同意，建议由“严重”调整为“一般”。
第三步：质量负责人拍板
- 最终等级：一般
- 定级理由：采纳技术复核意见。该缺陷影响单一渠道、有明确人工兜底、资金无损失，按“影响范围+资金风险+兜底手段”三项判断，未达到严重级别。同时要求修复上线前补充该渠道的回调监控告警。
- 拍板人：质量负责人（示例角色）
第四步：改判记录与定级归档
- 改判记录：初判“严重”→终判“一般”，改判人：质量负责人，改判依据：技术复核意见及影响范围核实结果。
- 争议情况：提交人对降级有保留意见，认为资金相关应从严；该意见记入缺陷单备注，作为后续分级口径校准的输入。
- 定级后去向：缺陷单等级字段更新为“一般”，流转至修复排期环节。本文的分级确认到此结束，后续排期与处理归属不在示例范围内。
这份记录的关键在于：每一次等级变化都有责任人、有依据、有留痕。初判与终判不一致时，处理方式是在同一张缺陷单上保留初判、复核意见、终判和改判理由，让后来的人能看到等级为什么变。
逐项解释：每个字段和每个签字为什么这样填
示例中的字段不是随意设置的，每个字段对应一类判断信息，填错字段会让定级失去依据。下面逐项说明填写口径和责任边界。
影响范围、严重程度、优先级三者的区别
| 字段 | 回答的问题 | 示例填写 | 填写口径 |
|---|---|---|---|
| 影响范围 | 影响到谁、影响多少 | 单一支付渠道，约十余笔订单 | 用可观察的事实描述，不写“很多用户”这类模糊表述 |
| 严重程度 | 问题本身有多重 | 一般 | 综合影响范围、资金或数据风险、有无兜底手段判断 |
| 优先级 | 多快需要处理 | 示例未涉及 | 属于排期范畴，与等级相关但不由定级环节决定 |
三者容易混填：有人把“着急修”直接写成“严重”，导致等级虚高。示例的做法是先定严重程度，优先级留给排期环节单独判断。
初判与终判不一致时怎么处理
示例中初判“严重”、终判“一般”，处理方式是保留完整链条：初判等级和理由不删除，复核意见写明不同意的原因，终判写明采纳或推翻的依据，改判记录单独一行。这样做的目的是让降级或升级都有据可查，避免事后争论“当时为什么这么定”。
各角色的权限边界
- 提交人：可以给出初判等级和影响描述，不能自行确定最终等级。
- 技术负责人：可以提出复核意见和调整建议，最终等级由质量负责人确认。
- 质量负责人：有权确定最终等级，并对改判负责。
- 流程负责人：维护分级口径和争议记录，不直接参与单条缺陷的定级拍板。
权限边界写清楚，能减少“谁都能改等级”造成的口径漂移。示例中提交人的保留意见被记入备注而非直接改级，就是权限边界的体现。
记录留痕对后续复盘的作用
定级记录积累一段时间后，可以回答两类问题：哪些类型的缺陷经常被初判偏高或偏低，哪条分级口径在实际判断中产生了分歧。示例中提交人的保留意见就是口径校准的输入材料。缺陷单字段、定级留痕与流转可以在 ONES Project 这类工作项工具中承载，ONES Project 支持缺陷跟踪管理，可一键提交 Bug 至对应项目或迭代并记录跟踪修复情况；ONES TestCase 中未通过的用例也可快速创建缺陷任务，在测试与研发团队间流转。工具承载的是记录和流转，分级口径和角色责任仍需团队自己约定。
可迁移规律：把这份范例套到自己的缺陷分级流程
示例的价值在于规律可迁移。把上面的记录改造成自己团队的分级责任表，可以按以下顺序操作。
按影响维度定级，而非凭主观感受
判断顺序建议为：先看影响范围（多少用户、哪些渠道或模块），再看风险类型（资金、数据、安全、可用性），最后看有无兜底手段（人工修正、降级方案、监控告警）。三项都核实后再给等级，能减少“感觉挺严重”式的定级。示例中技术复核正是按这个顺序推翻了初判。
角色最小集：提交人、技术复核、质量拍板
小团队可以只保留三个角色：提交人负责提议，技术负责人负责复核，质量负责人负责拍板。流程负责人可以由质量负责人兼任，但改判记录仍需单独留存。角色可以合并，动作不能省略，尤其是复核和拍板两个动作要分开。
争议升级路径与时限
示例中提交人对降级有保留意见，处理方式是记入备注并进入口径校准。团队可以进一步约定：提交人与拍板人对等级有分歧时，在约定时限内（例如一个工作日内）提交给上一级质量负责人裁定，裁定结果同样写入缺陷单。时限和升级对象要提前写进流程，避免争议悬置。
分级口径的定期校准
建议按固定周期（例如每季度）回看改判记录和争议备注，统计初判与终判不一致的比例和原因，据此修订分级口径。校准的产物是一份更新后的等级判定说明，而不是对个案的追责。示例中的改判记录就是这类校准的原始素材。
适用边界：哪些情况不适用这套分级责任示例
这套示例只回答“缺陷严重到什么程度、由谁确认”，以下情形需要另行处理。
| 情形 | 是否适用本示例 | 说明 |
|---|---|---|
| 确定缺陷等级及确认责任 | 适用 | 示例的核心范围 |
| 缺陷分诊、处理归属、修复排队 | 不适用 | 属于定级之后的相邻环节，需另行约定规则 |
| 工单紧急性与 SLA 管理 | 不适用 | 与缺陷等级相关但判断口径不同，不在示例范围 |
| 不同团队规模与行业的调整 | 需调整后适用 | 角色名称、复核层级、校准周期可按组织方式替换 |
| 认证或合规依据 | 不适用 | 示例为管理方法演示，不作为认证或合规依据 |
团队规模较小时，复核与拍板可能由同一人承担，此时仍建议在缺陷单上分别记录复核意见和定级理由，保留判断依据。行业差异主要体现在风险类型的权重上，例如涉及资金或个人信息安全的缺陷，可以在口径中单独提高权重，具体标准由团队结合自身业务确定。
常见问题
小团队里复核和拍板由同一个人承担，分级记录还能简化吗？
可以合并角色，但建议保留两个动作的记录。同一个人先写复核意见，再写最终等级和定级理由，两段内容在缺陷单上分开呈现。这样做的目的是让判断依据可回看，避免等级变化时找不到原因。角色合并后，争议升级对象可以改为团队外部或上一级负责人，并在流程中提前写明。
提交人对最终等级有异议，除了记入备注还能怎么处理？
示例的做法是把保留意见记入缺陷单备注，作为分级口径校准的输入。团队可以进一步约定升级路径：在约定时限内提交给上一级质量负责人裁定，裁定结果同样写入缺陷单。关键是把升级对象和时限提前写进流程，让分歧有明确出口，避免争议长期悬置或私下改级。
缺陷等级和优先级应该分开填吗？
建议分开。等级回答“问题本身有多重”，综合影响范围、资金或数据风险、有无兜底手段判断；优先级回答“多快需要处理”，属于排期环节的判断。示例中先定严重程度，优先级留给排期单独决定，可以减少“着急修就写成严重”导致的等级虚高。
分级口径多久校准一次比较合适？
可以按固定周期回看改判记录和争议备注，例如每季度一次，统计初判与终判不一致的比例和原因，据此修订等级判定说明。团队缺陷量较大或业务变化较快时，可以缩短周期。校准的产物是更新后的分级口径，重点在调整判定标准，个案追责不在其中。
在缺陷管理工具里记录分级过程，需要关注哪些字段？
至少保留初判等级、初判理由、复核意见、最终等级、定级理由和改判记录这几类信息。ONES Project 支持缺陷跟踪管理，可一键提交 Bug 至对应项目或迭代并记录跟踪修复情况；ONES TestCase 中未通过的用例也可快速创建缺陷任务，在测试与研发团队间流转。工具承载记录与流转，分级口径和角色责任仍需团队自行约定。
