累积测试分析的情况

　　现在，让我们将图 1 和 2 中例举的传统方法与新方法在同样的情况下进行对比。首先，我们对来自于上面测试的结果执行累积测试分析的新技术。为了这样做，我们向此图表引入许多附加颜色（参见图 3）。

• 如以前一样，通过（绿色）或失败（红色）的新测试显示为暗色。因为图 3 显示了测试循环的末尾，所以显示出很少“新的”测试运行。
• 用橙色突出的测试表示那些瞄准已知构建，但因某种原因没运行的分析。
• 浅绿和浅红色的结果表示从较早的构建中转过来的结果。“新的”和“重新运行”的测试之间的差别仅仅是，“新的”测试是那些对正讨论的构建首次运行的测试。

　　还要注意的是图表不再从 0％ 到 100％，而替换为测试的度量数字。这背后的原因将在我们讨论新数据时显现出来。

图 3：利用传统回归测试方法的 CTA 累积测试结果

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

• 橙色“遗漏”结果表明构建 1 和 2 没有充分的测试，但它们从对早期的构建的测试（没有显示）那里带来了非常多有效的结果。
• 对构建 3 的测试减少到遗漏测试累积的大约三分之二，所需的余下的测试在整个过程中都没运行，直到构建 11。
• 附加的测试针对于构建 6（“遗漏”测试的数量增加），说明对产品有附加的功能变更。
• 对许多构建出现了大量的测试，构建 3、构建 9 和构建 11 特别的昂贵 —— 问题是，这些都是必要的吗？

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

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

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

• 构建 1 中出现的大量变更，并且几乎所有这些都对构建 3 充分测试了。
• 在构建 3 之后，许多未测试的变更从一个构建带到了下一个中，使“确定缺陷的时间”拉得更长。
• 在构建 4 和 5 中出现的大量变更，可能已经否定了早先执行的测试的某些好处。更重要的是，对构建 3 运行的并且随后不在循环中重新运行的测试可能会错过构建 4 或之后引入的缺陷。
• 我们管理了对每个构建运行的少量测试，我们将提供所引入变更的最有效的覆盖。