微服务架构下的软件测试实践

随着企业开发模式逐渐从传统的整体式（Monolithic）产品交付，向快节奏的微服务架构迁移，软件测试人员也必须相应地调整自己的测试方法和工具，才能多快好省地提高测试覆盖率，尽早发现潜在的缺陷。在快速迭代的背景之下，依然能够满足企业对产品质量的严格要求。

本文将结合 Martin Fowler、Rick Osowski 等行业大师们关于微服务的理论观点，以及我在 DevOps、自动化测试领域所积累的经验，向大家介绍怎样快速地构建起微服务的测试流水线（Pipeline）。本文主要面向的对象为：计划或者已经采用微服务架构的开发团队和测试人员。不敢奢言面面俱到，但求以实践经验的干货为主，避免重复读者们已经熟悉的概念，让大家有所收获或启示。

当我们提到微服务的时候，我们在说什么？

坊间关于微服务的介绍已经连篇累牍，相信读者都或多或少有所了解。那么对于测试人员而言，“微服务”到底有什么特点呢？

（1） 每个服务承担一定的职责：“尽可能小，但是又达到必要的规模。（as small as possible but as big as necessary）” 。

在问答网站 Quora 上，有一个著名的问题：什么是程序员觉得最浪费时间的事情？排名第一的回答中提到：“不必要的微服务。” 这句话揭示了企业在转向微服务架构时经常走入的误区。“微”固然重要，但是首要的是提供“服务”，这才构成“微服务”的价值。盲目地切分功能（Feature），却没有起到解耦合的作用，只是会增加维护、测试的成本。毕竟，多一项服务，就会多出一系列的流水线和测试要求。

（2）微服务之间通常通过 Rest over HTTP 连接。

最常见的连接/交互方式，即通过 POST、GET、PUT、DELETE 这些命令操作 API，通过 JSON 传递参数。这种简易、明确的交互方式为契约测试（Contract Test）提供了基础，本文《契约测试入门》小节将详细介绍。

（3）每种服务不一定提供用户界面。

这意味着每种服务的测试，并不一定能够或者需要从 UI 完成。这对 API 级别的集成化测试提出了要求，详见本文《了解集成测试》小节。

（4）微服务通常还可以划分为更小的模块。

如下图所示，一个典型的微服务可以分为这几个模块：资源、业务逻辑、数据存储接口、外部通信接口等。

微服务架构对于软件测试意味着什么？

综合微服务的上述特点，对于测试提出了什么要求呢？

开发团队采用的任何测试策略，都应当力求为服务内部每个模块的完整性，以及每个模块之间、各个服务之间的交互，提供全面的测试覆盖率，同时还要保持测试的轻便快捷。

以一个常见的开发团队为例，可能同时开发多个功能模块，有不同的开发进度和交付期限，但是整个团队又必须保证在固定的时间节点（譬如每月一次、每个 Sprint 一次，甚至每天一次），持续地为用户提供可以部署、使用的产品。这意味着，过去那种等待产品经理、业务部门提供需求，开发人员进行开发，最后交给测试人员集成测试的方法，已经无法提供足够的测试粒度和足够快的响应速度。

归结起来，与基于整体式架构的传统测试方法相比，微服务架构对测试提出了以下挑战：

• 服务/模块/层次（layer）之间存在复杂的依赖性：这意味着，如果想单独测试某一个服务，或者服务中的某个模块，就必须剥离它们对于其他环节的依赖关系。这需要通过 mock 等方式来实现，具体请见下文。
• 不同的服务可能会在不同的环境/设置下运行：特别是一些后端服务，与前端服务的运行环境可能截然不同。这时在考虑对每种服务设立自动化管线时，就必须有针对性的设置相应的环境配置。
• 涉及多个服务的 UI 端到端测试（End-to-End 测试，简称 E2E 测试）非常容易出错：因为每种服务的开发进度不同，集成不同服务的端到端测试往往会因为某一个服务的微小改动而出错。这种出错是测试人员希望避免的干扰信息。这意味着，对端到端测试的设计，必须采取一定的防干扰、防误报策略，详见本文《端到端测试的优化策略》小节。
• 测试结果可能取决于网络的稳定性：特别是涉及到数据存储和外部通信的部分，如果在测试中不摆脱这些因素的影响，就可能会得到一些随机性的误报，干扰测试结果。
• 与交付周期不同的开发团队之间的交流成本：这一点虽然跟技术无关，但是实际上会对测试人员的工作造成很大的困扰。因为开发模式分解为负责不同服务的多个小组，测试人员往往每天要花费大量的时间，了解不同团队的开发进度。如果还需要手动进行回归测试（Regression Test），最终将会不堪重负。所以自动化是必须采取的手段和方向。

如何应对这些挑战，我总结了下面这三个原则：

• 自动化：测试任务的增加，要求测试人员必须把主要的精力用于将测试自动化，摆脱手动测试带来的沉重负担。当然，自动化测试必须足够稳定、稳健，不能动辄误报，否则反而会导致很高的维护成本。
• 层次化：这意味着采用分层次的测试方法，粒度由细到粗，范围由小到大。下面这幅度说明了几个主要层次之间的关系：

最底层的是单元测试（Unit Test），粒度最细，速度最快，维护成本也最低