这是由来自AWS的工程师Nathan Peck发布的“测试微服务”系列文章的第一篇，介绍了测试金字塔模型以及如何建立测试文化。以下内容翻译自Nathan的博客。

自动化测试是一个软件公司取得成功的关键因素之一。经过严格测试的代码容易获得客户的信赖，而没有经过测试或缺乏严密测试的软件系统容易出现故障，让客户感到失望。

尽管在测试单体系统方面已经有很多最佳实践，但在测试分布式系统（比如微服务）时仍然面临很多挑战。开发者不但要确保每个组件的内部行为是一致的，也要确保组件之间能够良好地集成。分布式系统需要额外的故障测试，比如针对网络故障进行测试。有些分布式系统太过庞大，进行完整的端到端测试不太现实，所以开发人员需要制定一些策略，对整体架构的局部进行单独测试，同时还能保证组件之间的互操作性。

这篇文章介绍了一些测试分布式系统的基础概念，并讨论了如何在开发流程中加入这些概念，确保它们可以有效地落地。

金字塔模型

为了构建一个全面的测试框架，我们需要先了解“测试金字塔”概念。这一概念是由Mike Cohn提出的，当时的大部分软件测试还是通过用户界面进行的。测试工程师直接手动操作用户界面，或者编写自动化宏脚本来操作界面。这种方式通常无法检测出代码内部的问题。此时，测试金字塔的概念就变得十分重要，因为它让我们明白，用户界面测试应该处于金字塔的顶端。

使用多种测试类型可以帮助我们检测出不同类型的问题，不同的测试类型集中在系统的不同层面上。一个分布式系统的端到端测试可以被分为以下几个层次。

　　单元测试

单元测试用于验证服务内部的类方法或函数的行为。它们执行代码文件里的类方法或函数，提供不同的输入，并验证与每一个输入相对应的输出。

集成测试

集成测试用于验证服务的外部行为。测试框架会启动服务的一个实例，并调用服务的外部接口来执行业务逻辑。

端到端测试

端到端测试用于验证多个服务之间的交互行为。在一个独立的环境里启动多个服务的实例，让服务实例间发生交互，以便完成测试。端到端测试需要发起网络请求，比如REST请求，然后被调用的服务返回的响应进行验证。

用户界面测试

用户界面测试用于验证整个平台的行为，不仅会测试客户端的逻辑，也会测试后端系统的逻辑，确保客户端和后端系统能够正常交互。

建立测试文化

只有把测试作为开发流程和发布管道不可或缺的组成部分，才能让它发挥应有的作用。如果代码有问题，就不应该把它发布出去。

无法通过测试的代码不应该被合并到代码仓库里。无法通过测试的代码不应该被发布出去。

金字塔模型里的每个测试层级都建立在下一个层级之上：

工程师们需要对测试抱有正确的态度，他们不仅要开发功能，也要负责编写测试代码，所以他们在很大程度上决定着测试的质量和效率。如果没有认真对待测试，就无法测出很多边界情况，又或者为了提高“覆盖率”而走捷径，但其实什么都没有测到。

我们不能为了测试而测试，测试的真正目的是为了交付高质量的软件给用户。测试人员要保证软件质量高起高走，在加入新特性或更改已有特性时仍能保证质量。

这就要求我们要严肃对待故障测试，我们不能为了让测试能够通过而去修改它们。有些测试时而通过时而失败，它们都是假性的测试，需要引起我们的注意。如果生产环境出现了缺陷，说明测试没有到位。如果发现了测试没能覆盖到的地方，需要给工程师足够的时间和资源去修复缺陷。

我们不能仅仅依赖工程师来建立良好的测试文化。产品经理也需要了解测试流程，并参与其中。如果他们对开发人员作出过分的要求，要求开发新功能的速度超过了开发人员能够对新功能作出全面测试的速度，那么软件质量就会受到影响，问题会一路跟着进入到测试管道，到达用户那里，影响用户满意度。

结论

为分布式系统创建完备的测试框架要求使用多个层级的测试。基于客户端UI的测试无法捕捉到各种类型的错误。软件工程师们必须建立起一种测试文化，把自动化测试融入到开发和发布管道的各个阶段，包括单元测试、集成测试、端到端测试和UI测试。

查看英文原文：Microservice Testing: Introduction

感谢郭蕾对本文的审校。