测试金字塔实战

“测试金字塔”是一个比喻，它告诉我们要把软件测试按照不同粒度来分组。它也告诉我们每个组应该有多少测试。虽然测试金字塔的概念已经存在了一段时间，但一些团队仍然很难正确将它投入实践。本文重新审视“测试金字塔”最初的概念，并展示如何将其付诸实践。本文将告诉你应该在金字塔的不同层次上寻找何种类型的测试，如何实现这些测试。

2018 年 2 月 26 日
作者：Ham Vocke

---

Ham 是德国 ThoughtWorks 的一名软件开发和咨询师。由于厌倦了在凌晨 3 点手动部署软件，他开始持续交付实践，加紧自动化步伐，并着手帮助团队高效可靠地交付高质量软件。这样他就可以把省出来的时间用在别的有趣的事情上了。

目录

• 测试自动化的重要性
• 测试金字塔
• 我们用到的工具和库
• 应用例子
  • 功能
  • 整体架构
  • 内部架构
• 单元测试
  • 什么是单元？
  • 社交和独处
  • 模拟和打桩
  • 测试什么？
  • 测试架构
  • 实现一个单元测试
• 集成测试
  • 数据库集成\
  • REST API 集成
  • 几个独立服务的集成
  • JSON 的解析和撰写
• 契约测试
  • 消费者测试(我们团队)
  • 提供者测试(其他团队)
  • 提供者测试(我们团队)
• UI 测试
• 端到端测试
  • 用户界面端到端测试
  • REST API 端到端测试
• 验收测试 - 你的功能工作正常吗?
• 探索测试
• 测试术语误解
• 把测试放到部署流水线
• 避免测试重复
• 整洁测试代码
• 结论

---

准备上生产环境的软件在上生产之前需要进行测试。随着软件开发行业的成熟，软件测试方法也日趋成熟。开发团队正在逐渐自动化大部分的测试，以此取代大量测试人员手工测试。通过自动化测试，开发团队可以分分钟就知道他们的软件是否被破坏，而不是后知后觉几天后才知道。

自动化测试极大地缩短了反馈周期，这与敏捷开发实践、持续集成、DevOps 文化等是一脉相承的。拥有高效的软件测试方法，可以让你的团队快速而自信地前行。

本文将探讨一个具备高响应力的、可靠并且可维护的测试组合应该如何构建，这与你具体构建的是一个微服务架构、移动应用程序或者物联网生态系统都无关。此外，我们还将详细介绍如何写出高效且可读的自动化测试。

（测试）自动化的重要性

软件已经成为我们日常生活中的一个重要组成部分。早期它仅仅用于提高企业的效率，但如今它的作用远不止如此。如今许多公司都想方设法成为一流的数字化公司。作为用户，我们每天使用的软件越来越多。创新的车轮正加速向前滚动。

如果你想跟上时代的步伐，你必须研究如何在不牺牲质量的情况下更快地交付你的软件。持续交付——一种高度自动化的、确保你可以随时将软件发布到生产环境中的实践——正能帮你达到这个目的。它通过构建流水线自动测试你的软件，自动将其部署到测试和生产环境中。

软件的数量正以前所未有的速度增长，手动进行构建、测试和部署，很快就会变得不可能——除非你想把所有的时间都用来进行手动重复的工作，而不是用来开发可工作的软件。将一切自动化，从构建到测试，从部署到基础架构，这是你唯一的出路。

（使用构建流水线来自动并可靠地将你的软件部署到生产环境）

传统的软件测试过于依赖手工操作：首先将应用程序部署到测试环境，然后执行一些黑盒测试，例如，通过点击用户界面来查看一切是否工作如常。通常这些测试将由文档指定，以确保测试人员每次测试的内容是一致的。

很明显，手动测试所有更改非常耗时、重复而且繁琐。重复很无趣，无趣就容易犯错，这样子还没测到这周工作结束你就会想找下一份工作了。

幸运的是，重复性劳动还是有药可治的：自动化。

自动化繁琐重复的测试将给软件开发人员的生活带来重大改变。自动化这些测试后，你就不需要再一味遵循测试文档点点点以确保软件是否仍正常工作。自动化这些测试，你可以充满自信地修改你的代码。如果你曾试过在没有适当自动化测试的情况下进行大规模重构，那你应该知道这种体验多么恐怖。你怎么知道你是否意外地破坏了某些功能呢？显然，你需要将所有的测试用例手动点一遍。不过老实说，你真的享受这个过程吗？你想象一下，如果你对代码做了大规模改动后惬意地喝了一口咖啡，喝完咖啡后就能马上得知你的改动有没有破坏原有功能。这样的开发体验是不是听起来就让人舒服多了？

测试金字塔

如果你真的想为你的软件构建自动化测试，你必须知道一个关键的概念：测试金字塔。Mike Cohn 在他的着作《Succeeding with Agile》一书中提出了这个概念。这个比喻非常形象，它让你一眼就知道测试是需要分层的。它还告诉你每一层需要写多少测试。

（测试金字塔）

根据 Mike Cohn 的测试金字塔，你的测试组合应该由以下三层组成（自下往上分别是）：

• 单元测试
• 服务测试
• 用户界面测试

不幸的是，如果你仔细思考就会发现，测试金字塔的概念有点太短了。有人认为，Mike Cohn 的测试金字塔里的命名或某些概念不是最理想的。我也同意这一点。从当今的角度来看，测试金字塔似乎过于简单了，因此可能会产生误导。

然而，由于其简洁性，在建立你自己的测试组合时，测试金字塔本身是一条很好的经验法则。你最好记住 Cohn 测试金字塔中提到的两件事：

• 编写不同粒度的测试
• 层次越高，你写的测试应该越少

为了维持金字塔形状，一个健康、快速、可维护的测试组合应该是这样的：写许多小而快的单元测试。适当写一些更粗粒度的测试，写很少高层次的端到端测试。注意不要让你的测试变成冰淇淋那样子，这对维护来说将是一个噩梦，并且跑一遍也需要太多时间。

不要太拘泥于 Cohn 测试金字塔中各层次的名字。事实上，它们可能相当具有误导性：服务测试是一个难以掌握的术语（Cohn 本人说他观察到很多开发人员完全忽略了这一层）。在单页应用框架（如 react，angular，ember.js 等）的时代，UI 测试显然不必位于金字塔的最高层，你完全能够用这些框架对 UI 进行单元测试。

考虑到原始名称的缺点，只要在你的代码库和团队讨论中达成一致，你完全可以为测试层次提供其他名称。

我们将使用的工具和库

• JUnit : 测试执行库
• Mockito: 模拟依赖
• Wiremock: 为外部服务打桩
• Pact: 用于编写消费者驱动的契约测试
• Selenium: 用于编写用户界面驱动的端到端测试
• REST-assured: 用于编写 REST API 驱动的端到端测试

示例应用

我已经写好了一个简单的微服务应用，其中涵盖了测试金字塔各种层次的测试。

示例应用体现了一个典型的微服务的特点。它提供了一个 REST 接口，与数据库进行通信并从第三方 REST 服务中获取信息。它是使用 Spring Boot 实现的，即使你之前从未使用过 Spring Boot，它也简单到应该让你很容易理解。

请下载 Github 上的代码。Readme 里写了你在计算机上运行应用程序及其自动化测试所需的说明。

功能

应用的功能十分简单。它提供了三个 REST 接口：

• GET /hello 总是返回"Hello World"
• GET /hello/{lastname} 根据 lastname 来查询人，如果查到了结果将返回"Hello {Firstname} {Lastname}"
• GET /weather 返回现在德国汉堡的天气情况

高层架构

从高层次来看，这个系统的结构是这样：

（我们微服务系统的高层架构）

我们的微服务提供了一个可以通过 HTTP 调用的 REST 接口。对于某些接口，服务将从数据库获取信息。在其他情况下，服务将通过 HTTP 调用外部天气 API来获取并显示当前天气状况。

内部架构

在内部，Spring Service 有一个典型的 Spring 架构：

（我们微服务的内部架构）

• Controller 提供 REST 接口，处理 HTTP 请求和响应
• Repository 和数据库打交道，关注数据在持久化存储里的读写操作
• Client 和别的 API 交互，在我们的应用里它会通过 HTTPS 从 darksky.net 获取天气情况
• Domain 这是我们的领域模型，它包含了领域逻辑（相对来说，在我们的示例中不甚重要）

有经验的 Spring 开发人员可能会注意到这里缺失了一个常用的层次：受Domain-Driven Design的启发，很多开发人员通常会构建一个由服务类组成的服务层。我决定不在这个应用中包含服务层。原因之一是我们的应用程序很简单，服务层只会成为一个不必要的中间层。另一个是我认为人们过度使用服务层。我经常遇到在服务类中写了全部业务逻辑的代码库。领域模型仅仅成为数据层，而不是行为（贫血域模型）。对于每一个稍有复杂度的应用来说，这浪费了很多让代码保持结构良好且易于测试的优秀方案，并且没能充分利用面向对象的威力。

我们的 repositories 非常简单，它提供简单的 CRUD 功能。为了保持代码简单，我使用了 Spring Data。 Spring Data 为我们提供了一个简单而通用的 CRUD 实现，我们可以直接使用而不需再造轮子。它还负责为我们的测试启动一个内存数据库，而不是像生产中一样使用真正的 PostgreSQL 数据库。

看看代码库，熟悉一下内部结构。这将有助于我们的下一步：测试我们的应用！

单元测试

单元测试将成为你测试组合的基石。你的单元测试保证了代码库里的某个单元（被测试的主体）能按照预期那样工作。单元测试在你的测试组合里测试的范围是最窄的。它的数量在测试组合中应该远远多于其他类型的测试。

（一个用测试替身隔绝了外部依赖的典型单元测试）

一个单元指的是什么？

如果你去问三个人同样的问题：“单元”在单元测试的上下文中意味着什么，你很可能会获得四种非常相似的答案。某种程度上讲，对“单元”的定义取决于你自己，因此这个问题没有标准答案。

如果你正在使用函数式语言，一个单元最有可能指的是一个函数。你的单元测试将使用不同的参数调用这个函数，并断言它返回了期待的结果。在面向对象语言里，下至一个方法，上至一个类都可以是一个单元（从一个单一的方法到一整个的类都可以是一个单元）。

群居和独居

一些人主张，应该将被测试主体下的所有合作者（比如在测试里被你的类调用的其他类）都使用模拟或者桩替换掉，这样可以建立完美的隔离，避免副作用和复杂的测试准备。而有些人主张，只有那些执行起来很慢或者有较大副作用的合作者（比如读写数据库或者发送网络请求的类）才应该被模拟或者打桩替代。

偶尔有人会把用桩隔离所有依赖的测试称为独居单元测试，把和依赖有交互的测试成为群居单元测试（Jay Fields 的《Working Effectively with Unit Tests》这本书里创造了这些概念）。如果有空你可以继续深究下去，读一读不同思想流派各自的利弊在哪。

说到底，决定采用群居方式还是独居方式的单元测试其实并不重要。写自动化测试才是重要的。就我自己而言，我发现我自己经常两种方式都用。如果使用真正的合作者很麻烦，我就会用模拟对象或者桩。如果我觉得引用真正的合作者能让我对测试更有信心，我会仅仅打桩替代掉 service 最外层的依赖。

模拟和打桩(这里以及下文的桩都指 stub)

模拟对象和桩是两种不一样的测试替身（测试替身还不止这两种）。很多人会混用模拟对象和桩这两个概念。我认为，准确的用词会好点，并且最好能将它们各自的特性谙熟于心。你可以使用测试替身来替换掉真实的对象，给它一个可以更方便测试的实现。

换句话说，这意味着你是用一个假的实现来代替真的那个（例如，一个类，一个模块或者一个函数）。这个假的实现外表和行为和真的很像（都能响应同样的方法调用），只不过真实的响应内容是你在单元测试开始前就定义好的。

并不是在单元测试时我们才使用测试替身。还有很多精妙的测试替身能以非常可控的方式来模拟整个系统的功能。然而，在单元测试里使用模拟对象和桩的概率会更高（取决于你是喜欢群居风格还是独居风格的开发者），这主要是因为现代语言和库使得构建模拟对象和桩变得更加简单了。

不管你的技术选型是怎么样的，一般来说，编程语言的标准库或一些比较有名的三方库都会提供一些优雅的方式来帮你构建 mocks。即使需要自己编写 mock 对象，也只是写一个假类/模块/函数的事，只需要让它与真实的合作者有相同的签名，并设置到你的测试中去即可。

你的单元测试跑起来应该非常快。在一般的机器上跑完数千个单元测试应该只需要几分钟。为了得到快速的单元测试，你应该独立地测试代码库的每一小块，并避免进行真实的数据库操作、文件系统操作，或者发送真实的 HTTP 请求（使用模拟对象和桩来隔离这一部分）。

一旦你掌握了写单元测试的诀窍，你写起来就能越来越顺畅。打桩隔离掉外部依赖，准备一些输入数据，调用被测试的主体，然后检查返回值是不是你所期待的。看看测试驱动开发，让单元测试指引你的开发；如果使用得当，测试驱动开发将帮你进入一个非常顺畅的工作流，它能帮你创造出一个良好且可维护的设计，顺便还能送你一套全面且自动化的测试。当然，测试驱动开发并不是银弹。但是建议你尝试一下，看看它是否适合你。

应该测试什么？

单元测试有个好处，就是你可以为所有的产品代码类写单元测试，而不需要管它们的功能如何，或者它们在内部结构中属于哪个层次。你可以对 controller 进行单元测试，也可以用同样的方式对 repository、领域类或者文件读写