缺陷严重程度（Severity）衡量一个缺陷对系统功能、数据和用户造成的实际损害，回答“这个问题有多坏”；它由缺陷本身的影响决定，与“先修哪个”的优先级是两件事。本文给出可直接使用的定义、分级档位与判定信号，并划清它与优先级、缺陷类型、SLA 的边界，帮助团队在记录和复评缺陷时有统一口径。
要点总览（TL;DR）
- 缺陷严重程度（Severity）衡量缺陷对功能、数据、用户和业务造成的实际损害，回答“这个问题有多坏”，由缺陷本身的影响决定。
- 常见档位为阻断、严重、一般、轻微，判定时综合复现率、影响用户比例、是否阻塞主流程、数据是否可恢复等信号，并支持随影响变化复评。
- 严重程度不包括修复排期、责任归属、工单响应时限和缺陷类型，这些分别属于优先级、缺陷分诊与责任分配、SLA 管理和缺陷分类。
- 严重程度与优先级需要分别判断：高严重度缺陷可能因影响面小或版本下线而排在后面，低严重度缺陷也可能因对外可见而优先处理。
- 定级依据可观察的影响而非报告人级别，分级记录应随缺陷进入跟踪流程，复评时更新字段并保留变更原因。
缺陷严重程度的准确定义
缺陷严重程度（Severity）是对缺陷所造成损害程度的度量，描述缺陷发生时系统功能、数据、用户和业务受到影响的大小。它衡量的是影响，不衡量处理顺序。一个缺陷的严重程度在缺陷被确认和复现时基本确定，后续随影响范围变化而调整。
可以直接引用的定义是：缺陷严重程度是依据缺陷对功能可用性、数据完整性、用户操作和业务连续性的实际影响，对缺陷损害程度作出的档位判定。这个定义包含四个衡量对象：
- 功能可用性：相关功能是否还能使用，主流程是否被阻塞。
- 数据完整性：是否产生错误数据、丢失数据，或需要人工修复数据。
- 用户影响：受影响的用户范围、是否有替代操作路径、用户能否自行绕过。
- 业务损失：是否影响交易、结算、对外服务承诺或合规要求。
判定通常发生在缺陷被受理和复现的时点。测试人员在提交缺陷时给出初始严重程度，开发人员在复现后确认或修正，测试负责人或缺陷评审环节在影响判断有分歧时做最终裁定。判定依据是可观察的现象和影响范围，报告人的职位或情绪不构成判定依据。
严重程度包括什么、不包括什么
严重程度的范围边界可以用一份清单说明。它覆盖缺陷造成的损害事实，不覆盖围绕缺陷产生的管理安排。把两者混在一起，分级就会随排期和人员变化而漂移。
严重程度包括以下内容：
- 影响范围：受影响的功能模块、用户比例、环境范围（如仅测试环境或已到生产）。
- 可恢复性：影响是否可逆，数据能否恢复，恢复需要多长时间和多少人工介入。
- 替代路径：用户是否有其他方式完成同一任务，绕过成本有多高。
- 数据风险：是否涉及数据错误、丢失、越权访问或对外泄露。
严重程度不包括以下内容：
- 修复排期：什么时候修、排在哪个版本，属于优先级和发布计划。
- 责任归属：由谁引入、由谁负责修复，属于缺陷分诊与责任分配。
- 工单响应时限：多久必须响应、多久必须关闭，属于 SLA 与工单管理。
- 缺陷类型：这是功能错误、界面问题还是性能问题，属于缺陷分类维度。
严重程度与缺陷类型是两个独立维度。类型回答“这是什么问题”，便于统计分布和分派给对应角色；严重程度回答“这个问题有多坏”，用于判断影响和决定处理力度。同一个类型下可以有不同严重程度的缺陷，同一严重程度也可以出现在多个类型中。记录缺陷时两个字段应分别填写，不用类型替代严重程度，也不用严重程度推断类型。
严重程度分级的组成与判定机制
常见的严重程度采用四档结构：阻断、严重、一般、轻微。不同团队可以增减档位或调整名称，但档位之间需要有可区分的影响描述，避免出现“介于严重和一般之间”的模糊地带。下表给出一种常见口径，团队可据此改写为自身产品的表述。
| 档位 | 典型影响 | 判定信号 |
|---|---|---|
| 阻断 | 主流程无法进行，系统不可用，或核心数据出现不可恢复的损坏 | 阻塞主流程、无替代路径、影响全部或大部分用户、数据无法恢复 |
| 严重 | 核心功能明显受损，重要数据出错，用户难以完成任务 | 影响主要用户群、替代路径成本高、数据需人工修复 |
| 一般 | 非核心功能异常，或核心功能有可用的替代路径 | 影响部分用户、存在绕行方式、数据风险可控 |
| 轻微 | 界面、文案、提示等不影响任务完成的问题 | 不影响功能使用、无数据风险、用户基本无感知 |
判定时综合以下信号，而不是只看单一指标：
- 复现率：稳定复现、偶发复现还是特定条件下才出现。偶发问题若影响核心流程，仍可能定为高档位。
- 影响用户比例：全部用户、特定角色、特定租户或个别账号。
- 是否阻塞主流程：用户能否继续完成当前任务，是否需要中断操作。
- 数据是否可恢复：错误数据能否回滚，是否需要人工订正，是否涉及对外数据。
分级需要支持复评。缺陷在复现后影响范围可能扩大或缩小，例如原本认为只影响测试环境的问题在生产环境出现，或原本以为会丢数据的问题实际只影响展示。复评时应更新严重程度并记录调整原因，保留变更痕迹，便于后续统计和回溯。复评由确认影响的人发起，不因排期变化而调整档位。
严重程度与优先级、缺陷类型的区别
严重程度、优先级、缺陷类型和工单紧急性回答的是不同问题。混用最典型的后果是：所有高严重度缺陷都被默认为最高优先级，导致修复队列失去弹性；或者低严重度缺陷被长期搁置，直到影响扩大。
| 概念 | 回答的问题 | 决定因素 | 典型错配 |
|---|---|---|---|
| 严重程度（Severity） | 这个问题有多坏 | 功能、数据、用户和业务的实际影响 | 把严重程度直接当作排期依据 |
| 优先级（Priority） | 先修哪个 | 业务节奏、发布计划、资源安排、影响面 | 高严重度但影响面小的缺陷占用紧急资源 |
| 缺陷类型 | 这是什么问题 | 问题性质，如功能、界面、性能、兼容性 | 用类型代替严重程度填写 |
| 工单紧急性与 SLA | 多久必须响应或关闭 | 服务承诺、合同约定、支持流程 | 把 SLA 时限当作严重程度档位 |
严重程度与优先级的常见错配有两种。一种是高严重度、低优先级：缺陷确实造成较大损害，但只影响即将下线的旧版本或极少数用户，团队按发布计划安排修复。另一种是低严重度、高优先级：界面文案错误本身影响轻微，但出现在对外发布的主页或合同页面上，需要尽快处理。两种情形都说明两个字段需要分别判断，不能互相推导。
严重程度与工单紧急性的边界在于：严重程度描述缺陷的损害，SLA 描述服务响应的时限承诺。一个轻微缺陷如果来自付费客户的正式工单，可能触发较短的响应时限，但它的严重程度仍然是轻微。响应时限管理属于工单与 SLA 流程，不改变缺陷本身的分级。
具体例子与常见误解
以下示例用于演示判定过程，场景为演示情景，不对应具体产品或真实案例。
现象：某订单系统在提交订单时，部分用户点击提交后页面无响应，刷新后订单未生成，购物车内容保留。影响：主流程被阻塞，受影响用户无法完成下单；未产生错误数据，用户可重新提交；影响范围为部分浏览器版本的用户，其他浏览器正常。判定：主流程被阻塞且无替代路径，但影响范围限于特定浏览器，数据未损坏，定为“严重”档。若确认所有浏览器均无法提交，则升为“阻断”；若仅个别用户偶发且可重试成功，可降为“一般”。
常见误解及纠正：
- 误解一：严重程度高就必须优先修复。纠正：优先级还取决于影响面、发布计划和资源，高严重度缺陷可以排在低严重度但影响面更大的缺陷之后。
- 误解二：低严重度缺陷可以忽略。纠正：轻微缺陷累积会影响体验和信任，且部分轻微问题在特定条件下会放大，应进入跟踪流程而不是直接关闭。
- 误解三：按报告人级别定级。纠正：严重程度依据可观察的影响，管理者报告的问题不自动升档，一线用户报告的问题也不自动降档。
- 误解四：定级一次就不再调整。纠正：影响范围变化时应复评并记录原因，保持分级与事实一致。
分级记录需要进入缺陷跟踪流程才能发挥作用。缺陷提交时填写严重程度字段和判定依据，复现后由确认人复核，评审环节处理分歧，复评时更新字段并保留变更记录。在缺陷数量较多的项目中，严重程度字段与状态流转、版本信息结合，可以支撑按档位统计、按影响范围筛选和发布前的缺陷收敛判断。ONES 的缺陷管理工作项支持自定义严重程度字段、状态流转和变更记录，团队可以把上述判定口径落到字段选项和评审动作中，让分级结果随缺陷一起流转，而不是停留在提交说明里。
常见问题
缺陷严重程度和缺陷优先级可以只填一个吗？
建议两个字段分别填写。严重程度描述缺陷造成的损害，优先级描述修复的先后安排，二者的决定因素不同。只填严重程度，排期时缺少业务节奏和影响面的信息；只填优先级，则难以回溯缺陷本身的影响判断。若团队字段有限，至少保留严重程度作为缺陷属性，并在评审记录中说明排期理由。
同一个缺陷在不同环境下严重程度不同，应该怎么记录？
按当前已确认的最严重影响定级，并在判定依据中写明环境范围。例如问题已在生产环境出现，就按生产环境的影响定级，测试环境的表现作为补充信息记录。若生产环境尚未确认，可先按已复现环境定级，待生产验证后复评更新，并保留调整原因，避免同一缺陷在不同记录中档位不一致。
偶发缺陷复现率低，严重程度是否一定定得低？
不一定。复现率只是判定信号之一，还要看影响后果。偶发问题如果一旦出现就阻塞主流程或造成数据损坏，仍可能定为高档位；反之，稳定复现但只影响界面提示的问题，档位可以较低。判定时把复现条件和影响后果一起写入依据，便于后续复评时判断是否需要调整。
缺陷复评后严重程度变了，历史统计会不会失真？
保留变更记录可以兼顾两者。复评时更新严重程度字段，同时记录原档位、新档位和调整原因，统计时既可以看当前档位分布，也可以回溯定级变化。若团队按发布周期统计缺陷收敛情况，建议在发布前固定一次分级口径，减少统计周期内的频繁变动，复评记录仍照常保留。
客户通过工单报告的问题，严重程度要按 SLA 时限来定吗？
不需要。SLA 时限约束的是响应和关闭的时间承诺，严重程度描述的是缺陷本身的损害。客户工单可能触发较短的响应时限，但缺陷分级仍按功能、数据、用户和业务的实际影响判断。两者分别记录，处理时先按 SLA 响应，再按严重程度和优先级安排修复。
