微服务测试的 12 项实用技术

作者丨Wojciech Bulaty，Liam Williams

译者丨平川

本文要害

微服务架构对在线（长途）依靠项的依靠较多，而对进程内组件的依靠较少，您的测验战略和测验环境需求习惯这种改变。

当运用现有技能（如服务虚拟化）测验单体运用时，您不用一同测验一切内容；相反，您能够分而治之，测验单个模块或一组关系密切的组件。

当运用微服务时，还有几个选项可供挑选，由于微服务一般布置在容器（如 Docker）环境中。

您需求办理相互依靠的组件，以便在测验微服务时能够有效地运用时刻及操控本钱。您能够在微服务测验中运用测验替身（Test Double）到达测验意图。

依据您的需求，您能够选用本文列出的其间一个选项或许多个选项的组合。

微服务架构和依据容器的基础设施的组合需求一个合适这个美丽新世界的测验战略。微服务架构对在线（长途）依靠项的依靠较多，而对进程内组件的依靠较少，您的测验战略和测验环境需求习惯这种改变。

在线通讯越多，测验微服务之间的衔接和契约所需的精力就越多。此外，在搬迁到依据容器的基础设施时，能够运用若干新的测验技能来处理选用微服务时常常出现的组件依靠。

从上市时刻、本钱和危险的视点挑选测验技能。

当运用服务虚拟化等技能测验单体运用时，您不用一同测验一切内容。相反，您能够分而治之，测验单个模块或或一组关系密切的组件。您能够创立安全的阻隔环境让开发人员测验他们的作业。在测验单体运用时，运用服务虚拟化让您能够将测验环境与相关组件解耦，并削减以下问题的影响：

难以预备或装备相关组件

测验数据预备本钱高，耗时多

团队由于其他团队没有及时交给 API 而受阻

测验环境时刻调度

当运用微服务时，您的挑选更多，由于微服务一般布置在容器（如 Docker）环境中。在微服务架构中，您的团队或许会运用更广泛的测验技能。此外，由于微服务更多地经过网络进行通讯，所以需求更彻底地测验网络衔接的影响。运用更合适新架构的东西和技能能够缩短上市时刻，降低本钱和危险。

许多 IT 部分运用或保护着选用单体架构开发和布置的体系。典型的单体架构具有以下特色：

从事运用程序相关作业的人员被安排成独立的专家团队：UI 开发人员、中间件开发人员、后端开发人员、数据库办理员和体系办理员。

办理由架构师会集进行——例如，有一组用于代码质量、安全原则和测验办法的大局规矩。

数据会集办理，因而，单体运用程序一般依靠于单个大型数据库。

主动化程度或许很低，有一些主动化测验，可是很少有基础设施主动化。

运用程序开发人员的安排结构常常会影响代码和测验环境的安排办法；这种效应被称为康威规律。一般，代码会被分红几个组件层，如 UI、服务和存储库。每个层都是一个单体，它们将被布置到同享环境中，一般包含开发、QA 和用户检验测验（UAT），参见图 1。

许多单体体系都是由功用竖井团队构建的，例如，运营团队是一个独自的实体，有独自的时刻表。向这样的安排引进容器化办法需求做出革新，这或许会十分耗时，由于它触及供给新的基础设施、训练职工以及为搬迁到新办法创立搬迁方案。

这意味着，从单体架构中解耦依靠项的技能常常局限于那些不需求容器的技能，它们运转在进程中，或许是在运营团队供给的已有的 VM 或硬件上。不需求容器化的技能包含：

运用测验替身，如 stub、 mock 或虚拟服务；

衔接到后端或第三方体系中的实在测验实例；

契约测验。

依据康威规律，沟通形式杂乱的功用竖井团队会创立出通讯形式相同杂乱的单体。这意味着用于服务虚拟化的东西有必要十分强壮，能够支撑杂乱的作业流和许多技能（例如，许多通讯协议），这取决于被测体系（单体运用程序）的杂乱性和测验用例的杂乱性。

一般，会有一个独自的团队担任创立后端或第三方服务的 stub、mock 或虚拟服务。这常常会在担任服务虚拟化的团队中引起作业抵触，导致测验基础设施预备时刻很长，保护本钱很高。

在微服务架构中，你会发现：

团队是环绕事务功用安排的，例如由多名 UI、中间件和后端开发人员、数据库办理员和 DevOps 专家组成的跨功用团队；

去中心化办理，答应每个团队挑选合适其作业的恰当东西；

去中心化数据办理，答应每个微服务或每一组相关的微服务办理自己的数据；

测验、布置和基础设施一般主动的，很少或没有人为干涉。

这将影响到运用什么技能解耦微服务及其依靠项来到达测验意图。由于不需求满意一切团队需求的同构技能栈，所以每个团队一般都有更多满意其特定需求的选项能够挑选。

关于微服务测验，解决方案主要是那些能够用于单体架构的解决方案（它们也适用于微服务）以及那些专门为微服务架构而规划的解决方案。

可用于单体架构的办法包含：运用测验替身，如 stub 、 stub 或虚拟服务；衔接到后端或第三方体系的实践测验实例；契约测验。

可用于微服务架构的办法有测验容器（如数据库测验容器、服务虚拟化测验容器）、第三方服务测验容器（如 Redis 测验容器、ESB 测验容器或虚拟设备测验容器）和把留传单体运用装盒。

关于怎么编写微服务测验战略的文章和讲演已经有许多。下面是一些资源，供参阅：

“微服务架构的测验战略”，Toby Clemson，ThoughtWorks（2014 年 11 月 18 日）

“微服务测验”，André Schaffer，Spotify（2018 年 1 月 11 日）

“微服务测验：从开发到出产”，Daniel Bryant，JAX London（2018 年 10 月 9 日）

您将运用许多用于单体架构的测验技能，并触及容器的新技能。可是，不同测验技能的适用性或许会发生改变，由于微服务架构中的反应循环更严密，由于团队一般在一同并且是跨功用的。

上面列出的参阅资料有一个一同的主题，即您需求办理相关组件，以便在测验微服务时能够有效地运用时刻及操控本钱。依据需求，您能够挑选本中列出的其间一个选项，或许多个选项的组合。

在测验中运用依靠项

用于微服务测验的测验环境或许运用实在的依靠项，而不是测验替身。

在测验场景中，微服务能够与以下几种组件类型通讯：

您能够运用另一个微服务的测验实例来测验您的微服务。例如，在测验微服务 A 时，将其衔接到微服务 B 的测验实例并将它们一同测验。

您能够运用另一个微服务的出产实例来测验您的微服务。例如，在测验微服务 A 时，将其衔接到微服务 B 的出产实例，并在将微服务 A 发布到出产环境之前将它们一同测验。

您能够运用第三方依靠项测验微服务。例如，在测验微服务 A 时，将其衔接到第三方体系的出产实例。

您能够运用留传的非微服务内部依靠项来测验微服务。例如，在测验微服务 A 时，您将它衔接到已有的本地运转的大型机体系的测验实例。

您能够运用非软件（硬件）依靠项测验微服务。例如，在测验微服务 A 时，将其衔接到担任完结服务的硬件设备。

除了上面列出的组件外，接下来，咱们将列出能够在微服务测验中运用的特定于测验的依靠组件。

当然，您能够在微服务测验中运用所谓的测验替身，它们会假充实在的依靠项。你有几种技能能够挑选，这取决于依靠项的类型和手头的问题：

Mock （进程内或经过网络 / 长途）用一个特定于测验的目标替换微服务所依靠的目标，以验证微服务是否正确地运用了它。

Stub （进程内或经过网络 / 长途）用一个特定于测验的目标替换微服务所依靠的目标向微服务供给测验数据。测验数据能够是静态的，也能够是动态的。

模拟器（进程内或经过网络 / 长途）是 stub 的智能版别，它仿照微服务所依靠的体系的一些行为。例如，您不需求在测验中衔接到实在的付出体系，而是能够衔接到一个部分完结了可观测付出功用的模拟器。

服务虚拟化（经过网络 / 长途）也称为 API simulation 或 API mock。它的做法是，运用强壮的服务虚拟化东西创立测验版别，替换实在的依靠组件。服务虚拟化东西供给一种相似模拟器的体会，可是削减了开发人员和测验人员的作业量。与为每个依靠项构建自界说的测验替身不同，有现成的东西能够处理常见的需求手写完结的样板功用。服务虚拟化东西供给的特性一般比 stub 或 mock 多，比方记载请求和呼应，或许内置对 HTTP、JMS、FTP 或 gRPC 等多种技能的支撑。

您能够运用一个内存数据库来替代实在的数据库实例用于测验。

您能够运转一个测验容器，即一个坐落容器中的针对每个构建或管道的依靠项的测验实例，而不是运用跨多个团队、构建或管道同享的实例。例如，您能够运用数据库测验容器或服务虚拟化测验容器。

您能够把留传单体运用装盒。您能够在容器中运转留传体系，而不是依靠于同享的测验环境。您能够依据自己的测验需求来装备它。

契约测验

在运用相似微服务这样的松耦合组件时，契约测验是一个要害部分。

契约描绘组件之间怎么通讯和交互，包含组件之间的音讯格局（语法）和组件的行为预期（语义）。您能够运用契约测验来验证组件之间的契约是否得到履行，从而使您信任这些组件能够协同作业。当您运用特定于测验的依靠组件（例如测验替身）时，您还能够运用契约测验来保证它们契合最新的或任何特定版别的契约。以下是测验或办理组件之间的契约的几种办法：

在契约快照测验中，您的测验替身代表了组件之间在某个时刻点上的契约快照。该快照或许会过期。您能够以主动化的办法测验契约快照。

契约快照改写让您能够从头记载（改写）组件之间的契约。一般，改写要考虑语法，并在必定程度上考虑契约的语义。要进一步了解语法和语义测验，请参阅顾客驱动的契约测验。

顾客驱动的契约测验是完好微服务测验战略的一个组成部分。顾客驱动的契约分为出产者和顾客。顾客驱动的契约测验验证出产者是否供给了满意一切顾客希望的契约。顾客验证出产者是否供给了它们需求的音讯结构和行为。

针对每个契约的小范围集成测验能够测验微服务中的衔接器模块和依靠组件之间的契约。一般，在这种情况下，契约更多地是出产者驱动的，而不是顾客驱动的。

如果您想要两个依靠组件独立发布，请运用面向独立组件发布的契约测验。您有必要记住测验最新工件和出产工件的组合。

端到端（E2E）测验意味着验证一切组件在完结用户旅程时都能很好地协同作业。这意味着组件之间的契约在跨体系履行用户旅程测验时得到了隐式验证。

总结

在测验微服务时，有许多办理依靠组件的技能。本文给出的信息应该能够添补一些空白，并协助您界说开发和测验战略（包含测验金字塔）。

在第二部分中，咱们将依据团队的成熟度、改变速度、上市时刻、本钱和危险来比较这些技能。

关于作者

Wojciech Bulaty 专心于灵敏软件开发和测验架构。他在灵敏、主动化、XP、TDD、BDD、结对编程和整齐编码方面有十多年的实践编程和领导经验。他最新供给的服务是 Traffic Parrot ，经过供给 API mocking 和服务虚拟化东西协助运用微服务的团队加快交给、进步质量和缩短上市时刻。

Liam Williams 是一位主动化专家，专心于运用高质量的软件解决方案改进简单犯错的手艺流程。他是一个开源贡献者和一些小型库的作者。最近，他加入了 Traffic Parrot 的团队，将注意力转向了搬迁到现代微服务架构时测验体会的改进问题上。

https:///articles/twelve-testing-techniques-microservices-intro/

点个在看少个 bug