缺陷严重程度分级标准写完并发布，只是判级工作的起点。测试与研发在真实缺陷上反复判级，标准用词、影响范围判断和新业务场景都会让判级结果逐渐漂移。定期校准要解决的是让判级长期保持一致、争议可追溯、标准能随案例迭代。本文按现状基线、分歧来源、校准动作、前提代价和效果验证的顺序，给出一套可以固定周期执行的方案。
要点总览（TL;DR）
- 校准机制由周期、样本、角色和记录四个要素组成：每迭代或每月抽查20–30条已关闭缺陷，由测试与研发各一名复判人独立复判，再与原判级比对。
- 判级分歧主要来自标准用词模糊、影响范围与复现条件判断差异、缺少判级记录、标准未覆盖新场景，校准动作要针对这些来源设计。
- 明显分歧的缺陷逐条复盘，结论分为细化标准表述、新增边界案例、个人判断偏差三类，前两类回流到标准文档并指定责任人。
- 校准需要测试与研发共同投入，每次约两到三小时；频率过高会让评审流于形式，频率过低则分歧积累，新标准建议只对之后提交的缺陷生效。
- 效果验证用校准前后的同口径对照，关注判级一致率、争议率、判级返工、复评次数和案例库覆盖，指标变化要与具体校准动作对应。
当前判级做法与校准目标
先记录现状，校准才有参照。多数团队在标准落地后的判级流程大致是：测试人员提交缺陷时给出一个初始严重程度，研发在确认或修复时复核，双方意见不同就线下沟通，达成一致后修改字段。参与角色通常包括提交缺陷的测试人员、负责模块的研发人员，部分团队还有测试负责人或产品经理在争议较大时介入。
判级依据往往混合了三种来源：分级标准文档中的定义和示例、个人对业务影响的经验判断、以及团队之间长期形成的口头约定。这三种依据在标准刚发布时比较一致，随着人员变动和业务变化，口头约定会逐渐偏离文档，经验判断也会因人而异。现状基线要记录的就是：谁在什么环节判级、依据哪份材料、分歧如何解决、结果记录在哪里。
校准目标可以归纳为三条。第一，长期判级一致，同类缺陷在不同人、不同时间得到相同或相近的级别。第二，争议可追溯，每一次判级分歧都能找到原始缺陷、双方意见和处理结论。第三，标准可迭代，校准中发现的边界案例能回流到标准文档，形成补充条目。这三条目标对应后续的样本抽查、记录字段和案例库维护。
判级不一致的常见来源
分歧的产生有相对固定的机制，识别来源才能设计针对性的校准动作。常见来源可以归为四类，每类都有可观察的证据。
| 来源 | 典型表现 | 可收集的证据 |
|---|---|---|
| 标准用词模糊 | “主要功能不可用”“部分用户受影响”等表述没有量化边界，边界案例判级不同 | 同一缺陷被改判的字段历史、争议缺陷的原始描述 |
| 影响范围判断差异 | 测试按复现路径判断影响面，研发按代码调用范围判断，结论不同 | 争议记录中双方对影响范围的陈述 |
| 复现条件判断差异 | 偶现缺陷是否算高严重程度，取决于对触发概率的估计 | 缺陷描述中的复现步骤与出现频率记录 |
| 标准未覆盖新场景 | 新业务模块上线后，标准中没有对应条目，判级靠临时约定 | 新模块缺陷的判级依据缺失记录 |
缺少判级记录会让上述分歧无法回溯。如果严重程度字段只保留最终值，改判过程、双方理由和结论都没有留下，争议就只能靠记忆复述，校准样本也无从抽取。标准长期不更新是另一个累积性问题：新业务场景不断出现，文档停留在旧范围，判级依据逐渐转向口头约定，一致性随之下降。
定期校准的优先改进动作
校准机制由周期、样本、角色和记录四个要素组成，下面按执行顺序说明。
设定校准周期与触发条件
固定周期建议按团队节奏选择：迭代周期两周左右的团队可以每个迭代做一次短校准，版本节奏较长的团队可以每月一次。除固定周期外，设置触发条件：重大版本发布后、新业务模块首次提缺陷后、以及单月争议缺陷数量明显上升时，追加一次专项校准。周期过短会占用过多评审时间，过长则分歧积累到难以逐条复盘。
抽样判级与一致性抽查
抽查样本从当期已关闭或已修复的缺陷中抽取，覆盖不同严重程度和不同提交人。建议每次抽取20到30条，数量以一次评审会能逐条讨论完为准。抽查方法是：由未参与原判级的测试和研发各一人，仅依据标准文档对样本重新判级，再与原判级结果比对。结果分为一致、可接受偏差和明显分歧三档，明显分歧的缺陷进入争议复盘。
| 要素 | 建议做法 | 记录内容 |
|---|---|---|
| 周期 | 每迭代或每月一次，重大版本后追加 | 校准日期、覆盖版本或迭代 |
| 样本 | 当期已关闭缺陷抽20–30条，覆盖各严重程度 | 缺陷编号、原判级、复判级、比对结论 |
| 角色 | 测试与研发各一名复判人，测试负责人主持 | 参与人、主持人、缺席说明 |
| 记录 | 校准结论写入固定文档，分歧缺陷关联原缺陷 | 分歧理由、标准补充条目、责任人 |
争议缺陷的复盘与标准补充
复盘只针对明显分歧的缺陷，逐条回答三个问题：双方各自依据标准中的哪一条、标准在该场景下缺什么、补充后能否让下次判级不再分歧。结论分三种处理：标准表述需要细化、需要新增边界案例、属于个人判断偏差。前两种回流到标准文档，第三种在团队内同步。每条结论指定责任人和完成时间，下次校准会检查落实情况。
边界案例库与判级字段维护
边界案例库按业务模块和严重程度组织，每条案例包含缺陷描述摘要、争议焦点、最终判级和依据条目。案例库与标准文档放在同一知识空间，判级时可以直接检索。判级字段方面，除严重程度外，建议保留判级依据、复判记录和争议标记三个字段，让校准样本可以直接从缺陷数据中筛出。字段配置以团队实际使用的缺陷管理工具为准。
在缺陷记录与案例沉淀环节，ONES 可以提供承载：ONES Project 支持缺陷跟踪管理，与 TestCase 数据互通并可一键提 Bug，统计缺陷状态分布；ONES TestCase 支持未通过用例快速创建缺陷任务，缺陷任务在测试与研发团队间流转，并提供项目缺陷分布统计；ONES Wiki 支持文档关联任务，并可插入 ONES Project 的工作项列表，适合把标准文档、边界案例库和校准记录放在一起维护。具体字段与报表配置以实际开通的套餐和团队环境为准。
校准的适用前提与代价
校准要真正运转，需要几个前提。测试与研发必须共同投入时间，每次校准会按20到30条样本估算，加上准备和记录，大约需要两到三小时，参与人需要提前完成独立复判。缺陷管理工具要能保留判级字段的修改历史和争议标记，否则样本抽取和回溯都依赖人工整理。团队还需要指定一名主持人，通常由测试负责人担任，负责控制讨论范围和结论落地。
频率选择有代价。频率过高，评审会变成重复确认，参与人容易敷衍，校准结论质量下降；频率过低，分歧积累，单次复盘量过大，标准补充滞后于业务。标准频繁调整也有稳定性代价：每次补充条目都会改变判级边界，已关闭缺陷的判级与新标准可能不一致，团队需要明确新标准只对之后提交的缺陷生效，避免历史数据被反复重判。
推行初期还可能遇到阻力：研发认为判级是测试的职责，参与意愿低；或者校准结论停留在文档，没有进入下一次判级。前者靠明确角色分工和主持人推动解决，后者靠下次校准会检查上期结论落实情况来约束。
校准效果如何验证
效果验证要用校准前后的对照，单点数字说明不了问题。建议在启动校准前先做一次基线抽查，记录当期的一致率、争议率和返工情况，之后每次校准用相同口径复测。
| 指标 | 口径建议 | 观察方向 |
|---|---|---|
| 判级一致率 | 复判结果与原判级一致的样本数 ÷ 抽查样本总数 | 逐期上升并趋于稳定 |
| 争议率 | 出现明显分歧的缺陷数 ÷ 当期提交缺陷总数 | 下降，且分歧集中在已知边界场景 |
| 判级返工 | 严重程度字段被改判的次数 ÷ 当期缺陷总数 | 下降 |
| 复评次数 | 同一缺陷进入复评的平均次数 | 下降 |
| 案例库覆盖 | 已收录边界案例覆盖的业务模块数 ÷ 在用模块数 | 上升，重点模块优先覆盖 |
对照方法上，至少比较校准启动前一个周期与最近一个周期的同口径数据，并排除样本构成变化的影响，例如某期抽查集中在新模块，一致率偏低属于正常波动。指标改善要与具体动作对应：一致率上升是否伴随标准条目补充，争议率下降是否集中在已收录案例的场景。如果指标没有变化，先检查校准会是否按样本逐条执行、结论是否落实到标准文档，再考虑调整周期或样本量。
校准机制稳定运行后，团队可以把重心从“纠正分歧”转向“预防分歧”：新业务模块上线前先补充判级条目，新成员入职时用边界案例库做判级练习。这样标准文档、案例库和判级记录形成闭环，测试与研发的共同判级就有了可复查、可迭代的基础。
常见问题
校准会每次抽多少缺陷合适，样本怎么选才不偏？
建议每次抽取20到30条当期已关闭或已修复的缺陷，数量以一次评审会能逐条讨论完为准。抽样时覆盖不同严重程度和不同提交人，避免只抽高严重程度或只抽某几个模块的缺陷。如果当期缺陷总量较少，可以按比例抽取，但下限保持在10条以上，否则一致率波动太大，难以判断趋势。
样本构成变化会影响指标可比性。某期抽查集中在新模块，一致率偏低属于正常波动，比较时应说明样本构成，或在下一期补充常规模块样本后再看趋势。
研发参与判级校准的意愿不高，怎么推动？
先明确角色分工：测试负责提交初始判级，研发负责复核影响范围，校准会由测试负责人主持，双方都是判级责任人。把校准结论与具体缺陷关联，让研发看到分歧集中在哪些模块和场景，比泛泛强调一致性更有说服力。
另一个有效做法是控制单次投入。提前把样本和复判表发给参与人，会上只讨论明显分歧的条目，一致和可接受偏差的样本快速确认即可。每次校准会检查上期结论的落实情况，让参与人看到投入有产出，意愿会逐步稳定。
新标准补充后，已关闭缺陷的判级要不要按新标准重判？
一般不建议对历史缺陷批量重判。标准补充会改变判级边界，重判历史数据既增加工作量，也会让统计口径前后不一致。更稳妥的做法是明确新标准只对之后提交的缺陷生效，历史缺陷保留原判级，在标准文档中记录生效时间和变更内容。
如果某条历史缺陷与新增边界案例高度相似，可以在案例库中标注关联，供后续判级参考，但不改动原记录。这样既保留了历史数据的稳定性，也让新标准有据可查。
校准做了一段时间，一致率没有明显变化，问题出在哪？
先检查执行层面：校准会是否按样本逐条比对，还是只做了形式上的确认；分歧结论是否写入了标准文档并指定责任人；下次校准是否检查了上期结论的落实情况。这三个环节任一缺失，校准就难以影响实际判级。
再检查指标口径：一致率的分子分母是否前后一致，样本构成是否发生较大变化。如果执行和口径都没有问题，可以考虑调整样本量或周期，例如增加边界案例较多的模块样本，或把校准频率从每月改为每迭代，缩短反馈周期。
边界案例库应该怎么组织，才能在日常判级时用得上？
案例库按业务模块和严重程度组织，每条案例包含缺陷描述摘要、争议焦点、最终判级和依据条目。案例库与分级标准文档放在同一知识空间，判级时可以直接检索，避免案例散落在个人文档或聊天记录里。
维护上指定一名负责人，每次校准产生的新案例在会后一周内入库，并标注来源缺陷和校准日期。新成员入职时用案例库做判级练习，可以让案例库从记录工具变成判级训练材料，提高日常使用频率。
