测试和研发对缺陷严重程度判断不一致，多数时候是双方对影响范围、业务后果和触发条件的判断口径不同。处置时先把争议从“谁对”转成“按同一组证据核对影响”，再按预设规则定档并留痕，最后把分歧回填到分级标准，减少同类争议反复出现。本文只讨论分级判断本身，分诊归属与工单SLA另行处理。
要点总览（TL;DR）
- 严重程度争议多源于双方对影响范围、业务后果和触发条件的判断口径不同，处置时先把争议转成按同一组证据核对影响。
- 核对证据按影响范围、业务后果、触发条件、临时绕行的顺序推进，未验证的推测不能直接作为定档依据。
- 证据齐备后双方按同一分级定义逐条对照；仍不一致时提交事先约定的裁决角色共同定档，并把结果与理由写入缺陷记录。
- 定档后确认双方无异议或异议已记录、缺陷按定档进入后续处理，再通过补充判定示例、建立案例库、前置证据字段减少复发。
- 涉及线上影响的缺陷先止损再定档，定档完成前不擅自降级关闭或修改已发布结论。
争议先看症状：分歧集中在哪几类判断
“严重程度有争议”是一个笼统说法，落到具体缺陷上，分歧通常集中在四类判断上。先把争议归类，双方才知道要核对什么，避免在“你不懂业务”“你不懂技术”这类互相质疑上消耗时间。
- 影响范围判断不同。测试认为影响所有使用该功能的用户，研发认为只在特定配置或特定数据下出现。双方对“多少人、多少数据受影响”没有共同结论。
- 触发条件是否普遍。测试按常规操作路径复现，研发认为该路径属于边缘场景；或者测试偶现一次，研发认为不具备代表性。
- 业务后果评估不同。测试关注流程走不通、数据可能出错，研发关注系统未崩溃、有日志可查。双方对“后果有多重”的尺度不一致。
- 是否存在临时绕行方案。研发认为用户可以用另一种操作完成目标，严重程度应下调；测试认为绕行代价高或普通用户不知道如何绕行。
需要把严重程度与另外两个概念分开。严重程度描述缺陷本身造成的影响，处理优先级描述团队打算多快处理它，责任归属描述由谁修改。三者相关但判断依据不同：一个严重程度高的缺陷，可能因为已有绕行方案而优先级靠后；一个严重程度低的缺陷，也可能因为临近发布而被优先处理。本文处理的是严重程度这一项的分级判断，分诊排队、责任分配和工单SLA不在讨论范围内。
逐类核对原因：哪些证据能支持或推翻判断
分歧的根源是双方各自掌握的信息不同，或者把推测当成了结论。核对证据的目的，是让每个判断都能被对方检验。建议按“影响范围—业务后果—触发条件—临时绕行”的顺序排查，前一项的证据往往会影响后一项的结论。
| 分歧类型 | 需要核对的证据 | 能支持或推翻什么 |
|---|---|---|
| 影响范围 | 复现环境（测试环境、预发、生产）、受影响用户或数据范围、复现稳定程度 | 确认影响是普遍还是局部；仅在测试环境出现且无法在生产复现时，不能直接按生产影响定档 |
| 业务后果 | 是否产生数据错误、是否阻断关键流程、是否涉及资金或合规 | 把“感觉严重”转成可描述的业务损失；有数据错误或流程阻断的记录优先于主观描述 |
| 触发条件 | 必现还是偶现、常规路径还是边缘路径、触发所需的前置条件 | 判断影响发生的概率；偶现但后果严重的缺陷，需要单独说明概率与后果的组合 |
| 临时绕行 | 是否存在替代操作、替代操作的步骤数与失败风险、普通用户能否自行发现 | 绕行方案可用且代价低，可作为下调严重程度的依据；绕行需要特殊权限或高风险操作时，不能据此下调 |
核对时要区分“已证实”和“未验证的推测”。例如“这个接口可能被很多系统调用”是推测，需要查调用方清单或日志才能变成证据；“用户应该不会这么操作”也是推测，需要看操作路径的入口位置和实际使用数据。未验证的推测不能直接作为定档依据，只能作为下一步验证的方向。报告方补齐证据后，双方再回到分级定义逐条对照，而不是各自引用对自己有利的案例。
按争议情形处置：对齐、升级与定档
证据齐备后，处置按四步推进。多数争议在前两步就能收敛，只有判断口径确实无法调和时才进入升级裁决。
第一步，由报告方补齐证据。缺陷报告方负责补充复现步骤、影响面描述和业务后果说明，把“很严重”替换成“在什么环境、什么条件下、影响哪些用户或数据、导致什么结果”。证据不齐时，先补证据，不进入定档讨论。
第二步，双方按同一分级定义逐条对照。拿出团队现行的严重程度定义，对每一档的判定条件逐条核对，标注双方一致项和分歧项。对照时只讨论定义中的条件是否满足，不讨论对方的态度或能力。一致项先确认，分歧项单独列出，争议范围通常会明显缩小。
第三步，仍不一致时提交预设裁决角色。团队应事先约定裁决方式，常见做法是由测试负责人与研发负责人共同定档，或由质量负责人牵头裁定。裁决依据是分级定义和已核对的证据，不是职位高低。裁决角色需要在争议发生前就明确，临时找人裁定容易让争议变成部门之间的博弈。
第四步，把定档结果与理由写入缺陷记录。记录内容包括最终严重程度、双方分歧点、裁决依据。保留分歧说明不是追责，而是为后续复盘和标准修订留下材料。
处置过程中有几条风险边界需要守住。定档完成前，不擅自降级关闭缺陷，也不修改已经发布的结论；涉及线上影响的缺陷，先止损或降级处理，再讨论定档，避免为了争论级别延误处置。裁决结果一旦写入，后续修改应走变更记录，而不是私下改字段。
争议处置过程需要承载在缺陷记录上，否则证据、分歧和裁决理由容易散落在聊天记录里。ONES TestCase 支持未通过用例一键提 Bug，缺陷任务在测试与研发团队间流转；ONES Project 支持缺陷跟踪管理，与 TestCase 数据互通，可一键提交 Bug 至对应项目或迭代，记录修复情况。团队可以把复现步骤、影响面说明和定档理由随缺陷一起留存，让下一次争议有据可查。分级字段的具体配置方式需以实际环境为准。
验证恢复与减少复发：定档后怎么确认有效
定档不等于争议结束，需要确认争议已闭环，并从个案中提取机制改进。验证信号有两个：双方对定档结果无异议，或异议已明确记录在缺陷中；缺陷按定档结果进入后续处理流程，没有被搁置或绕开。
闭环之后做一次简短复盘，重点看高频分歧类型。如果争议反复集中在“影响范围”上，说明分级定义对影响范围的描述不够具体，需要补充判定示例；如果争议集中在“业务后果”上，说明缺陷报告缺少业务影响字段，问题出在证据采集环节而非定义本身。区分这两种情况，才能对症修改。
回填动作包括三项：在分级定义中补充典型判定示例，把“影响所有用户”“仅影响配置了某选项的用户”这类边界情形写清楚；建立典型争议案例库，记录争议点、证据和最终定档，供后续参照；在新缺陷报告中前置要求填写影响面和业务后果字段，让证据在提交时就具备，减少事后补证的成本。
复发预防的效果可以用一个简单指标观察：同类分歧在争议总量中的占比是否下降。占比下降说明定义和证据要求起了作用；占比不变则需要检查分级定义是否真正被使用，还是仍靠个人经验判断。ONES TestCase 提供项目缺陷分布统计，可用于沉淀问题与经验，帮助团队观察争议集中的环节。统计维度的具体口径以实际配置为准。
常见问题
测试和研发对缺陷严重程度有争议时，第一步应该做什么？
第一步由缺陷报告方补齐证据，把“很严重”替换成可核对的事实：在什么环境、什么条件下出现，影响哪些用户或数据，导致什么业务结果。证据不齐时先补证据，不进入定档讨论。补齐后再由双方按同一分级定义逐条对照，标注一致项与分歧项。
偶现但后果严重的缺陷，严重程度怎么定？
偶现不等于影响小，需要把发生概率和后果分开描述。核对时记录复现频率、触发所需的前置条件，以及一旦发生是否造成数据错误、流程阻断或资金、合规影响。概率低但后果重的缺陷，应在定档说明中同时写明这两项，由双方按分级定义中对应的条件判断，而不是用“偶现”一个词直接下调。
存在临时绕行方案时，是否一定要下调严重程度？
绕行方案可以作为下调依据，但要先核对代价。替代操作步骤少、普通用户能自行发现且失败风险低时，下调有依据；绕行需要特殊权限、依赖人工处理或本身有较高失败风险时，不能据此下调。绕行的具体步骤和限制应写入缺陷记录，供裁决角色参考。
双方僵持不下时由谁裁决，裁决结果还能改吗？
裁决角色应在争议发生前约定，常见做法是测试负责人与研发负责人共同定档，或由质量负责人牵头裁定，依据是分级定义和已核对的证据。结果写入缺陷记录后如需修改，走变更记录并说明理由，避免私下改字段导致后续统计和复盘失真。
争议反复出现，应该改分级标准还是改缺陷报告模板？
看分歧集中在哪里。争议反复集中在影响范围，说明分级定义对影响范围的描述不够具体，需要补充边界判定示例；反复集中在业务后果，说明报告环节缺少业务影响信息，应在缺陷提交时前置要求填写影响面和业务后果字段。两类问题对应不同的修改动作，复盘时先区分再动手。
