缺陷严重程度和缺陷优先级分别回答两个不同问题：前者看缺陷造成的影响有多大，后者看团队打算多快处理它。两者依据不同、判断角色不同，也允许出现“严重程度高但优先级不高”的情况。理解这层区别，才能让缺陷记录里的两个字段各自发挥作用，而不是把等级简单等同。
要点总览（TL;DR）
- 缺陷严重程度回答“影响有多大”，依据功能受损程度、数据风险和受影响用户范围，由测试人员或业务方偏事实判断。
- 缺陷优先级回答“多快处理”，综合影响、发生频率、发布节点和绕行方案，由产品负责人、开发负责人或评审会决定。
- 两者允许不一致：存在稳定绕行方案的高严重程度缺陷，优先级可以排在阻断主流程的中等严重程度缺陷之后。
- 填写时两个字段各自独立，严重程度写明受损功能与影响范围，优先级写明排期理由和调整触发条件。
- 小团队可简化等级档位但保留两个字段；对外交付型产品侧重严重程度，快速迭代场景更频繁调整优先级。
两个概念各自回答什么问题
严重程度描述缺陷本身的技术后果，回答“影响有多大”。判断时看功能受损到什么程度、是否涉及数据错误或丢失风险、影响多少用户和使用场景。例如支付金额计算错误、核心数据被覆盖，属于影响面大的缺陷；某个设置页在极端分辨率下文字重叠，影响面就小得多。严重程度尽量依据可观察的事实判断，减少对排期的考虑。
优先级描述团队的处理顺序，回答“多快处理”。它综合影响程度、发生频率、影响用户范围、当前发布节点、是否存在临时绕行方案等因素。一个缺陷可能影响不小，但已有稳定替代操作，且当前版本发布在即，团队会选择先处理阻断主流程的问题，把它排后。
两个判断通常由不同角色在不同时点完成。严重程度多由发现缺陷的测试人员或提出问题的业务方给出，偏重事实描述；优先级多由产品负责人、开发负责人或缺陷评审会在排期时确定，偏重资源与节奏。测试人员可以坚持严重程度的判断，同时接受优先级被调整，这两件事并不冲突。
同口径差异对照：判断依据、责任人与变化节奏
把两个概念放在同一组维度下对照，差异来源会更清楚。下表按回答的问题、判断依据、判定责任人、变化节奏和常见等级划分逐项比较。
| 对照维度 | 缺陷严重程度 | 缺陷优先级 |
|---|---|---|
| 回答的问题 | 影响有多大 | 多快处理 |
| 判断依据 | 功能受损程度、数据风险、受影响用户与场景范围 | 影响程度、发生频率、影响范围、发布节点、绕行方案、修复成本 |
| 判定责任人 | 测试人员、提出缺陷的业务方，偏事实判断 | 产品负责人、开发负责人或缺陷评审会，偏排期决策 |
| 变化节奏 | 相对稳定，缺陷修复或影响条件变化时才调整 | 随发布计划、资源情况和绕行方案出现而频繁调整 |
| 常见等级划分 | 致命、严重、一般、轻微，或按高、中、低分档 | 紧急、高、中、低，或按处理时限分档 |
等级名称各团队可以自定，关键是两套等级描述的对象不同：严重程度等级描述后果，优先级等级描述处理次序。若两个字段使用同一套名称和同一套判断标准，字段就失去区分意义，评审时也容易把“影响大”直接当成“马上做”。
为什么高严重程度不等于高优先级
严重程度高而优先级可以下调，最常见的情形是存在稳定绕行方案。例如导出报表功能在特定筛选条件下报错，严重程度可判为高，因为功能确实不可用；但如果用户可以先取消筛选再导出，结果正确且操作只多一步，团队就可能先处理其他问题，把修复排到下一个迭代。影响大是事实，处理可以稍后也是事实。
低频边缘场景与高频主流程的取舍是另一类情形。某个缺陷会导致页面崩溃，但只发生在极少使用的旧版浏览器上；另一个缺陷只是提示文案错误，却出现在每天被大量用户看到的主流程页面。前者严重程度更高，后者优先级可能更高，因为发生频率和用户触达范围直接影响业务损失。
数据安全类缺陷需要单独对待。涉及越权访问、敏感数据泄露、数据被错误覆盖且难以恢复的缺陷，即使触发条件苛刻、暂时没有观察到实际发生，也通常按高严重程度处理，并在优先级上从紧安排。这类缺陷的后果不可逆，绕行方案往往不能真正消除风险，判断时应把潜在损失纳入考量，必要时走安全问题的专门流程。
两个字段不一致本身说明判断在起作用，并不代表谁填错了。真正需要纠正的是判断依据缺失：严重程度没有说明受损功能与影响范围，优先级没有说明排期理由。把理由写进缺陷记录，后续复盘时才能判断当时的取舍是否合理。
如何在缺陷记录中同时填写两个字段
两个字段要各自独立填写，避免用一个字段推导另一个。可以按下面的规则执行。
严重程度填写规则：
- 致命：核心功能完全不可用、数据丢失或损坏、存在安全风险，且无合理绕行方案。
- 严重：主要功能受损或结果错误，影响较多用户，绕行成本较高。
- 一般：次要功能异常或局部体验问题，有可接受的替代操作。
- 轻微：文案、样式、提示类问题，不影响任务完成。
填写时写明受损的功能、触发条件和影响范围，让等级有据可查。等级描述应保持稳定，同一类后果在不同缺陷上判出同一等级。
优先级填写规则：
- 紧急：阻断当前发布或主流程，需立即安排处理。
- 高：本迭代内处理，影响关键用户或关键节点。
- 中：排入近期迭代，按正常节奏修复。
- 低：进入待办池，结合版本规划统一处理。
优先级需要写明调整触发条件，例如“发布前阻断项升为紧急”“绕行方案失效时上调”“连续多个版本未处理则重新评估”。这样优先级的变化有依据，不依赖个人记忆。
字段联动与评审机制方面，可以约定：严重程度为致命或严重的缺陷进入定期评审，由产品与开发共同确认优先级；优先级被下调时，在记录中补充绕行方案和复查时间；发布前对未关闭的高严重程度缺陷做一次集中核对。评审关注的是判断理由是否完整，避免逐条重新定级。
一个完整填写示例：缺陷标题“订单列表按金额排序后导出 Excel 报错”。严重程度填“严重”，说明主要功能导出不可用、影响使用报表的运营人员；优先级填“中”，说明用户可先取消排序再导出、结果正确，当前版本有其他阻断项，排入下个迭代修复，并注明复查时间。两个字段各自成立，接手的人也能看懂取舍。
在工具承载上，缺陷记录需要能同时保存这两个字段，并在测试与研发之间流转。ONES Project 支持缺陷跟踪管理，可一键提交 Bug 至对应项目或迭代，记录和跟踪修复情况，并统计缺陷状态分布；ONES TestCase 中未通过的用例可快速创建缺陷任务，使缺陷在测试与研发团队间流转。实际配置时，可在系统中核验缺陷工作项是否已设置严重程度与优先级两个独立字段及对应等级选项，再按上面的规则填写。
适配场景与选择建议
小团队可以简化等级数量，例如严重程度只保留高、中、低三档，优先级只保留紧急、正常、低三档，但两个字段都应保留。字段少而稳定，比等级细却无人维护更有用。简化时同步写清每档的判断标准，避免不同成员理解不一致。
对外交付型产品，例如面向客户交付的软件或系统集成项目，严重程度的权重通常更高。合同约定、验收标准和客户感知都直接对应缺陷后果，严重程度需要更严格地依据影响范围和数据风险判定，并在交付前集中核对高严重程度缺陷的处理状态。优先级仍按交付节点调整，但下调高严重程度缺陷时需要更充分的绕行说明和客户沟通记录。
快速迭代场景下，优先级的动态调整更频繁。每个迭代开始前复核一次待处理缺陷的优先级，把阻断当前迭代的项上调，把已有稳定绕行方案的项下调并设定复查时间。严重程度在这一过程中保持相对稳定，作为判断影响的基础信息，不随排期反复改动。
落地检查可以从三个动作开始：抽查近期缺陷记录，看两个字段是否都有填写理由；在迭代评审中核对高严重程度缺陷的优先级安排是否合理；在版本复盘时回看被下调优先级的缺陷是否按约定复查。若发现两个字段长期取值相同、理由栏空白，说明区分没有真正落地，需要回到等级描述和评审规则上调整。
常见问题
严重程度判为高、优先级却被下调，测试人员应该接受吗？
可以接受，前提是下调理由写清楚了。严重程度描述的是缺陷后果，测试人员依据功能受损和数据风险给出判断；优先级是排期决策，产品负责人或评审会结合绕行方案、发布节点和资源情况调整。两者职责不同，并不冲突。
需要关注的是记录里是否写明了下调依据，例如“已有稳定绕行方案，排入下个迭代，某日期前复查”。如果理由栏空白，建议在评审中要求补充，而不是直接改回优先级。
涉及数据安全的缺陷，严重程度和优先级应该怎么定？
涉及越权访问、敏感数据泄露、数据被错误覆盖且难以恢复的缺陷，通常按高严重程度处理，即使触发条件苛刻、暂时没有观察到实际发生。这类后果不可逆，绕行方案往往不能真正消除风险。
优先级上一般从紧安排，必要时走安全问题的专门流程，与常规缺陷分开跟踪。判断时把潜在损失纳入考量，并在记录中写明风险类型和影响的数据范围。
团队规模小、缺陷量不大，还需要同时维护两个字段吗？
建议保留两个字段，但可以简化等级档位。例如严重程度只保留高、中、低三档，优先级只保留紧急、正常、低三档。字段少而稳定，比等级细却无人维护更有用。
简化时同步写清每档的判断标准，避免不同成员理解不一致。两个字段长期取值相同、理由栏空白，说明区分没有真正落地，需要回到等级描述上调整。
优先级定下来之后，什么情况下应该重新评估？
常见触发条件包括：绕行方案失效或变得不可接受、缺陷升级为当前发布的阻断项、影响范围随版本扩大、连续多个版本未处理。把这些条件写进优先级字段或团队约定中，调整就有依据，不依赖个人记忆。
快速迭代场景下，可以在每个迭代开始前统一复核一次待处理缺陷的优先级，把阻断当前迭代的项上调，把已有稳定绕行方案的项下调并设定复查时间。严重程度在这一过程中保持相对稳定。
在缺陷管理工具里配置这两个字段时要注意什么？
关键是让两个字段独立存在、各自有等级选项，避免用一个字段推导另一个。配置完成后抽查近期缺陷记录，看两个字段是否都填写了理由，等级取值是否与团队约定一致。
以 ONES 为例，ONES Project 支持缺陷跟踪管理，可一键提交 Bug 至对应项目或迭代，记录和跟踪修复情况，并统计缺陷状态分布；ONES TestCase 中未通过的用例可快速创建缺陷任务，使缺陷在测试与研发团队间流转。实际配置时，可在系统中核验缺陷工作项是否已设置严重程度与优先级两个独立字段及对应等级选项，再按团队规则填写。
