缺陷优先级判定要解决的是“先处理哪一个”的问题，而不是简单给缺陷贴一个高或低的标签。可执行的做法是先建立一套稳定的分级标准，再按固定步骤逐项判定：确认影响范围与严重程度，叠加发生频率、临时规避手段、所处研发阶段和业务时间窗口，得出优先级，并记录判定依据与责任人。本文聚焦分级本身，分诊排队与工单SLA时限不在讨论范围内。
要点总览（TL;DR）
- 先区分严重程度与优先级：严重程度由测试或质量角色按功能受损与数据影响给出，优先级由产品、业务与研发结合业务条件共同确认。
- 用四档优先级（P0–P3）起步，每档写明可观察的进入条件；调节因素只能在严重程度基线上下一档内调整，跨两档需复核人确认。
- 判定按五步执行：确认影响范围、评估严重程度、叠加频率与规避手段等调节因素、对照档位表得出优先级、记录判定依据与判定人。
- 提交人、测试、产品业务、研发负责人、判定人与复核人各有明确交付物，判定记录随缺陷单保存，便于复核与复盘。
- 定期抽样复核判定记录，重点纠正按提交人级别定级、按情绪定级、忽略规避手段和阶段末期一律降级等偏差。
缺陷优先级判定的核心答案与操作步骤
优先级判定要先把两个容易混淆的概念分开。严重程度描述缺陷本身对系统功能和数据造成的破坏，属于技术属性，通常由测试或质量角色给出；优先级描述在当前业务和时间条件下应该多快处理，属于调度属性，由产品、业务与研发共同确认。同一个严重程度为“高”的缺陷，如果只影响内部测试环境，优先级可以低于一个严重程度为“中”但正在影响线上核心交易的缺陷。
建议设置四档优先级，并为每档写明进入条件，避免判定时凭感觉。下表可作为起步模板，团队可按业务规模调整档位数量，但每档的进入条件必须可观察、可核对。
| 优先级 | 进入条件 | 典型响应要求 |
|---|---|---|
| P0 紧急 | 核心业务不可用、数据丢失或泄露、影响全部或大部分线上用户，且无临时规避手段 | 立即停止其他工作处理，当日给出修复或止损方案 |
| P1 高 | 核心功能明显受损或影响较大用户群，存在临时规避手段但代价较高 | 纳入当前迭代优先处理，明确修复时间点 |
| P2 中 | 非核心功能受损，或核心功能有可接受的规避方案，影响范围有限 | 排入近期迭代，按正常节奏修复 |
| P3 低 | 体验问题、文案错误、边缘场景异常，不影响业务连续性 | 进入待办池，随版本批量处理 |
判定按五步执行，每一步都要有输入、动作、输出和完成标志，这样判定结果才能被复核。
- 确认影响范围。输入是缺陷描述、复现步骤和环境信息；动作是确认受影响的用户群体、功能模块和是否涉及数据安全；输出是影响范围结论；完成标志是能明确回答“谁在什么场景下会遇到”。
- 评估严重程度。输入是影响范围结论和复现结果；动作是对照严重程度定义给出档位；输出是严重程度档位；完成标志是档位与功能受损程度、数据影响一致。
- 叠加调节因素。输入是复现频率、是否存在临时规避方案、发现阶段和业务时间窗口；动作是逐项判断这些因素对处理紧迫性的影响；输出是调节因素清单；完成标志是每个因素都有明确取值。
- 得出优先级。输入是严重程度和调节因素；动作是对照优先级档位表匹配进入条件；输出是优先级结论；完成标志是结论能对应到某一档的进入条件。
- 记录依据。输入是前四步的结论；动作是填写判定记录，写明关键理由和判定人；输出是可追溯的判定记录；完成标志是他人依据记录能复现同一结论。
判定标准怎么写：字段与档位定义
把标准落成字段，判定才能从个人经验变成团队可复用的规则。每个字段要有明确的取值枚举，并说明它对优先级的影响方向。下表给出字段设计示例，权重方式建议采用“严重程度定基线、调节因素做升降”的方式，而不是给每个字段打分求和，后者容易让判定变得机械且难以解释。
| 字段 | 取值枚举 | 对优先级的影响 |
|---|---|---|
| 影响用户范围 | 全部用户 / 大部分用户 / 部分用户 / 个别用户 / 内部环境 | 范围越大，优先级越高 |
| 功能受损程度 | 功能不可用 / 功能错误 / 功能降级 / 体验问题 | 受损越重，优先级越高 |
| 数据与安全 | 数据丢失或泄露 / 数据错误 / 无数据影响 | 涉及数据安全时直接进入高优先级评估 |
| 复现频率 | 必现 / 高频 / 偶发 / 极难复现 | 频率越高，优先级越高；偶发但后果严重时仍需上调 |
| 临时规避方案 | 无 / 有但代价高 / 有且可接受 | 无规避方案时优先级上调 |
| 发现阶段 | 线上 / 预发布 / 测试中 / 开发自测 | 越接近线上，优先级越高 |
| 业务时间窗口 | 大促或结算期 / 常规运营期 / 无特殊窗口 | 处于关键业务窗口时优先级上调 |
边界情形需要在标准中提前写明处理规则。例如“低频但影响核心交易”的缺陷，复现频率低不应成为降级理由，只要功能受损程度为不可用且无规避方案，就应按P0或P1处理。再如“阶段末期一律降级”的做法也不可取，临近发布时发现的严重缺陷反而应保持高优先级，避免带病上线。标准中应明确：调节因素只能在严重程度基线上下调整一档，跨两档调整需要复核人确认。
标准需要有人维护。建议由质量负责人牵头，产品与研发负责人共同评审，每季度或在重大业务变化后回顾一次，记录版本号和变更原因。字段枚举发生变化时，历史判定记录保留原值，不追溯改写，保证记录可追溯。
角色分工与交付物
判定不是一个人的事，各角色在流程中承担不同职责，交付物也要明确，避免出现“谁都看过、没人负责”的情况。
| 角色 | 主要职责 | 交付物 |
|---|---|---|
| 提交人 | 提供可复现的步骤、实际结果与预期结果、影响描述 | 完整的缺陷单，含环境、账号、截图或日志 |
| 测试或质量角色 | 复现缺陷，初判严重程度，核对影响范围 | 严重程度初判结论与复现记录 |
| 产品与业务角色 | 确认业务影响、受影响用户规模和时间窗口 | 业务影响说明与优先级建议 |
| 研发负责人 | 评估修复成本、是否存在临时规避方案及代价 | 修复方案预估与规避手段说明 |
| 判定人或分诊负责人 | 汇总各方输入，对照档位表给出最终优先级 | 判定记录，含结论、依据和判定人 |
| 复核人 | 抽查判定结果与字段是否一致，处理争议 | 复核意见与争议处理结论 |
判定记录建议包含以下字段：缺陷编号、影响范围、严重程度、复现频率、规避方案、发现阶段、业务时间窗口、优先级结论、判定理由、判定人、判定时间、复核人。记录随缺陷单一起保存，后续复盘时可以直接查看当时的判断依据。在ONES中，这些内容可以作为缺陷工作项的自定义字段与状态流转记录保存，判定结论、判定人和复核意见都留在同一条工作项上，便于后续查询与统计。
完整判定示例
以下为演示情景，用于说明字段填写与结论推导过程，不代表真实项目数据。
背景：某电商系统在常规运营期收到一条缺陷，用户提交订单后点击支付，页面提示“系统繁忙”，订单状态停留在“待支付”，重试三次后仍失败。该问题在测试环境未出现，线上约三成用户遇到，部分用户可通过退出后重新下单完成支付。
逐字段填写如下：影响用户范围为“部分用户”，功能受损程度为“功能不可用”（支付链路中断），数据与安全为“无数据影响”（订单未支付，无资金损失），复现频率为“高频”，临时规避方案为“有但代价高”（需重新下单，用户体验受损），发现阶段为“线上”，业务时间窗口为“常规运营期”。
推导过程：严重程度基线定为“高”，因为支付属于核心交易功能且线上已出现不可用。调节因素中，无数据安全问题不触发直接升级，存在代价较高的规避方案不构成降级理由，线上发现和较高复现频率支持维持高档位。最终优先级结论为P1，理由为核心交易链路受损、影响约三成用户、规避方案代价较高，但未造成资金损失且非全部用户受影响，因此不进入P0。
交接点：判定记录完成后，缺陷进入分诊环节，由分诊负责人根据优先级安排处理顺序并指定修复责任人；修复方案与规避手段由研发负责人在缺陷单上补充。本文不展开排队规则与SLA时限的具体设定。
判定质量检查与常见偏差
判定结果需要定期检查，才能保证标准被一致执行。可按以下清单逐项核对：判定记录中的字段是否填写完整，是否存在空值或“待定”；优先级结论是否与严重程度和调节因素一致，跨档调整是否有复核记录；判定人是否具备对应职责；复核意见是否留痕；同一类缺陷在不同时间的判定是否一致。
常见偏差有几类。按提交人级别定级，把高职级同事提交的缺陷自动调高，会让判定偏离事实；按情绪定级，受用户投诉或会议压力影响临时拔高优先级，会挤占真正紧急问题的处理资源；忽略规避手段，只看功能是否报错而不评估是否有可接受的替代路径，容易高估紧迫性；阶段末期一律降级，为赶发布节点把严重缺陷压到低优先级，会把风险带到线上。
纠正方式包括：判定时强制填写理由字段，理由必须引用具体字段取值；建立定期抽样复核机制，每周或每个迭代抽取一定比例的判定记录，由复核人对照标准检查，发现偏差时记录案例并在团队内同步；对争议较大的判定组织短会讨论，形成结论后补充到标准的边界情形说明中。标准更新后，对新旧判定做一次对比，确认调整方向符合预期。
常见问题
缺陷优先级和严重程度到底怎么区分，判定时先看哪一个？
严重程度描述缺陷本身对功能和数据的破坏，属于技术属性，通常由测试或质量角色复现后给出；优先级描述在当前业务和时间条件下应该多快处理，属于调度属性。判定时先确定严重程度作为基线，再叠加复现频率、规避手段、发现阶段和业务时间窗口等调节因素得出优先级。同一个高严重程度的缺陷，如果只影响内部测试环境，优先级可以低于一个正在影响线上核心交易的中等严重程度缺陷。
复现频率很低但后果严重的缺陷，应该定低优先级吗？
不建议仅因频率低就降级。标准中应提前写明边界规则：只要功能受损程度为不可用、涉及数据丢失或泄露，且没有可接受的临时规避方案，即使偶发或极难复现，也应按高优先级处理。频率是调节因素之一，作用是在严重程度基线上做有限调整，不能覆盖数据安全和核心交易受损这类硬条件。
判定结果出现争议时，团队按什么流程处理？
先由判定人对照档位表和字段取值说明理由，再由复核人核对记录是否完整、结论与字段是否一致。争议集中在跨档调整时，复核人确认是否满足跨档条件；仍无法达成一致，可组织产品、业务与研发负责人短会讨论，形成结论后补充到标准的边界情形说明中。争议处理结论应写入判定记录，作为后续同类缺陷的参考。
分级标准多久回顾一次，历史判定记录要不要跟着改？
建议由质量负责人牵头，产品与研发负责人共同评审，每季度或在重大业务变化后回顾一次，记录版本号和变更原因。字段枚举或档位定义发生变化时，历史判定记录保留原值，不追溯改写，保证记录可追溯；新标准只适用于生效之后的判定，必要时可对新旧标准下的同类缺陷做一次对比，确认调整方向符合预期。
判定完成后，缺陷进入分诊环节时需要注意什么衔接问题？
判定记录要随缺陷单完整流转，分诊负责人依据优先级安排处理顺序并指定修复责任人，研发负责人在缺陷单上补充修复方案与规避手段说明。衔接时容易出现的问题是判定理由缺失或字段留空，导致分诊阶段重新讨论优先级。建议在判定完成时检查记录字段是否完整、结论是否对应到某一档进入条件，再移交分诊。
