缺陷严重程度标准示例通常包含一张四级分级表和一组已填好的判定样例，用“影响范围、功能可用性、数据与安全风险、有无替代路径”四个判断点，把“这个缺陷到底多严重”从主观争论变成可对照的选择。本文给出可直接套用的分级表、5个假设缺陷的逐条判定演示，以及把示例改造为团队标准的步骤；示例均为演示情景，响应时限和量化阈值需按团队实际调整。
要点总览（TL;DR）
- 缺陷严重程度标准示例的核心是一张四级分级表：致命、严重、一般、轻微，用影响范围、功能可用性、数据与安全风险、有无替代路径四个判断点逐项对照。
- 判定时按固定顺序走：先看数据与核心流程，再看主要功能是否可用，最后看替代路径和影响面；同一缺陷命中多条时取更严重的一条。
- 偶现崩溃、可绕行但影响面大的缺陷容易误判，频率低不等于影响小，有替代路径也不必然降级。
- 把示例改成团队标准，保留判断结构、替换具体内容，并用历史缺陷回填校准、按迭代复核级别分布。
- 严重程度只描述影响，分诊决定由谁处理，优先级决定排队顺序，三者应分别记录；示例中的时限与阈值需按团队实际调整。
示例要解决的分级问题
这份示例的用途，是让测试、研发和产品在提交或评审缺陷时，面对同一段描述能落到同一个级别。它要消除三类常见分歧：一是“能不能用”与“好不好用”混在一起讨论，导致界面问题被抬到严重级别；二是只描述现象、不说明影响范围，评审人只能凭印象判断；三是把“谁该修、先修哪个”带进严重程度讨论，级别随排期压力上下浮动。
分级只回答一个问题：这个缺陷对用户和业务造成了多大影响。具体拆成四个判断点：影响多少用户或哪条核心流程；主要功能是否还能完成；是否涉及数据错误、丢失或安全暴露；用户是否存在可接受的替代路径。四个判断点回答完，级别基本就确定了。
需要划清的边界是：严重程度描述影响，分诊决定由谁处理，优先级决定排队顺序。一个轻微缺陷可能因为临近发布而被优先处理，一个严重缺陷也可能因为已有绕行方案而排在后面。本文只讨论严重程度分级本身，分诊流程、责任分配和工单优先级不在示例范围内。以下所有缺陷情景、级别名称和时限数字均为演示设定，不对应任何真实客户或项目。
完整示例：四级严重程度分级表
下表是一份已填写的分级表，可直接作为讨论底稿。级别采用四级：致命、严重、一般、轻微。判断条件按四个判断点展开，典型缺陷帮助提交人快速对号入座，响应时限一列仅作演示，团队应替换为自己的服务约定。
| 级别 | 定义 | 判断条件 | 典型缺陷举例 | 响应时限（演示） |
|---|---|---|---|---|
| 致命 | 核心业务流程中断，或造成数据损坏、安全风险 | 核心流程无法完成且无替代路径；或出现数据丢失、错乱、越权访问 | 下单提交后订单未生成；用户能看到他人账户数据；批量导入导致原有数据被覆盖 | 立即响应，当天给出处理方案 |
| 严重 | 主要功能不可用，且没有可接受的替代路径 | 主要功能报错或结果不可信；影响面覆盖多数用户；绕行成本明显高于正常操作 | 报表导出持续失败；支付回调丢失导致状态不同步；登录在特定浏览器下失败 | 1个工作日内响应 |
| 一般 | 功能可用，但结果偏差或需要绕行 | 主流程能走通；存在明确替代操作；影响限于部分场景或部分用户 | 筛选条件组合后结果少一条；导出文件字段顺序错乱但内容完整；提示文案与实际操作不符 | 当前迭代内安排 |
| 轻微 | 界面、文案、体验问题，不影响任务完成 | 不影响功能结果；用户可正常完成任务；仅观感或一致性问题 | 按钮间距不一致；错别字；暗色模式下图标对比度偏低 | 排入常规优化 |
使用这张表时有两个约定。第一，判断顺序从上往下：先看是否触及数据和核心流程，再看主要功能是否可用，最后看替代路径和影响面。第二，同一缺陷命中多条时取更严重的一条，例如一个偶现崩溃虽然出现频率低，但一旦发生会丢失用户正在编辑的内容，应按致命处理，频率信息写入描述供后续分析。
示例缺陷逐条判定演示
下面用5个假设缺陷走一遍判定过程。每条先写现象，再按四个判断点逐项对照，最后给出级别和理由。这些情景为演示而设，用于说明判定思路。
| 示例缺陷 | 影响范围 | 功能可用性 | 数据与安全风险 | 替代路径 | 判定 |
|---|---|---|---|---|---|
| 示例A：提交订单后页面报错，订单列表中没有新订单 | 所有下单用户 | 核心流程中断 | 订单数据未落库，存在交易丢失 | 无 | 致命 |
| 示例B：批量导入客户资料时，重复编号的记录覆盖了已有联系人信息 | 使用导入功能的运营人员 | 导入功能可用但结果错误 | 已有数据被覆盖，属于数据损坏 | 可手工逐条修正，但成本高 | 致命 |
| 示例C：报表导出在数据量超过一万行时超时失败 | 需要导出大报表的部分用户 | 主要功能不可用 | 无数据风险 | 可按时间分段导出后合并，操作繁琐 | 严重 |
| 示例D：移动端在弱网下偶现闪退，重进后可继续操作 | 弱网环境下的移动端用户 | 主流程可完成 | 闪退时未保存的草稿丢失 | 重新进入并重填 | 严重 |
| 示例E：设置页开关文案写反，开启后实际为关闭状态 | 使用该设置的用户 | 开关功能本身正常 | 无 | 用户可试一次后自行纠正 | 一般 |
几个边界情形值得单独说明。示例C属于“可绕行但影响面大”：分段导出确实能拿到数据，但一次常规工作被拆成多次操作，且容易遗漏，因此不因存在替代路径就降为一般。示例D是偶现崩溃，频率低不等于影响小，闪退造成草稿丢失这一点把它推到严重；如果闪退发生在支付确认环节并导致重复扣款，则应升为致命。示例E容易被误判为轻微，因为现象只是文案问题，但它让用户对功能状态产生错误认知，按“结果偏差、有绕行方案”归入一般更合适。
性能劣化类缺陷需要额外口径。例如“列表页加载从1秒变为4秒”，如果团队没有约定阈值，判定会随人而异。示例做法是在分级表中补一行量化说明：超过约定阈值的响应时间按主要功能不可用处理，未超过的按一般处理。阈值本身由团队根据用户场景设定，不直接照搬本文数字。
从示例到团队标准的迁移规律
把示例改成团队自己的标准，关键动作是保留判断结构、替换具体内容。级别名称可以改，四个判断点建议保留，因为它们对应的是可观察的事实，而不是主观感受。以下步骤可作为改造清单。
- 确定判断点顺序。先数据与安全，再核心流程，再主要功能，最后体验问题。顺序固定后，评审时按同一路径走，减少来回争论。
- 用历史缺陷回填校准。抽取过去一个季度的缺陷，按新表重新定级，统计有多少条与原级别不一致。不一致集中的地方，往往就是判断条件写得含糊的位置，据此补充示例。
- 把分级字段写进提交模板。缺陷提交表单中设置严重程度为必填单选，并在选项旁附一句判断条件；同时保留“影响范围”“替代路径”两个短文本字段，让定级依据随缺陷一起留存。
- 约定争议升级方式。提交人与评审人对级别不一致时，由测试负责人或质量角色在固定时间窗口内裁定，裁定理由记录在缺陷中，作为后续校准的样本。
- 定期复核分布。按迭代查看各级别缺陷的数量和占比，若致命与严重长期占比过高，检查是否级别膨胀；若大量缺陷集中在一般，检查判断条件是否过宽。
分级表要真正被使用，需要落在缺陷工作项里，而不是停留在文档中。ONES Project 适配缺陷管理等研发场景，提供缺陷跟踪管理，并可统计缺陷状态分布；ONES TestCase 支持将未通过的用例快速创建为缺陷任务，让缺陷在测试与研发团队间流转。团队可以把严重程度作为缺陷工作项的一个属性，在提交环节随缺陷一并填写，使分级结果与缺陷记录同步留存，便于后续按迭代回看分布。严重程度字段的具体配置方式，建议在启用前与管理员确认。
示例的适用边界与常见误用
这份示例面向通用软件产品的功能缺陷。产品形态不同，判断点需要调整：To B 产品往往还要看缺陷是否影响多租户隔离、权限边界和客户合同约定；硬件相关产品需要把故障是否可远程恢复、是否涉及现场返修纳入判断；数据类产品则应把数据准确性、可追溯性和计算口径错误放在更高位置。直接套用四级名称而不调整判断条件，容易出现级别与业务风险脱节。
两类偏差最常见。级别膨胀表现为大量缺陷被定为严重或致命，原因是提交人希望尽快被处理，把优先级诉求写进了严重程度；后果是分级失去区分度，真正的高风险缺陷被淹没。级别压缩则相反，评审人习惯性降级，把“有绕行方案”当作降级理由，忽略影响面和数据风险。两种偏差都可以通过回填校准和分布复核发现。
另一个高频误用是把严重程度当优先级使用。严重程度回答影响多大，优先级回答先做哪个，二者可以不一致，也应当分别记录。此外，示例中的响应时限、性能阈值和影响用户比例都是演示数字，不能直接写进团队规范；这些数值需要结合产品使用场景、服务承诺和历史数据确定，并在团队内达成一致后再启用。
常见问题
缺陷严重程度分几级比较合适？四级够用吗？
四级是常见起点：致命、严重、一般、轻微，能覆盖大多数功能缺陷的区分需求。级别数量本身不是关键，关键是每级都有可对照的判断条件。团队规模小、缺陷量不大时，四级通常够用；如果产品涉及数据、安全或多租户隔离，可以在致命之上补充判断说明，而不必增加级别名称。级别过多会让提交人难以选择，反而加剧定级分歧。
偶现崩溃频率很低，应该定严重还是一般？
先看崩溃发生时造成的后果，而不是出现频率。如果崩溃会导致用户未保存的内容丢失、交易中断或状态错乱，即使偶现也应按严重或致命处理，频率信息写入缺陷描述供后续分析。如果崩溃后用户重进即可继续、没有数据损失，可归为一般。把频率作为独立判断点容易让高风险缺陷被系统性低估，建议在分级表中明确“后果优先于频率”。
有替代路径的缺陷，是不是都可以降一级？
不一定。替代路径要评估绕行成本：如果绕行只是多点击两次，降级合理；如果绕行意味着把一次常规操作拆成多次、容易遗漏或需要人工核对，影响面仍然很大，就不应仅因存在替代路径而降级。示例中的大报表导出超时就是这种情况，分段导出能拿到数据，但操作繁琐且易出错，仍按严重处理。建议在判断条件中写明“替代路径可接受”的标准，而不是笼统写“有绕行方案”。
严重程度和优先级可以合并成一个字段吗？
不建议合并。严重程度描述缺陷对用户和业务的影响，优先级描述先处理哪个，两者依据不同：一个轻微缺陷可能因临近发布而被优先处理，一个严重缺陷也可能因已有绕行方案而排在后面。合并后，排期压力会直接影响定级，分级失去稳定性。实践中可以保留两个字段，严重程度由提交与评审环节确定，优先级在排期时确定，并允许二者不一致。
把示例改成本团队标准后，怎么判断分级是否有效？
可以用两个信号检验。一是回填校准：抽取过去一个季度的缺陷按新表重新定级，统计与原级别不一致的比例，不一致集中的位置通常说明判断条件写得含糊，需要补充示例。二是分布复核：按迭代查看各级别缺陷的数量和占比，致命与严重长期占比过高可能是级别膨胀，大量缺陷集中在一般可能是判断条件过宽。两项检查都应以缺陷记录为依据，而不是凭印象判断。
分级表落地时，严重程度字段应该怎么设置？
建议把严重程度设为缺陷提交表单中的必填单选，选项旁附一句判断条件，同时保留“影响范围”“替代路径”两个短文本字段，让定级依据随缺陷一起留存。这样评审时可以回看提交人的判断依据，争议裁定也有记录可查。ONES Project 提供缺陷跟踪管理，并可统计缺陷状态分布；ONES TestCase 支持将未通过的用例快速创建为缺陷任务。严重程度字段的具体配置方式，建议在启用前与管理员确认。
