团队C

　　与团队B的情况相同，但是我们把测试放在更好的机器上运行，这样速度更快（比方说20分钟），而且80%的测试都自动化了（10%不能自动化，另10%是新功能）。

　　现在再来看，测试单次提交的时间总量为（以分钟计）：

　　任务1（手动） - 10 + （200*10）/5 = 410 分钟。
　　任务2（自动） - 10 + 20 minutes = 30 分钟。

　　结果，我们在30分钟内就覆盖了80%的测试，大约7小时即可结束整个测试。更值一提的是，在30分钟内跑完80%的测试，可以让我们尽早发现blocker，以便暂缓进一步手工测试。这样的话测试成本低、反馈快，在很大程度上改变了测试的过程，不是吗？

　　每次发布的测试成本

　　自动化不仅缩短了周期，还大大缩减了每次发布的成本。成本减少源自两个方面：

　　● 通过自动化测试尽早给开发人员反馈，提升了所测构建的质量，让他们得以收获“绿色”构建。

　　● 测试成本直接减少，因为反复运行相同测试的人员减少了。

　　测试成本直接减少比较容易解释清楚。以上面我们所提到的团队为例，下列图表显示了在运行所有测试时各个团队所花费的成本；这里假定每位测试人员每小时需花费50美元。

　　如你所见，对某一发布的候选构建做一次全面测试，团队A的花销（10万美元之多）几乎是团队C的5倍。

　　如果周期更长的话，比如说2年，那节约下来的成本就相当可观了。如果目标是一天之内能够跑完一遍发布构建测试的话（这一目标不算过分），那么团队C已经达标。团队A需要25个测试人员才能达到该目标，而团队B则需要15人。下面，我还要增加进硬件和编写程序的成本，来说明自动化测试对于一个超过2年的发布周期的有何意义：

　　硬件成本 - 机器及其他共5万美元

　　编写程序成本 - 再投入2个开发人员，最初2个月编写自动化测试程序，剩余时间维护测试套件，那么团队B和团队C的人数现在是7个。

　　针对这一数字，为了达到每天测试一遍构建这一目标，在2年时间里团队A的成本有四百八十万美元之巨。相比之下，团队C的成本接近一百四十万美元，成本减少了70%。从下面的图表可以更直观地看到这一点：

　　除了在缩短周期和减少成本上发挥作用外，自动化测试还创造了很多间接价值，包括：