ODC 缺陷分类是什么
ODC（正交缺陷分类）从多个正交维度给每个缺陷打标签——触发（Trigger）、类型（Type）、目标（Target）、影响（Impact）、来源（Source）、龄期（Age）。结构化分类后可以回答：缺陷从哪来、在哪里集中、如何预防，把缺陷数据变成过程改进依据，而不是躺在缺陷库里的流水账。
基本信息
| 六个维度 | 触发、类型、目标、影响、来源、龄期 |
|---|---|
| 触发取值 | 缺失、多余、错误等（缺陷如何被发现） |
| 类型取值 | 赋值、检查、接口、算法、时序等（缺陷形态） |
| 来源取值 | 需求、设计、代码、文档等（引入环节） |
| 使用门槛 | 字段少而稳定；先小范围试点再推广 |
| 分析输出 | 来源分布、集中模块与预防措施建议 |
六个维度示意
六个维度示意
触发（缺失/多余/错误）
类型（赋值/检查/接口/算法/时序）
目标（模块、功能、界面）
影响（安全/性能/可用性/维护）
来源（需求/设计/代码/文档）
龄期（引入到发现的阶段跨度）典型使用场景
- 过程改进：按来源统计缺陷分布，定位需求或设计环节的薄弱点。
- 预防措施验证：改进落地后对比同类缺陷的下降情况。
- 测试策略调整：按触发方式分布优化测试类型比例。
- 外包质量评估：用统一分类对比不同供应商的交付质量。
- 培训素材：高频类型与来源直接指向团队培训重点。
- 版本复盘：对比多个版本的分类分布，观察改进趋势。
问题与维度对照
| 想问的问题 | 用到的维度 | 输出 |
|---|---|---|
| 缺陷从哪来 | 来源与类型 | 各引入环节的缺陷占比 |
| 在哪里集中 | 目标与触发 | 缺陷集中的模块与功能 |
| 如何预防 | 触发与影响 | 针对性预防措施清单 |
| 何时引入、何时发现 | 龄期 | 发现延迟与漏检环节 |
分类字段要少而稳定；先在小范围试点，再推广到全部团队：字段多、口径乱，数据必然失真。
分类在缺陷处理时同步完成，不能事后补：补填的分类准确性无法保证。
ODC 的价值在趋势而不在单条：定期看分布变化，再决定投入方向。