同一缺陷同时影响多个客户时，严重程度容易在两个方向上失真：按客户数量累加，等级被迅速抬高；被投诉最强烈的单个客户牵着走，又会让其他受影响客户的情况被忽略。更稳妥的做法是把缺陷本身的技术后果与客户影响分开记录，先定基础严重程度，再用客户范围、业务关键性和影响方式做修正，取修正后的最高档作为对外等级，并留下可复核的依据。
要点总览（TL;DR）
- 先按缺陷本身的技术后果（功能失效、数据风险、可用性后果）定基础严重程度，再用客户影响做修正，两步分开记录、合并定级。
- 客户影响用三个字段量化：受影响客户范围、客户业务关键性、影响方式；合成时影响方式定上限、业务关键性决定是否触及上限、客户范围定下限。
- 合并规则取修正后的最高档，不按客户数量相加，避免等级随客户名单变长而虚高。
- 定级依据要写清基础判断、客户清单来源、修正过程和复核人，等级变更保留原等级、新等级、原因、时间与操作人。
- 达到团队设定的高等级阈值时触发复核，复核不通过退回补充证据。
先定基础严重程度，再叠加客户影响
两步定级的第一步只看缺陷本身：它造成了什么技术后果。判断依据包括功能是否失效、失效范围多大、是否涉及数据错误或数据丢失风险、是否影响系统可用性、是否存在绕过路径。这一步不引入客户信息，目的是让同一个缺陷在不同人手里得到一致的技术判断。
第二步才引入客户影响。客户影响是修正项，作用是在基础等级上做上调或维持，不能替代基础判断。一个只影响单个客户、但造成核心交易数据错误的缺陷，基础等级可能已经不低；一个影响多个客户、但只是展示样式异常的缺陷，基础等级仍然较低，客户范围只能做有限上调。
两步的顺序不能颠倒。先看客户再看技术，容易把商务压力带进技术判断；先看技术再看客户，才能保证定级有稳定的锚点。合并规则建议采用“取修正后最高档”：基础等级经过客户影响修正后，若多个客户组合指向不同档位，取其中最高的一档作为对外定级，而不是把各客户的影响分值相加。
取最高档的理由在于对外定级要覆盖最不利的影响情形。相加会让等级随客户数量线性膨胀，几个轻度受影响的客户叠加后可能超过一个重度受影响客户，这与实际风险不符。取最高档既保证最严重情形被覆盖，也让等级不会因客户名单变长而虚高。
客户影响怎么量化：范围、关键性、影响方式三个字段
要让不同评估人对同一缺陷得出接近的结论，客户影响需要落成可填写的字段。建议使用三个字段：受影响客户范围、客户业务关键性、影响方式。每个字段给出固定取值，评估时逐项选择，再按规则合成影响修正档。
| 字段 | 取值 | 判定口径 |
|---|---|---|
| 受影响客户范围 | 单客户 / 多客户 / 全量 | 单客户指仅一个客户可复现；多客户指两个及以上但未覆盖全部在用客户；全量指所有在用客户或主要客户群均受影响 |
| 客户业务关键性 | 核心交易 / 内部效率 / 展示类 | 核心交易指直接影响客户对外经营或收入链路；内部效率指影响客户内部作业效率；展示类指仅影响信息呈现，不阻断业务动作 |
| 影响方式 | 阻断 / 降级 / 数据错误 / 体验问题 | 阻断指业务无法继续；降级指可继续但需绕行或性能明显下降；数据错误指结果不正确或存在数据风险；体验问题指操作不便但不影响结果 |
三个字段合成影响修正档时，先看影响方式确定修正力度：阻断和数据错误修正力度最高，降级次之，体验问题最低。再用客户业务关键性调整：核心交易客户遇到阻断或数据错误，修正到最高档；内部效率客户遇到同类问题，修正到次高档；展示类客户一般只做一档上调。最后用受影响客户范围确认覆盖程度：全量客户受影响时，修正档不低于多客户情形；多客户情形不低于单客户情形。
这套合成规则的关键是让字段之间形成约束，而不是各自打分再求和。影响方式决定上限，业务关键性决定是否触及上限，客户范围决定下限。评估人只需按顺序判断，就能得到相对稳定的修正档，也便于第三方按同样字段复算。
定级操作步骤：从缺陷记录到最终等级
把框架落到日常操作，可以拆成五个动作。每个动作都应有明确的输入、做法、输出和完成标志，避免定级停留在口头讨论。
- 录入缺陷时先填基础严重程度。输入是缺陷现象、复现步骤和初步技术分析；做法是依据功能失效、数据风险、可用性后果选择基础等级；输出是缺陷记录中的基础严重程度字段；完成标志是该字段已填写且附有一句判断理由。
- 收集受影响客户清单与影响方式证据。输入是客户反馈、支持工单、监控告警或测试复现结果；做法是逐客户记录影响方式和可复现证据；输出是受影响客户清单；完成标志是清单中每个客户都有影响方式说明，无法确认的标注为待确认。
- 按字段表计算影响修正档。输入是客户清单和三个字段的取值；做法是按影响方式、业务关键性、客户范围的顺序合成修正档；输出是影响修正档及计算说明；完成标志是修正档可以由他人按字段表复算得出。
- 合并得出最终等级并写入定级依据。输入是基础严重程度和影响修正档；做法是按取最高档规则合并；输出是最终等级和定级依据段落；完成标志是依据中同时包含基础判断、客户清单来源、修正过程和复核人。
- 触发高等级复核与升级。输入是最终等级；做法是达到团队设定的高等级阈值时提交复核，复核不通过则退回补充证据；输出是复核结论；完成标志是复核意见已记录，等级变更附有原因和时间。
这五步中，第二和第三步最容易出现口径分歧。建议在缺陷记录中固定保留“受影响客户清单”和“影响方式证据”两个区域，让支持人员和测试人员填写同一份信息，减少反复确认。
在工具承载上，缺陷工作项可以把基础严重程度、受影响客户范围、业务关键性、影响方式作为记录字段，把复核结论和等级变更写入处理记录。ONES Project 适配缺陷管理等场景，支持缺陷跟踪管理和缺陷状态分布统计；ONES TestCase 支持未通过用例快速创建缺陷任务，使缺陷在测试与研发团队间流转。团队可据此把定级字段与复核记录放在同一条缺陷记录中，便于后续按状态和分布做质量复盘。
角色分工与交付物
定级不依赖某一个人的判断，而是由几个角色分别提供输入并互相校验。职责划分清楚，定级依据才完整。
| 角色 | 主要职责 | 交付物 |
|---|---|---|
| 缺陷提交人 | 填写缺陷现象、复现步骤和初步基础严重程度 | 缺陷记录及基础等级初判 |
| 测试或质量负责人 | 确认基础严重程度，校验影响方式证据，计算影响修正档 | 基础等级确认意见、影响修正档计算说明 |
| 客户成功或支持 | 提供受影响客户清单、客户业务关键性和影响方式的一手信息 | 受影响客户清单及来源说明 |
| 研发负责人 | 复核技术判断，确认高等级缺陷的定级结论 | 复核意见与最终等级确认 |
定级依据字段建议由测试或质量负责人汇总填写，客户影响信息由客户成功或支持确认来源，最终等级由研发负责人复核。客户影响信息的来源要写清楚，例如来自哪个工单、哪次客户沟通或哪份监控记录，避免出现“听说有客户受影响”这类无法追溯的描述。
等级发生变更时，记录中应保留原等级、新等级、变更原因、变更时间和操作人。变更留痕既服务于复核，也方便后续复盘定级口径是否需要调整。
示例：一个缺陷影响三类客户时的定级过程
以下为演示情景，用于说明字段填写与合并规则，不代表真实客户情况。
某缺陷导致报表导出功能在特定条件下返回错误数据。技术判断：功能可用但结果不正确，存在数据错误风险，基础严重程度定为“高”。
受影响客户清单包含三类：A 客户为金融机构，报表用于对外报送，属于核心交易类，影响方式为数据错误；B 客户为内部管理团队，报表用于内部效率分析，影响方式为数据错误；C 客户仅将报表用于展示，影响方式为体验问题。
| 客户 | 业务关键性 | 影响方式 | 修正判断 |
|---|---|---|---|
| A | 核心交易 | 数据错误 | 修正到最高档 |
| B | 内部效率 | 数据错误 | 修正到次高档 |
| C | 展示类 | 体验问题 | 上调一档 |
客户范围为多客户。按合成规则，影响方式中数据错误修正力度最高，A 客户属于核心交易，修正档达到最高档；B、C 客户的修正档低于 A。取修正后最高档，最终对外等级维持“高”，定级依据中写明 A 客户的核心交易属性和数据错误证据。
若后续确认该缺陷对所有在用客户均生效，客户范围从多客户变为全量。全量情形下修正档不低于多客户情形，最终等级仍为“高”，但定级依据需要更新客户范围字段和清单来源。若同时发现某客户因该错误数据已完成对外报送，影响方式证据增强，复核时应重新确认是否需要上调等级。
完成检查：定级结果是否可复核
一次定级完成后，可以用以下清单逐项核对。任何一项不满足，都说明定级依据还不够扎实。
- 基础严重程度与客户影响是否分开记录，基础判断是否附有技术理由。
- 受影响客户清单是否有明确来源，每个客户的影响方式是否有证据支撑。
- 三个客户影响字段的取值是否符合字段表口径，修正档是否可由他人按规则复算。
- 最终等级是否与合并规则一致，是否存在按客户数量相加或按单一客户情绪定级的情况。
- 定级依据是否包含基础判断、客户清单、修正过程、复核人，第三方能否据此独立复核。
- 等级变更是否记录了原等级、新等级、原因、时间和操作人。
这份清单既可以作为提交复核前的自检，也可以作为质量复盘时的抽查标准。定级口径稳定后，同一缺陷在不同客户组合下的等级差异会变得可解释，对外沟通和内部排期也更容易对齐。
常见问题
基础严重程度和客户影响修正档出现冲突时，以哪个为准？
以合并后的结果为准，但两个记录都要保留。基础严重程度只反映技术后果，客户影响修正档只反映影响面，二者是叠加关系。合并时按取修正后最高档的规则得出对外等级，定级依据中同时写明基础判断理由和修正过程，第三方可以分别核对这两部分。
受影响客户清单里有些客户暂时无法确认是否受影响，定级时怎么处理？
在清单中把这类客户标注为待确认，并写明待确认的原因和确认责任人。定级可以先按已确认客户计算修正档，同时在依据中注明存在待确认项。待确认项确认后若改变了客户范围或影响方式，按等级变更流程处理，记录原等级、新等级、原因和时间。
客户范围从多客户扩大到全量，等级一定要上调吗？
不一定。合成规则要求全量情形下修正档不低于多客户情形，这保证的是下限，不是强制上调。如果多客户情形下修正档已经达到最高档，全量确认后等级维持不变，但客户范围字段和清单来源需要更新。是否上调取决于影响方式和业务关键性是否同时发生变化。
定级字段和复核记录放在哪里，才能让第三方独立复核？
建议把基础严重程度、受影响客户范围、业务关键性、影响方式作为缺陷记录的固定字段，把复核结论和等级变更写入处理记录，使字段与留痕在同一条缺陷记录中。ONES Project 适配缺陷管理等场景，支持缺陷跟踪管理和缺陷状态分布统计；ONES TestCase 支持未通过用例快速创建缺陷任务，使缺陷在测试与研发团队间流转。团队可据此把定级信息集中在一处，便于按状态和分布做质量复盘。
这套定级方法适用于哪些缺陷，工单类的客户反馈要不要也走一遍？
方法适用于进入缺陷跟踪流程、需要给出严重程度等级的问题。工单的紧急程度和响应时限属于另一套判断，按工单优先级与 SLA 管理处理，不并入缺陷严重程度。同一问题如果既有工单又有缺陷记录，两边可以共享受影响客户信息，但等级口径各自独立。
