减少人为出错

　　不管你信不信，最优秀的人同样也会在日常工作中犯错。工作做得好，犯错的机会就少一些，但是出错的机率还是大于0。在检验构建质量过程中，对人为出错的风险了然于胸是非常重要的。实际上，软件应用大部分bug背后都隐藏着人为错误。相反，计算机做这些重复性任务效率极高 - 它们既勤奋又细心，通过自动化测试可以减少人为错误风险。

　　测试是可执行的文档

　　测试场景是应用程序状态一个极佳的知识来源。如果想了解应用程序能为最终用户做些什么，手工测试结果可以提供一个很好视图，并且告知开发团队其代码中哪些部分比较“古怪”。所记录的测试结果由两个部分组成 - 展示应用软件能做什；记录什么会出错，怎么出得错。有了这些信息，就很容易管理应用程序的异常举动。如果测试人员很勤奋，可以保证文档总是最新的（另一项开销），可能看一下测试结果就会知道软件的状态。但随着错误量的增大，工作量会大幅增加，作为测试人员需要记录操作步骤，抓取屏幕快照甚至是崩溃情况下的视频。如果在这些事情上花时间多了反而会增加变更的成本，实际上由于成本太高，人们不太愿意在每次发布时都记录状态。

　　有了自动化测试，通过选择正确的工具，记录应用程序状态的成本明显降低了。自动化测试工具提供了很好的方式来执行测试、按类别收集结果并把结果发布在Web页面上，让你能够直观看到测试结果数据以监视测试进度并从测试结果数据中获取相关反馈。使用类似Twist，Concordian，Cucumber等工具的话，给用户展示测试结果甚至让他们来编写测试都变得相当容易；这样既减少了信息传递过程中的损失，也让用户能更深地介入到应用开发过程中。对于测试失败的结果，多数测试工具都自动化了抓取屏幕快照及视频的过程，以更有意义的方式记录失败和错误。测试结果可以邮件方式发送给测试人员，还有更好的：每次构建都以RSS feed的形式提供给感兴趣的人。

　　技术层面测试（Technology facing tests）

　　测试应用程序的非功能特性——比如响应用户动作的性能，测试网络延迟及其对最终用户与应用程序交互的影响等等，传统上都是部分自动化（尽管我早期曾经干过用秒表来手工测试性能的活，低保真但有效）。我们可以很容易利用自动化测试并重用它们来做非功能性测试。例如，多次重复运行一个自动化测试可以告诉你Web页面上某个动作的平均性能 。该模型很容易建立，将功能性自动化测试的次数输入所选的框架内，那么在测试运行过程中你就可以建立并探测非功能性属性。要测试并监视例如基于较色的安全、延迟的影响、查询性能等，都可以通过重用已有的自动化测试来自动化，这是自动化测试额外的好处。

　　小结

　　在持续交付的过程中，不论大小，你都必须采取诸多步骤。其中最难逾越的障碍是在减少测试周期同时保持较低成本。自动化测试能帮你做到这些，同时让你建立起更加高效、快乐的团队，他们是在开发过程中进行测试。我的理解及建议是：从小处着手，充分投入以建立一套健壮的自动化测试套件，给它配备最优秀的人，培养团队尊重测试及结果的习惯，先建立起一个主干，然后逐步细化，平稳过渡。