累积测试分析和目标测试入门[6]

　　累积测试分析和目标测试入门[6]     软件测试

　　利用该技术，我们立即有了更多要考虑的信息：

　　橙色“遗漏”结果表明构建 1 和 2 没有充分的测试，但它们从对早期的构建的测试(没有显示)那里带来了非常多有效的结果。

　　对构建 3 的测试减少到遗漏测试累积的大约三分之二，所需的余下的测试在整个过程中都没运行，直到构建 11。

　　附加的测试针对于构建 6(“遗漏”测试的数量增加)，说明对产品有附加的功能变更。

　　对许多构建出现了大量的测试，构建 3、构建 9 和构建 11 特别的昂贵 —— 问题是，这些都是必要的吗?

　　接下来，因为知道变更是 CTA 的重要部分，所以我们引入一个图 4 中的新图表，显示出每次构建中变更的影响，以及那些变更测试得有多好。数据重新从构建带到相关的构建中，被变更了的类被反映在零线以上，而覆盖这些变更的测试在零线以下。充分测试的变更将因此显示为一个绿色的条，处于与上面所示的变更相同高度的轴之下。

　　图 4：每此构建的变更以及所完成的测试

　　通过传统的回归测试的观点查看该数据，可以看到，对构建 3 的测试是有效的，但是构建 4 到 8 中对产品类的附加的功能变更(显示为“新的”或者“非常新的”项)，直到构建 11 才完全测试完成。上面较早描述的其它提示点：

　　构建 1 中出现的大量变更，并且几乎所有这些都对构建 3 充分测试了。

　　在构建 3 之后，许多未测试的变更从一个构建带到了下一个中，使“确定缺陷的时间”拉得更长。

　　在构建 4 和 5 中出现的大量变更，可能已经否定了早先执行的测试的某些好处。更重要的是，对构建 3 运行的并且随后不在循环中重新运行的测试可能会错过构建 4 或之后引入的缺陷。

　　我们管理了对每个构建运行的少量测试，我们将提供所引入变更的最有效的覆盖。

　　利用目标测试使效果最大化

　　指出了老方法中的不足，我们现在使用新的方法。假设相同的环境，通过 CTA 可以完成什么?要论证这点，如先前一样，我们使用同样的两个图表，图 5 和 6 中分别显示出结果和变更。

　　图 5：利用目标测试方法的 CTA 累积测试结果

　　图 5 和 6 中的数据是基于已经部署了累积测试分析和目标测试的测试团队，在需要覆盖每次构建中的变更时只运行那些确定出来的测试。

原文转自：http://www.ltesting.net