缺陷分级表把缺陷的影响范围、严重程度、发生频率和业务后果映射到统一等级，让不同人面对同一条缺陷时给出相同判断。本文提供一张可直接复制到文档或表格工具中的空白分级表，并逐列说明填写口径、必填项划分和一条完整填写示例，最后给出模板随团队变化时的调整方法。分级关注的是等级判定本身，缺陷分诊、责任分配和工单 SLA 管理不在本文展开。
要点总览（TL;DR）
- 缺陷分级表的核心列包括缺陷编号、缺陷标题、所属模块、影响范围、严重程度、发生频率、业务后果、建议等级、定级依据、复现条件、定级人、复核人和定级日期，可直接复制使用。
- 定级时先用严重程度和影响范围确定基础等级，再用发生频率和业务后果做上下调整，并在定级依据中写明推导过程。
- 缺陷编号、标题、所属模块、影响范围、严重程度、发生频率、业务后果、建议等级、定级依据、定级人和定级日期为必填；复现条件选填，复核人按等级高低和争议情况决定是否填写。
- 模板调整遵循先改口径再改数据的原则，档位增减、字段新增和口径变更都要留下记录，并通过定期回顾确认模板持续可用。
可复制空白缺陷分级表
下表可直接复制使用。表格分为两个区域：基础定级区记录缺陷的基本信息和影响判断，调整依据区记录频率、后果、最终等级和复核信息。列名在后续字段说明、必填划分和填写示例中保持一致，复制后不需要改名。
| 缺陷编号 | 缺陷标题 | 所属模块 | 影响范围 | 严重程度 | 发生频率 | 业务后果 | 建议等级 | 定级依据 | 复现条件 | 定级人 | 复核人 | 定级日期 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
使用时可把前七列视为基础定级区：缺陷编号到业务后果描述缺陷本身和它的影响，是推导等级的事实输入。后六列视为调整依据区：建议等级是结论，定级依据解释结论怎么来的，复现条件支撑判断可被他人验证，定级人、复核人和定级日期构成责任记录。两个区域分开看，能避免把结论和依据混填在同一格。
分级表字段说明与取值口径
字段说明解决“这一格该填什么”。四类判断字段各有取值口径，建议等级由它们推导，定级依据负责把推导过程写清楚。
| 字段 | 含义 | 取值示例 | 填写口径 |
|---|---|---|---|
| 缺陷编号 | 缺陷在缺陷库中的唯一标识 | BUG-2041 | 沿用缺陷管理系统生成的编号，不另行自编 |
| 缺陷标题 | 一句话概括缺陷现象 | 订单提交后金额显示为0 | 写现象和对象，不写推测原因 |
| 所属模块 | 缺陷所在的业务或功能模块 | 订单结算 | 使用团队既有的模块划分名称 |
| 影响范围 | 受影响的功能、用户群或数据范围 | 全部下单用户 | 写清受影响对象和边界，如单用户、单租户、全量用户 |
| 严重程度 | 缺陷对功能可用性的破坏程度 | 核心功能不可用 | 按功能是否可用、有无替代路径判断，与用户数量无关 |
| 发生频率 | 缺陷在正常使用中出现的概率 | 必现 | 用必现、高频、偶发、极低四档描述，附触发条件 |
| 业务后果 | 缺陷造成的业务损失或风险 | 订单无法支付，影响当日营收 | 写可观察的业务影响，如资损、数据错误、流程中断 |
| 建议等级 | 定级人给出的缺陷等级 | P1 | 从团队等级档位中选一个，与定级依据一致 |
| 定级依据 | 支撑建议等级的理由 | 核心支付功能不可用且必现，按规则定为P1 | 写明基础等级由哪几项判断得出，调整项及调整方向 |
| 复现条件 | 触发缺陷所需的环境和步骤 | iOS 客户端，购物车含优惠券时提交订单 | 写环境、数据和操作步骤，保证他人可复现 |
| 定级人 | 完成本次定级的人 | 测试工程师A | 填实际填写人，便于追溯 |
| 复核人 | 对等级做确认的人 | 测试负责人B | 由具备定级权限的角色担任 |
| 定级日期 | 等级确定的日期 | 2025-03-12 | 填定级完成当天，复核后如有变更另记 |
四类判断字段的关系是：严重程度和影响范围决定基础等级，发生频率和业务后果用于上下调整。例如严重程度高但仅影响单个内部账号，基础等级可能下调；严重程度中等但必现且造成资损，则应上调。建议等级必须能在定级依据中找到对应表述，两者不一致时以复核结论为准并更新记录。
定级人、复核人和定级日期的作用是把等级变成可追溯的记录。当后续对等级有争议时，能快速找到是谁在什么时间依据什么做出的判断，而不是重新讨论一遍。团队规模较小时定级人与复核人可以是同一人，但两个字段仍应分别填写，保留复核动作的痕迹。
哪些字段必填、哪些可以选填
必填字段保证一条缺陷记录能被独立理解和复核。缺填任何一项，等级都难以被他人验证，记录也就失去了作为定级依据的价值。
| 字段 | 必填/选填 | 说明 |
|---|---|---|
| 缺陷编号 | 必填 | 缺失则记录无法与缺陷库对应 |
| 缺陷标题 | 必填 | 缺失则无法识别缺陷内容 |
| 所属模块 | 必填 | 缺失则难以判断影响边界和分派方向 |
| 影响范围 | 必填 | 基础定级的核心输入 |
| 严重程度 | 必填 | 基础定级的核心输入 |
| 发生频率 | 必填 | 调整等级的必要依据 |
| 业务后果 | 必填 | 调整等级的必要依据 |
| 建议等级 | 必填 | 分级表的结论字段 |
| 定级依据 | 必填 | 争议复核时的核心证据 |
| 复现条件 | 选填 | 难以稳定复现或环境特殊时填写，帮助复核人验证 |
| 定级人 | 必填 | 责任记录 |
| 复核人 | 选填 | 低等级缺陷可由定级人自行确认；高等级或存在争议时必填 |
| 定级日期 | 必填 | 时间记录，用于统计和维护 |
缺填处理规则建议写进模板说明：必填项缺失的记录退回定级人补全，不进入复核；选填项缺失不影响记录成立，但复核人认为判断依据不足时，可要求补充复现条件。定级依据在争议复核中尤为关键，它把“为什么是这个等级”从个人经验变成可讨论的文字，复核人据此判断调整是否合理，而不是重新凭印象定级。
当分级结果需要落到缺陷工作项上并支持复核流转时，可以把这些字段配置为缺陷工作项的自定义字段，用状态流转承载“待定级—待复核—已确认”的过程。ONES 支持在工作项中配置自定义字段和状态流转，定级依据、定级人和复核人可随工作项一起留存，等级变更也有记录可查。具体字段配置方式以团队实际使用的版本为准。
完整填写示例：一条缺陷如何定级
以下示例为演示情景，用于说明填写过程，不代表真实项目数据。
原始描述：用户反馈在购物车使用优惠券后提交订单，订单金额显示为0，无法完成支付。测试确认在 iOS 客户端、购物车含满减券时必现，安卓端未出现。
| 字段 | 填写内容 |
|---|---|
| 缺陷编号 | BUG-2041 |
| 缺陷标题 | 使用优惠券提交订单后金额显示为0 |
| 所属模块 | 订单结算 |
| 影响范围 | iOS 客户端全部使用满减券的下单用户 |
| 严重程度 | 核心功能不可用 |
| 发生频率 | 必现 |
| 业务后果 | 订单无法支付，影响当日成交 |
| 建议等级 | P1 |
| 定级依据 | 支付属核心功能，iOS 端使用满减券必现不可用，影响范围为该场景全部用户，按规则基础等级为P1；业务后果涉及成交损失，维持P1不下调 |
| 复现条件 | iOS 客户端，购物车含满减券，提交订单后查看金额 |
| 定级人 | 测试工程师A |
| 复核人 | 测试负责人B |
| 定级日期 | 2025-03-12 |
推导过程分三步。第一步看严重程度与影响范围：支付是核心功能，缺陷导致该功能在特定场景下完全不可用，影响范围覆盖该场景的全部 iOS 用户，两项都指向高等级，基础等级定为P1。第二步用发生频率和业务后果调整：必现说明触发门槛低，业务后果涉及成交损失，两项都支持维持高等级，没有下调理由。第三步把上述判断写进定级依据，明确写出基础等级由哪两项得出、调整项为何不改变结论。
调整理由的写法要点是“事实加规则”。先写观察到的事实，如“iOS 端使用满减券必现不可用”，再写对应的规则，如“支付属核心功能，按规则基础等级为P1”，最后写调整结论。避免只写“影响较大所以定为P1”这类无法复核的表述。若本例安卓端同样复现，影响范围应改为全平台下单用户，定级依据同步更新，等级维持P1。
分级表的调整与维护方法
模板用久了会遇到等级档位不够、字段不适应新业务、口径理解不一致等问题。调整的原则是先改口径再改数据，每次变更留下记录，避免历史记录和新规则混在一起无法比较。
等级档位增减时，先确认新档位与现有档位的边界。例如从三级扩展为四级，需要明确新增档位对应哪类严重程度和影响范围组合，并同步更新定级依据的写法示例。档位减少时，把被合并档位的历史记录标注原等级和合并后的等级，保留映射关系，统计时可按需换算。
新增字段时，优先追加在表格末尾，避免打乱已有列顺序和引用。新字段先设为选填，运行一段时间确认取值稳定后再考虑转为必填。若新字段替代了旧字段的判断作用，在模板说明中注明旧字段的停用时间和替代关系，历史记录不强制回填。
口径变更后，历史数据按“新记录用新口径、旧记录保留原判断”处理，需要横向对比时在统计口径中说明差异。复核安排上，可对变更后一个月内的新定级记录提高复核比例，确认新口径被正确执行。定期回顾的触发条件包括：连续出现定级争议、同一类缺陷等级反复调整、业务模块发生较大变化、季度或半年度例行检查。回顾时重点看定级依据是否写得清楚、必填项缺失率是否上升，据此决定是否修订模板。
把模板放进缺陷管理系统维护，可以减少版本混乱。在 ONES 中，等级档位可配置为缺陷工作项的选项字段，口径说明可作为工作项模板或文档随项目留存，字段调整通过配置完成，历史工作项保留原值。这样模板的每次变更都有配置记录，新成员打开工作项即可看到当前口径，不必在多个文档版本之间对照。
常见问题
团队规模很小，定级人和复核人可以是同一个人吗？
可以。团队规模较小时，定级人与复核人由同一人担任是常见做法，但两个字段仍应分别填写，保留复核动作的痕迹。当缺陷等级较高或定级过程中存在争议时，建议由另一位具备定级权限的成员担任复核人，避免同一人既提出结论又确认结论。
同一条缺陷在不同平台上表现不同，影响范围该怎么填？
按实际受影响的范围填写，并写清平台边界。例如缺陷只在 iOS 客户端复现、安卓端正常，影响范围应写“iOS 客户端全部使用满减券的下单用户”，而不是笼统写“全部下单用户”。如果后续确认其他平台同样复现，需要同步更新影响范围和定级依据，等级是否变化取决于更新后的判断。
定级依据写多详细才算够？
判断标准是复核人能否只凭这段文字还原推导过程。建议包含三部分：观察到的事实，如“iOS 端使用满减券必现不可用”；对应的规则，如“支付属核心功能，按规则基础等级为P1”；调整结论，如“业务后果涉及成交损失，维持P1不下调”。只写“影响较大所以定为P1”这类表述，复核时无法验证，不建议使用。
等级档位从三级扩展到四级，历史记录需要全部重新定级吗？
不需要。历史记录保留原等级，并在记录中标注原档位与合并或拆分后的对应关系，统计时按需换算。新档位启用后，新产生的定级记录按新口径填写。如果新旧档位差异较大，可对变更后一段时间内的新记录提高复核比例，确认新口径被正确执行。
分级表放在文档里维护和放在缺陷管理系统里维护，有什么区别？
放在文档里维护上手快，适合分级规则尚未稳定、需要频繁讨论的阶段，但容易出现多个版本并存、填写口径不一致的问题。放在缺陷管理系统里维护，等级档位可配置为工作项字段，口径说明随项目留存，字段调整通过配置完成，历史记录保留原值。ONES 支持在工作项中配置自定义字段和状态流转，定级依据、定级人和复核人可随工作项一起留存，等级变更也有记录可查，具体配置方式以团队实际使用的版本为准。
