验证及时

　　如果要再2小时内完成一个构建的验证，前面提到的团队A需要50名测试人员，但客户不会对这块成本感兴趣。如果没有自动化测试，大多数情况下，一天之内完成验证到交付几乎是不可能的。之所以这么说，是因为这种情况下成本极其高昂。因此，如果我的团队没有自动化测试，也没有无限资金的话，即便开发人员只提交一行代码，我们完整验证一个构建的时间也会成小时甚至成天的增加。这样的话，管理人员对每次构建都完整运行测试的积极性就会下降，最终导致构建测试覆盖面下降，对系统中bug的测试时间减少。另外，我还遇到过因此而减少代码提交频率的情况，这样并不健康。

　　反馈频繁、快速

　　自动化最重要的一个方面是团队从构建过程中可以得到快速反馈。每次提交都进行了无预判测试，团队很快就能得到测试报告。反馈越快则意味着建立在有错代码之上的代码越少，进而提高了软件可靠性。仍以上面的团队A、B、C为例：

　　● 对于团队A - 第一天发现blocker的概率是1/2，这就意味着测试第二天找到bug的风险比较高，这样的话第一天的工作就全浪费了，因为这个blocker修正之后所有测试都需要重新验证一遍。最坏的情况是这个bug在代码提交两天之后才发现。

　　● 对于团队B - 最坏的情况是在这一天最后几个小时才发现blocker。这也比团队A的情况好得多。而且，由于50%的测试用例是自动化测试，在3小时之内发现blocker的几率非常高（50%）。这种快速反馈可以让你更快发现并修正bug，因此响应客户需求的速度也非常快。

　　● 对团队C - 这三个团队中情况最好的。最坏场景是团队C在3小时之后才知道他们是否提交了blocker。因为80%的测试用例都进行了自动化，20分钟他们就能知道是否有错误。从团队A到团队C有很长一段路要走，但20分钟比2天要好得多。

　　机会成本

　　经济学家使用一个贴切的术语 - 机会成本来定义在多种选项中选择其一时将会失去的东西。 对一个又一个构建反复验证那些乏味的测试用例，其机会成本是：失去了花在探索性测试上的时间。机会成本通常不在于一个bug导致多个bug的情况，而在于对手工测试投入过多精力，这样的话测试人员很难找到时间来创建新的测试场景并跟进问题。不仅如此，由于所有时间都集中在回归测试上，测试人员在新功能上投入时间不足，然而从这些新特性中找到bug的概率却是比较高的。通过尽量自动化测试用例，可以释放测试人员的大部分精力，让他们做更具创造性的任务，并从“人的角度”去探索应用程序，以增加测试覆盖深度和质量。在我做过的项目中，只要有自动化测试辅助手工测试，测试得都比较深入，因而质量也比较高。

　　手工测试还包括乏味地、日复一日重复验证相同测试用例的工作，这是手工测试的另一个缺点。即便每天把测试分配给不同的人也是有创造性的活动，过一段时间之后，每轮测试也只是重复而已。测试人员鲜有时间去做创造性工作，因此他们对工作也缺乏满足感。测试人员是有创造性的人，他们的长项是以最终用户的角度去使用软件并找到新的方法来测试并发现应用程序的问题，而不是不断的重复一套过程。如果没有自动化测试，留住最好的测试人员并让他们满意的机会成本是非常巨大的。