缺陷严重程度标准要回答的是“这个缺陷对用户和业务造成多大影响”，而不是“谁先修、什么时候修”。一套可执行的标准通常包含四步：先确定影响维度，再为每个维度写出可观察的档位，组合成固定的级别，最后用历史缺陷回测校准边界。本文按这个顺序展开，交付维度—档位—级别对照表、定级流程与角色分工、完整示例和校准检查清单，帮助团队对同一缺陷得出接近的结论。
要点总览（TL;DR）
- 严重程度衡量单个缺陷在发现时点造成的影响后果，优先级衡量处理顺序，两者分开定义，标准才不会写成排队规则。
- 分级维度建议固定五个：功能可用性、数据完整与安全、受影响用户范围、业务与合规损失、可绕过性，每个维度用可观察的档位描述。
- 级别数量控制在四档（致命、严重、一般、轻微），采用主维度定级、辅助维度上调，并预先约定维度冲突时的取舍顺序。
- 定级流程让提交人填写判断依据，设复核角色和争议裁决人，级别变更记录原因与时间点。
- 用历史缺陷分层抽样回测，一致率达到团队约定水平且争议闭环后，标准才算可用，并配套修订触发条件与版本管理。
先定分级对象：严重程度到底衡量什么
严重程度衡量的是单个缺陷造成的影响后果，评估时点以缺陷被发现时掌握的事实为准。发现之后影响范围扩大或缩小，属于级别变更，需要另行记录，不能反过来改写最初的判断依据。把评估对象锁定为“一个缺陷在发现时点的影响”，可以避免讨论滑向“这个功能很重要所以要优先修”这类与后果无关的理由。
严重程度与优先级是两套判断。严重程度回答影响有多大，优先级回答在资源约束下先处理哪一个。一个影响很大的缺陷可能因为已有临时绕行方案而排在后面；一个影响轻微的文案缺陷也可能因为即将对外发布而提前处理。两者分开定义，标准才不会写成排队规则。同样，缺陷由谁处理、进入哪个队列、工单响应时限如何约定，属于分诊与SLA管理的范围，本文不展开，只在定级流程中说明级别信息如何交接给后续环节。
制定标准前需要明确三个边界，写进标准文档的开头：
- 评估对象：单个缺陷，不评估一组缺陷的累计影响；累计影响由版本质量评估另行处理。
- 评估时点：以发现时的事实为准，后续变化通过级别变更记录体现。
- 不覆盖内容：处理归属、排队顺序、工单SLA、修复排期，这些由分诊与优先级机制承接。
边界写清楚之后，标准文档的篇幅会明显收敛，评审时也更容易判断某条争议究竟该在分级标准里解决，还是应该交给分诊会议。
分级维度与档位：把影响写成可观察的判断
可执行的严重程度标准，靠的是每个维度都有能直接观察或验证的描述，而不是靠“严重”“一般”这类没有参照的形容词。建议先固定五个影响维度，再为每个维度定义三到四个档位，最后用维度组合映射到级别。
五个影响维度及其档位写法
| 维度 | 档位示例（由重到轻） | 判定依据 |
|---|---|---|
| 功能可用性 | 核心流程完全不可用 / 核心流程部分受阻 / 非核心功能异常 / 体验瑕疵 | 缺陷发生时用户能否完成该功能的主要任务 |
| 数据完整与安全 | 数据丢失或损坏、越权访问 / 数据写入异常但可修复 / 展示错误 / 无数据影响 | 是否造成数据不可恢复、是否突破权限边界 |
| 受影响用户范围 | 全部用户 / 特定角色或特定租户 / 特定条件下的小部分用户 / 个别用户 | 按账号、角色、环境、数据条件估算覆盖范围 |
| 业务与合规损失 | 直接资金损失或合规违规 / 对外承诺无法履行 / 内部效率下降 / 无明显业务影响 | 是否触发合同条款、监管要求或对外服务承诺 |
| 可绕过性 | 无任何绕行方式 / 有临时方案但需人工介入 / 有稳定替代路径 / 不影响使用 | 用户或客服能否在不改代码的前提下完成原任务 |
每个档位的描述要能被第三方复核：写“核心流程完全不可用”时，标准里应指明哪些流程属于核心流程；写“特定条件下的小部分用户”时，应说明条件如何识别。描述里出现“可能”“部分情况下”这类词，通常意味着档位还没写到位，需要补充可验证的条件。
维度组合映射到级别
级别数量建议控制在四档，例如致命、严重、一般、轻微。四档在多数团队中能被稳定执行，档位再细会增加边界争议，档位再少则难以区分处理紧迫度差异。映射规则采用“主维度定级、辅助维度上调”的方式：
- 致命：功能可用性为“核心流程完全不可用”，或数据维度为“数据丢失、损坏、越权访问”，且受影响范围为全部用户或主要角色。
- 严重：核心流程部分受阻，或非核心功能完全不可用但涉及对外承诺；无稳定绕行方式时按严重处理。
- 一般：非核心功能异常，存在稳定替代路径，业务损失有限。
- 轻微：体验、文案、样式类问题，不影响任务完成。
维度之间出现冲突时，预先约定取舍顺序：数据完整与安全优先于功能可用性，功能可用性优先于受影响范围，受影响范围优先于业务损失，可绕过性作为下调依据而非上调依据。这个顺序要在标准文档中写明，并在培训时用案例解释，否则不同角色会各自按直觉取舍。
判定流程：谁定级、怎么记录、争议怎么处理
定级流程的输入是缺陷描述与复现信息，输出是带有判断依据的级别记录。流程的关键是让提交人填写依据而不只是选一个级别，这样复核才有材料可看。
角色分工
| 角色 | 职责 | 产出 |
|---|---|---|
| 提交人（测试或用户支持） | 按五个维度填写初判依据，附复现步骤、影响范围、是否已有绕行方案 | 带依据的初判级别 |
| 定级责任人（测试负责人或模块负责人） | 确认初判依据是否完整，对边界情形作出判定 | 确认后的级别 |
| 复核角色（产品负责人或技术负责人） | 对致命、严重级别，以及跨模块缺陷进行复核 | 复核意见 |
| 裁决人（质量负责人或项目负责人） | 处理级别争议，给出最终结论并说明理由 | 裁决记录 |
操作步骤
- 提交：提交人填写缺陷描述、复现步骤、五个维度的判断依据和初判级别。缺少依据的缺陷退回补充，不进入定级。
- 确认：定级责任人在约定时限内确认级别。依据与级别一致时直接确认；不一致时写明调整理由。
- 复核：致命与严重级别进入复核；一般与轻微级别由定级责任人直接确认。
- 争议处理：提交人与定级责任人对级别有分歧时，提交至裁决人。裁决人依据标准中的维度定义和取舍顺序作出结论，结论与理由一并记录。
- 变更记录：级别发生变化时，记录变更前后的级别、变更原因、时间和操作人。变更原因应指向具体事实，例如“确认影响范围为全部租户”或“发现稳定绕行方案”。
完成标志是：每个缺陷都有级别和判断依据，致命与严重级别有复核记录，所有争议都有裁决结论，级别变更可追溯。在工具层面，ONES 测试管理支持未通过用例快速创建缺陷任务，缺陷在测试与研发团队间流转，级别字段与判断依据可以随缺陷记录一起传递；级别变更的原因和时间点能否在缺陷工作项中完整留痕，需要按实际版本的字段与历史记录配置确认。
示例：一次定级的完整判断过程
以下为演示情景，用于说明维度判断如何落到级别，不指向任何真实产品或团队。
缺陷描述：某后台系统的订单导出功能在筛选条件包含“跨月”时返回空文件，其他筛选条件正常。客服反馈已有三家企业客户咨询，其中一家表示影响月末对账。
| 维度 | 判断依据 | 档位 |
|---|---|---|
| 功能可用性 | 导出功能在特定筛选条件下不可用，其他条件正常，属于核心流程部分受阻 | 核心流程部分受阻 |
| 数据完整与安全 | 导出结果为空，源数据未受影响，无越权 | 无数据影响 |
| 受影响用户范围 | 仅使用跨月筛选的账号受影响，客服确认三家企业客户 | 特定条件下的小部分用户 |
| 业务与合规损失 | 影响客户月末对账，尚未触发合同条款 | 对外承诺无法履行 |
| 可绕过性 | 可按月分次导出后合并，需人工操作 | 有临时方案但需人工介入 |
按映射规则，功能可用性为“核心流程部分受阻”，业务损失为“对外承诺无法履行”，初判为严重。定级责任人注意到可绕过性为“需人工介入”，提出可下调为一般；提交人认为对账场景下人工合并容易出错，坚持严重。争议提交裁决人，裁决人依据取舍顺序中“功能可用性优先于受影响范围、可绕过性仅作下调依据”的约定，结合业务损失档位，裁定维持严重，理由记录为“对外承诺受影响，绕行方案存在操作风险”。
这个例子也说明信息不足时的处理：如果缺陷描述只写“导出有问题”，没有说明筛选条件、影响客户数量和绕行方案，就无法完成定级，应退回补充复现步骤和影响范围，而不是先给一个级别再改。
校准与完成检查：标准是否真的被一致执行
标准写完不等于可用。验证方法是拿历史缺陷做回测：从近三到六个月的缺陷中分层抽样，覆盖四个级别和主要模块，让两名以上不同角色的成员在只看缺陷描述和依据的情况下独立定级，统计一致程度。一致率的约定水平由团队根据缺陷量设定，例如抽样 30 条、一致率达到 80% 视为可用；未达到时，重点分析分歧集中在哪些维度和档位。
完成检查清单
- 五个维度都有可观察的档位描述，标准中指明了核心流程清单和受影响范围的识别方式。
- 四个级别之间没有空档，也没有重叠；每条映射规则都能对应到具体维度组合。
- 维度冲突的取舍顺序已写入标准，并有至少一个案例说明。
- 每个缺陷都有级别和判断依据，致命与严重级别有复核记录。
- 所有级别争议都有裁决结论和理由，争议记录可检索。
- 级别变更记录了原因、时间和操作人。
- 抽样回测的一致率达到团队约定水平，分歧项已归因到具体档位。
修订触发条件与版本管理
出现以下情况时启动标准修订：回测一致率连续两次低于约定水平；同一档位在一个季度内产生三次以上争议；业务形态变化导致核心流程清单失效；新增合规要求改变了业务损失档位的判断。修订后的标准保留版本号和生效日期，历史缺陷沿用定级时的版本，不批量重判。修订记录中写明改了哪个维度、哪个档位、依据是什么，便于后续回测对比。
完成标志是：抽样一致率达到团队约定水平，争议全部闭环，标准文档带有版本号和生效日期。达到这个状态后，级别数据才可以用于缺陷分布统计和版本质量评估；ONES 测试管理提供项目缺陷分布统计并自动生成测试报告，统计能否按严重程度等自定义维度分组，需以实际产品配置为准。
常见问题
团队规模小、缺陷量少，还需要完整的四档分级和复核流程吗？
可以简化流程，但不宜取消分级本身。缺陷量少的团队可以只保留致命、严重、一般三档，把轻微问题并入一般；复核环节可只对致命和严重级别保留，一般级别由定级责任人直接确认。需要保留的是两件事：每个缺陷仍要写判断依据，级别变更仍要记录原因。否则后续做缺陷分布统计或版本质量评估时，级别数据无法解释。
同一个缺陷在不同环境下影响不同，应该按哪个环境定级？
按标准中约定的评估时点和事实定级。通常以生产环境或对外服务环境的影响为准，测试环境发现的问题若可确认会同样出现在生产环境，按生产影响评估；若只在特定配置下出现，把配置条件写进受影响范围维度。环境差异导致级别变化时，走级别变更记录，写明新发现的事实，例如“确认该配置在全部租户默认开启”。
定级争议频繁，是标准写得不够细，还是执行有问题？
先看分歧集中在哪。如果争议反复出现在同一档位，通常是档位描述缺少可观察条件，需要补充核心流程清单、受影响范围的识别方式等；如果分歧分散在多个维度，可能是取舍顺序没有被理解和执行，需要培训与案例说明。回测时把分歧项归因到具体档位，比笼统统计一致率更有用。同一档位一个季度内产生三次以上争议，可作为启动修订的触发条件。
级别定下来之后，和分诊、排期的衔接要注意什么？
级别是分诊的输入之一，不是排期的结论。交接时把级别、判断依据和可绕过性一并传递，分诊环节再结合资源、发布计划和客户承诺决定处理顺序。这样安排的好处是：级别变化只反映影响事实的变化，排期调整不需要反过来改级别。处理归属、排队规则和工单响应时限属于分诊与SLA管理的范围，应在那套机制里定义。
在工具里落地定级标准，需要关注哪些配置点？
关注三处：级别字段与选项是否与标准中的四档一致；判断依据能否作为结构化字段随缺陷记录保存；级别变更的原因、时间和操作人能否留痕。ONES 测试管理支持未通过用例快速创建缺陷任务，缺陷在测试与研发团队间流转，并提供项目缺陷分布统计与测试报告自动生成。缺陷严重程度字段的自定义范围、级别变更历史的记录方式、统计能否按严重程度分组，需按实际版本的字段与报表配置确认。
