众所皆知，测试应该自动化。敏捷强调要实现测试自动化，但是我们往往都做的不够多、不够快、甚至可能根本没有做。我认为，测试自动化不足的主要原因之一是因为我们关注错了自动化的层次。大多数团队都把精力集中在单元测试和UI测试上，却忽略了服务层测试。
　　为了说明为何服务层测试如此有价值，让我们仔细观察下测试自动化金字塔的每一层。


　　
图 测试自动化金字塔

　　单元测试
　　单元测试构成了测试自动化金字塔的基础。因此，它应该是可靠的测试自动化策略中的大部分。自动化的单元测试是非常棒的，因为它能够向程序员提供具体的错误数据。例如，自动化的单元测试报告说“在第56行有一个BUG”，那么程序员可能真的会在62行附近找到这个BUG，相对而言测试人员只能告诉“在你从数据库中检索成员记录的过程中出现了BUG”，这意味着你可能需要在1000行以上的代码中查找这个BUG，自动化的单元测试的优越性在于它能够大大缩小对缺陷存在范围的定位。此外，由于通常采用与系统开发相同的语言编写，所以程序员更适合编写单元测试。
　　UI（用户接口）测试
　　相比之下，我们想尽可能少的做UI自动化测试。为什么？因为UI自动化测试更加脆弱、昂贵和花时间。例如，假设我们希望测试一个非常简单的计算器，这个计算器允许用户输入两个整数，点击一个乘或者除按钮，能够看到运算结果。如果要通过UI进行测试，我们需要编写一系列的测试脚本来驱动UI，例如往各字段中输入适当的数据，按动乘或除按钮，然后比较期望数值和实际数值。这种测试有用，但是并不理想。
　　此外，用这种方式测试一个应用是部分冗余的——思考一下这样一套测试需要对UI进行多少次测试。每个测试用例都调用了乘除按钮相关的代码和进行函数运算的代码，每个测试用例还会测试显示结果的代码，等等。像这样通过用户接口进行测试，是非常昂贵的，应该尽量少。
　　服务层测试
　　然而这并不意味着我们不需要对特性进行测试。我们需要是找出一种合适的方法来避开UI执行测试，这是测试自动化金字塔中服务层测试的由来。在我们采用的这种测试方法中，“服务”是指应用程序对某个输入或者某一套输入做出的响应。在我们的计算器例子中涉及到两个服务：乘法和除法。服务层测试是独立于用户界面外对应用程序服务进行的测试。因此如果要测试十几个乘法测试用例，我们不通过计算器的用户界面而是通过服务层来执行这些测试用例。与在用户层执行同样的测试用例相比较，这样做更加有效而不繁琐。
　　自动化的单元测试是非常棒的，但它只能覆盖应用程序的部分测试需求。UI测试通常是必须的，但是应当少量使用。服务层测试弥补了单元测试和UI测试间的空白；以更小的工作量和成本满足了团队的自动化测试需求。