缺陷等级确认的责任，可以拆成提议、复核、裁定三个动作，分别交给提交人、模块负责人或测试负责人、缺陷评审小组。要让这套分工真正执行，还需要先统一等级口径，再把等级设为受控字段，记录定级人、定级时间与变更理由。本文给出一套可直接落地的职责设计与操作步骤，适用于希望减少等级争议、让定级过程可追溯的研发与测试团队。
要点总览（TL;DR）
- 把缺陷定级拆成提议、复核、裁定三个动作，分别交给提交人、模块负责人或测试负责人、缺陷评审小组，避免等级由单一角色单方面决定。
- 先统一等级口径：用致命、严重、一般、轻微四级，每级写明影响范围、可复现性、数据与业务后果，并列出所需证据，让复核与裁定有共同参照。
- 流程按四步走：提交时填初始等级与证据、复核人确认或调整、争议升级到评审小组裁定、等级写入受控字段并通知相关方，每步约定完成标志与超时处理。
- 用工具固化责任：等级设为必填受控字段，修改权限限定到角色，记录定级人、定级时间与变更理由，等级变更自动通知相关方。
- 落地检查靠抽查：核对等级、证据、复核意见与变更记录是否完整，等级调整比例偏高或争议集中时回到定义表修订口径。
先定分级规则：等级口径与判定依据
责任分配的前提是所有人对“什么算严重”有共同参照。等级定义表要把每一级的判定依据写清楚，让提交人提议、复核人判断、评审小组裁定都基于同一套标准，减少因理解差异产生的争议。
等级数量不宜过多，常见做法是四级：致命、严重、一般、轻微。命名可以按团队习惯调整，关键是每级都有可观察的判定依据。判定依据建议从三个维度描述：影响范围（多少用户、多少功能受影响）、可复现性（必现、偶现、特定条件下出现）、数据与业务后果（数据丢失、流程阻断、体验受损、仅显示异常）。
| 等级 | 判定依据 | 所需证据 |
|---|---|---|
| 致命 | 核心业务流程阻断、数据丢失或损坏、存在安全风险，影响全部或大部分用户 | 复现步骤、错误日志、影响面截图、受影响用户范围说明 |
| 严重 | 主要功能不可用或结果错误，有可用的临时绕行方式，影响较大范围用户 | 复现步骤、日志或接口返回、影响功能与用户范围说明 |
| 一般 | 次要功能异常或主要功能体验受损，不影响核心流程完成 | 复现步骤、现象截图 |
| 轻微 | 文案、样式、提示信息等显示问题，不影响功能使用 | 现象截图与所在页面说明 |
等级与处理时限存在对应关系，例如致命级要求更快响应，但这属于工单优先级与 SLA 管理的范畴，本文只把它作为等级定义表的附注说明，不展开分诊排队规则。定级所需证据要写进定义表，提交人按表准备，复核人按表核对，证据不足时可以退回补充，这是后续流程能走顺的基础。
责任怎么分：提议、复核、裁定三类角色
把定级拆成三个动作，是为了避免等级由单一角色单方面决定。提交人最了解缺陷现象，负责给出初始等级和证据；复核人具备技术判断力，负责确认影响与可复现性；评审小组处理分歧，负责最终裁定。三类角色的输入、动作与输出如下表。
| 角色 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 提交人（测试、客服、业务方等） | 缺陷现象、复现环境 | 按等级定义表给出初始等级，附复现步骤、日志、影响面截图 | 带初始等级和证据的缺陷单 | 缺陷单提交成功，证据项齐全 |
| 模块负责人或测试负责人 | 缺陷单、代码或环境信息 | 核对影响范围与可复现性，确认等级或提出调整意见 | 复核结论：确认、调整或退回补充证据 | 复核意见写入缺陷单，等级状态变为已确认或待裁定 |
| 缺陷评审小组（产品、研发、测试代表） | 争议缺陷单、双方意见与证据 | 依据等级定义表讨论并投票或由指定负责人裁定 | 最终等级与裁定理由 | 裁定结论记录在缺陷单，等级字段更新 |
响应时限需要事先约定，例如复核人在一个工作日内给出结论，评审小组在收到升级后两个工作日内裁定。时限的具体数值由团队根据迭代节奏确定，写进协作约定即可。超时处理也要有规则：复核超时可由测试负责人代行复核，裁定超时可由评审小组指定负责人直接裁定，避免缺陷因等待定级而停滞。
操作步骤：从提交到等级确认的流程
流程按顺序推进，每一步都有明确的输入、动作、输出和完成标志，交接点清晰，责任才不会在环节之间丢失。
- 提交时填写初始等级与证据。输入是缺陷现象与复现环境；动作是提交人对照等级定义表选择初始等级，附上复现步骤、日志和影响面截图；输出是带初始等级的缺陷单；完成标志是缺陷单进入待复核状态。证据缺失时，复核人可退回补充，退回原因要写明缺哪项证据。
- 复核人确认或提出调整。输入是缺陷单与证据；动作是模块负责人或测试负责人核对影响范围、可复现性，判断初始等级是否准确；输出是确认结论或调整建议；完成标志是等级状态变为已确认，或转为待裁定。复核人提出调整时，必须写明调整理由和依据的判定维度。
- 争议升级到评审小组裁定。输入是双方意见不一致的缺陷单；动作是提交人或复核人发起升级，评审小组依据定义表讨论并给出结论；输出是最终等级与裁定理由；完成标志是裁定结论记录在缺陷单中。升级路径要事先约定由谁发起、通知哪些人、在哪个工作项状态下流转。
- 等级写入受控字段并通知相关方。输入是确认或裁定后的等级；动作是具备权限的角色将等级写入受控字段，系统记录定级人与定级时间；输出是更新后的缺陷单与通知；完成标志是相关方收到等级变更通知，缺陷进入后续处理。超时未完成的环节按约定由代行人处理，并记录代行原因。
用工具固化责任：字段、权限与变更留痕
流程写在文档里容易走样，落到缺陷管理工具的配置上才能稳定执行。核心是三件事：等级作为受控字段、修改权限限定到角色、每次变更留下记录。
- 受控字段：把缺陷等级设为必填的枚举字段，取值与等级定义表一一对应，避免出现表外等级或自由填写。
- 权限限定：提交人只能在创建时填写初始等级，复核角色可修改为确认等级，最终裁定后的等级仅评审小组指定角色可改，其他角色修改需走升级流程。
- 变更留痕：记录定级人、定级时间、变更前后的值和变更理由，等级变更自动通知提交人、复核人与处理人。
- 评审记录：争议裁定的讨论结论作为评论或关联记录附在缺陷单上，与等级字段的变更对应起来。
在 ONES 中，缺陷可以作为工作项在项目中跟踪，ONES Project 适配缺陷管理等场景并提供缺陷跟踪管理与质量统计，支持一键提交 Bug 至对应项目或迭代并记录修复情况；ONES TestCase 支持未通过的用例快速创建缺陷任务，使缺陷在测试与研发团队间流转。等级字段、状态流转与操作记录可以承载定级与变更留痕的管理动作，具体字段级权限与变更日志的配置方式，建议在试用环境中按团队角色实际验证后再固化到流程里。
示例：一次严重等级争议的确认过程
以下为演示情景。某电商项目的测试人员在回归测试中发现，订单列表页在筛选“待发货”时偶现空白，刷新后恢复。提交人判断该问题影响下单后的订单查看，初始定为严重，附上复现步骤、两次复现的录屏和接口返回日志。
模块负责人复核时发现，该问题只在特定浏览器版本下出现，且刷新即可恢复，核心下单流程不受影响，认为应定为一般，并在缺陷单中写明调整理由：影响范围限于单一浏览器，存在可用绕行方式。提交人认为订单查看属于主要功能，坚持严重，双方意见不一致，缺陷转为待裁定。
评审小组由产品、研发、测试各一名代表组成。小组核对证据后确认：问题偶现、影响单一浏览器用户、有刷新绕行，但订单查看是高频操作，按定义表“主要功能体验受损且有绕行方式”归为一般，同时要求研发在下一个迭代修复浏览器兼容问题。裁定理由记录在缺陷单评论中，等级字段更新为一般，系统记录定级人与定级时间，并通知提交人、复核人和处理人。整个过程从提交到裁定用了两个工作日，符合事先约定的时限。
完成检查：定级责任是否真正落地
机制建立后，用一份清单逐项核对，判断它是否真的在运行，而不只是停留在文档里。
- 等级定义表覆盖全部等级，每级都有判定依据和所需证据，团队内可公开查阅。
- 每个等级都有明确的复核人和裁定人，角色姓名或岗位在协作约定中可查。
- 争议升级路径可走通：从缺陷单能发起升级，评审小组能收到通知并给出结论。
- 等级变更留有记录，包含定级人、定级时间、变更理由，可追溯到具体缺陷。
- 抽查近期若干缺陷，核对等级、证据、复核意见与变更记录是否完整，发现缺失时明确补录责任人和补录时限。
- 统计一段时间内的等级调整比例与争议数量，比例异常偏高说明等级口径需要重新对齐，争议集中在某类缺陷说明定义表需要补充判定依据。
检查发现的问题应回到对应环节修正：口径不清就修订定义表，权限过宽就收紧字段修改角色，记录缺失就补齐留痕配置。定级责任机制的价值在于让每次等级判断都有依据、有人负责、可被追溯，抽查和修订让这套机制随团队实践持续校准。
常见问题
提交人给出的初始等级被复核人调整，责任算谁的？
初始等级由提交人负责，复核结论由复核人负责，两者是先后衔接而非互相替代。提交人按等级定义表给出初始等级并附证据，复核人核对影响范围与可复现性后确认或提出调整，调整时必须写明理由和依据的判定维度。最终写入受控字段的等级以复核结论为准，复核人对该结论负责；若提交人不认可，进入评审小组裁定，由裁定结论作为最终等级。这样每个等级都能对应到具体责任人和判断依据。
团队规模小、没有独立的评审小组，争议等级怎么裁定？
评审小组的作用是提供第三方判断，人数少时可以简化形式而不取消这一环节。常见做法是由产品、研发、测试各指定一名代表组成固定或临时的三人小组，争议出现时按需召集；也可以约定由测试负责人与产品负责人共同裁定，两人意见不一致时升级到研发负责人。关键是裁定人提前指定、裁定理由记录在缺陷单上，避免争议久拖不决。响应时限同样要事先约定，例如收到升级后两个工作日内给出结论。
等级定义表和工单优先级、SLA 是什么关系，会不会重复？
两者回答的问题不同。缺陷等级描述问题本身的严重程度，由提交人提议、复核人确认、评审小组裁定；工单优先级与 SLA 管理的是响应和处理的时限承诺，通常由处理方结合排期确定。等级可以作为设定优先级的输入之一，但等级确认责任与排队规则分开设计，避免把“定级”和“排期”混在一个动作里。本文只讨论等级口径与定级责任，分诊排队与 SLA 规则按团队既有机制执行。
等级变更留痕具体要记录哪些内容，怎么用起来？
至少记录四项：定级人、定级时间、变更前后的等级值、变更理由。争议裁定的讨论结论作为评论或关联记录附在缺陷单上，与等级字段的变更对应起来，方便事后追溯。这些记录的价值在检查环节体现：抽查近期缺陷时，能核对等级、证据、复核意见与变更记录是否完整；统计一段时间内的等级调整比例与争议数量，比例异常偏高说明等级口径需要重新对齐，争议集中在某类缺陷说明定义表需要补充判定依据。
用 ONES 承载定级流程时，哪些能力可以直接用，哪些需要先验证？
ONES Project 适配缺陷管理等场景，提供缺陷跟踪管理与质量统计，支持一键提交 Bug 至对应项目或迭代并记录修复情况；ONES TestCase 支持未通过的用例快速创建缺陷任务，使缺陷在测试与研发团队间流转，并支持为不同用户组配置不同权限。等级字段、状态流转与操作记录可以承载定级与变更留痕的管理动作。缺陷等级字段能否设为受控字段并限定特定角色修改、字段变更人与变更时间是否完整记录，建议在试用环境中按团队角色实际配置验证后再固化到流程里。
