设计缺陷分级表，关键是把“严重程度”和“优先级”拆成两个字段：前者判断缺陷造成多大影响，后者决定多快处理。两个字段各自给出可对照的判定条件和示例，再用一张组合表把两者映射为处理要求。下面按字段结构、分档规则、角色分工、填写示例和上线检查五个部分展开，给出可以直接照着建表和填写的做法。
要点总览（TL;DR）
- 缺陷分级表要把严重程度和优先级拆成两个字段：严重程度判断影响大小，优先级决定处理顺序，两者分别给出可对照的判定条件。
- 严重程度建议分阻断、严重、一般、轻微四档，每档写清业务影响、功能可用性、数据与安全影响，并配示例和边界归属规则。
- 优先级用严重程度×优先级的二维组合表给出默认映射，高严重低优先、低严重高优先两类例外必须写明理由。
- 定级由提交人初判、测试或质量角色复核确认，改级需附依据并留痕，争议按固定路径升级裁决。
- 上线前用历史缺陷回测一致性、核对字段枚举与工具选项、安排定期复审，再进入试用。
先定结构：分级表要包含哪些字段
缺陷分级表首先是一张字段定义表，而不是一句“按影响定级”的口号。字段结构决定了后续判定能否被复核：如果严重程度和优先级混在一个字段里，定级人就要同时权衡影响和处理顺序，结论容易随人变化；拆成两个字段后，影响判断和处理顺序判断可以分别核对，也便于在组合表中设置例外规则。
建议的字段清单如下，取值一律使用固定枚举，避免自由文本导致统计和筛选失效。
| 字段名 | 类型 | 取值 | 是否必填 | 填写人 |
|---|---|---|---|---|
| 缺陷编号 | 系统生成 | 按工具规则自动编号 | 必填 | 系统 |
| 标题 | 单行文本 | 现象＋对象＋条件，如“订单提交后金额显示为0” | 必填 | 提交人 |
| 模块 | 枚举 | 按产品模块维护固定列表 | 必填 | 提交人 |
| 严重程度 | 枚举 | 阻断／严重／一般／轻微 | 必填 | 提交人初判，复核人确认 |
| 优先级 | 枚举 | P0／P1／P2／P3 | 必填 | 复核人确认 |
| 判定依据 | 多行文本 | 引用分档表中的条件编号，并写明实际影响 | 必填 | 定级人 |
| 发现阶段 | 枚举 | 需求评审／开发自测／测试／预发布／生产 | 必填 | 提交人 |
| 提交人 | 人员字段 | 系统账号 | 必填 | 系统 |
| 确认人 | 人员字段 | 系统账号 | 必填 | 复核环节填写 |
| 复现概率 | 枚举 | 必现／高频／偶现 | 选填 | 提交人 |
| 影响用户范围 | 枚举 | 全部用户／部分用户／单个用户／内部可见 | 选填 | 提交人 |
| 关联需求 | 关联字段 | 关联到需求或用户故事 | 选填 | 提交人 |
| 环境 | 枚举 | 测试环境／预发布／生产；含浏览器或设备信息 | 选填 | 提交人 |
“判定依据”是这张表里最容易被省略、也最影响一致性的字段。它要求定级人写出引用了哪条分档条件、对应什么实际影响，而不是只留一个档位结果。复核人据此判断定级是否成立，后续改级时也能看到原始理由。复现概率和影响用户范围作为选填字段，主要服务于边界情形的判断，例如偶现缺陷在严重程度上的归属。
严重程度怎么分档：判定条件与示例
严重程度回答“这个缺陷造成多大影响”，与什么时候修无关。四档划分适合多数产品团队，每档需要同时写清业务影响、功能可用性、数据与安全影响三个侧面，并配具体示例，让不同人能对照同一组条件得出结论。
| 档位 | 判定条件 | 示例 | 边界说明 |
|---|---|---|---|
| 阻断 | 核心业务流程无法继续；或存在数据丢失、数据错误、安全漏洞等不可接受风险；无替代操作路径 | 支付成功后订单状态未更新，用户无法查看已购内容；批量导入导致历史数据被覆盖 | 核心流程降级可用（如换入口可完成）时，按“严重”处理并在依据中写明替代路径 |
| 严重 | 主要功能结果错误或不可用，存在可绕行的替代路径；影响范围覆盖多数用户 | 报表导出缺少一列关键数据，需手工补录；消息通知延迟超过一小时 | 仅特定浏览器或特定配置下出现、且影响面可界定时，可定为严重并注明环境条件 |
| 一般 | 次要功能异常或体验缺陷，主流程可正常完成；影响局部用户 | 列表页排序在翻页后重置；提示文案错别字导致理解偏差 | 偶现缺陷若一旦出现即造成严重以上影响，按影响定档，复现概率记入选填字段 |
| 轻微 | 界面样式、文案、易用性问题，不影响任务完成；或仅内部可见 | 按钮间距不一致；后台日志格式不统一 | 不影响用户但增加维护成本的问题，归入轻微并在依据中说明 |
边界情形需要在表内给出统一归属，而不是留给定级人临场判断。偶现缺陷按“出现时的最坏影响”定档，复现概率单独记录；特定环境问题按受影响用户范围判断，环境信息写入字段；降级可用的缺陷原则上不进入阻断档，替代路径要写进判定依据。这样处理的好处是，同一缺陷在不同人手里能得到相同档位，争议集中在条件是否满足，而不是印象差异。
优先级怎么定：与严重程度组合成处理规则
优先级回答“多快处理”，它受严重程度、影响范围、发布节点和替代方案共同影响，因此不能由严重程度直接推导。实践中用二维组合表给出默认映射，再为两类例外保留说明入口，可以让大多数缺陷快速定级，少数例外有据可查。
| 严重程度＼优先级 | P0 | P1 | P2 | P3 |
|---|---|---|---|---|
| 阻断 | 默认：立即处理 | 需说明理由 | 不允许 | 不允许 |
| 严重 | 需说明理由 | 默认：当轮处理 | 需说明理由 | 不允许 |
| 一般 | 需说明理由 | 默认：排入近期计划 | 默认：常规排期 | 可延后 |
| 轻微 | 不允许 | 需说明理由 | 默认：常规排期 | 默认：择机处理 |
表中“默认”表示按组合直接确定，“需说明理由”表示允许偏离默认值但必须在判定依据中写明原因，“不允许”表示该组合不成立，需要回到严重程度重新核对。高严重低优先的典型理由是已有临时方案且修复风险高，例如生产环境已通过配置规避、代码改动涉及核心链路需要灰度验证；低严重高优先的典型理由是阻塞发布或影响关键客户演示，例如文案错误出现在对外宣传页面。两类例外都应写明影响对象和时间约束，避免“领导关注”成为唯一理由。
这张表只定义处理顺序和响应要求，具体派给谁、进入哪个队列，属于分诊环节的工作，不在分级表内展开。这样划分可以让分级表保持稳定，分诊规则随团队结构变化单独调整。
角色分工与分级变更规则
分级结果要可信，需要明确三个角色：提交人负责初判并填写现象与影响，测试或质量角色负责复核判定条件是否成立，开发负责人负责确认技术影响和修复可行性。三者分工不等于三次签字，常见做法是提交人填初判档位，复核人在确认环节核对依据并最终定级，开发负责人在排期时对技术影响提出异议。
| 角色 | 职责 | 交付物 |
|---|---|---|
| 提交人 | 描述现象、影响范围、复现步骤，给出严重程度初判 | 缺陷记录及初判依据 |
| 测试或质量角色 | 核对分档条件，确认或调整严重程度，确定优先级 | 确认人签字与最终档位 |
| 开发负责人 | 评估技术影响与修复风险，对定级提出异议或确认 | 技术影响说明 |
| 争议裁决人 | 对无法达成一致的定级作出决定 | 裁决记录 |
改级需要附判定依据与影响说明，并在记录中保留原档位、新档位、改级人和改级时间。争议升级路径建议固定为：复核人与提交人意见不一致时，由测试负责人裁定；涉及技术风险时，由开发负责人参与；仍无法达成一致，提交产品负责人或项目负责人裁决。分级结果在缺陷生命周期中的每次变化都应留痕，关闭前保留最终档位，便于后续统计各档缺陷的分布和修复周期。
当分级字段需要在工具中落地时，可以把严重程度、优先级、判定依据设为缺陷工作项的固定属性，用枚举约束取值，并在状态流转中要求确认人填写后才能进入处理环节。ONES 的工作项字段与状态流转可以承载这类配置，改级记录随工作项操作历史留存，便于复核时追溯。具体字段配置方式以团队实际使用的工具版本为准。
填写示例：一条缺陷如何完成分级
以下为演示情景，用于说明填写过程，不代表真实项目数据。
缺陷描述：某电商后台在促销活动期间，运营人员批量修改商品价格后，部分商品详情页仍显示旧价格，刷新缓存后恢复。影响范围为参与活动的部分商品，涉及对外展示价格。
第一步判定严重程度。该问题导致对外价格信息错误，属于主要功能结果错误；存在刷新缓存这一替代路径，且影响范围可界定为部分商品，对照分档表定为“严重”，判定依据写明“价格展示错误，影响部分在售商品，可通过刷新缓存恢复”。
第二步确定优先级。严重程度为严重，活动正在进行中，价格错误直接影响成交与客诉，按组合表默认对应 P1；因活动窗口临近且无稳定规避手段，复核人将优先级定为 P0，并在依据中写明“活动期间对外价格错误，客诉风险高，需立即处理”。
第三步记录复核意见。复核人确认严重程度为严重、优先级为 P0，开发负责人补充技术影响说明“缓存更新逻辑缺少失效通知”。最终记录包含：缺陷编号、标题、模块、严重程度严重、优先级 P0、判定依据两条、发现阶段生产、提交人与确认人、影响用户范围部分用户、环境生产环境。修复完成后如发现同类问题再次出现，可据此记录发起改级或合并处理。
上线前检查：分级表是否可用
分级表写完后，需要用一组可核对的检查项判断它能否直接投入使用。建议在正式启用前完成以下核对，并保留核对记录。
- 抽取十到二十条历史缺陷，由两名以上成员独立定级，比较结论是否一致；不一致的条目回到分档表补充条件或示例。
- 检查分档表是否覆盖历史高频缺陷类型，例如支付、登录、数据导出、权限相关缺陷，缺失的类型补充判定条件和示例。
- 核对字段枚举与工具中的选项是否完全一致，避免表里四档、系统里五档，或优先级命名不统一。
- 确认判定依据为必填项，改级记录可追溯，确认人字段在流程中实际被填写。
- 安排一次回测：用新表对近一个版本的缺陷重新定级，统计与原定级的差异比例，差异集中的档位重点修订。
- 设定定期复审机制，例如每季度或每次重大版本后复核分档条件，产品形态或业务流程变化时同步更新示例。
完成上述检查后，分级表即可进入试用。试用期内保留争议记录，把反复出现的分歧点转化为分档条件的补充说明，分级表会随着使用逐步稳定，成为团队对缺陷影响和处理顺序的共同判断依据。
常见问题
严重程度和优先级能不能合并成一个字段？
不建议合并。严重程度判断缺陷造成多大影响，优先级决定多快处理，两者的判断依据不同：一个缺陷可能影响很大但已有临时方案，处理顺序可以靠后；也可能影响很小但阻塞发布，需要优先处理。合并成一个字段后，定级人要同时权衡影响和处理顺序，结论容易随人变化，也无法在组合表中设置例外规则。拆成两个字段后，影响判断和处理顺序判断可以分别复核，统计时也能分开看各档缺陷的分布。
偶现缺陷应该按哪一档定严重程度？
按“出现时的最坏影响”定档，复现概率单独记录在选填字段里。例如一个偶现缺陷一旦触发就会导致订单状态错误，应按严重或阻断处理，同时在复现概率中标注偶现，供复核人和开发评估修复优先级。这样处理可以避免因为“难以复现”而低估影响，也让复现概率成为独立信息，而不是混进严重程度的判断里。
分级表和缺陷分诊是什么关系，边界怎么划？
分级表负责回答“影响多大、多快处理”，输出严重程度和优先级两个结果；分诊负责回答“派给谁、进入哪个队列”。把处理归属和排队规则放进分级表，会让表随团队结构调整频繁变动，也不利于跨团队统一口径。建议分级表只定义档位、判定条件和组合映射，分诊规则单独维护，两者通过优先级字段衔接。
改级需要走什么流程，记录要保留哪些内容？
改级需要附判定依据与影响说明，记录中保留原档位、新档位、改级人、改级时间和理由。意见不一致时按固定路径升级：复核人与提交人分歧由测试负责人裁定，涉及技术风险时开发负责人参与，仍无法达成一致再提交产品负责人或项目负责人裁决。每次变化都留痕，关闭前保留最终档位，便于后续统计各档缺陷的分布和修复周期。
分级表上线后多久需要复审一次？
建议每季度或每次重大版本后复核一次分档条件，产品形态或业务流程发生变化时同步更新示例。试用期内重点收集争议记录，把反复出现的分歧点转化为分档条件的补充说明。复审时可以用近一个版本的缺陷重新定级，统计与原定级的差异比例，差异集中的档位优先修订。
