在软件交付过程中，你应该尽可能地发现问题和缺陷。测试自动化可以快速并持续性地反映软件的状态。测试自动化可以保证在不破坏已存在功能的前提下，增加新的功能和修复缺陷。整个团队要对测试的自动化负责（包括开发团队和运营团队）。
重点是，尽管测试自动化至关重要，但不是所有测试工作都可以自动化。比如，可用性测试，探索性测试和一次性的测试行为（更多信息在《Agile Testing》第285页）
混合自动化测试，囊括了单元测试，后端服务测试和界面测试（见《Succeeding with Agile》第312页）。你应该经历过这三类测试，整体测试策略是基于单元测试的。我们接下来阐述这一点。
单元测试
单元测试的覆盖率，是自动化测试体系的基石。
单元测试，所测的经常是用于某个类中的独立单元。与其他资源（如，数据库），其他的子系统或组件（由一系列的类组成）不存在依赖关系。事实上xUnit系列工具有助于生成标准的单元测试代码。单元测试代码可以运行在开发环境，以及你自己构建的集成环境中。
集成测试会调用不同的单元，经常访问数据库和其他（远程）服务器。后台服务测试的运行时间会长于单元测试，而且应该由构建服务器来触发。位于金字塔顶端的界面测试，则是由图形控件触发，由用户在界面上的操作来驱动。我们有足够的手段可以对他们实现自动化。探索性测试，是由人工来进行的一项界面测试。
尽管有潜在需求，但测试环节在变更管理中还不算普及。在运营层面上，有很多种途径去测试系统行为，利用Cucumber-puppet工具用代码表现系统行为，这是一种很强大的方法。
“Cucumber is a framework for applying BDD, and Cucumber-puppet and rspec-puppet allow you to test Puppet manifests.”
Manifests
测试驱动开发值得一试，‘测试先行’备受推崇。在小型迭代的重构中，都应有测试代码辅助以提升设计质量。大多数人选择‘单元测试’，都是因为需要周期性地快速响应，以及提高代码质量，特别是设计质量。在测试某个独立单元的过程中，关键要探究如何模拟其他的组件和子系统。
后台服务测试
不同的单元构成了服务（组件）层。集成测试，是在不接触用户界面的情况下，连接多个组件把系统作为一个整体进行的测试。白盒测试，近似于单元测试和后台服务（组件）测试。That is, they test how a specific test was passed. 有个很强大的集成测试工具，名为Arquillian. Arquillian的宗旨是将测试逻辑从Container lifecycle和部署细节中提炼出来，使得团队可以轻松地定义集成测试用例。
用户界面测试
用户界面（即: 界面交互）测试，理所当然地会测到所执行的应用程序、中间件和底层架构。界面测试也很重要，但只是整体测试策略的一部分。界面测试属于黑盒测试范畴，他们响应具体的问题（例如: 一项特殊任务是指什么？）。因而，这项测试即检验应用程序是否按照已定义好的行为执行。界面上的控件，控件的顺序，以及布局样式，多多少少都会随着时间的推移进行调整；再则，就像企业代号（Business Code）需要被维护一样，界面测试也应该用类似的方法维护好。为了减少工作量，把抵触情绪降到最低，测试工作应当易执行且具健壮性。由于界面测试的对象易变，编写用例又很费时，代价较大，所以要对界面测试进行解耦处理。打个比方，如果要测试一个按钮的提交功能，不要去验证它是否在数据库中创建了一条新记录，推荐的做法是基于单元测试，并设置相应的后台服务测试用例（例如有些后台服务可以通过在页面上点击调用按钮进行测试）。你应当做到界面测试与上下文相分离。比如说，应该使用相对路径定义界面上的控件，xPath表达式或html中的“name”属性。
界面测试覆盖率，这一数据非常有价值。例如在新发布的程序部署到目标环境之后，或许自动运行一次冒烟测试就足够了。正如此书第三章所述，冒烟测试是在最开始去检验程序是否可用，确保用户在主要的场景下可以正常使用。你或许只需要执行相关的较重要的测试用例，而不是所有的界面用例。当然，若能执行全部用例则最好。
界面测试通常要连接外部子系统，包括网络服务，数据库，文件系统等等。所以，界面测试最重要的‘点’在于：应用程序是如何工作的。James Whittaker, Jason Arbon, 和Jeff Carollo根据测试规模的大小，分为小型，中型和大型测试（参见<How Google Tests Software>第46页）。界面测试因涉及的范围广，而属于大型测试；这意味着如果一个用例不能执行通过，或许会花较长的时间去调研。大型测试的数据准备会比较困难，而且很费时。
Selenium2（WebDriver）是Web测试的利器。Selenium有不同的模式供你选择：在真实或模拟的浏览器上进行测试。前者可以得到真实环境下的结果，后者可以使页面测试得到快速响应。界面测试往往被作为‘用户验收测试’。好的验收测试，应该是数据驱动，并用通俗易懂的语言形成易执行的标准文档。这个过程通常称作“范例标准化"（specification by example）。我们将在第10章进行讨论。
