缺陷严重程度标准是团队对缺陷影响范围与破坏程度进行统一分级的约定，用来回答“这个缺陷有多严重”。它通常由等级数量、每级判定依据和典型示例组成，常见四到五级，判定时综合功能可用性、数据与安全影响、影响用户范围、绕行方案和修复紧迫性。严重程度描述缺陷本身的影响，与处理先后顺序的优先级、分诊和责任分配是不同概念。
要点总览（TL;DR）
- 缺陷严重程度标准是团队对缺陷影响范围与破坏程度进行统一分级的约定，由等级数量、每级判定依据和典型示例三部分构成。
- 常见划分为四到五级，如致命、严重、一般、轻微、建议；判定时综合功能可用性、数据与安全影响、影响用户范围、绕行方案和修复紧迫性。
- 定级要把多个维度组合起来看，以最不利维度或综合判断取较高等级，并为相邻等级的模糊地带补充边界示例。
- 严重程度描述缺陷本身的影响，优先级安排处理先后，分诊决定归属与流转；三者分别记录、互不替代。
- 常见误解包括把严重程度当优先级、按修复难度定级、认为等级越多越好；定级争议可通过写明依据、指定裁决人和沉淀边界示例来处理。
缺陷严重程度标准是什么
缺陷严重程度标准（Defect Severity Standard）是团队事先约定的分级规则，用于判断一个缺陷对产品功能、数据、用户和业务造成的破坏程度。它把连续、模糊的影响判断收敛为有限几个等级，让测试、研发、产品在提交、评审和统计缺陷时使用同一把尺子。需要说明的是，严重程度评价的是缺陷本身，与“先修哪个”的处理顺序分开维护。
一套可用的严重程度标准通常包含三类要素：
- 等级数量与命名：确定分几级、每级叫什么，例如致命、严重、一般、轻微、建议。等级数量应与团队规模和缺陷量匹配，过多会增加判定成本，过少会掩盖差异。
- 判定依据：为每一级写明判断维度，如功能是否可用、是否造成数据丢失或安全问题、影响多少用户、是否存在临时绕行方案。判定依据要写成可观察的条件，避免“影响较大”这类无法核对的表述。
- 典型示例：每级配一到两个来自本产品的真实场景，帮助新成员快速对齐。示例应覆盖不同模块，避免只举某一类缺陷。
这三类要素共同构成标准文本。仅有等级名称而缺少判定依据和示例，标准在实际定级时仍会退回到个人经验；只有示例而缺少维度，遇到新场景又无法类推。团队可以把标准放在测试规范或缺陷管理文档中，随业务变化定期修订。
严重程度标准的边界：它管什么、不管什么
严重程度标准只回答“缺陷影响有多大”，不负责决定“谁来处理、什么时候处理”。把这几件事混在一张字段里，会导致定级争议和处理混乱。下面用对照方式说明各自的范围。
| 事项 | 归属概念 | 回答的问题 | 典型维护方 |
|---|---|---|---|
| 缺陷影响程度 | 严重程度 | 这个缺陷有多严重 | 测试与产品共同约定 |
| 处理先后顺序 | 优先级 | 先修哪个、排到哪一轮 | 研发负责人或产品 |
| 归属与排队 | 缺陷分诊与责任分配 | 交给谁、进入哪个队列 | 测试负责人或值班人员 |
| 响应与解决时限 | 工单优先级与 SLA 管理 | 多久内响应、多久内解决 | 服务或运维管理方 |
边界清晰之后，同一缺陷可以同时拥有严重程度和优先级两个字段，两者取值不必一致。一个严重程度为“严重”的缺陷，如果已有稳定的临时绕行方案且当前版本不对外发布，优先级可以排后；一个严重程度为“轻微”的界面错别字，如果出现在对外宣传页上，优先级也可能被提前。严重程度保持相对稳定，优先级随版本计划、客户影响和资源情况动态调整，这是两者分开维护的价值。
工单场景中的紧急性排序和 SLA 时限属于服务管理范畴，与产品缺陷的严重程度标准是两套规则。团队可以借用相同的等级词汇，但判定依据和责任人不同，不宜直接套用。
常见等级维度与各级判定边界
行业通行的做法是划分四到五级。四级的常见命名为致命、严重、一般、轻微；五级则在轻微之后增加“建议”或“优化”，用于收纳不影响功能使用的改进项。命名可以不同，关键是每级的判定边界清楚。下表按五个维度给出一种常见划分，团队可据此裁剪。
| 等级 | 功能可用性 | 数据与安全影响 | 影响用户范围 | 绕行方案 | 修复紧迫性 |
|---|---|---|---|---|---|
| 致命 | 核心功能完全不可用，系统崩溃或无法启动 | 造成数据丢失、数据错误或安全漏洞 | 全部或大部分用户 | 无 | 立即修复，阻断发布 |
| 严重 | 核心功能部分失效或主要流程中断 | 存在数据风险但未实际发生，或权限异常 | 较多用户或关键客户 | 绕行代价高 | 当前版本内必须修复 |
| 一般 | 次要功能失效，主流程仍可完成 | 无数据与安全影响 | 部分用户或特定条件触发 | 有可接受的绕行方案 | 排入近期版本 |
| 轻微 | 功能可用，表现为显示错误、文案问题或体验瑕疵 | 无 | 少量用户或不易察觉 | 不影响使用 | 可随版本批量处理 |
| 建议 | 功能正常，属于改进期望 | 无 | 不涉及用户受阻 | 不适用 | 进入需求池择机处理 |
定级时要把多个维度组合起来看，不能只凭单一维度下结论。例如一个缺陷只在特定浏览器下导致页面错位，功能仍可完成，按功能可用性看接近轻微；但如果它出现在支付确认页且影响所有使用该浏览器的用户，影响范围和业务后果会把等级推到严重。反过来，一个导致报错的缺陷如果只在内部测试环境出现、外部用户无法触达，影响范围维度会拉低其等级。团队可以在标准中写明“以最不利维度为准”或“综合判断后取较高等级”，并保持全团队一致。
判定边界还需要处理相邻等级的模糊地带。常见做法是为每一级补充“不满足上一级条件时归入本级”的说明，并给出边界示例。例如“核心功能不可用但存在官方临时开关可恢复”应归入严重而非致命，因为绕行方案存在且代价可控。这类边界说明比等级名称更能减少争议。
严重程度与优先级、分诊的区别
三个概念经常被合并成一个字段使用，实际承担不同职责。严重程度是对缺陷影响的客观描述，优先级是对处理顺序的主观安排，分诊是决定缺陷流向和责任人的动作。三者配合的方式是：先定级，再分诊，最后排优先级。
| 对比项 | 严重程度 | 优先级 | 分诊 |
|---|---|---|---|
| 描述对象 | 缺陷本身的影响 | 处理任务的先后 | 缺陷的归属与流转 |
| 变化频率 | 相对稳定，除非影响被重新评估 | 随版本、客户和资源动态调整 | 提交后短时间内确定 |
| 主要判断者 | 提交者与评审者 | 研发负责人或产品 | 测试负责人或值班人员 |
| 典型取值 | 致命、严重、一般、轻微、建议 | 高、中、低或数字序号 | 模块、负责人、处理队列 |
配合使用时，严重程度为分诊提供输入：致命和严重缺陷通常进入快速通道，由专人跟进；一般和轻微缺陷进入常规队列。分诊结果又为优先级提供依据：分配给关键模块负责人的缺陷，其处理顺序会结合版本计划确定。三者各自记录、互不替代，出现争议时可以回溯是哪一环判断不同。
在缺陷量较大的团队中，定级后的记录和流转需要工具承载。ONES Project 支持缺陷跟踪管理并可统计缺陷状态分布，也支持一键提交 Bug 至对应项目或迭代，记录和跟踪修复情况；ONES TestCase 中未通过的用例可快速创建缺陷任务，使缺陷在测试与研发团队间流转，并提供项目缺陷分布统计。这些能力承接的是定级之后的记录、交接与统计环节，等级标准本身仍由团队约定。
具体例子与常见误解
下面用一个演示情景说明完整定级过程。某电商应用的订单列表页在弱网环境下加载失败，用户反复下拉仍无法看到历史订单，但通过“我的订单”入口可以正常进入同一列表。按维度逐项判断：功能可用性上主流程存在替代入口，属于部分失效；数据与安全上无数据丢失；影响范围上仅弱网用户，占比有限；绕行方案存在且用户可自行完成；修复紧迫性为当前版本内处理。综合后定为“严重”而非“致命”，因为核心功能可通过另一入口完成，但影响真实用户且绕行不够直观。若该问题同时导致订单状态显示错误，数据维度会把等级推到致命。这个例子说明定级要逐维度核对，并在标准中记录判断理由。
实际工作中常见的误解有三类：
- 把严重程度当优先级：认为定了“严重”就必须立刻修。严重程度描述影响，是否立刻处理取决于版本计划、客户承诺和资源，两者应分别填写。
- 按修复难度定级：缺陷难修不等于影响大。修复成本属于研发评估，定级只看影响；把难度混入等级会让统计失真，也会让简单但影响大的缺陷被低估。
- 等级越多越好：等级过细会增加判定成本和争议，团队难以稳定区分。四到五级通常已能覆盖多数场景，确有需要时可通过标签补充细分，而不必扩充等级。
定级争议的处理方式可以固化为流程：提交者在缺陷中写明判定维度和依据；评审时由测试、研发、产品共同确认，无法达成一致时由事先指定的裁决人决定；争议结论沉淀为标准中的边界示例，供后续参考。定期抽样复核已定级缺陷，能发现标准表述不清的地方，并据此修订标准文本。
常见问题
团队规模较小、缺陷量不大时，是否也需要完整的四到五级标准？
等级数量应与团队规模和缺陷量匹配。缺陷量不大时，可以先采用三级或四级划分，把判定依据和典型示例写清楚，保证提交、评审和统计使用同一把尺子。随着缺陷量增长、模块增多，再补充“建议”或“优化”这类收纳改进项的等级。关键是每级的判定边界可核对，等级名称本身可以按团队习惯调整。
同一个缺陷，测试定为“严重”、研发认为只是“一般”，怎么处理？
这类分歧通常来自判定维度没有逐项核对。可以要求提交者在缺陷中写明功能可用性、数据与安全影响、影响用户范围、绕行方案和修复紧迫性各维度的判断依据，评审时由测试、研发、产品共同确认。仍无法达成一致时，由事先指定的裁决人决定，并把结论沉淀为标准中的边界示例，供后续同类场景参考。
严重程度定级之后，缺陷的记录和流转如何衔接？
定级完成后，缺陷需要进入可跟踪的记录与流转环节。ONES Project 支持缺陷跟踪管理并可统计缺陷状态分布，也支持一键提交 Bug 至对应项目或迭代，记录和跟踪修复情况；ONES TestCase 中未通过的用例可快速创建缺陷任务，使缺陷在测试与研发团队间流转，并提供项目缺陷分布统计。等级标准本身仍由团队约定，工具承接的是定级之后的记录、交接与统计。
缺陷出现在内部测试环境、外部用户无法触达，等级要不要下调？
影响用户范围是判定维度之一，外部用户无法触达会拉低这一维度的取值。但定级仍需逐维度核对：如果该缺陷同时造成数据错误或安全风险，数据与安全影响维度可能把等级推高。建议在标准中写明各维度的组合规则，例如“以最不利维度为准”或“综合判断后取较高等级”，并保持全团队一致，避免同类场景出现不同结论。
严重程度标准需要多久修订一次？
没有统一周期，可以结合业务变化和定级争议情况安排。常见触发点包括：新增模块或业务线带来标准未覆盖的场景、抽样复核发现多起定级不一致、边界示例积累到一定数量。修订时同步更新判定依据和典型示例，并通知测试、研发、产品等相关角色，保证标准文本与实际使用保持一致。
