我们的业务逻辑相当复杂，而且新架构将这一逻辑从数据库和用户接口层中分离出来，这样就可以通过设置内存中数据并在其上运行产品代码来进行测试。这是金字塔的中间层———比底层运行的测试要少但是依然很重要。

　　我们还需要测试UI，但是通过UI进行的自动化测试本身就非常脆弱、维护费用高且运行缓慢。因为最终想使UI测试所占的比例尽量最小，所以它就处在金字塔的最顶端。尽管如此，与其他团队一样，我们从图形用户界面（GUI）冒烟测试（smoke test）开始，来获取一些代码防护。所以，从这个角度，我们的金字塔是上下颠倒的，但是没关系———最终我们会将它翻转过来。（我们最终花了4年时间才获得为之努力的三角形形状！）

图1-1　自动化测试金字塔

　　【小窍门】

　　解决问题的最直接途径未必是最佳途径。

　　我们现在明白了我们需要做什么，所以我们开始着手实施那个能给我们带来最大实惠的任务。

　　1.3.2　建立构建过程

　　我们只有4位程序员，但是他们会经常检查源代码控制系统中的变化。我们需要确保他们没有不小心修改别人的内容或者破坏现有的任何功能。同时，我（测试人员）有时候不得不等待好几天，部署在测试环境中的代码才能完成一次构建。一个自动化的构建过程（build process）将保证在每次检入后的几分钟内，最新代码的可部署版本就是可用的。

　　管理层向我们强调了质量是我们的第一目标，他们乐意宽限一些时间来让我们搭建一个好的基础结构。

　　【真知灼见】

　　好的管理者会准许团队花时间去开发自动化的基础结构。

　　我们停下正在做的事情，使用CruiseControl和一个新的Linux服务器建立了一个持续集成（Continuous Integration, CI）过程。因为我们还没有可以运行的任何测试实例，所以只是简单编译代码和构建可部署的二进制文件。我可以看到每次构建的检入文件并能够选择想部署到产品中的二进制文件。这很有用，但是还不够。

　　1.3.3　获取测试的基准：GUI冒烟测试

　　程序员正在学习如何使单元测试自动化并编写测试先行（test-first）的代码，但是要真正实施测试驱动开发需要花好几个月的时间。针对遗留代码，使用GUI冒烟测试可能是一个快速获得自动化测试覆盖的途径。但是使用什么工具最好呢？

　　我们有购买一个付费工具的预算资金，但是团队里的程序员是Java程序员，他们万不得已是不愿意使用另一种脚本语言来进行测试的。捕获/回放并不适合我们，因为我们需要可维护的、稳定的测试脚本。我们选中了 Cannoo WebTest——一个可以让我们修改XML文件中的测试用例，并使用Ant运行它们的开源框架。而且它很容易与我们的构建过程集成。