把严重程度和修复优先级分开判定，核心做法是拆成两次独立动作：先由提交人或测试依据复现结果判定缺陷造成的后果，再由分诊负责人或分诊会在固定时点判定修复时限。两个字段各有量表、判定人和变更规则，严重程度不直接推导优先级。下面按建表、分工、留痕、示例和检查五个环节说明操作步骤。
要点总览（TL;DR）
- 先建两张独立量表：严重程度只判缺陷造成的后果，修复优先级只判多长时间内安排修复，两列互不推导。
- 判定顺序固定为两步：提交人或测试先判严重程度并附证据，分诊负责人或分诊会在固定时点单独判修复优先级。
- 缺陷单上两列分开存储，各自记录档位、判定依据、判定人、判定时间和变更原因，便于复核追溯。
- 两列结论不一致是正常结果，例如致命缺陷在平峰期且有对账兜底时可排为本迭代修复，记录依据即可，不强行拉平。
- 按周或按迭代抽查两列是否有独立依据、是否存在同步变动，用检查结果反过来修订量表和分诊输入。
先定两张量表：严重程度与修复优先级各自判什么
拆分判定的第一步是把两个概念写成两张独立的量表。严重程度回答“这个缺陷造成了多大后果”，修复优先级回答“我们准备在多长时间内安排修复”。两张表各设3–5档，每档写清判定依据和典型例子，让不同的人在同一档位上能得出相近结论。
严重程度的判定依据集中在缺陷本身的后果，包括功能是否不可用、数据是否错误或丢失、是否带来安全与合规风险、影响范围有多大。它不参考当前是不是大促、有没有临时规避手段，也不考虑修复要花多少人力。
| 档位 | 判定依据 | 典型例子 |
|---|---|---|
| 致命 | 核心功能完全不可用，或造成数据丢失、错误扩散，或存在安全与合规风险 | 支付成功后订单状态未写入，用户重复付款 |
| 严重 | 主要功能受阻且无替代路径，影响范围较大 | 批量导出功能报错，所有运营人员无法导出报表 |
| 一般 | 次要功能异常，或主要功能存在可绕过的错误 | 列表页排序结果偶尔错乱，刷新后恢复 |
| 轻微 | 界面文案、样式或提示信息问题，不影响业务操作 | 按钮文案与页面标题不一致 |
修复优先级的判定依据是排期条件：缺陷发生在什么业务时段、受影响用户量有多大、是否存在临时规避手段、距离下一个发布窗口还有多久、修复本身需要多少成本。同样的“严重”缺陷，在业务低峰期且有规避手段时可以排到下一迭代，在业务高峰期且无规避手段时需要立即安排。
| 档位 | 判定依据 | 典型例子 |
|---|---|---|
| 立即修复 | 处于业务高峰或关键时段，受影响用户量大，无规避手段，需在当班内处理 | 大促期间下单接口报错，客服无手工补救方案 |
| 本迭代修复 | 影响当前迭代目标，有短期规避手段但不可长期维持 | 报表导出失败，可临时由数据同学手工出数 |
| 下迭代修复 | 影响范围有限，规避手段可维持，修复需要一定开发量 | 后台筛选条件偶发失效，运营可换用其他筛选方式 |
| 排期处理 | 影响轻微，无明确业务时限，可随版本节奏安排 | 提示文案错别字 |
两张表建好后要写明一条规则：两列互不推导。严重程度高不等于优先级高，例如一个只在极端条件下触发的致命缺陷，如果已有监控拦截且当前无用户触发，优先级可以排到下迭代；优先级高也不改写严重程度，紧急上线一个临时补丁不改变缺陷本身的后果等级。这条规则要写进缺陷分级规范，作为后续判定和复核的依据。
判定顺序与角色分工：谁先判、谁后判、谁复核
量表确定后，需要规定两次判定的先后顺序和责任人，避免同一个人在一次操作里把两列一起拍板。推荐顺序是先判后果、再判时限，中间留出分诊环节。
第一步由缺陷提交人或测试人员完成。输入是复现结果、日志、影响数据范围等证据；动作是依据严重程度量表选定档位，并在缺陷单中填写判定依据；输出是带有证据的严重程度字段；完成标志是该字段有档位、有依据、有判定人和判定时间。这一步只回答后果，不讨论什么时候修。
第二步由分诊负责人或分诊会在固定时点完成，例如每日一次或每周两次的缺陷评审。输入包括已判定的严重程度、缺陷所在业务模块、当前业务时段、受影响用户量、是否存在规避手段、发布窗口和预估修复成本；动作是依据修复优先级量表单独选定档位；输出是修复优先级字段及其判定依据；完成标志是该字段有档位、有依据、有判定人和判定时间，且判定依据中能看到对业务时段、用户量或规避手段的具体说明。
| 角色 | 职责 | 交付物 |
|---|---|---|
| 提交人 | 提交缺陷，提供复现步骤和现象描述 | 缺陷单基础信息 |
| 测试人员 | 复现并判定严重程度，附日志、截图、影响范围 | 严重程度档位与判定依据 |
| 分诊负责人或分诊会 | 在固定时点判定修复优先级，说明业务时段、用户量、规避手段 | 修复优先级档位与判定依据 |
| 复核人 | 抽查两列是否各有独立依据，识别照抄和同步变动 | 复核记录与整改意见 |
复核角色可以由质量负责人或测试负责人兼任，检查重点是两列是否各自有依据、是否存在把严重程度直接复制成优先级的情况。复核不需要逐单进行，按周抽样即可。
两个字段的变更规则也要分开。严重程度变更的触发条件是复现结果变化、影响范围扩大或缩小、发现新的数据或安全风险，由测试人员发起并附新证据。修复优先级变更的触发条件是业务时段变化、规避手段失效、发布窗口调整或修复成本变化，由分诊负责人发起并记录原因。两类变更分别记录，不合并成一条“等级调整”。
字段与记录：缺陷单上怎么留痕
拆分判定能否持续，取决于缺陷单是否把两次判定分别记录下来。缺陷单上应为严重程度和修复优先级各设一组字段，分开存储，不用一个字段承载两种含义。
严重程度字段组包括：档位、判定依据、证据（复现步骤、日志、影响数据范围）、判定人、判定时间。修复优先级字段组包括：档位、判定依据（业务时段、受影响用户量、规避手段、发布窗口）、判定人、判定时间。两组字段在缺陷单上分区展示，避免填写时相互参照。
变更记录单独设一个区域，格式可以写成：变更字段、原档位、新档位、变更原因、变更人、变更时间。每次调整两列中任一列都追加一条记录，不覆盖原值。这样在复核时能还原每一次调整的来由，也能看出是否存在频繁同步调整的异常模式。
在工具承载上，ONES 测试管理支持未通过的用例快速创建缺陷任务，缺陷任务在测试与研发团队间流转；缺陷可关联至迭代，便于把修复优先级落到具体排期。缺陷单的字段设置和变更留痕方式，需要按实际部署的配置确认，量表档位和判定依据可以先以文本字段或选项字段落地，再逐步细化。
完整示例：一条支付缺陷的两次判定
下面用一条支付缺陷走完两次判定，示范两列结论不一致时的处理方式。示例为演示情景，用于说明填写方法。
缺陷现象：用户在支付成功后，订单状态未同步更新，页面仍显示“待支付”，重复点击支付会生成第二笔支付单。影响范围为使用该支付渠道的全部用户，已有一笔重复支付记录。证据包括复现视频、支付回调日志和订单表截图。
严重程度判定：核心交易功能出现数据错误，可能造成用户重复付款，属于数据与资金风险，影响范围为全部使用该渠道的用户。按量表判为“致命”。判定人为测试人员，判定时间记录在缺陷单上。
修复优先级判定：当前处于业务平峰期，该渠道日订单量占比不高；运营已配置人工对账，可在两小时内发现并退款，属于临时规避手段；距离下一个发布窗口还有三天，修复涉及支付回调逻辑，预估需要一天开发加半天回归。综合判断，规避手段可维持到发布窗口，但资金风险不宜长期存在，判为“本迭代修复”，要求在下一次发布中带上修复。判定人为分诊负责人，判定依据中写明业务时段、订单占比、人工对账方案和发布窗口。
两列结论不一致：严重程度为致命，修复优先级为本迭代修复，而不是立即修复。这种不一致是正常结果，记录时分别保留两列的依据，在分诊记录中说明“已有对账兜底、平峰期、发布窗口临近”，不为了看起来整齐而把优先级改成立即修复，也不因为优先级没有拉满而把严重程度降为严重。如果后续进入大促，业务时段变化，分诊负责人可以单独调整优先级并记录原因，严重程度保持不变。
完成检查：这套判定是否真的分开了
规则落地一段时间后，用一份检查清单确认拆分判定是否真正执行。检查按周或按迭代进行，抽查样本覆盖不同模块和不同判定人。
- 抽查缺陷单，严重程度和修复优先级是否都有独立的判定依据和判定人，依据是否具体到影响范围、业务时段或规避手段。
- 统计两列的变动记录，是否存在完全同步变动、疑似照抄的情况；同步变动比例过高时，回到分诊环节确认是否由同一人一次填写。
- 变更记录是否完整，能否还原每次调整的原因、调整人和时间；是否存在覆盖原值导致历史丢失的情况。
- 分诊会是否按固定节奏运行，判定时点是否可查；长期没有分诊记录而优先级字段却有值的，需要核实判定过程。
- 发现两列不一致时，是否有明确的记录和沟通路径，而不是强行拉平或直接改档。
检查结果可以作为下一轮量表修订的输入。如果某一档位长期没有使用，或判定依据经常写得笼统，说明量表需要补充典型例子；如果复核发现大量照抄，说明分诊环节的输入材料不足，需要把业务时段、用户量和规避手段作为分诊前的必填信息。ONES 测试管理提供项目缺陷分布统计，可用于观察缺陷在不同模块和档位上的分布，辅助判断量表是否被正确使用，具体统计口径以实际配置为准。
常见问题
严重程度判为致命，修复优先级却排到下迭代，这样记录会被认为不合理吗？
是否合理取决于优先级判定依据是否写清楚。严重程度描述的是缺陷后果，修复优先级描述的是排期条件。一个致命缺陷如果触发条件极端、当前没有用户实际触发、已有监控或人工兜底，且修复需要较大改动，分诊时排到下迭代是可以解释的。关键是在修复优先级字段中写明业务时段、受影响用户量、规避手段和发布窗口，让复核人能还原判断过程。如果写不出这些依据，才说明判定过程有问题。
小团队没有独立的分诊会，两次判定可以由同一个人完成吗？
可以由同一人完成，但要保留两次独立动作的痕迹。建议在缺陷单上分两步填写：先只填严重程度和证据，隔开一段时间或在固定的每日评审时点再填修复优先级，并分别记录判定时间。这样即使判定人是同一人，两列也各有依据、各有时间戳，复核时能看出是否存在一次拍板、两列照抄的情况。团队规模扩大后再引入独立的分诊负责人或分诊会。
严重程度和修复优先级分别在什么情况下允许变更？
两类变更的触发条件不同，应分开记录。严重程度变更通常由复现结果变化、影响范围扩大或缩小、发现新的数据或安全风险引起，由测试人员发起并附新证据。修复优先级变更通常由业务时段变化、规避手段失效、发布窗口调整或修复成本变化引起，由分诊负责人发起并写明原因。每次变更追加一条记录，保留原档位，不覆盖历史值。
量表档位设几档比较合适，档位太多会不会增加判定负担？
严重程度和修复优先级各设3–5档比较实用。档位过少难以区分后果差异，档位过多会让判定人频繁纠结相邻档位。建议每档配一到两个典型例子，例子取自团队真实缺陷，判定时对照例子选档。运行一段时间后，如果某一档长期没有使用，或判定依据经常写得笼统，可以合并档位或补充例子，量表的修订记录也应保留。
怎么判断拆分判定已经真正落地，而不是停留在规范文档里？
看缺陷单的实际填写情况。抽查时确认两列是否都有独立的判定依据和判定人，依据是否具体到影响范围、业务时段或规避手段；统计两列的变动记录，看是否存在完全同步变动；检查分诊是否有固定节奏的记录，判定时点是否可查。如果复核发现大量照抄，问题通常出在分诊输入材料不足，需要把业务时段、用户量和规避手段设为分诊前的必填信息，而不是反复强调规范条文。
