3、常见缺陷分类模型：ODC、IEEE标准分类、基于业务场景的分类

聊到缺陷分类，很多团队的做法就是「随便打个标签」。Bug类型选个「功能错误」，严重程度选个「一般」，完事。说实话，这样分类基本等于没分。

我做了十几年质量工作，见过太多团队在缺陷分析上栽跟头。问题出在哪？说白了，分类维度太粗，根本挖不到根因。今天我就把三种主流的分类模型掰开揉碎讲清楚。

3.1 Orthogonal Defect Classification (ODC)

ODC 是 IBM 搞出来的，核心思想就四个字：正交分类。什么意思？就是每个缺陷只能归到一个类别，类别之间互不重叠。

我个人习惯把 ODC 分成两个维度来看：

• 缺陷类型（Defect Type）：代码写错了？还是设计有问题？
• 缺陷触发条件（Trigger）：什么场景下暴露的？

举个例子。我在项目中遇到过这样一个Bug：用户点击「保存」按钮后，数据没写进数据库。用ODC分类：

• 缺陷类型：赋值/初始化错误（代码层面）
• 触发条件：边界条件（刚好在并发写入时触发）

你看，这么一分，根因就清晰了——不是功能逻辑错，是并发场景下的变量初始化没处理好。

3.2 IEEE标准分类

IEEE 1044 标准，这个更偏向于缺陷管理流程。它把缺陷的生命周期分成了几个阶段：

• 来源（Origin）：缺陷是在哪个阶段引入的？需求？设计？编码？
• 类型（Type）：和ODC类似，但更粗粒度
• 严重程度（Severity）：对系统的影响有多大
• 优先级（Priority）：修复的紧迫程度

嗯，这里要注意。IEEE 标准和 ODC 最大的区别是：IEEE 更关注「缺陷从哪来」，而 ODC 更关注「缺陷是什么」。

我建议团队这样用：

1. 用 IEEE 标准做缺陷的阶段溯源——比如这个月70%的Bug来自需求阶段，那说明需求评审要加强
2. 用 ODC 做技术根因分析——具体到代码层面，是算法问题还是接口问题

3.3 基于业务场景的分类

这个分类模型，说白了就是从用户视角出发。你想想看，用户才不管你是什么ODC类型还是IEEE标准，用户只关心一件事：这个Bug影响我干活了吗？

我常用的业务场景分类维度：

• 核心流程阻断：用户无法完成主要业务操作。比如电商不能下单、银行不能转账
• 非核心功能异常：次要功能出问题，但主流程还能走。比如个人中心头像上传失败
• 体验性问题：功能能用，但用着不爽。比如页面加载慢、按钮位置不对
• 数据一致性问题：显示的数据和实际数据对不上。比如订单状态显示「已发货」但实际没发
• 安全合规问题：存在数据泄露或违反法规的风险。比如密码明文传输

我在项目中遇到过最典型的业务场景Bug：一个金融App，用户转账时输入金额后，页面卡了5秒才响应。按ODC分类，这算「性能问题」。但按业务场景分类，这就是核心流程阻断——用户会以为转账失败了，很可能重复操作，导致重复扣款。

最后说一句。分类模型没有绝对的好坏，关键看你的团队想解决什么问题。我个人习惯是：日常用ODC做技术分析，周报用IEEE标准做趋势统计，排期用业务场景分类定优先级。三个模型配合着用，效果最好。