CODING DevOps 系列第五课：微服务测试——微服务下展开体系化的微服务测试

微服务测试的痛点与挑战

这张图能够形象地展现单体服务和微服务的对比，单体应用就像左边巨大的集装箱，软件模块和应用都包括其中；而微服务就像是由一个小集装箱组成，微小的服务组成一个庞大、完整的系统。单体服务是一个大而全的应用体，而微服务由拆分红出来的不少小服务来组成一个庞大而完整的系统。

微服务是一种架构模式，是面向服务型架构 SOA 的一种变体，提倡将单一应用程序逐渐还原划分红小的服务，服务间互相协调、互相配合，为用户提供最终价值。微服务架构风格就是一些小而自治的服务协同工做造成松耦合的系统。另外，咱们须要尽可能避免一个统一的、集中式的服务管理机制，对具体的一个服务而言，应该根据上下文选择合适的语言工具对其进行构建。

结合下方的这张图，咱们能够理解微服务构建的核心实际上是中间领域的业务逻辑，围绕着这个领域业务逻辑，会有一些微服务去进行拆分构建。

微服务具备专一、自治、独立进程、独立部署和技术异构的特色，即每一个服务只限定于特定的业务而专一作一件事情，每一个服务承担的是单一职责，可是它也须要达到必定规模可以完整的处理特定的领域业务。不少人都会被微服务的“微”这个词所误导，认为微服务就是要拆分的越小越好。可是其实为了“微”而将同一领域的业务拆分到不一样的服务，只会徒劳增长软件的复杂度和维护困难。

咱们能够围绕应用的业务能力进行分组，每一个小组的开发组人员开发微服务的技术能够不受限制。每一个服务小组可使用不一样的技术架构和存储技术，有针对性地解决一些性能瓶颈问题。每一个服务是互相独立部署互不影响的，这样的话咱们能够实现独立打包、独立测试和独立附属，减小部署时间，提高研发效率。

微服务架构测试具备三个痛点：1、如何测试微服务的外部依赖是否正常；2、如何在微服务架构下验证系统的整个功能是否符合预期；3、这么多微服务的部署和测试，应如何开展。按照以上痛点咱们能够看到，微服务测试是一种验证成本高、结果不稳定、反馈周期长的测试。

测试金字塔

测试金字塔实际上是一种方法论，解决微服务测试的关键在于将微服务的测试按照不一样的力度来分组。测试金字塔的概念由麦克科恩首先提出。测试是分层次的，咱们看到图片左边，这个金字塔被分为三个层次，从下往上分别是单元测试、服务测试、界面测试，从下往上测试的运行速度是逐渐减慢的，外物依赖或者服务间的依赖从下到上会依赖更多。这个测试金字塔的另一个重要特征是，从下往上对每一层的测试代码是逐层减小的。下方应该写一些小而快的测试，往上应该编写一些粗粒度的测试，编写更少的高层次测试。

然而实际中若是以这个金字塔图来做为指导，会过于笼统简单，因此咱们会采用右边的分为四层的测试金字塔来作内部测试的指导思想。底层是单元测试，在这之上是集成测试，再往上是端到端的测试，顶层是探索测试。

做为开发人员或测试人员，应该关注金字塔的哪些部分呢？微服务开发人员应更多关注位于塔基底部的单元测试与集成测试。在这两层须要开发人员编写必定量的测试代码来保证覆盖，应该写许多小而快的单元测试覆盖绝大部分的业务场景，再写必定的粗粒度的集成测试，来测试重要系统之间外部依赖的交互是否正常。测试人员和质量保证人员应更多关注金字塔上面两层，测试人员能够依据 BDD 的规范来编写测试用例，用于校验系统功能的交互是否正常，还能够用很是规的手段进行破坏性的探索测试。

单元测试是测试金字塔的底基，它的定义没有标准答案。从编程角度来看，在函数式语言中咱们能够认为一个函数是一个单元，在面向对象的语言中一个方法或者一个类能够表示一个单元。单元测试具备可以及时发现 bug、利于重构、保证代码质量的优点，咱们系统中须要编写得最多的其实就是单元测试。

微服务的测试通常是对入栈适配器、业务逻辑和出栈适配器这三部分进行测试。入栈适配器测试的是 Controller API 是否正确；业务逻辑部分测试 Service 业务逻辑是否正确，而出栈适配器部分测试的是 SQL 逻辑是否正确。单元测试通常会遵循一个通用的 3A 结构：Arrange，Act，Assert，这样写出来的代码更有阅读性和表达力。

在微服务架构下咱们所理解的集成测试是测试应用与外部依赖的集成。第三方外部服务依赖主要有两种类：第一种是微服务会依赖第三方系统的服务；第二种是系统内部的微服务与微服务之间，一种服务可能会依赖另外一种微服务来实现自身逻辑。对应这两种状况会有不一样的策略，第一种策略是准备真实的外部服务的依赖，第二种是使用测试替身隔绝外部依赖。进行集成测试的时候咱们一般会使用一些，依赖第三方服务的话会采用 WireMock 或者 mountebank，而微服务之间的依赖调用会使用 Spring-Cloud-Contract 或者 Pact。

微服务之间的测试会使用契约测试，服务之间的接口文档就是一个契约。契约测试能够解决联调成本太高，接口变更把控困难，契约变化时提供一种可当即被服务端和消费端发现的方式，这三种痛点。契约测试的提供者指微服务接口的提供者，消费者指微服务接口的消费者。契约文件是微服务提供者和消费者共同定义的接口规范，包括接口的访问路径和输出数据。

CDC 的核心思想在于从消费者业务实现的角度出发，由消费者本身定义须要的测试数据格式以及交互细节，并驱动生成一份消费者契约。而后生产者根据契约来实现本身的逻辑，并在服务提供者端进行测试验证。契约文档应该被转换成一个存根。生产者会根据契约编写契约验证测试，契约验证测试经过会将契约文件转换为存根，存根会被消费者引用，契约的修改会致使任意一方测试的失败。这样的话能够保证契约被消费者和生产者共同遵照。

契约测试适用于微服务接口的消费者和提供者由不一样的团队维护，或提供者接口被多个消费者消费这样的场景中。

端到端测试主要用于验证工做流程中的全部流程，以检查一切是否按照预期工做，确保系统以统一的方式工做，从而知足业务需求。端到端测试的难点在于安装和配置相关依赖，测试数据的自动准备二号服务的自动部署。

微服务测试蓝图

作微服务测试须要作 TDD，也就是测试在先，编码在后的开发实践。有别于以往的先编码、后测试的开发过程，而是在编程以前，先写测试脚本或设计测试用例。TDD 能够增长开发人员代码质量的信心，有利于代码设计和重构，以及快速迭代和持续交付。

微服务测试推动主要分为四步：第一步是工具，依照微服务测试层次，阶段选择合适的测试框架与工具；第二步是依据测试金字塔制定规范，贯穿生命周期始终，明确开发、测试人员的职责；第三步是自动化，贯穿 CI、CD 流程，与 DevOps 的融合；第四步是测试平台搭建，以容器化技术搭建测试平台，以 namespace 隔离不一样测试环境。

点击观看完整课程视频