缺陷分级规范最常见的失效点，是把严重程度和修复优先级合成一个字段：测试按影响定级，研发按排期改级，最后既说不清缺陷有多严重，也说不清为什么先修它。本文分别给出两套判定规则——严重程度按影响对象、功能可用性、数据与安全后果、绕行方案定级，由提出方在提交时填写；修复优先级以严重程度为基线，结合影响范围、频率、发布节点和修复成本推导，由研发负责人或分诊角色在评审时判定，并配套组合矩阵、角色分工、填写示例与落地检查清单。
要点总览（TL;DR）
- 严重程度回答“缺陷造成多大影响”，由提出方在提交时按影响对象、功能可用性、数据与安全后果、绕行方案定级；修复优先级回答“当前先修哪个”，由研发负责人或分诊角色在评审时判定。
- 严重程度建议设 S1–S4 四级，每级写清影响对象与用户能否完成目标，并附正反例；无绕行方案时按实际阻断程度上调一级，有临时方案时按方案生效后的实际影响定级。
- 修复优先级以严重程度为基线，再用影响范围、发生频率、发布节点、修复成本与风险做一档上调或下调，每次调整记录理由和复核时间。
- 用严重程度×优先级组合矩阵标出常规、需说明和禁止的组合；高严重度低优先级须记录降级理由与临时措施，低严重度高优先级不修改严重程度字段。
- 规范发布后按抽样清单检查两字段是否独立填写、升降级是否附理由、分级分布是否异常集中，复盘时优先修订触发条件而非增加等级。
先拆开两个维度：严重程度与修复优先级各回答什么问题
两个字段回答的是不同问题，混用会让分级失去解释力。严重程度描述缺陷本身造成的损害，是一个相对稳定的属性；修复优先级描述团队在当下资源与节奏下先处理哪一条，会随发布节点和排期变化。规范应把两者写成独立章节，各自定义等级、判定依据和判定人。
判定时点也不同。严重程度在缺陷提交时确定，此时提出方掌握复现步骤和影响事实；修复优先级在缺陷评审或分诊时确定，此时研发已了解修复路径和排期约束。若在提交时就把优先级定死，评审环节只能被动接受或悄悄改值，规范就形同虚设。
两个字段应独立存储、独立变更。修改严重程度需要说明影响事实的变化，例如发现数据被污染或找到绕行方案；修改优先级需要说明排期或范围的变化。任何一方变更都不应自动覆盖另一方，变更记录保留在原字段上，便于后续复盘。
| 对比项 | 严重程度 | 修复优先级 |
|---|---|---|
| 回答的问题 | 缺陷造成多大影响 | 当前先修哪一个 |
| 判定时点 | 缺陷提交时 | 评审或分诊时 |
| 判定人 | 缺陷提出方，测试负责人复核 | 研发负责人或分诊角色 |
| 主要依据 | 影响对象、功能可用性、数据与安全后果、绕行方案 | 严重程度、影响范围、发生频率、发布节点、修复成本与风险 |
| 变更规则 | 影响事实变化时修改，附说明 | 排期或范围变化时修改，记录调整理由 |
严重程度判定规则：等级定义与判定字段
严重程度建议设四级，按影响对象从大到小排列。等级数量不宜过多，四级足以区分处置差异，也便于提出方快速判断。每级定义要写清“影响什么”和“用户还能不能完成目标”，而不是只写“严重、一般、轻微”这类形容词。
| 等级 | 定义 | 判定要点 | 正例 | 反例 |
|---|---|---|---|---|
| S1 致命 | 核心业务中断，或造成数据丢失、泄露、资金错误等不可接受后果 | 主流程完全不可用且无绕行；数据或安全后果已发生或必然发生 | 支付成功后订单未生成；用户可越权查看他人账单 | 某个报表导出按钮点击无响应，但数据可在列表页查看 |
| S2 严重 | 主要功能受损，用户无法完成关键任务，但有临时绕行方式 | 关键路径受阻；绕行成本高或需人工介入 | 批量导入失败，只能逐条手工录入 | 导入速度比预期慢，但结果正确 |
| S3 一般 | 次要功能异常，主流程可正常完成 | 影响局部操作或非关键角色；有可接受的替代路径 | 筛选条件组合后结果少一条，单独筛选正常 | 页面在特定浏览器下样式错位，不影响操作 |
| S4 轻微 | 体验、文案、样式问题，不影响任务完成 | 无功能阻断；仅影响观感或表述准确性 | 提示语存在错别字；按钮间距不一致 | 提交按钮在移动端被遮挡，导致无法提交 |
判定时按固定字段填写依据，避免只写一句结论。建议字段包括：影响的功能模块、受影响用户范围（全部用户、特定角色、特定租户或环境）、数据或安全后果、是否存在绕行方案及其成本。这四个字段既是定级依据，也是后续复核和争议裁决的证据。
边界情形用两条规则收敛。第一，无绕行方案时按实际阻断程度上调一级，例如本属次要功能但该场景下是唯一入口，应按主要功能受损处理。第二，存在临时方案时按方案生效后的实际影响定级，并在字段中写明方案内容；临时方案本身不稳定或需人工每日操作的，不应据此大幅下调。测试负责人在复核时重点检查这两类情形。
修复优先级判定规则：输入项与判定步骤
优先级不能直接照搬严重程度，否则所有高严重度缺陷会挤在同一队列，研发无法排序。规范应把优先级定义为多输入项推导的结果，并给出可重复的判定步骤。
第一步，以严重程度确定基线：S1 对应最高优先级，S4 对应最低优先级。第二步，用其余输入项在基线上做一档上调或下调，并记录理由。输入项包括：影响范围（受影响用户或租户数量）、发生频率（必现、高频、偶发）、发布节点（是否阻塞当前版本上线或客户验收）、修复成本与风险（修复是否涉及数据迁移、是否可能引入回归）。
| 输入项 | 取值示例 | 对优先级的作用 |
|---|---|---|
| 严重程度 | S1–S4 | 确定基线档位 |
| 影响范围 | 全部用户 / 单角色 / 单租户 | 范围越大越倾向上调 |
| 发生频率 | 必现 / 高频 / 偶发 | 必现且高频可上调；极难复现可下调 |
| 发布节点 | 阻塞发版 / 本迭代内 / 可延后 | 阻塞发版时上调 |
| 修复成本与风险 | 低风险小改动 / 需数据修复 / 高风险重构 | 高风险大改动可先降级并安排专项，避免仓促上线 |
优先级建议设三级或四级，并与排期动作对应，例如 P1 进入当前迭代立即修复、P2 排入下一迭代、P3 进入待办池按版本规划、P4 合并处理或随版本顺手修复。等级命名与排期动作的对应关系要写进规范，避免同一等级在不同团队有不同含义。
下调条件必须写明。常见可下调情形包括：已有稳定绕行方案且影响范围有限、缺陷极难复现且无数据后果、修复需要跨版本重构而当前有临时规避手段。下调时须在优先级字段旁记录理由和复核时间，防止高严重度缺陷被长期搁置而无人跟踪。
组合矩阵与冲突处理：两个维度不一致时怎么办
两个字段独立判定，必然出现不一致的组合。矩阵的作用不是强制配对，而是标出哪些组合属于常规、哪些需要额外说明，让评审时一眼看出异常。
| 严重程度 \ 优先级 | P1 立即修复 | P2 下一迭代 | P3 待办规划 | P4 合并处理 |
|---|---|---|---|---|
| S1 致命 | 常规 | 需说明 | 禁止，须升级裁决 | 禁止，须升级裁决 |
| S2 严重 | 常规 | 常规 | 需说明 | 需说明 |
| S3 一般 | 需说明 | 常规 | 常规 | 常规 |
| S4 轻微 | 需说明 | 需说明 | 常规 | 常规 |
高严重度低优先级的典型情形：S1 缺陷已定位为第三方服务问题，临时切换备用通道后影响可控，修复需等待供应商排期；或 S2 缺陷仅影响已下线功能的旧入口。这类组合允许存在，但必须记录降级理由、临时措施和复核日期，由研发负责人确认。
低严重度高优先级的典型情形：S4 文案错误出现在对外宣传页或合同模板中，涉及合规表述；或轻微样式问题出现在即将交付的客户演示环境。触发条件是“对外可见”或“阻塞验收节点”，此时上调优先级合理，但严重程度字段不应随之改动。
出现矩阵中标注“禁止”的组合，或评审各方对定级有分歧时，由研发负责人与测试负责人共同裁决，裁决结论和依据记录在缺陷的讨论或变更记录中，并设定复核时间。复核节点建议放在版本发布前或迭代评审会上，避免争议悬置。
角色分工与交付物：谁在什么环节填什么
规则能否执行，取决于每个角色的动作是否具体到字段。下表把分级流程拆成四类角色，每类角色对应明确的输入、动作和产出。
| 角色 | 环节 | 动作 | 交付物 |
|---|---|---|---|
| 缺陷提出方（测试或业务方） | 提交缺陷 | 填写严重程度及四项判定依据，附复现步骤和影响事实 | 完整的缺陷单，严重程度字段有依据 |
| 测试负责人 | 提交后复核 | 检查边界情形，处理无绕行方案或临时方案导致的定级偏差 | 复核结论，必要时调整严重程度并说明 |
| 研发负责人或分诊角色 | 评审或分诊 | 以严重程度为基线判定优先级，记录上调或下调理由 | 优先级字段值及调整说明 |
| 规范维护人 | 周期性复盘 | 统计分级分布与变更记录，识别规则歧义并修订等级定义 | 复盘记录与规范修订版本 |
在工具层面，两个字段需要作为独立属性存在于缺陷对象上，并保留变更历史，才能支撑上述分工。ONES 测试管理支持未通过的用例快速创建缺陷任务，缺陷任务在测试与研发团队间流转，缺陷可关联至迭代，并提供项目缺陷分布统计用于沉淀问题与经验。团队可据此把严重程度与优先级作为两个独立字段分别维护，让提出方、测试负责人和研发负责人在同一缺陷记录上完成各自动作；字段的具体配置方式以实际产品配置为准。
填写示例：一条缺陷从提交到定级
以下为演示情景，用于说明两套规则的填写方式，不指向任何真实项目。
缺陷描述：某后台管理系统中，运营人员批量导出订单明细时，选择超过 30 天的日期范围会返回空文件，单日导出正常。影响事实：涉及全部运营角色，每日对账依赖该导出，目前只能按天分批导出后手工合并。
严重程度判定：影响功能为订单导出，属主要功能；受影响范围为全部运营角色；无数据错误或安全后果，返回空文件而非错误数据；存在绕行方案，但需人工分批合并，成本较高。按分级表定为 S2 严重，判定字段逐项填写，绕行方案注明“按天导出后手工合并，单次约 20 分钟”。
优先级判定：以 S2 为基线对应 P2。影响范围为全部运营角色，发生频率为必现，且下周为月度对账节点，按发布节点上调一档至 P1，调整理由记录为“阻塞月度对账，必现，影响全部运营角色”。修复成本评估为查询条件拼接问题，改动小、风险低，支持上调判断。
最终字段值：严重程度 S2，优先级 P1，排期动作为进入当前迭代立即修复，并在修复后由提出方按原复现步骤验证。若修复延期，需在复核节点重新评估优先级并更新理由。
落地与检查：规范发布后的校验项
规范发布只是开始，执行偏差通常在前两三个迭代集中暴露。建议按以下清单做抽样检查，每项都对应可观察的记录，而不是笼统的“执行情况良好”。
- 抽查缺陷单，确认严重程度与优先级两个字段均有值，且严重程度附有影响功能、影响范围、数据或安全后果、绕行方案四项依据。
- 检查是否存在用优先级替代严重程度的情况，例如严重程度字段长期空白或全部填同一等级。
- 核对所有上调或下调记录是否附理由，尤其是 S1、S2 缺陷被定为 P3 及以下的情形，确认有临时措施和复核日期。
- 统计一个周期内的分级分布，若某一等级占比超过八成，或优先级全部集中在 P1，说明判定标准过宽或评审未真正执行，需要回到等级定义修订。
- 对比严重程度变更记录与缺陷实际影响，识别提出方系统性高估或低估的模式，作为培训与规则修订依据。
- 在版本发布前复核高严重度低优先级的缺陷清单，确认降级理由仍然成立。
复盘时优先修订触发条件，而不是频繁增加等级。例如发现“无绕行方案上调一级”被普遍误用，应补充绕行方案的认定标准；发现发布节点因素导致优先级长期通胀，应明确只有阻塞当前版本验收的缺陷才可据此上调。规则修订后保留版本记录，并在下一次抽样中验证修订是否生效。
常见问题
严重程度和修复优先级可以由同一个人在同一步骤里一起定吗？
可以同一个人参与，但建议分两步、分两个字段记录。严重程度在缺陷提交时确定，依据是复现步骤和影响事实；修复优先级在评审或分诊时确定，依据是排期、修复路径和资源约束。若在提交时就把两个值一次定死，评审环节只能被动接受或悄悄改值，变更记录也会混在一起，后续复盘时无法判断是影响事实变了还是排期变了。
小团队人手有限时，可由同一人先后完成两次判定，但两次判定之间应保留评审动作，并在字段变更记录中分别写明依据。
S1 致命缺陷被定为 P3 待办规划，规范上允许吗？
允许存在，但必须满足记录要求。常见情形是缺陷根因在第三方服务，已切换备用通道使影响可控，修复需等待供应商排期；或缺陷仅影响已下线功能的旧入口。这类组合在矩阵中标注为“禁止，须升级裁决”或“需说明”，处理方式是记录降级理由、临时措施和复核日期，由研发负责人确认。
复核节点建议放在版本发布前，确认降级理由仍然成立。若临时措施失效或影响范围扩大，应立即重新评估优先级。
临时绕行方案能作为下调严重程度的依据吗？
可以，但要按方案生效后的实际影响定级，并在判定字段中写明方案内容。若临时方案本身不稳定、需要人工每日操作，或只覆盖部分用户，不应据此大幅下调。规范中建议把“绕行方案认定标准”写清楚，例如方案是否稳定、是否覆盖全部受影响用户、单次操作成本多少，避免“有绕行方案”被普遍误用为降级理由。
分级分布长期集中在某一等级，应该先改等级定义还是先加强评审？
先看偏差来源再决定。若某一等级占比超过八成，或优先级全部集中在 P1，通常说明判定标准过宽或评审未真正执行。建议先抽样核对缺陷单：严重程度字段是否附有影响功能、影响范围、数据或安全后果、绕行方案四项依据，升降级是否附理由。若依据普遍缺失，问题在评审执行；若依据齐全但定级普遍偏高，问题在等级定义的触发条件，应补充正反例和边界规则。
规则修订后保留版本记录，并在下一次抽样中验证修订是否生效。
在缺陷管理工具中落地这套规范，字段和流程上要注意什么？
两个字段需要作为独立属性存在于缺陷对象上，并保留变更历史，才能支撑提出方、测试负责人和研发负责人分别填写与复核。ONES 测试管理支持未通过的用例快速创建缺陷任务，缺陷任务在测试与研发团队间流转，缺陷可关联至迭代，并提供项目缺陷分布统计用于沉淀问题与经验。团队可据此把严重程度与优先级作为两个独立字段分别维护；字段的具体配置方式以实际产品配置为准。
