缺陷分类要能落地，关键是把“分几层、每层怎么判、谁来填、何时复核”这四件事写清楚。做法是先确定缺陷类型、严重程度、优先级和来源模块四个维度，再为每个取值写出可对照的判定条件，规定提交人初判、测试负责人复核、开发确认的分工，最后用抽样一致性和统计异常检验分类是否稳定。严重程度与优先级需要分开定义，前者描述影响，后者决定排期。
要点总览（TL;DR）
- 缺陷分类先定四个维度：缺陷类型、严重程度、优先级、来源模块，维度够用、互斥、可统计即可，不必求多。
- 严重程度描述缺陷对系统与用户的实际影响，优先级决定修复排期，两者分开判定，避免把“来不及修”写成“影响不严重”。
- 每个等级要写成可对照的条件句并配典型判据和边界说明，判定顺序为先定严重程度、再定优先级。
- 流程上由提交人初判、测试负责人复核、开发确认，优先级由测试负责人与开发负责人共同确定，分类修改需留痕，争议由仲裁人裁决。
- 上线后用抽样一致性和统计异常信号校验分类体系，出现取值长期空置、判定分歧集中等情况时触发修订。
先定维度：缺陷分类要分哪几层
缺陷分类的维度不宜多，四个维度足以覆盖大多数研发团队的管理需要：缺陷类型回答“这是什么问题”，严重程度回答“影响有多大”，优先级回答“什么时候修”，来源模块回答“问题出在哪里”。维度再多，填写成本上升，不同人给出相同结论的难度也会增加。控制维度数量的原则是够用、互斥、可统计：每个维度解决一个独立问题，取值之间不重叠，且能直接用于筛选和统计。
缺陷类型按问题性质划分，常见取值包括功能缺陷、界面缺陷、性能缺陷、兼容性缺陷、数据缺陷。划分依据是缺陷表现出的主要异常特征，一条缺陷只归入一个主类型。功能缺陷指业务逻辑与预期不符；界面缺陷指展示、布局、文案错误；性能缺陷指响应时间、吞吐量、资源占用超出约定；兼容性缺陷指特定浏览器、设备、系统版本下表现异常；数据缺陷指数据错误、丢失、不一致。类型取值应结合产品形态裁剪，例如纯后端服务可以去掉界面缺陷。
严重程度与优先级是两个独立维度，判定对象不同。严重程度描述缺陷对系统功能、数据、用户的实际影响，判定时看缺陷本身造成的后果；优先级描述修复的排期与资源投入，判定时结合业务影响、发生频率、修复成本和当前迭代目标。两者不构成固定映射：一个影响很大的缺陷可能因为已有临时规避方案而排在后面，一个影响轻微的文案错误也可能因为面向重要客户而优先处理。
来源模块或引入阶段是辅助维度，用于定位问题和做质量分析。来源模块记录缺陷所属的功能模块或服务，便于分派和统计模块缺陷密度；引入阶段记录缺陷是在需求、设计、开发还是测试环节引入，用于回溯过程质量。这一维度不参与严重程度判断，只在分析和改进时使用。
| 维度 | 作用 | 建议取值数量 | 填写时点 |
|---|---|---|---|
| 缺陷类型 | 区分问题性质，支撑分类统计与专项改进 | 4–6 个 | 提交时初判，复核时确认 |
| 严重程度 | 描述缺陷对系统与用户的影响 | 4 级左右 | 提交时初判，复核时确认 |
| 优先级 | 决定修复排期与资源投入 | 3–4 级 | 复核后由测试负责人与开发共同确定 |
| 来源模块 | 定位问题位置，支撑模块质量分析 | 按产品模块设置 | 提交时选择 |
维度定义完成后，应形成一份团队共用的维度定义表，写明每个维度的作用、取值、填写时点和责任人。这张表是后续判定标准和流程分工的基础，也是新成员上手时的对照材料。
写判定标准：每个等级怎么判
判定标准的作用是让不同人面对同一条缺陷给出相同结论。写法上要把每个等级写成可对照的条件句，并配典型判据和边界说明。只写“严重”“一般”这类形容词，判定结果会随个人经验漂移。
严重程度建议分为阻断、严重、一般、轻微四级。阻断指核心业务流程无法进行、系统不可用或数据出现不可恢复的损坏，且没有规避方案；严重指主要功能失效、关键数据错误或存在明显安全风险，但有临时规避手段；一般指次要功能异常、局部展示错误或体验受损，不影响主流程；轻微指文案、样式、提示语等不影响使用的细节问题。每级判据应结合产品实际写出具体例子，例如“下单接口返回 500 且无重试成功”属于阻断，“订单列表分页在特定筛选条件下少显示一条”属于一般。
优先级建议分为紧急、高、中、低四级，定义的是响应预期而非影响程度。紧急指需要立即安排修复、暂停其他工作处理；高指在当前迭代内修复；中指排入近期迭代；低指进入待办池、按资源情况安排。优先级判定要写明响应预期的时间口径，例如“紧急：当日响应并给出处理方案”，口径由团队根据迭代节奏确定，写清楚即可执行。
判定顺序是先定严重程度，再定优先级。严重程度依据缺陷的客观影响判定，尽量不受排期压力影响；优先级在严重程度基础上，结合业务影响面、发生频率、修复成本、是否有规避方案综合确定。这样做的目的是避免把“这次来不及修”写成“影响不严重”，导致质量数据失真。
| 严重程度 | 典型判据 | 边界说明 |
|---|---|---|
| 阻断 | 核心流程不可用、系统崩溃、数据不可恢复损坏，无规避方案 | 有稳定规避方案时降为严重 |
| 严重 | 主要功能失效、关键数据错误、明显安全风险，有临时规避手段 | 影响范围限于边缘场景时降为一般 |
| 一般 | 次要功能异常、局部展示错误、体验受损，不影响主流程 | 同一问题大面积出现时上调 |
| 轻微 | 文案、样式、提示语等细节问题 | 涉及对外承诺或合规表述时上调 |
边界情形需要单独写规则。常见边界有三类：一是同一缺陷影响多个模块时，按影响最大的模块定级，不重复提交；二是缺陷在特定环境才出现时，注明环境条件，严重程度按该环境下的实际影响判定；三是缺陷由需求理解偏差引起时，先确认需求口径，再判定是缺陷还是需求变更。升级规则也要写明：当缺陷影响范围扩大、出现数据损坏或客户投诉时，允许提交人或测试负责人发起升级，升级需记录理由。
定流程：谁在什么时点填、怎么复核
分类动作要嵌入缺陷生命周期，明确每个角色的动作和时点。基本分工是：提交人做初判，填写缺陷类型、严重程度和来源模块；测试负责人复核分类，重点检查严重程度是否准确、类型是否归错；开发在确认缺陷时对严重程度提出异议或确认，优先级由测试负责人与开发负责人结合排期共同确定。
| 角色 | 动作 | 时点 | 产出 |
|---|---|---|---|
| 提交人（测试或用户支持） | 填写缺陷类型、严重程度、来源模块，描述复现步骤 | 提交缺陷时 | 初始分类字段 |
| 测试负责人 | 复核类型与严重程度，修正明显偏差，标记争议 | 提交后、进入修复前 | 复核后的分类 |
| 开发负责人 | 确认严重程度，参与确定优先级 | 缺陷受理时 | 确认或异议记录 |
| 仲裁人（测试与开发共同上级或质量负责人） | 裁决分类争议 | 争议提出后一个工作日内 | 最终分类结论 |
分类字段的修改要留痕。缺陷在修复过程中如果发现影响比初判更大，允许修改严重程度，但需记录修改人、修改时间和修改理由。优先级随排期调整是正常操作，同样记录调整依据。留痕的价值在于事后能区分“初判不准”和“情况发生变化”，为判定标准的修订提供依据。
争议缺陷的处理路径要写清楚：开发对严重程度有异议时，先在缺陷记录中说明理由，由测试负责人复核；双方仍不一致时提交仲裁人裁决，裁决结论作为最终分类，并在团队内同步判例。积累若干判例后，把共性情形补进判定标准，减少同类争议。
分类与缺陷分诊、责任分配是相邻但不同的动作。分类解决“是什么、多严重、多急”，分诊解决“派给谁、排进哪个队列”，责任分配解决“谁负责修复”。流程设计上可以让分类在分诊之前完成，分诊直接使用分类结果，但不要把分诊规则写进分类标准，否则分类字段会承担排班信息，统计时失真。
这些字段和流程需要有承载的地方。ONES Project 支持缺陷跟踪管理，可一键提交 Bug 至对应项目或迭代，并记录和跟踪修复情况；ONES TestCase 支持未通过的用例快速创建缺陷任务，使缺陷在测试与研发团队间流转。团队可以把缺陷类型、严重程度、优先级作为缺陷字段固定下来，让提交、复核、修改都发生在同一条记录上，便于后续按维度统计。具体字段配置方式和修改留痕能力，以实际产品环境为准。
示例：一条缺陷从提交到定级
以下为演示情景，用于说明分类字段的填写与修正过程。
某电商项目的测试人员在回归测试中发现：在商品详情页选择“货到付款”后提交订单，页面提示“支付方式不可用”，订单未生成。测试人员提交缺陷，初始填写为：缺陷类型“功能缺陷”，严重程度“严重”，来源模块“订单结算”，优先级暂填“高”，复现步骤写明操作路径和账号条件。
测试负责人复核时发现两个问题。第一，该支付方式在需求文档中属于本期上线范围，当前所有使用货到付款的用户都无法下单，且没有其他可用路径完成该类订单，影响范围覆盖核心流程，严重程度应从“严重”上调为“阻断”。第二，缺陷类型归为“功能缺陷”准确，但来源模块应细化为“订单结算—支付方式校验”，便于定位。复核后修改严重程度并补充模块信息，修改理由记录为“核心下单路径不可用，无规避方案”。
开发受理后确认该问题由支付方式配置遗漏引起，修复工作量约半天。测试负责人与开发负责人据此确定优先级为“紧急”，响应预期为当日修复并验证。最终字段取值为：类型“功能缺陷”、严重程度“阻断”、优先级“紧急”、来源模块“订单结算—支付方式校验”。
这条示例体现的判断规律有三条：严重程度看实际影响和有无规避方案，不看修复工作量；类型按问题性质判定，模块信息用于定位而非定级；优先级在严重程度确定后，结合修复成本和排期确定。团队可以把这类典型情形整理成判例，作为判定标准的补充说明。
完成检查：分类体系是否可用
分类体系上线后，需要用可核验的检查项判断它是否稳定可执行。以下清单可逐项核对。
- 每个维度的取值互斥，任意一条缺陷只能落入一个取值，不存在“既像功能又像性能”的模糊地带。
- 取值覆盖近三个月出现过的常见缺陷情形，抽样检查中未出现大量“其他”或空值。
- 严重程度与优先级各有独立判定表，表中每个等级都有判据示例和边界说明。
- 提交、复核、确认三个环节的责任人和时点已写入团队规范，新成员能按表操作。
- 分类修改有记录，能查到修改人、时间和理由。
- 争议处理路径明确，近期争议有裁决结论并已同步。
抽样一致性检查是验证判定标准是否有效的直接方法。做法是每月抽取一定数量的已分类缺陷，由两名未参与原判定的成员独立重新判定严重程度和类型，统计一致率。一致率的具体通过标准由团队设定，例如严重程度一致率达到八成以上视为稳定；低于标准时，分析分歧集中的等级和情形，补充判据或调整取值。抽样数量不必很大，关键是覆盖不同模块和不同提交人。
分类数据的统计用途主要有三类：按类型看缺陷构成，判断哪类问题高发；按严重程度看质量趋势，观察阻断和严重缺陷的占比变化；按来源模块看缺陷密度，定位薄弱模块。异常信号包括某一取值长期空置、某一等级占比突然大幅变化、跨团队对同类缺陷判定分歧集中、大量缺陷在修复过程中被上调严重程度。这些信号说明判定标准与实际不符，或填写环节执行不到位。
需要修订分类体系的触发条件可以预先约定：新增产品形态导致现有类型无法覆盖；连续两个月抽样一致率低于标准；争议裁决中同类情形反复出现；统计显示某维度长期无区分度。修订时同步更新维度定义表、判定表和团队规范，并对已有关键判例做一次回看，避免新旧标准混用。
常见问题
团队规模小、缺陷量不大，是否也需要完整的四个分类维度？
可以按实际需要裁剪，但建议保留缺陷类型和严重程度两个维度。缺陷类型支撑问题性质的统计，严重程度支撑质量趋势判断，这两项是后续分析的基础。优先级在缺陷量少、排期沟通靠口头即可完成时，可以先简化甚至暂缓单独设字段；来源模块在只有单一模块或产品形态简单时，也可以先不设。裁剪的原则是每个保留的维度都有人用、有数据可查，避免设了字段却长期空置。
严重程度和优先级出现冲突时，以哪个为准？
两者判定对象不同，出现“不一致”是正常现象，不需要强行统一。严重程度依据缺陷的客观影响判定，优先级在严重程度基础上结合业务影响面、发生频率、修复成本和规避方案确定。处理方式是先确认严重程度是否判准，如果影响确实大而优先级低，需要在优先级判定中写明理由，例如已有稳定规避方案、影响用户范围有限。反过来，影响轻微但优先级高，也要记录业务原因。关键是让每条不一致都有可查的依据，而不是让两个字段互相迁就。
分类字段在缺陷修复过程中被修改，如何避免统计失真？
修改本身是正常操作，失真来自修改没有记录。做法是要求每次修改严重程度或优先级时填写修改理由，并保留修改人和时间。统计时区分初判值和最终值：看判定标准是否准确，用初判值与复核结果对比；看质量趋势，用最终值。如果某类缺陷大量在修复过程中被上调严重程度，说明初判标准偏松或提交环节培训不足，应作为修订判定标准的信号，而不是简单归因于个人。
分类做完之后，和缺陷分诊、派单怎么衔接？
分类解决“是什么、多严重、多急”，分诊解决“派给谁、排进哪个队列”，两者是前后衔接的关系。流程上可以让分类在分诊之前完成，分诊直接读取类型、严重程度和优先级作为分派依据。需要注意的是，分诊规则、责任人归属和队列顺序不写进分类标准，否则分类字段会混入排班信息，按维度统计时结果会失真。分类结果稳定之后，分诊规则的调整不会反过来影响分类数据。
抽样一致性检查具体怎么操作，多久做一次？
做法是定期抽取一批已分类缺陷，由两名未参与原判定的成员独立重新判定严重程度和类型，统计两人结论与原判定的一致率。抽样覆盖不同模块和不同提交人，数量不必很大，关键是持续做。频率可以按月，缺陷量大的团队可以按双周。一致率的通过标准由团队自行设定，例如严重程度一致率达到八成视为稳定。低于标准时，分析分歧集中在哪些等级和情形，补充判据示例或调整取值，而不是直接追责填写人。
