缺陷严重程度分级示例要解决的是把“影响多大、多急、能否绕过”变成可填写的等级判断。下面用一条假设的支付失败缺陷，演示从描述、影响确认到五级定级的完整记录，并解释相邻等级的边界与迁移方法。示例为演示情景，不代表真实客户案例或实测效果。
要点总览（TL;DR）
- 缺陷严重程度分级示例的核心，是把影响范围、功能可用性、数据与安全风险、可恢复性四项判断落成可填写的等级表，再用一条完整缺陷记录演示从描述到定级的过程。
- 示例采用五级体系：致命、严重、一般、轻微、建议；定级顺序为数据与安全风险优先，其次看核心流程是否中断，再看替代路径与影响范围。
- 示例中的支付失败缺陷因核心流程对局部用户中断、存在订单状态不一致、替代路径可用，定为严重而非致命。
- 迁移到团队时先确定级数，再固定判定顺序与一票升级规则，用固定句式写清判定理由，并保留测试与研发的分歧记录。
- 分级只回答影响程度，不决定处理归属、排队顺序与响应时限；这些属于缺陷分诊、责任分配和工单优先级与 SLA 管理。
示例目标：这份分级示例要解决什么判断问题
这份示例的目标是给测试与研发提供一份可直接对照的填写样板。它展示一条缺陷记录如何从标题和复现步骤出发，经过影响范围、功能可用性、数据与安全风险、可恢复性四项判断，最终落到一个严重程度等级，并写清判定理由。读者可以据此检查自己团队的缺陷单是否缺少关键信息，也可以把示例中的字段和句式改成内部模板。
示例采用五级体系：致命、严重、一般、轻微、建议。定级顺序固定为：先确认是否存在数据损坏、安全暴露或核心流程完全中断；再确认是否存在可用的替代路径；最后确认受影响的是单用户、局部用户还是全量用户。这个顺序的作用是避免先看用户数量而忽略数据风险，也避免把“有人能绕过”直接等同于低等级。
分级只回答三个问题：影响多大、多急、能否绕过。它不决定由谁处理、排在第几位、多久必须修复。为了让示例自洽，假设该缺陷发生在一个已上线的支付流程中，测试环境与生产环境行为一致，影响范围依据客服反馈和日志抽样确认。示例中的产品名称、订单号和用户数量均为虚构。
完整示例：一条支付失败缺陷的分级填写全过程
以下是一条完整填写的缺陷分级记录。它把描述、判断和结论放在同一张记录里，便于测试与研发在评审时逐项核对。
| 字段 | 填写内容 |
|---|---|
| 缺陷标题 | 部分用户在提交订单后支付页面持续加载，订单状态停留在“待支付”，重复提交后出现两笔待支付记录 |
| 复现步骤 | 1. 使用测试账号登录；2. 选择一件库存充足的商品；3. 进入结算页并点击“提交订单”；4. 在支付页等待超过30秒；5. 返回订单列表查看状态；6. 再次点击“去支付”并观察是否生成新的待支付记录 |
| 实际结果 | 支付页持续加载，订单状态未更新；重复操作后订单列表出现两条待支付记录，支付渠道侧未见扣款成功 |
| 预期结果 | 提交订单后进入支付页并正常发起支付；同一订单重复点击不生成新的待支付记录 |
| 影响范围 | 局部用户：近两小时客服反馈涉及约数十名用户，日志抽样显示集中在某一支付渠道；其他渠道未复现 |
| 功能可用性 | 核心购买流程在该支付渠道下中断，用户无法完成付款；浏览、加购和下单入口仍可用 |
| 数据与安全风险 | 存在重复待支付记录，暂未发现实际扣款或资金损失；订单状态与实际支付结果可能不一致，需要人工核对 |
| 替代路径 | 用户可返回结算页切换其他支付渠道完成付款；已产生的重复待支付记录需要后台清理或等待超时关闭 |
| 严重程度 | 严重 |
| 判定理由 | 核心购买流程在特定支付渠道下中断，影响局部用户且持续发生；存在订单状态不一致和重复记录，但未确认资金损失，且用户可切换渠道完成支付。按判断顺序，先排除致命所需的数据损坏或安全暴露，再确认替代路径存在，因此定为严重而非致命。 |
| 测试与研发确认记录 | 测试初判为致命，理由是“支付失败影响收入”。研发复核后指出：影响集中在单一渠道、未发现扣款成功、用户可切换渠道，建议降为严重。双方对照判断顺序确认：数据风险尚未达到资金损失程度，核心流程对局部用户中断且替代路径可用，最终一致同意定为严重，并约定两小时内补充支付渠道日志再复核一次。 |
这条记录的关键在于把“严重”写成有依据的结论，而不是只填一个下拉选项。判定理由同时说明了为什么没有升到致命，以及为什么没有降到一般。测试与研发的分歧记录保留了初判、复核意见和最终共识，后续复盘时可以直接看到定级依据的变化。
逐项解释：每个判断点为什么这样定级
影响范围的区分要看受影响的用户集合和发生条件。单用户问题通常只在特定账号、设备或数据状态下出现；局部用户指某一渠道、某一地区、某一版本或某一类订单集中出现；全量用户指不区分条件、所有用户都会遇到。示例中问题集中在单一支付渠道，其他渠道未复现，因此归为局部用户。若日志显示所有渠道都出现同样现象，影响范围应改为全量，等级也需要重新评估。
数据与安全风险的优先级最高，原因是这类问题可能造成不可逆后果。示例中出现重复待支付记录和订单状态不一致，属于需要核对的数据异常，但尚未确认实际扣款或资金损失，也没有凭证泄露迹象。因此它足以阻止定级为轻微或建议，但还不足以单独构成致命。若后续确认出现重复扣款、支付金额错误或用户支付信息暴露，应立即按致命处理并重新复核。
替代路径决定用户在受阻后能否完成目标。示例中用户可以切换其他支付渠道完成付款，替代路径存在且操作成本不高，这是没有定为致命的重要依据。替代路径的判断要写清“谁能用、怎么用、代价多大”：如果只有部分用户能切换、切换后仍需人工处理重复记录，替代路径就不算完全可用，等级应更保守。
相邻等级的边界可以用一组对照来理解。致命与严重的分界在于是否存在数据损坏、安全暴露或核心流程对全量用户完全中断；严重与一般的分界在于核心流程是否中断，以及是否存在可用的替代路径；一般与轻微的分界在于功能是否仍可用、问题是否只影响体验或非关键路径；轻微与建议的分界在于是否影响正常使用，还是仅涉及文案、样式或改进期望。示例落在严重，是因为核心流程对局部用户中断、替代路径存在、数据风险待确认，三个条件同时成立。
可迁移规律：把示例改写成自己团队的分级表
迁移时先决定级数。四级体系通常合并“轻微”和“建议”，适合缺陷量不大、团队希望减少定级争议的场景；五级体系保留更细的体验类区分，适合有专门体验或文案评审流程的团队。级数本身不决定质量，关键是每一级都有可观察的判断条件，并且相邻等级能用一句话说清区别。
判定顺序建议固定下来，并设置一票升级规则。可以按以下顺序执行：
- 先检查数据损坏、安全暴露、资金错误或核心流程全量中断，命中任一项直接进入最高等级。
- 再检查核心流程是否中断，以及受影响的是单用户、局部用户还是全量用户。
- 然后检查是否存在可用替代路径，记录替代路径的适用对象和操作代价。
- 最后检查是否只影响体验、文案或非关键路径，落入轻微或建议。
定级理由可以用固定句式填写：“影响【范围】用户的【功能】，【是否存在】替代路径，【数据/安全风险描述】，因此定为【等级】；未定为【相邻更高等级】的原因是【缺少的条件】。”这个句式强迫填写人同时说明升级和降级的依据，评审时更容易发现遗漏。
测试与研发共同评审可以落到一个轻量动作：测试提交初判等级和理由，研发在约定时间内复核影响范围与技术原因，分歧记录写在同一条缺陷记录里，约定补充信息的时限和复核人。评审的目标是让等级有共同依据，避免把定级变成单方决定。在缺陷工作项上记录严重程度、判定理由和复核记录，可以让后续统计和复盘直接使用这些字段。ONES Project 适配缺陷管理等场景，支持缺陷跟踪管理并可统计缺陷状态分布；与 TestCase 数据互通，可一键提交 Bug 至对应的项目或迭代中。团队可以把分级字段、判定理由和复核记录放在同一条缺陷工作项里，让测试提交、研发复核和后续查询围绕同一份记录进行。
适用边界：分级示例不覆盖哪些判断
严重程度分级只回答影响程度，不决定处理归属和排队顺序。缺陷由哪个模块负责人处理、是否需要跨团队协作、先修哪一条，属于缺陷分诊与责任分配的范畴；工单多久响应、多久解决，属于优先级与 SLA 管理的范畴。把严重程度直接当成排期依据，容易让多个同级缺陷争抢同一资源，也容易忽略紧急但影响有限的问题。
工单紧急性与缺陷严重程度是两个维度。面向外部用户的工单可以用优先级评估紧急事件，缺陷严重程度则描述技术影响。两者可以关联，但不能互相替代。ONES Desk 可评估和定义工单优先级，优先解决紧急事件，并支持工单一键关联到 ONES Project 的需求或缺陷工作项，持续跟踪直至处理完成；这种关联适合需要把用户反馈与技术缺陷对应起来的场景，分级结论仍应回到缺陷记录本身。
等级需要随信息更新复核。示例中的“严重”建立在未确认资金损失、替代路径可用的前提上；一旦补充日志确认重复扣款，或发现替代渠道同样失败，就应重新定级并更新判定理由。复核条件可以提前写进记录：出现资金损失、影响范围扩大到全量、替代路径失效、修复方案变更时，由原定级人发起复核。示例中的假设条件变化时，按同样的判断顺序重新走一遍，而不是在原有等级上做局部修补。
常见问题
五级体系和四级体系该怎么选？
四级体系通常把“轻微”和“建议”合并，适合缺陷量不大、团队希望减少定级争议的场景；五级体系保留更细的体验类区分，适合有专门体验或文案评审流程的团队。级数本身不决定质量，关键是每一级都有可观察的判断条件，相邻等级能用一句话说清区别。若团队经常在“轻微”和“建议”之间反复讨论，合并这两级往往更省沟通成本。
定级时测试和研发意见不一致，应该怎么处理？
把分歧写进同一条缺陷记录，而不是各自口头保留。测试提交初判等级和理由，研发在约定时间内复核影响范围与技术原因；双方对照固定的判断顺序逐项确认，记录初判、复核意见和最终共识。示例中测试初判致命，研发复核后指出影响集中在单一渠道、未发现扣款成功、用户可切换渠道，双方据此一致同意定为严重，并约定补充日志后再复核一次。约定补充信息的时限和复核人，可以让分歧有明确的收口方式。
缺陷定级后，什么情况下需要重新复核？
等级建立在当时掌握的信息上，信息变化就应复核。可以提前把复核条件写进记录：出现资金损失或数据损坏、影响范围扩大到全量用户、替代路径失效、修复方案发生变更时，由原定级人发起复核。示例中的“严重”以未确认资金损失、替代路径可用为前提；一旦补充日志确认重复扣款，或发现其他支付渠道同样失败，就应按同样的判断顺序重新走一遍，而不是在原有等级上做局部修补。
严重程度高是否意味着应该优先修复？
严重程度描述技术影响，修复顺序还取决于业务节奏、资源占用和外部承诺。缺陷由谁处理、先修哪一条，属于缺陷分诊与责任分配的范畴；工单多久响应、多久解决，属于优先级与 SLA 管理的范畴。把严重程度直接当成排期依据，容易让多个同级缺陷争抢同一资源，也容易忽略紧急但影响有限的问题。较稳妥的做法是分级结论与分诊结论分开记录，再在排期时综合判断。
在缺陷工作项上记录分级结果，有什么实际作用？
把严重程度、判定理由和复核记录放在同一条缺陷工作项里，测试提交、研发复核和后续查询围绕同一份记录进行，复盘时可以直接看到定级依据的变化。ONES Project 适配缺陷管理等场景，支持缺陷跟踪管理并可统计缺陷状态分布；与 TestCase 数据互通，可一键提交 Bug 至对应的项目或迭代中。团队可以据此把分级字段和判定理由纳入日常缺陷记录。
