缺陷严重程度分级要先把“影响”拆成可观察的判定项，再按固定档位组合成等级，并让测试与研发用同一套证据口径共同判定。可执行的做法是：定义3–5个严重程度档位，为每档写明影响范围、功能可用性、数据与业务后果、有无绕行方案四类判据；用一张判定表把判据映射到档位；规定提单人初判、研发复核、争议升级三步流程；最后用抽样复核和误判统计检验分级是否稳定。
要点总览（TL;DR）
- 缺陷严重程度通常设3–5档，从致命、严重、一般、轻微起步，需要区分体验优化时再加建议档；档位数量要与团队的复核能力匹配。
- 每档用四类判据判定：影响范围、功能可用性、数据与业务后果、有无绕行方案；多判据冲突时按后果优先、范围其次、可用性再次、绕行最后的顺序取舍。
- 判定走提单人初判、研发复核、争议裁决三步，分歧升级到测试与研发负责人共同裁决，裁决依据是判定表和已留存证据。
- 严重程度只描述影响，不描述处理顺序和紧急程度；分诊、责任分配与 SLA 分别用不同字段记录。
- 标准发布前检查档位互斥与判据可观察，运行中每月抽样复核，统计复核调整率、裁决改档率和争议判据分布来校准。
严重程度分级先定哪几个档位
缺陷严重程度通常设3–5档。档位太少，无法区分“核心功能不可用”和“界面文案错误”；档位太多，判定边界模糊，测试与研发容易在相邻档位之间反复争论。多数团队可以从四档起步：致命、严重、一般、轻微。发布节奏快、缺陷量大的团队可以保留四档，把“建议”类问题并入轻微档；需要区分体验优化与功能缺陷的团队，可以增加第五档“建议”，但要在定义中写清它和轻微档的差别。
档位数量与团队规模、发布节奏的关系体现在判定成本上。团队人数少、迭代周期短，四档足够覆盖常见争议，评审时也容易达成一致；多团队协作、对外交付或涉及资金与合规的系统，可以保留五档，但需要配套更明确的判据和复核机制。档位增加带来的收益是区分度，代价是每次判定都要多对照一层边界，因此档位数量应与团队实际能执行的复核能力匹配。
档位命名建议采用“名称+固定编号”的方式，例如S1致命、S2严重、S3一般、S4轻微。编号用于排序和统计，名称用于沟通。团队内部要避免“高”“中”“低”“紧急”“重要”等词与严重程度混用，同一含义只保留一个正式名称，历史文档中的旧称在标准发布时统一替换。
需要明确的是，严重程度只描述缺陷造成的影响，不描述处理顺序和紧急程度。一个轻微档缺陷如果卡住了即将发布的版本，它的处理顺序可以提前，但严重程度仍应如实记录为轻微。把紧急程度写进严重程度，会让统计失真，也会让研发在复核时难以判断提单人的真实依据。
| 档位名称 | 编号 | 一句话定义 | 典型例子 | 反例 |
|---|---|---|---|---|
| 致命 | S1 | 核心业务整体不可用，或造成数据错误、资金损失、合规暴露，且无可行绕行方案 | 支付主流程无法提交订单，已产生错误扣款 | 某个后台报表打不开，主流程正常 |
| 严重 | S2 | 主要功能不可用或结果明显错误，影响多个用户或关键场景，绕行成本高 | 批量导入功能对特定格式文件全部失败 | 单个用户偶发页面样式错位 |
| 一般 | S3 | 局部功能降级或结果偏差，存在可接受的替代操作，影响范围有限 | 筛选条件在部分组合下结果少一条 | 登录完全无法完成 |
| 轻微 | S4 | 不影响功能完成，仅影响体验、文案或非关键展示 | 提示语错别字、图标对齐偏差 | 提交后数据未保存 |
| 建议 | S5 | 现有功能可用，属于改进建议或体验优化，不构成功能错误 | 希望增加快捷键、调整默认排序 | 按钮点击无响应 |
每一档用什么判据判定
把严重程度落到可观察的判定项，需要四类判据：影响范围、功能可用性、数据与业务后果、绕行方案。影响范围看缺陷波及单点、单个模块还是全局；功能可用性看相关功能是完全不可用、降级可用还是正常可用；数据与业务后果看是否产生数据错误、资金损失、合规暴露或对外承诺违约；绕行方案看用户或业务方是否存在可行替代操作，以及替代操作的成本。
四类判据组合成档位时，建议按“后果优先、范围其次、可用性再次、绕行最后”的顺序取舍。出现多判据冲突时，先看是否造成数据错误、资损或合规暴露，这类后果一旦成立，通常直接进入高档位；没有此类后果，再看影响范围是否覆盖全局或关键链路；范围和可用性指向不同档位时，以更严重的可用性结论为准；绕行方案用于在相邻档位之间做最终校准，有低成本绕行可下调一档，无可行绕行则维持或上调。
| 判据组合 | 建议档位 | 需附证据 |
|---|---|---|
| 全局不可用，或已产生数据错误/资损/合规暴露，无绕行 | S1 致命 | 复现步骤、错误数据截图、影响用户范围、日志 |
| 主要功能不可用或结果明显错误，影响多个用户，绕行成本高 | S2 严重 | 复现步骤、失败截图或日志、影响模块与用户范围 |
| 局部功能降级或结果偏差，有可接受替代操作 | S3 一般 | 复现步骤、偏差前后对比、替代操作说明 |
| 功能可完成，仅体验、文案或非关键展示受影响 | S4 轻微 | 截图、所在页面与触发条件 |
| 功能正常，属于改进建议 | S5 建议 | 现状说明与期望效果 |
证据要随缺陷记录留存，至少包括复现步骤、日志或截图、影响用户范围。复现步骤写清环境、账号角色、操作路径和实际结果；日志与截图用于支撑“不可用”或“结果错误”的判断；影响用户范围可以用受影响角色、租户、地区或数据量描述。证据不足时，提单人应先补充，再提交复核，避免研发仅凭描述猜测影响。
有些情况不进入严重程度判定：需求缺失、需求理解不一致属于需求澄清；测试环境配置错误、依赖服务未启动属于环境问题；用例本身写错属于测试资产问题。这些情况应先按对应流程处理，确认构成产品缺陷后，再按判据定档。把它们标成高严重程度，会稀释分级标准的可信度。
测试与研发如何共同判定并处理分歧
分级判定采用三步：提单人初判、研发复核、争议裁决。每一步都有明确的输入、动作和输出，避免分级停留在口头讨论。
| 步骤 | 负责人 | 输入 | 动作 | 输出 |
|---|---|---|---|---|
| 初判 | 提单人（测试或发现问题的角色） | 缺陷现象、复现步骤、日志截图 | 对照判定表选择档位，填写判据依据和证据 | 带档位、判据说明和证据的缺陷记录 |
| 复核 | 研发负责人或模块负责人 | 初判记录与证据 | 确认影响范围与技术后果，同意或提出调整并写明理由 | 确认后的档位，或带调整理由的待裁决记录 |
| 裁决 | 测试负责人与研发负责人共同指定 | 双方理由与证据 | 按判定表逐项对照，形成裁决结论 | 最终档位与裁决说明，记录在缺陷中 |
分歧处理要明确升级对象和闭环时限。双方对档位有不同意见时，先由研发复核人给出调整理由，理由需要对应到具体判据，例如“影响范围仅限单个租户的导出功能，且存在手工导出替代操作”。仍不能达成一致，升级到测试负责人与研发负责人共同裁决，裁决依据是判定表和已留存证据，不引入新的口头信息。建议约定一个工作日内闭环，避免缺陷在待定档位中滞留。
分级变更要留记录。档位调整时，在缺陷中写明调整前后档位、调整人、调整理由和新增证据，保留历史记录以便追溯。这样在版本复盘时，可以回看哪些缺陷在复核阶段被调整、调整原因集中在哪类判据，为后续修订标准提供依据。
当分级判定需要在测试与研发之间流转时，承载字段和证据的工具会影响执行成本。ONES TestCase 支持未通过用例一键提 Bug，缺陷任务在测试与研发团队间流转；ONES Project 支持一键提交 Bug 至对应项目或迭代，并与 TestCase 数据互通。团队可以在缺陷工作项中记录档位、判据说明和证据附件，让初判、复核和裁决围绕同一条记录进行。具体字段配置与流转规则需在实际环境中确认。
一个完整的分级示例
以下为演示情景，用于说明判据如何组合成结论，不代表真实项目数据。
某版本测试中发现：运营人员在批量导入商品价格时，选择包含500条记录的表格，系统提示导入成功，但其中约30条价格未更新，页面仍显示旧价格。该问题在预发布环境复现，影响范围为使用批量导入的运营角色，涉及价格数据错误，手工逐条修改可以绕过。
按判定表逐项对照：数据与业务后果成立，已产生价格数据错误；影响范围限于批量导入模块，未波及下单与支付主流程；功能可用性为降级可用，单条编辑正常；存在手工逐条修改的绕行方案，但500条中约30条需要人工核对，绕行成本中等。综合判断，数据错误优先于绕行方案，档位定为S2严重，而非S1致命，因为核心交易链路未受影响且存在可行替代操作。
研发复核时提出：错误数据仅出现在特定模板格式下，使用标准模板导入正常，建议调整为S3一般。复核理由对应判据中的影响范围与绕行方案。测试方补充证据：运营当前使用的模板正是出问题的格式，且该格式由系统下载入口提供，属于默认路径。双方对照判定表后维持S2，并在缺陷中记录调整讨论过程。
| 记录字段 | 填写样例 |
|---|---|
| 缺陷标题 | 批量导入商品价格时部分记录未更新且提示成功 |
| 严重程度 | S2 严重 |
| 判据说明 | 数据后果：价格数据错误；影响范围：批量导入模块，运营角色；可用性：降级可用；绕行：可手工逐条修改，成本中等 |
| 证据 | 复现步骤、导入前后价格对比截图、导入结果日志、问题模板文件 |
| 复核结论 | 维持S2，默认模板路径下可复现，绕行成本不可忽略 |
| 变更记录 | 初判S2；复核建议S3；裁决维持S2，附讨论说明 |
分级落地后的检查与校准
标准发布前先做一轮检查，确认档位定义互斥、判据可观察、证据要求明确。可以逐条核对：相邻档位是否存在重叠描述；每条判据是否能从缺陷记录中直接看到；证据要求是否写清由谁提供、提供到什么程度；判定表是否覆盖团队常见缺陷类型；档位名称与编号是否在全团队统一。检查发现定义模糊时，先修订标准再发布，避免带着歧义进入日常判定。
运行中的校准依靠抽样复核和误判统计。建议每月抽取一定比例的已关闭缺陷，由测试与研发各一人独立按判定表重新定档，统计与原档位不一致的比例，并按判据类别归类不一致原因。误判统计口径可以包括：复核阶段被调整的缺陷占比、裁决阶段被改档的缺陷占比、同一判据反复引发争议的次数。连续出现争议的判据，说明表述需要细化，而不是继续靠个案讨论解决。
分级标准需要随业务变化维护。出现以下情况时触发修订：新增核心业务链路或对外承诺变化；资损、合规相关判据的适用范围调整；连续两个校准周期某档位误判率偏高；团队发布节奏或协作方式发生明显变化。修订后保留版本记录，并对测试与研发同步一次判定表示例。
最后要划清边界：严重程度描述影响，缺陷分诊与责任分配决定由谁处理、按什么顺序处理，工单优先级与 SLA 管理约定时限和响应要求。三者使用不同字段和不同决策依据，可以在同一条缺陷记录中并存，但不应互相替代。把严重程度直接当作排期依据，会让高档位缺陷堆积，也会让轻微但紧急的问题失去表达渠道。
- 上线前检查：档位定义互斥、判据可观察、证据要求明确、判定表覆盖常见缺陷类型、命名与编号统一。
- 运行中校准：每月抽样复核，统计复核调整率、裁决改档率和争议判据分布。
- 维护触发：业务链路变化、合规要求调整、连续误判偏高、发布节奏变化时修订标准。
- 边界确认：严重程度、分诊与责任分配、优先级与 SLA 分别记录，不混用同一字段。
常见问题
缺陷严重程度和缺陷优先级有什么区别，能不能只用一个字段？
两者描述的内容不同。严重程度描述缺陷造成的影响，依据是影响范围、功能可用性、数据与业务后果和绕行方案；优先级描述处理顺序和时限要求，依据是版本节点、业务窗口和资源安排。同一条缺陷可以严重程度低但优先级高，例如轻微档的文案错误恰好出现在对外发布页面上。
建议分开记录。合并成一个字段，统计时会失真，研发复核时也难以判断提单人依据的是影响还是排期压力。处理归属与排队规则属于缺陷分诊与责任分配，时限约定属于工单优先级与 SLA 管理，本文只讨论严重程度这一层。
团队规模小、缺陷量不大，是否也需要四档分级？
可以简化，但至少要保留能区分“功能不可用”和“体验问题”的档位。两档分级在缺陷量少时执行成本低，代价是相邻争议会集中到同一条边界上，复核时缺少中间档位做缓冲。
更稳妥的做法是先按四档定义，实际使用时允许部分档位长期为空。档位定义完整、判据写清，后续业务增长时不必推翻重来；档位数量真正要匹配的是团队能否执行复核，而不是缺陷总量。
提单人证据不足时，研发应该直接改档还是退回补充？
建议退回补充，而不是直接改档。证据不足意味着判据无法对照，此时改档只是换一个主观判断，争议会留到下一次。
可以约定最低证据要求：复现步骤、日志或截图、影响用户范围。提单人补齐后再进入复核；如果确实无法复现，按“无法复现”单独处理，不占用严重程度档位。这样复核阶段的调整理由才能对应到具体判据，而不是停留在感觉上。
分级标准多久校准一次，什么情况下要提前修订？
常规节奏可以按月抽样复核，每季度汇总一次误判统计。出现以下情况时提前修订：新增核心业务链路或对外承诺变化；资损、合规相关判据的适用范围调整；连续两个校准周期某档位误判率偏高；发布节奏或协作方式明显变化。
修订后保留版本记录，并同步一次判定表示例，让测试与研发对新边界形成一致理解。修订频率过高也会带来执行成本，建议把零散争议先归入待观察清单，积累到一定数量再统一调整。
在工具里落地分级，需要关注哪些记录字段？
至少需要三类承载：严重程度字段（含档位选项）、判据说明字段、证据附件。此外要能保留分级变更记录，写明调整前后档位、调整人、理由和新增证据，便于版本复盘时回看复核阶段的调整集中在哪类判据。
ONES TestCase 支持未通过用例一键提 Bug，缺陷任务在测试与研发团队间流转；ONES Project 支持一键提交 Bug 至对应项目或迭代，并与 TestCase 数据互通。团队可以在缺陷工作项中记录档位、判据说明和证据附件，让初判、复核和裁决围绕同一条记录进行。具体字段配置与流转规则需在实际环境中确认。
