缺陷优先级判定要落到可执行，关键是先把“影响范围、业务后果、发生频率、是否有临时绕过手段”四个因子定义成可观察的档位，再用一张判定表把因子组合映射到P0–P3，并明确谁在什么时点定级、判错如何改判。本文只讨论分级判定本身，缺陷处理归属与排队、工单SLA时限不在范围内。
要点总览（TL;DR）
- 缺陷优先级判定先固定四个可观察因子：影响范围、业务后果、发生频率、是否存在临时绕过手段，每个因子给出明确档位，提交人只填事实、不直接判等级。
- 用判定表把因子组合映射到P0–P3：以“业务后果×影响范围”定基础等级，再用发生频率和绕过手段做上下修正，并单独写明一票升级与一票降级规则。
- 因子结论冲突时按预设顺序裁决，建议业务后果优先于影响范围，影响范围优先于发生频率，发生频率优先于绕过手段，一票升级优先于普通组合。
- 定级嵌入缺陷生命周期：提交人填事实，测试或产品负责人按表定级，开发负责人确认技术影响；事实变化时改判并记录原等级、新等级、原因与审批人。
- 落地检查看判定表覆盖率、改判记录完整性、等级分布是否失真，并通过抽样复核和定期校准调整规则。
先定判定因子：优先级由哪几件事决定
优先级判定的第一步是把“感觉严重”拆成几个可以填写的事实。建议固定四个核心因子：影响范围、业务后果、发生频率、是否存在临时绕过手段。每个因子给出三到四个档位，档位描述使用可观察的现象，避免“严重”“紧急”“一般”这类需要主观解释的词。提交缺陷的人只需按事实勾选，不需要先判断等级。
影响范围看受影响的用户或业务对象数量与类型，例如全部用户、某一类角色、单个客户、内部测试环境。业务后果看缺陷发生时业务动作能否继续，例如资金损失、数据错误、流程中断、仅显示异常。发生频率看触发条件出现的概率，例如每次必现、特定条件下必现、偶发、仅一次出现。临时绕过手段看是否存在不改代码就能恢复业务的办法，例如切换入口、手工补录、回滚配置。四个因子各自独立取值，不互相替代。
优先级与严重程度需要配合使用，两者回答的问题不同。严重程度描述缺陷对系统或业务造成的技术性损害，通常由测试或开发在缺陷记录中给出；优先级描述团队应当多快处理它，还要考虑发生频率和绕过手段。一个严重程度高但仅影响内部报表且可手工导出的缺陷，优先级可能低于一个严重程度中等但每次支付都会失败的缺陷。把两者分开记录，可以避免用技术损害单一维度替代排期判断。
因子数量控制在四到五个，是执行成本和判断精度之间的取舍。因子太少，判定表无法区分“影响大但偶发”和“影响小但必现”；因子太多，提交人填写负担重，评审时容易在细枝末节上争论。团队可以先固定上述四项运行一个迭代，再根据误判记录决定是否增加“监管或合同约束”这类补充因子。
| 因子 | 档位 | 可观察判断依据 | 取值示例 |
|---|---|---|---|
| 影响范围 | 广 / 局部 / 单点 | 受影响用户或业务对象的数量与类型 | 全部线上用户无法登录；某区域客户订单状态错误；单个内部账号头像不显示 |
| 业务后果 | 阻断 / 错误 / 体验 | 业务动作能否继续、是否产生错误数据或资金影响 | 支付无法完成；订单金额计算错误；页面文案错位 |
| 发生频率 | 必现 / 条件必现 / 偶发 | 按给定步骤或条件重复触发的结果 | 每次提交都失败；仅退款场景必现；压测时偶发超时 |
| 临时绕过手段 | 无 / 有但成本高 / 有且低成本 | 不改代码即可恢复业务的办法是否存在、操作代价多大 | 无替代入口；需人工逐单补录；切换备用通道即可 |
把因子组合映射成P0–P3：判定表怎么建
判定表的作用是把因子取值组合直接映射到等级，减少每次定级时的临场讨论。表的一侧列出因子组合，另一侧输出P0–P3。实际建表时不必穷举所有组合，可以按“业务后果×影响范围”形成主表，再用发生频率和绕过手段做修正列。主表负责给出基础等级，修正列负责上调或下调一档，并注明适用条件。
一票升级规则用于处理不能被普通组合稀释的情形。例如核心链路完全不可用、资金类错误持续产生、监管要求的数据出现错误，满足任一条件直接进入P0，不再看发生频率。一票降级规则用于防止过度定级，例如缺陷仅出现在测试环境、已有低成本绕过手段且影响范围限于单点，可以在基础等级上降一档，但不得低于P3以下的自定义档位。升级和降级规则都要写成可核对的触发条件，并放在判定表同一页。
因子结论冲突时，按预设裁决顺序处理，避免每次由声音大的人决定。建议顺序为：业务后果优先于影响范围，影响范围优先于发生频率，发生频率优先于绕过手段；一票升级规则优先于普通组合，一票降级规则只在没有触发升级条件时生效。裁决顺序写入判定表说明，评审时按顺序逐项核对，而不是重新讨论每个因子的合理性。
等级数量与团队规模、协作复杂度匹配。单一小组维护一个系统，三级（如高、中、低）通常够用，判定表更易记。跨团队协作、多系统依赖或核心交易系统，建议使用四级P0–P3，把“必须立即处理”和“本迭代内处理”分开。等级数量一旦确定，在一个季度内保持稳定，避免因个别缺陷临时增加档位。
| 业务后果 | 影响范围 | 基础等级 | 修正条件 | 修正后等级 |
|---|---|---|---|---|
| 阻断 | 广 | P0 | 仅测试环境出现 | P1 |
| 阻断 | 局部 | P1 | 发生频率为偶发且有低成本绕过 | P2 |
| 错误 | 广 | P1 | 涉及资金或监管数据错误 | P0（一票升级） |
| 错误 | 局部或单点 | P2 | 每次必现且无绕过手段 | P1 |
| 体验 | 广 | P2 | 有低成本绕过且不影响业务动作 | P3 |
| 体验 | 局部或单点 | P3 | 无 | P3 |
判定流程：谁在什么时点定级、如何改判
定级动作要嵌入缺陷从提交到进入排期的路径，每个角色只做自己掌握信息的那部分判断。提交人负责填写影响事实，测试负责人或产品负责人按判定表给出首次等级，开发负责人确认技术影响和绕过手段是否成立。等级写入缺陷记录后，才作为排期和修复顺序的输入。
首次定级的时点建议放在缺陷提交后的分诊环节，所需输入包括复现步骤、影响范围证据、业务后果描述、发生频率和已尝试的绕过方式。信息不足时，定级人应退回补充事实，而不是凭印象先给等级。首次定级输出包括等级、命中的判定表行、是否触发一票规则，以及定级人。
改判的触发条件包括影响范围扩大、发现新的业务后果、绕过手段失效或出现更优替代、原定级所依据的事实被证伪。改判由原定级人或其指定的负责人审批，开发负责人对技术影响变化提供确认。每次改判要记录原等级、新等级、触发原因、依据事实和审批人，保留在缺陷记录中，便于后续复核。
定级结果进入排期时，只回答“这个缺陷应排在哪一档处理顺序”，不回答“由谁修复、在哪个版本修”。缺陷归属与排队规则属于缺陷分诊与责任分配，工单紧急性与响应时限属于工单优先级与SLA管理，本文不展开。团队需要把定级字段与分诊字段分开维护，避免一个字段同时承担两种判断。
| 角色 | 时点 | 输入 | 输出 |
|---|---|---|---|
| 提交人 | 提交缺陷时 | 复现步骤、影响对象、发生条件、已尝试的绕过方式 | 四个因子的事实填写 |
| 测试负责人或产品负责人 | 分诊环节 | 提交人填写的事实、判定表 | 首次等级、命中行、是否触发一票规则 |
| 开发负责人 | 首次定级后、排期前 | 技术影响说明、绕过手段可行性 | 技术影响确认或异议 |
| 原定级人或指定负责人 | 事实变化时 | 新证据、原等级记录 | 改判记录：原等级、新等级、原因、审批人 |
当缺陷从测试用例执行中产生时，定级字段需要和缺陷记录一起流转。ONES 测试管理支持未通过的用例快速创建缺陷任务，缺陷任务在测试与研发团队间流转；缺陷可关联至迭代，便于把定级结果带入后续排期讨论。团队可以在缺陷记录中维护定级所需的事实字段和等级字段，让提交、定级、改判都围绕同一条记录完成。具体字段配置以团队实际使用的产品设置为准。
示例：一条线上支付缺陷如何定为P1
以下为演示情景，用于说明判定过程，不代表任何真实客户案例。某线上支付页面在用户选择“分期支付”后提交订单，页面提示“系统繁忙”，订单未生成。提交人填写的事实为：影响范围为使用分期支付的线上用户，属于局部；业务后果为支付流程阻断，用户无法完成下单；发生频率为按给定步骤每次必现；临时绕过手段为可改用一次性支付，属于有且低成本。
按判定表核对：业务后果为阻断、影响范围为局部，基础等级为P1；发生频率为必现，不触发降档；绕过手段为有且低成本，但降档规则要求同时满足偶发，因此不降档。未触发一票升级条件，因为核心支付链路的一次性支付仍可用。首次定级输出为P1，命中行为“阻断×局部”，定级人为测试负责人。
排期前开发负责人确认：分期支付接口对特定银行通道返回超时，改用一次性支付确实可完成下单，绕过手段成立。等级维持P1，进入本迭代修复队列。两天后发现使用分期支付的用户中有部分重复扣款提示，业务后果从“阻断”变为“错误且涉及资金”，触发一票升级规则，改判为P0。改判记录写明原等级P1、新等级P0、触发原因“资金类错误持续产生”、依据事实“重复扣款提示截图与订单记录”、审批人为产品负责人。
这个例子中的常见误判有两处。第一处是提交人最初想直接填P0，理由是“支付问题都很严重”，纠正方式是要求先填四个因子事实，由定级人按表输出等级。第二处是发现重复扣款后，有人主张把所有分期支付缺陷都升为P0，纠正方式是只对命中一票升级条件的那条缺陷改判，其余缺陷仍按判定表逐条核对，避免等级整体漂移。
落地检查：判定标准是否真的在被执行
判定表建好后，需要定期检查它是否在实际使用，而不是停留在文档里。检查以近期缺陷为样本，逐项核对判定表覆盖率、改判记录、等级分布和复核机制。检查结果由测试负责人或质量负责人汇总，在迭代回顾中讨论需要调整的档位或规则。
| 检查项 | 通过标准 | 责任人 |
|---|---|---|
| 判定表覆盖率 | 抽样缺陷中绝大多数能对应到判定表的具体行，落入“其他”兜底的比例很低 | 测试负责人 |
| 定级记录完整性 | 每条缺陷有等级、命中行、定级人；触发一票规则的记录注明触发条件 | 测试负责人 |
| 改判可追溯 | 改判记录包含原等级、新等级、原因、依据事实和审批人 | 产品负责人 |
| 等级分布合理性 | P0和P3占比处于可解释范围，未出现全员P0或全员P3 | 质量负责人 |
| 抽样复核 | 每迭代抽取一定数量缺陷，由未参与原定级的人按表复核，记录差异并说明原因 | 测试负责人与开发负责人 |
| 定期校准 | 按固定周期回顾误判记录，决定是否调整档位定义、修正规则或裁决顺序 | 质量负责人 |
等级分布是判断机制是否失真的直接信号。全员P0通常说明一票升级条件写得太宽，或者团队用高等级换取排期注意力；全员P3通常说明判定表没有覆盖真实业务后果，或者降档规则被过度使用。发现分布异常时，先抽样核对具体缺陷的因子填写，再决定调整规则，避免直接要求“以后少定P0”。
抽样复核和定期校准要形成固定节奏。复核差异本身不是问题，差异集中出现在某个因子或某条规则上，才是需要修订判定表的依据。校准记录与改判记录分开保存，前者用于调整规则，后者用于追溯单条缺陷的等级变化。ONES 测试管理提供项目缺陷分布统计，可用于观察缺陷在不同维度的分布；统计口径和可用维度以实际产品配置为准，团队可结合抽样复核结果一起判断定级是否失真。
常见问题
缺陷优先级和严重程度需要同时记录吗？
建议同时记录，两者回答的问题不同。严重程度描述缺陷对系统或业务造成的技术性损害，通常由测试或开发给出；优先级描述团队应当多快处理它，还要结合发生频率和绕过手段。分开记录后，一个技术损害高但影响面小、可手工绕过的缺陷，不会仅因为严重程度高就被排到最前面；一个技术损害中等但每次支付都失败的缺陷，也能获得应有的处理顺序。
团队规模小，用三级还是四级更合适？
单一小组维护一个系统时，三级通常够用，判定表更易记、评审更快。跨团队协作、多系统依赖或核心交易系统，建议使用四级P0–P3，把“必须立即处理”和“本迭代内处理”分开。等级数量确定后在一个季度内保持稳定，避免因个别缺陷临时增加档位，导致历史记录无法横向比较。
提交人认为缺陷很严重，可以直接定P0吗？
不建议由提交人直接定级。提交人的职责是填写影响范围、业务后果、发生频率和已尝试的绕过方式这些事实，等级由测试或产品负责人按判定表输出。如果提交人直接填P0，容易把“支付问题都很严重”这类印象带进排期。遇到核心链路完全不可用、资金类错误持续产生等情形，由定级人核对一票升级条件后给出P0，并在记录中注明触发条件。
改判需要走审批吗，记录要保留哪些内容？
改判需要由原定级人或其指定的负责人审批，开发负责人对技术影响变化提供确认。每次改判在缺陷记录中保留原等级、新等级、触发原因、依据事实和审批人。触发条件包括影响范围扩大、发现新的业务后果、绕过手段失效或原定级依据的事实被证伪。记录完整才能支撑后续抽样复核，也便于区分单条缺陷的等级变化和判定表规则本身需要调整。
等级分布出现全员P0，应该先改规则还是先纠正个别缺陷？
先抽样核对具体缺陷的因子填写和命中行，再决定是否调整规则。全员P0通常说明一票升级条件写得太宽，或者团队用高等级换取排期注意力；全员P3则可能说明判定表没有覆盖真实业务后果。核对后如果差异集中在某条规则或某个因子上，修订判定表；如果只是个别缺陷填错，按改判流程纠正单条记录即可，避免直接要求“以后少定P0”。
