图3表明在最初的几个月中，主要的缺陷出现于执行某个单独的功能时，正如图中的trigger（触发器）--coverage（覆盖）和variation（变量）所指出的那样。随后，在9月里，通过更为复杂的测试场景所发现的缺陷在增多，图中的trigger（触发器）--interaction（交互）、sequencing（连续）和software configuration（软件配置）可以说明这一点。 但是在大多数月份里variation是占主导地位的trigger（触发器）。Variation表示通过改变单个功能的输入参数所发现的缺陷。图2--活动和模块图，表明很多缺陷是从FVT（功能验证测试）中逃逸的，正如图中的trigger-- coverage（覆盖）、variation（变量）、interaction（交互）和sequencing（连续）所表现出来的那样。这些观测结果表明，我们必须对FVT（功能验证测试）过程进行改进，以确保逃逸的缺陷少之又少。具体点说，测试计划中必须包括更多的变量（variation）测试。通过对测试人员的培训，以及检查测试计划时对这一点的强调，我们可以实现上述的改进。

小结  ODC帮助我们在过程中找出下列不足和改进措施
        多数缺陷是从FVT（功能验证测试）逃逸的。Variation（变量）是最普遍的trigger（触发器）。因此，团队需要对测试人员进行有关FVT（功能验证测试）中各种测试类型的培训，确保FVT（功能验证测试）的测试计划中有足够的变量（variation）测试用例。
        q模块中有太多的基缺陷。团队必须针对此模块区域增加回归测试的次数。
        大多数缺陷都在b模块中。团队要保证所有的变更都具备清晰的文档说明，同时保证一旦有代码发生变化，受其影响的基代码应被作为测试中的重点对象来对待。
        未来的计划  团队会继续对外部（发现的）缺陷进行分类，并利用此信息改进他们的开发和测试过程。ODC外部缺陷为定义用户惯用法的简档提供了基础，而简档可以帮助测试团队来复查缺陷。在新版本的开发周期中，这个团队也开始对“过程中”发现的缺陷进行分类，并与外部缺陷的分类进行了对比。这样的对比会为当前的测试过程提供更加准确的信息，并为将来的测试工作提供关注点。
Case Study 2: A large middleware project
案例2：一个大型的中间件软件项目
        这个案例中包含了一些隶属于IBM系列的中间件产品，这些产品可用于大部分的操作系统平台。它们都是由几百人的团队开发的成果，开发过程遵循典型的瀑布过程，通过各个阶段的判定检查点评估产品是否可以进入到下一个阶段。
        产品团队中最先开始使用ODC的是测试组。而测试组正处于重组的过程中，以期通过此来解决一些问题。他们需要一套度量规则，使他们可以客观的评估他们的进度，并面对一些他们自己的问题，这些问题是：
        单元测试阶段，功能验证（FV）阶段和系统测试阶段，三个阶段互相叠加进行。理论上讲，这些阶段都是假定为有序的阶段，但是它们会经常叠加，有时是完全地叠加进行。系统测试的入口检查点的目的是判断前一个测试阶段的进度，测试是否充分，是否可以进入到系统测试的阶段中。而他们需要的度量规则能够为这一判断提供可度量的、客观的数据，而不是个人的（主观）意见。
        测试组开发了大量的测试序列，但是他们并不知道这些序列的有效性如何。他们只有两个度量方法：（1）缺陷--上升和关闭率 （2）测试用例--执行率和测试用例结果，如成功或失败。
        这些度量方法度量了测试进度，却不能说明测试的有效性如何。而ODC可以提供客观的、可量化的数据，对组织寻找的判断依据而言是非常必要的。
        ODC过程  分别由两个项目组对ODC过程展开实验，并以一系列的培训讲座为开始。团队成员参加的培训内容包括1小时的概貌介绍，以及2小时的关于如何分类缺陷的详细培训。其中的一部分测试人员和开发人员还要参加一个2小时的关于如何确认数据的课程。一个月后，很多人都接受了2小时的评估培训，学习如何复查数据，以及如何开始使用这些数据。
        数据由确认小组每周进行一次确认，以保证分类的正确性，并纠正每个错误。随后，由评估小组对数据进行复审，并评估项目的状态，决定是否需要采取某些特定的行动。对于个别项目，可以选择合适的时机进行评估。
        评估  在评估期间，他们决定是否可以开始系统测试，以及需要对系统测试和功能测试做哪些改进。
        提早进入系统测试的一个案例.  在这个产品的FV（功能验证）阶段进行到大约四分之三时，项目组开始使用ODC。七周内，项目到达了系统测试入口的判断检查点处。虽然ODC数据在那个时候还没有被正式地纳入到决策的过程范围内，但项目组还是饶有兴趣地复查了这些数据。为项目组启动系统测试提供的支持，证明这些数据是非常有用的。
        进入系统测试的（判断）标准之一是“FV（功能验证）的覆盖度超过百分之八十，而且完成了不少于百分之五十的功能验证”。在这个案例中，FV并没有达到百分之八十的覆盖度目标，但是有超过百分之七十的功能验证都完成了–非常高的通过率。此外，FV团队相信代码已经非常稳定了。图4则展现了activities（活动）和triggers（触发器），说明：
        功能测试的范围已经很大了，达到了ODC triggers（触发器）的范围。Coverage（覆盖）、variation（变量）、sequence（顺序）和interaction（交互）测试包含了所有已暴露的缺陷。实际上，在使用更复杂的系统测试的triggers（触发器）时，如recovery/exception（恢复/异常）和startup/restart（开始/重起），项目组已经让缺陷完全地暴露了。
        功能测试进入到更为复杂的triggers（触发器），意味着产品的基本功能已经稳固，准备进入系统测试阶段。这个暗示为FV团队的“直觉”提供了支持。

版权声明：51Testing软件测试网及相关内容提供者拥有51testing.com内容的全部版权，未经明确的书面许可，任何人或单位不得对本网站内容复制、转载或进行镜像。51testing软件测试网欢迎与业内同行进行有益的合作和交流，如果有任何有关内容方面的合作事宜，请联系我们。