软件测试ODC 缺陷分析法

      ODC（Orthogonal Defect Classification，正交缺陷分类）是获取缺陷的一种分类方案，但它不 仅仅是一个分类方案，还是一个软件过程的度量系统，它是建立在包含于缺陷流中的语义信息基础 上的，可以帮助评估测试效率，对错误进行跟踪，通过方案的分析机制可以评估客户的满意度。 1990 年 Ram Chillarege 博士等人提出 ODC 概念，并于 1997 年基本完成 ODC 理论体系建设。 1998 年以后，IBM 公司开始在其全球 24 个研发机构推广该技术，并取得了很好的经济效益。

        ODC 一共有 8 个属性，如图 9-17 所示。当测试工程师发现缺陷并进行提交时，可以为该缺陷分配“活动（Activity）”“触发（Trigger）”和“影响（Impact）”三个属性；开发工程师在修改缺陷 时，可以为该缺陷分配“阶段（Age）”“来源（Source）”“限定符（Qualifier）”“类型（Type）”和 “目标（Target）”五个属性。  活动（Activity）：是指当前缺陷被发现时的实际操作步骤（如代码审查、功能测试等）。  触发（Trigger）：描述暴露该缺陷时系统的环境或引发的条件。  影响（Impact）：该缺陷给用户带来哪些方面的影响。  阶段（Age）：缺陷是由新代码还是重写的代码引起的。  来源（Source）：缺陷出现在内部代码、重用库代码、移植代码还是外包代码。  限定符（Qualifier）：定义引起缺陷的原因。  类型（Type）：定义缺陷的类型，如算法、初始化等。  目标（Target）：将在哪里改正错误，如设计、代码等。

        图 9-17 ODC 八大属性 ODC 的生命周期包括三种可能的角色、三种可能的循环和六大实施步骤。 （1）ODC 实施中可能的三种角色  团队成员：团队成员包括开发工程师、测试工程师、用户。  ODC 负责人：ODC 负责人必须熟悉 ODC 分类的执行，需要制定 ODC 实施计划，指导 团队成员进行 ODC 分析。  ODC 特别小组：ODC 特别小组由开发工程师、测试工程师的代表组成，主要负责制定行 动计划、确认录入数据的正确性和进行 ODC 分析。 （2）根据 ODC 所需步骤的数量，有三种可能的循环  大循环：除了预备步骤，该循环本身包含五个步骤。

         中等循环：包含四个步骤，包含 ODC 生命周期的核心组成部分，尽管无法进行完整的 ODC 分析，但仍然可以执行一些有用的评估。  小循环：只包含两个步骤，只要找到一定数量的缺陷，随时可能发生确认的活动。 （3）ODC 包含以下六大步骤 1）预备阶段。获得主管的批准和支持来实施 ODC 方法，获得开发团队和测试团队的支持， 确定一个 ODC 负责人，由负责人来提供培训和指导，分析项目当前状态，确定 ODC 特别小组， 由开发工程师和测试工程师代表组成。 2）计划。需要把项目分成多个组件，每个缺陷都将追踪到相关组件，以供将来分析用，组件 的划分可以按照功能名称、物理分布或逻辑关系来确定。确定 ODC 分析的时间点，ODC 分析可以 在功能测试和用户验收测试之后进行，ODC 分析时间点的选择将直接影响后续质量改进的成效。 对于迭代的开发流程，可以在每个迭代结束的时候进行 ODC 分析。 3）数据录入。在数据录入之前，应该确保所有的开发工程师和测试工程师清楚地理解每一个 缺陷的含义。 4）数据确认。在数据录入之后，需要进行确认工作来保证录入数据的正确性。 5）分析。收集好一定的数据之后，即可以通过各种统计图表来分析这些数据，分析工作可以 在项目开发周期的任何时间点进行，通过统计图表分析出影响质量的原因。 6）行动。制定一个正式的行动计划来帮助我们持续地提高产品质量，行动计划可以是针对设 计文档、源代码、开发流程、测试方法等进行改进的建议，行动计划定义必须清晰且可度量。

          ODC 分析案例 1：使用 ODC 评估设计、代码的充分性。 首先从缺陷类型的角度来分析缺陷与设计相关的问题，按分配、校验、设计方法、接口、编辑 和打包几个维度对缺陷类型进行分类，如图 9-19 所示。

        从图 9-19 中可以看出设计方法的问题较多，说明系统设计的水平应该再提高。接下来，在该 图基础上可以从限定符维度对设计方法引入的缺陷进行详细的分析，从不同的角度来分析每种缺陷 类型的数量。我们设置三种限定符：错误的（Incorrect）、丢失的（Missing）以及外来的（Extraneous）， 如图 9-20 所示。错误的表示代码存在，编写不正确；丢失的表示代码本应该有的，但开发工程师 遗漏了。

        从图 9-20 中可以看出，大多数缺陷是由代码错误引起的，说明我们的代码写得太糟糕，如果 该案例丢失的缺陷很多，说明详细设计说明书做得不够好。 ODC 分析案例 2：使用 ODC 分析缺陷对客户的影响。 从缺陷影响的角度对缺陷进行分析，ODC 从可安装性、安全性、性能、易维护性、易操作性、易移植性、文档、易用性、标准符合性、可靠性、易获得和需求几个方面来分析缺陷对客户的影响。 ODC 分析图如图 9-21 所示。

      图 9-21 缺陷对客户影响图 从图 9-21 中可以看出，该产品问题主要集中在性能、易维护性和易用性方面，如果产品这样 上市是很可怕的，必须采取相应的措施来完善这几个方面的问题。 ODC 分析案例 3：ODC 评估缺陷修复效率。 在测试过程中有时会发现测试时间被延迟，通过 ODC 按缺陷严重等级的属性可以分析每类缺 陷修复的时间。通过描绘缺陷严重等级与修改缺陷的时间图，来分析修复缺陷所花费的时间，如图 9-22 所示。

        从图 9-22 中可以看出，致命缺陷和严重缺陷都已经修复，修复所有致命缺陷的时间为 17 天， 修复所有严重缺陷的时间为 20 天。