缺陷严重程度的分级要稳定可复用，需要把主观印象换成可观察的事实。本文按“业务影响范围、功能可用性、数据与安全后果、可恢复性”四个维度建立统一口径，用进入条件与排除条件写清四级边界，再用三条硬边界处理相邻等级的冲突，并给出角色分工、判定记录与验收清单。
要点总览（TL;DR）
- 严重程度判定先统一四个事实维度：业务影响范围、功能可用性、数据与安全后果、可恢复性，维度取值以复现结果为准。
- 四级边界用进入条件加排除条件成对描述：致命/严重对应核心流程完全阻断或已发生数据损坏、泄露且无替代路径；高对应核心功能部分不可用或结果错误、可绕行但影响面广；中对应非核心功能异常或体验偏差；低对应不影响业务结果的展示类问题。
- 相邻等级冲突时按三条硬边界裁定：是否阻断核心流程、是否造成数据损坏或权限越界、是否存在可用替代路径；多条件命中取最高等级。
- 证据不足的缺陷登记为待定，由缺陷评审会在固定时点裁定，记录等级、命中维度、裁定人、裁定时间与理由。
- 规则发布前逐项核对进入与排除条件是否可观察，并通过抽样复核验证判定结论与规则一致。
先定维度：严重程度按什么事实判定
判定严重程度时，先收集四个维度的事实取值，再对照等级条件得出结论。维度本身不直接等于等级，它提供的是判定输入：同一个维度取值在不同业务场景下可能对应不同等级，因此需要先把取值口径统一，避免不同人凭印象给级。
四个维度的取值说明如下，团队可在此基础上按自身业务补充示例，但取值口径应保持一致。
| 维度 | 取值说明 | 判定时的关注点 |
|---|---|---|
| 业务影响范围 | 单用户、单模块、多模块、全系统 | 受影响的是个别账号、一个功能模块，还是跨模块甚至全部用户 |
| 功能可用性 | 完全不可用、部分可用、可用但有偏差 | 功能能否完成预期操作，结果是正确、错误还是缺失 |
| 数据与安全后果 | 数据丢失、数据损坏、越权访问、信息泄露、无异常 | 是否产生不可逆的数据后果或权限越界 |
| 可恢复性 | 有替代路径、可自愈、需人工修复、无法恢复 | 用户能否绕行完成业务，修复是否需要人工介入及成本 |
填写时以复现结果为准，不以推测为准。例如“可能导致数据丢失”属于风险描述，应记录为待验证；只有实际观察到数据丢失或损坏，才在“数据与安全后果”维度取对应值。维度取值记录完整，后续等级判定和争议复核才有共同依据。
四级判定边界：每级写清进入条件与退出条件
四级划分采用致命/严重、高、中、低四档。每一档同时写进入条件与排除条件，排除条件用于回答“什么情况下不进入该级”，这是相邻等级之间最容易被忽略的部分。
致命/严重
进入条件：核心业务流程完全阻断，用户无法通过任何路径完成该业务；或已发生数据丢失、数据损坏、权限越界、信息泄露；且不存在可用的替代路径，需要人工修复才能恢复。
排除条件：核心流程仍可通过其他入口或临时操作完成；数据后果仅为展示异常而未影响存储与权限；问题可自愈或刷新后恢复。命中任一排除条件时，应下调至高或中等级别。
高
进入条件：核心功能部分不可用或输出结果错误，影响面覆盖多模块或多类用户；存在临时绕行路径，但绕行成本高、需要额外操作或依赖人工介入；不涉及数据损坏与权限越界。
排除条件：问题仅影响非核心功能；主流程可正常完成且结果正确；影响范围限于单用户或单模块且可快速自愈。满足排除条件时归入中或低。
中
进入条件：非核心功能异常，或核心功能存在体验偏差但业务结果正确；主流程可正常完成，用户有明确的替代操作；不涉及数据与安全后果。
排除条件：问题导致核心流程无法完成或结果错误；问题仅为文案、样式、提示类偏差且不影响任何业务判断。前者上调，后者下调。
低
进入条件：文案错别字、样式错位、提示语不准确等展示类问题，不影响业务结果，不改变用户操作路径，不涉及数据与安全。
排除条件：提示错误会引导用户执行错误操作，或文案缺失导致关键信息无法理解。此类问题应上调至中，因为它已经影响用户判断。
四级判定卡建议固化为一张对照表随缺陷模板发布，提交人与初判人使用同一版本，减少口径漂移。
边界冲突怎么裁：三条硬边界与仲裁规则
同一缺陷同时命中两个等级的条件时，按三条硬边界依次判断，再套用取高规则。
- 硬边界一：是否阻断核心业务流程。阻断即进入致命/严重区间；可绕行但绕行成本明显，进入高区间。
- 硬边界二：是否造成数据损坏、丢失或权限越界。已发生即至少为致命/严重；仅有风险而未发生，记录为待验证，不直接升级。
- 硬边界三：是否存在可用的替代操作路径。存在明确替代路径时，等级不高于高；替代路径需要人工介入或跨系统操作时，仍按高处理。
多条件命中时取最高等级，这是为了避免严重问题被低等级条件稀释。证据不足、无法确认是否命中的，先登记为“待定”，不强行给级。待定缺陷进入缺陷评审会，在固定时点集中裁定，例如每日或每个迭代固定一次评审窗口；参与角色包括测试负责人、模块负责人和产品负责人，裁定结论记录等级、命中维度、裁定理由、裁定人与裁定时间。裁定后缺陷状态从待定转为正式等级，后续如出现新证据可发起复评。
角色分工与判定记录
分级能否执行，取决于每个角色知道自己交付什么。建议按下表分工。
| 角色 | 职责 | 交付物 |
|---|---|---|
| 提交人 | 填写复现步骤、实际结果与预期结果、影响范围，给出初步等级 | 缺陷单及初步判定依据 |
| 测试或模块负责人 | 按判定卡初判，标注命中的硬边界与维度取值 | 初判等级与命中维度记录 |
| 缺陷评审会 | 裁定待定项与争议项，确认最终等级 | 裁定结论与理由 |
判定字段至少包含：严重程度等级、命中维度、命中的硬边界、裁定人、裁定时间、裁定理由。字段随缺陷单一起留存，抽样复核时可直接对照规则检查结论是否一致。在工具承载上，ONES 测试管理支持未通过用例快速创建缺陷任务，缺陷任务可在测试与研发团队间流转，并支持项目缺陷分布统计；等级、命中维度与裁定记录可作为缺陷单的固定字段随任务流转，评审结论与缺陷状态在同一处留痕，便于后续复核。缺陷字段的自定义范围与待定状态的具体配置方式，建议在选型或实施时向厂商确认。
示例：三个典型缺陷的边界判定
以下示例用于演示从维度取值推导等级的过程，场景为演示设定，实际判定以复现结果为准。
示例一：支付流程提交订单后报错且无替代路径
维度取值：业务影响范围为全系统下单用户；功能可用性为完全不可用；数据与安全后果为订单未生成、无数据损坏；可恢复性为无替代路径，需人工修复。命中硬边界一（阻断核心流程）与硬边界三（无替代路径）。结论：致命/严重。
示例二：列表页偶发加载失败、刷新可恢复
维度取值：业务影响范围为单模块部分用户；功能可用性为部分可用，刷新后恢复；数据与安全后果为无异常；可恢复性为可自愈且有替代操作。未命中硬边界一与硬边界二，硬边界三显示存在可用替代路径。结论：中。若该列表页属于核心业务流程且失败频率高、影响多模块，则应上调至高。
示例三：提示文案错别字
维度取值：业务影响范围为单页面展示；功能可用性为可用，结果正确；数据与安全后果为无；可恢复性为不影响操作。三条硬边界均未命中。结论：低。若该文案属于关键操作确认提示且错误表述会误导用户，则上调至中。
完成检查：判定边界是否可用的验收项
规则发布前，用以下清单逐项核对，确认分级规则可以落地执行。
- 每个等级都有可观察的进入条件与排除条件，条件描述不含“严重”“明显”等无法复核的形容词。
- 相邻等级之间至少存在一条硬边界，且硬边界的判断依据可以从复现记录中直接取得。
- 待定缺陷有明确的裁定时点、参与角色与责任人，裁定记录包含理由与时间。
- 抽样复核：随机抽取一批已判级缺陷，由未参与初判的人员按规则重新判定，结论与记录一致或差异有明确解释。
- 规则变更保留版本记录，注明变更内容、生效时间，并通知提交人、初判人与评审会成员。
抽样复核建议在每个迭代或每月固定执行一次，差异项作为规则修订的输入。规则版本与缺陷判定记录分开保存，便于回溯某次判定当时适用的是哪一版口径。
常见问题
缺陷严重程度和缺陷优先级是一回事吗？
两者回答的问题不同。严重程度描述缺陷对业务造成的实际影响，依据业务影响范围、功能可用性、数据与安全后果、可恢复性四个维度判定；优先级描述修复顺序，需要结合严重程度、影响用户数量、发布节奏和资源情况综合决定。一个严重程度为高的缺陷，如果只影响少量内部用户且当前版本不涉及该功能，优先级可能排在严重程度为中但影响全部用户的问题之后。本文只讨论严重程度各等级的判定边界，修复排队与响应时限属于另外的管理环节。
缺陷在提交时无法确认是否造成数据损坏，应该怎么定级？
先按已观察到的事实定级，把数据后果记录为待验证，不因存在风险就直接升级。如果核心流程可正常完成、存在替代路径，可先按高或中登记，并在缺陷单中注明需要验证的数据影响点。验证后确认已发生数据损坏、丢失或权限越界的，按硬边界二升级至致命/严重并记录复评理由。这样处理既避免风险描述被当成事实，也保证后续证据出现时有明确的升级路径。
不同团队对同一个缺陷给出不同等级，评审会应该按什么原则裁定？
裁定以判定卡和复现记录为依据，不以职位高低或主观感受为依据。评审时先核对四个维度的取值是否有复现证据，再检查命中的硬边界，多条件命中时取最高等级。裁定结论要写明等级、命中维度、裁定理由、裁定人与裁定时间。如果争议源于判定卡本身描述模糊，应把该条作为规则修订项记录，在下一版判定卡中补充可观察的条件，而不是每次评审临时解释。
判定卡发布后，如何发现规则在实际使用中已经走样？
用抽样复核来发现。每个迭代或每月固定抽取一批已判级缺陷，由未参与初判的人员按当前版本判定卡重新判定，对比结论是否一致。差异集中在某一等级或某一维度时，说明该处条件描述需要细化；差异分散则可能是判定卡未随缺陷模板同步发布。复核结果作为规则修订输入，修订后保留版本记录并通知提交人、初判人与评审会成员，确保大家使用的是同一版口径。
在缺陷管理工具中承载分级规则时，需要关注哪些配置点？
关注三处：严重程度字段的枚举值是否与判定卡的四级一致；命中维度、裁定人、裁定时间、裁定理由等记录字段能否随缺陷单留存；待定状态与评审裁定结果能否在同一处留痕并支持后续查询。ONES 测试管理支持未通过用例快速创建缺陷任务，缺陷任务可在测试与研发团队间流转，并支持项目缺陷分布统计，等级与裁定记录可作为缺陷单字段随任务流转。缺陷字段的自定义范围与待定状态的具体配置方式，建议在选型或实施时向厂商确认。
