有效缺陷分类管理

1、缺陷的有效管理缺陷的有效管理XXXX2016/08/XXXXXX1/24目目录录ODC缺陷分类法简介0102ODC属性03ODC工作流程04ODC与测试中心2/24目目录录ODCODC缺陷分类法简介缺陷分类法简介0102ODC属性03ODC工作流程04ODC与测试中心3/24ODCODC方法的发展历史方法的发展历史ODC : Orthogonal Defect Classification 正交缺陷分类法4/241990年1997年1998年后在IBM内部和业界推行，产生数亿美元的质量成本收益由IBM的T.J.Watson研究发明完成基本理论体系建设ODC : Orthogonal Defec

2、t Classification 正交正交缺陷缺陷分类法分类法5/24 软件缺陷：指的是软件工作产品的不足或不完美之处。 软件工作产品：指的是软件过程所创造的一切产物，包括计算机程序、计划、流程、及所有相关的文档和数据。 软件过程：是人们用以开发和维护软件工作产品的一系列活动、方法、实践和转换。 软件故障：指的是软件缺陷在一定的输入条件下被激活的结果，它在无适当容错措施的情况下造成失效。 软件失效：指的是软件执行过程中系统行为与用户需求的偏离。 何谓正交？0 xXYZXY 正交缺陷正交缺陷分类法分类法 ODC在高层次上，是帮助获取缺陷信息的一个缺陷分类方案。 它不仅仅是一个分类方法，ODC是一

3、个软件过程的度量系统，它是建立在包含于缺陷流中的语义信息基础上的。 它可以帮助我们评估测试的效力和效率，可以进行错误跟踪，通过ODC背后的分析机制评估顾客的满意度。6什么是什么是ODCODC？ ODC技术：结合了根原因分析和统计建模结合了根原因分析和统计建模(Statistical Modeling) 两种软件缺陷分析技术的优势。两种软件缺陷分析技术的优势。提供了一套用于捕获缺陷数据关键特性的方案，并给出对分类的缺陷数据集进行提供了一套用于捕获缺陷数据关键特性的方案，并给出对分类的缺陷数据集进行分析的指导。分析的指导。可以帮助我们全面了解缺陷，从而采取最有效的措施来改进软件开发过程中的不可以帮

4、助我们全面了解缺陷，从而采取最有效的措施来改进软件开发过程中的不足，不断地提高软件产品质量。足，不断地提高软件产品质量。 ODC统计分析可以：准确确定产品主要质量问题区域准确确定产品主要质量问题区域识别缺陷引入和去除过程的重点改进对象识别缺陷引入和去除过程的重点改进对象实现对过程和产品的精确改进指导实现对过程和产品的精确改进指导7/24正交缺陷分类法适用对象正交缺陷分类法适用对象 开发生命周期相对来说是一个很漫长的过程，包括后续的改进工作。例如，这个项目包括多个软件版本或者一个版本有多次迭代。 潜在的缺陷数目是相当大的。缺陷数目越多，客观的分析结果也越多，对了解软件质量越有好处。 这个项目已经

5、将“高可靠”设定为它的主要目标之一。8目目录录ODC缺陷分类法简介01ODCODC属性属性0203ODC工作流程04ODC与测试中心9/24ODCODC属性属性提出者提出者10ODCODC属性属性关闭关闭者者11ODCODC属性分配属性分配12/24目目录录ODC缺陷分类法简介01ODC属性02ODCODC工作流程工作流程0304ODC与测试中心13/24ODCODC使用模型使用模型14ODCODC工作流程工作流程15/24 正交缺陷分类法，Orthogonal Defect Classification（以下简称 ODC）是一种缺陷分析方法，由 IBM 在 1992 年提出。它通过给每个缺陷

6、添加一些额外的属性，利用对这些属性的归纳和分析，来反映出产品的设计、代码质量、测试水平等各方面的问题。从而得到一些解决办法来进行改进。 ODC 的工作流程分为四部分：“缺陷分类”，“校验已被分类的缺陷”，“评估数据”以及“采取行动来改进工作”。下面我们将逐一进行讲解。缺陷分类缺陷分类16/24 分类，是 ODC 工作流程中的第一步，即需要测试和开发人员分别对每一个缺陷填写 ODC 属性。对于团队成员来说，正确的了解每个属性的值尤为重要，这样才能保证他们在分类时尽量选择正确的选项。 在填写之前，需要缺陷管理工具进行改进，配置额外的属性。常用的缺陷管理工具包括 Clear Quest(CQ) 和

7、Configuration Management Version Control(CMVC) 等。需要增加的 8个 ODC 相关属性分别是： Activity：表示在做哪种测试时发现的缺陷。 Trigger；表示采取哪种方式触发的该缺陷，不同的 activity 对应不同的 trigger 类型； Impact：表示该缺陷的发生会对客户造成的影响；缺陷分类缺陷分类17/24 Target：表示开发人员为了修复这个缺陷，需要在哪方面做修改。比如可以修改的方面包括：产品设计、相应的代码和文档等； Defect Type：缺陷类型； Qualifier：表示该缺陷是由于丢失相关代码、还是代码不正确造

8、成的。或者是由于第三方提供的代码造成的； Source：表示该缺陷的来源是由于内部编写的代码引起的问题，还是由外包公司提供的代码引起的等； Age：表示该缺陷是由新代码产生的还是由于修改其它缺陷而引发的，或是在上一个发布版本中就已经有的问题等； （Content Type: 表示修复文档的类型。仅对文档类的缺陷有效。）测试人员进行分类测试人员进行分类 从下图 中我们可以看到，ODC Submitter 选项签中有三个选项，分别是 Activity、Trigger 和 Impact。这三个选项是由测试人员，也就是该缺陷的发现者来填写的。18/24开发人员进行分类开发人员进行分类从图 2 中我们可

9、以看到，ODC Responder 选项签中有六个选项，分别是 Target，Defect Type，Qualifier Source，Age 和 ContentType。这六个选项是由开发人员，也就是该缺陷的解决者来填写的。19/24分类常见问题分类常见问题缺陷管理工具对缺陷管理工具对 ODC 的支持不的支持不完善完善有些 ODC 属性间是有关联关系的。例如：在 ODC Submitter 选项签中，如果在 Activity 属性中选择了“Function Test”，那么 Trigger 属性就只能在“Coverage”，“Sequence”，“Variation”和“Interactio

10、n”中进行选择。如果在 Activity 属性中选择了“System Test”，那么可选的 Trigger 属性的值又是截然不同的另外几种选项，分别为：“Workload”，“Recovery”，“Startup/Restart”，“Hardware config”和“Software config”。在缺陷管理工具中，若对这些属性间的关联关系不做限制，选择每个选项时都会把所有的值列出来供用户选择，这样很容易造成选项间的不匹配。从而导致最后统计 ODC 数据时，结果不合理。20/24分类常见问题分类常见问题测试测试或开发人员对各自需要填写的或开发人员对各自需要填写的 ODC 属性不属性不熟悉

11、熟悉ODC 这种缺陷分析方法并没有普及到每一个项目中，因此在第一次应用 ODC 的项目中必须在分类阶段前，就要在项目内部做好 ODC 知识的系统培训。不仅仅是简单的了解，而是需要知道每个属性所有可选项的含义。21/24校验阶段校验阶段 在第一步中，测试人员和开发人员已经填写了 ODC 数据。那么接下来就需要 ODC 专家对这些数据进行校验。因为填写不正确的 ODC 数据会导致后面的评估和行动两个流程步骤没有意义。因此校验数据的正确性尤为重要。 校验结果如何在缺陷管理工具中体现校验结果如何在缺陷管理工具中体现？ 校验员在校验完某个缺陷并确认相关人员已经完成修改后，校验工作还并没有结束。为了在下一

12、阶段，即评估阶段中，仅仅对已被校验过的缺陷进行分析，就需要在缺陷管理工具中有地方进行标识，用以过滤掉未校验过的缺陷。22评估阶段评估阶段 在确保输入的 ODC 数据正确性的前提下，就可以对这些缺陷进行分析了。根据 ODC 的不同属性进行分类统计，可得出不同方面的结论。以此来反映测试、开发或产品设计方面的问题，指出潜在的改进的机会。比如：缺陷被发现的如何、产品是否稳定等。下面选择测试工作的评估方法进行说明。23对测试工作的评估对测试工作的评估 利用不同的 ODC 属性的组合，可以从多方面来评估测试工作的完成情况。例如利用测试阶段和 activity 属性来评估是否应在某一测试阶段中发现的缺陷却被

13、在下一测试阶段中才发现；利用 activity 和 trigger 属性来评估是否每个 activity 都使用了足够多的与之对应的 trigger 来发现缺陷；利用时间和 trigger 属性来评估是否随着时间的推移测试变得更加复杂等。下面就利用第一种评估方法来进行举例。24对测试工作的评估对测试工作的评估 不同的测试阶段有不同的测试重点。例如在功能测试阶段，所对应的 activity 就是 Function Test( 功能测试 )。而在系统测试阶段，所对应的 activity 就是 System Test（系统测试）。我们可以通过统计在每种测试阶段中发现缺陷的 activity 来判断是

14、否本应在该测试阶段中发现的缺陷被遗留到了下一测试阶段。以此来评估测试工作的完成情况。如图 所示。2526利用测试阶段和利用测试阶段和 activity 属性得到的评估图属性得到的评估图对测试工作的评估对测试工作的评估 这个评估方法常用于衡量是否本应该在功能测试阶段发现的缺陷没有被发现，而是到了系统测试阶段才被发现。因此该评估方法最好在系统测试开始后使用，因为在此之前的阶段使用没有太大的帮助； 客观上讲，在系统测试阶段发现一些功能测试阶段的缺陷是正常现象，这不会影响系统测试的正常运行。反而如果在系统测试阶段没有任何功能测试阶段的缺陷，就说明有问题了。很可能是由于测试人员对 activity 属性

15、理解不正确导致的错误输入引起的；27ODCODC缺陷分析方法缺陷分析方法28/24ODCODC缺陷分析方法缺陷分析方法29/24行动阶段行动阶段 仅仅发现了问题，是不够的，还需要解决问题。根据评估过程中反映出的不同问题，有针对性的提出解决方案并让相关人员采取行动。这一阶段也是最能给产品带来价值的。 测试和开发团队应该参与到这个过程中，因为他们才是最终行动的实施者； 所识别的行动应该是合理的，有可行性的； 所识别的行动越具体越好。不要笼统的指出对产品有什么改进行动，最好是能针对某个组件或是模块，采取行动； 利用在评估阶段生成的各种评估图一起分析、衡量出改进的行动方案，不要单凭某一个评估图来做决定； 要采取的行动应该是可以衡量的，这样可以看出是否该行动对产品有积极的影响。30目目录录ODC缺陷分类法简介01ODC属性02ODC工作流程03ODCODC与测试中心与测试中心0431/24ODCODC的好处的好处对于测试团队，通过 ODC 可以知道测试工作是否变得更加复杂；每一个测试阶段，是否利用了足够多的触发条件来发现缺陷；退出当前测试阶段有什么风险；哪个