软件测试和验证是细致活也是辛苦活，需要模仿最终用户尝试各种用法和输入场景、比较并断言所期望的行为。而这些细致的辛苦活是可以让计算机程序去做的。自动化测试套件中那些可编程部分对于大规模软件交付是非常有帮助的。在我做过的大部分项目里，有些测试是可以自动化的，也有些不能。不过，只要有自动化测试套件，我的团队都将倚重于它，而将精力集中在那些没有自动化的功能测试。而且，自动化测试还让我们能够满足客户快速变化的需求，并使我们达到了一个更高的层次，使得每次构建（即使只是微小变动）都是经过测试和验证的稳定版本。正如Jez有关持续交付的文章中所言，自动测试“让交付团队超越了基本的持续集成”并走上持续交付的康庄大道。实际上，我觉得自动化测试是非常重要的，如果你要实践持续交付，就必须在自动化测试上进行投入。本文解释了之所以我这么认为的原因。

　　时间周期 - 从最后一次代码提交到发布

　　当软件复杂度不断增长时，验证其变化部分和已构建部分的工作量都会随之增加，这种增长至少是线性的。这就意味着测试时间与需要验证正确性的测试用例数量是成比例的。因此，增加新特性即意味着从开发完成到交付软件的时间会拉长，如果投入更多测试人员来应对增加的工作量（假设所有测试任务是相互独立的），那么交付成本也会增加。很多团队通过保留一个测试人员池来应对这一问题，这票人马在整个发布版本验证期间都在做“回归”测试，以检查新变化是否破坏了已有功能，我待过的一些团队也是这么干的。但是这么做不仅成本高昂，而且效率低下、进展缓慢且容易出错。

　　在自动化测试场景下，你可以减少花在验证用户功能工作上的时间和金钱。我们不妨假设你的测试场景中有合理数量的测试用例是可以自动化的，比如50%，这通常是软件项目可自动化测试用例的下限。如果你的团队能够自动化该数量的测试用例，那么人们就可以将把更多注意力集中于那些新近变化的特性上。假设跑一遍这些自动化测试需要3小时（时间越短越好，甚至少于20分钟），这一时间将直接影响将产品推出的时间。增加自动化测试的数量，并尽量减少测试运行的时间，那么你快速响应的能力将显著提升，同时成本得到缩减。下面我用一些简化数字（平均用例数）加以说明：

　　团队A

　　1、需测试场景数量 - 1000且在增加中。
　　2、建立构建环境所需的时间 - 10分钟。
　　3、测试一个场景所需的时间 - 10分钟。
　　4、团队中的测试人员数量   - 5。
　　5、假定不存在blocker（阻塞）。

　　如果没有自动化测试，测试单次提交的时间总量为（以分钟计）：

　　10 + （1000*10）/5 = 2010 分钟。

　　接近于4个工作日（每工作日8小时）。如此不仅成本高昂，而且开发人员在4天后才能得到反馈。这种设置日后还有可能在你的迭代中形成迷你瀑布。

　　团队B

　　与团队A的情况相同，但是测试套件中有50%的测试用例自动化了。假设运行完这500个自动化测试用例需要3小时时间。

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

　　任务1（手工） -   10 + （500*10）/5 = 1010 分钟。
　　任务2（自动） -   10 + 180 分钟。

　　接近2工作日。这虽不十分理想，但足以证明减少了成本，我们可以测试完一天之前的构建。测试开销减少了一半，我们还在3小时内完成了50%的测试用例。

　　接下来是更加理想且是可以达到的状况。