微服务用了哪些组件（微服务测试策略）

当涉及到测试时，微服务需要一种不同的方法。微服务测试金字塔更加复杂。以下是使用方法

每天‬分享‬最新‬软件‬开发‬，Devops，敏捷‬，测试‬以及‬项目‬管理‬最新‬，最热门‬的‬文章‬，每天‬花‬3分钟‬学习‬何乐而不为‬，希望‬大家‬点赞‬，评论，加‬关注‬，你的‬支持‬是我‬最大‬的‬动力‬。下方抖音有我介绍自动化测试，以及google cloud 相关视频课程，欢迎观看。

微服务应用程序是一组分布式程序，它们通过网络进行通信，偶尔与第三方服务和数据库接口。微服务由于其网络化的特性，比传统的庞然大物提供了更多的失败点。因此，我们需要一种不同的、更广泛的测试方法。

那么，我们如何测试微服务应用程序呢？测试金字塔还能用吗？当涉及到第三方服务，并且网络可能中断时，我们如何进行测试？我们将尝试在这篇文章中回答所有这些问题。

测试微服务的挑战

微服务体系结构是一个范式转变，其影响如此深远，以至于我们必须重新考虑传统的测试技术。微服务在许多方面不同于传统的单一结构:

• 分布式: 微服务跨多个服务器部署，可能跨地理位置部署，增加延迟并使应用程序暴露于网络中断。依赖于网络的测试可能由于代码没有错误而失败，从而中断 CI/CD 管道并阻塞开发。
• 自治: 只要不破坏 API 兼容性，开发团队就可以随时部署他们的微服务。
• 增加测试范围: 由于每个微服务至少公开几个 API 端点，因此需要覆盖更多的可测试表面。
• 多语言: 开发团队可以为他们的微服务选择最好的语言。在一个大型系统中，我们不太可能找到一个适用于所有组件的单一测试框架。
• 生产是一个移动的目标: 因为微服务是可独立部署的，并且是由自主团队构建的，所以需要额外的检查和界限来确保它们在部署时仍然能够正确地一起工作。

所有这些特点迫使我们思考新的测试策略。

微服务测试金字塔

测试金字塔是自动化软件测试的计划工具。在传统形式下，金字塔使用三种测试:

• Unit tests
• Integration tests
• End-to-end tests.

微服务金字塔增加了两种新类型: 组件测试和契约测试。

这是微服务测试金字塔的一个版本。在其他情况下，顺序可能会有所不同。有些可能包括集成层中的契约测试。事实是，金字塔更多的是一个指导方针，而不是什么写在石头上

让我们更详细地了解一下每个金字塔层是如何工作的

微服务的单元测试

单元测试是最细粒度(且数量最多)的测试形式之一。一个单元由一个类、方法或函数组成，这些类、方法或函数可以单独进行测试。单元测试是开发实践(如测试驱动开发或行为驱动开发)中不可分割的一部分。

与整体相比，微服务中的单元更有可能需要网络调用来完成其功能。当这种情况发生时，我们可以让代码访问外部服务ーー接受一些延迟和不确定性ーー或者用一个 test double 替换调用，这给了我们两种处理微服务依赖性的方法:

• 独立单元测试: 当我们需要测试结果总是确定的时候，应该使用这个。我们使用模拟或存根来将测试中的代码与外部依赖项隔离开来。
• sociable单元测试: sociable测试允许调用其他服务。在这种模式下，我们将测试的复杂性推送到测试或临时环境中。sociable测试不是确定性的，但是当它们通过的时候，我们可以对它们的结果更有信心。

我们可以使用测试双精度来单独运行单元测试。或者，我们可以允许测试代码调用其他微服务，在这种情况下，我们讨论的是sociable测试

正如你将看到的，平衡自信与稳定将是贯穿整篇文章的主题。嘲笑会让事情变得更快，减少不确定性，但是你嘲笑的越多，你就越不能相信结果。sociable测试尽管有缺点，但更现实。因此，您可能需要在这两种类型之间取得良好的平衡。

Contract Testing

每当两个服务通过一个接口耦合时，就会形成一个契约。合同规定了所有可能的输入和输出及其数据结构和副作用。服务的使用者和生产者必须遵守合同中规定的规则，才能进行通信。

契约测试确保微服务遵守契约。它们不会彻底测试服务的行为; 它们只是确保输入和输出具有预期的特征，并且服务在可接受的时间和性能限制内执行。

根据服务之间的关系，契约测试可以由生产者、使用者或两者运行。

• 消费者端契约测试由下游团队编写和执行。在测试期间，微服务连接到虚假的或模拟的生产者服务版本，以检查它是否可以使用其 API。
• 生产者方契约测试在上游服务中运行。这种类型的测试模拟客户端可以发出的各种 API 请求，验证生产者是否匹配契约。生产者端测试让开发人员知道什么时候他们将要破坏消费者的兼容性。

Contract tests 可以运行在上游或下游。生产者测试检查服务是否实现了根据服务而中断的更改。消费者测试针对上游生产者(而非真正的生产者服务)的模拟版本运行消费者端组件，以验证消费者可以发出请求并使用生产者的预期响应。我们可以使用诸如 WireMock 之类的工具来重现 HTTP 请求

如果合同双方都通过了测试，那么生产者和消费者是兼容的，应该能够进行通信。契约测试应该始终在持续集成中运行，以便在部署前检测不兼容性

您可以在约定5分钟的入门指南中在线进行契约测试。Pact 是一个基于 HTTP 的测试工具，用于编写和运行基于消费者和生产者的契约测试。

微服务集成测试

微服务的集成测试与其他体系结构的工作方式略有不同。目标是通过使微服务交互来识别接口缺陷。不像契约测试(其中一方总是受到嘲笑) ，集成测试使用真正的服务。

集成测试对评估服务的行为或业务逻辑不感兴趣。相反，我们希望确保微服务之间以及它们自己的数据库之间可以进行通信。我们正在寻找丢失的 HTTP 头和不匹配的请求/响应配对之类的东西。因此，集成测试通常是在接口级别实现的。

使用集成测试来检查微服务是否可以与其他服务、数据库和第三方端点通信

看看这个Vitaly Baum's 关于微服务的帖子 查看集成代码的实际测试

https://articles.Microservices.com/practical-microservices-integration-tests-and-stub-services-80749ce01050

微服务的组件测试

组件是一个微服务或一组微服务，它们在较大的系统中完成一个角色。

组件测试是一种验收测试，其中我们通过用模拟资源或模拟代替服务来隔离地检查组件的行为。

组件测试比集成测试更彻底，因为它们走的是快乐和不快乐的道路ーー例如，组件如何响应模拟的网络中断或错误的请求。我们想知道组件是否满足其消费者的需求，就像我们在验收或端到端测试中所做的那样。

组件测试对一组微服务执行端到端测试。模拟组件范围外的服务

执行组件测试有两种方法: 进程内测试和进程外测试

进程内组件测试

在这个组件测试的子类中，测试运行程序与微服务存在于同一个线程或进程中。我们以“离线测试模式”启动微服务，在这种模式下，它的所有依赖项都被模拟，这样我们就可以在没有网络的情况下运行测试。

在与微服务相同的进程中运行的组件测试。测试在适配器中注入模拟服务以模拟与其他组件的交互

只有当组件是单个微服务时，进程内测试才能工作。乍一看，组件测试与端到端或验收测试非常相似。唯一的区别是组件测试挑选系统的一个部分(组件)并将其与其他部分隔离开来。对组件进行了彻底的测试，以验证它是否执行了用户或消费者所需的功能

组件和端到端测试可能看起来相似。但区别在于，端到端测试是在类生产环境中测试整个系统(所有微服务) ，而组件是在整个系统的一个独立部分上进行测试的。这两种类型的测试都从用户(或消费者)的角度检查系统的行为，跟踪用户将要执行的行程

我们可以使用任何语言或框架编写组件测试，但是最流行的可能是 Cucumber 和 Capybara

进程外组件测试

进程外测试适用于任何大小的组件，包括那些由许多微服务组成的组件。在这种类型的测试中，组件部署在一个测试环境中，在该环境中所有外部依赖项都被模拟或删除。

在这种类型的组件测试中，复杂性被推到测试环境中，而测试环境应该复制系统的其余部分

为了完善契约测试的概念，您可以探索 JavaSpring 契约测试的示例代码.

https://dzone.com/articles/component-tests-for-spring-cloud-microservices

另外，如果你是一个 Java 开发人员,本文提供了在各个级别测试 Java 微服务的代码示例.

https://phoenixnap.com/blog/microservices-continuous-testing

Microservices 的端到端测试

到目前为止，我们已经对系统进行了零碎的测试。单元测试用于测试微服务的各个部分，契约测试包括 API 兼容性，集成测试检查网络调用，组件测试用于验证子系统的行为。只有在自动化测试金字塔的顶端，我们才能测试整个系统。

端到端(E2E)测试确保系统满足用户的需求并实现他们的业务目标。E2E 套件应该使用与用户相同的接口来覆盖应用程序中的所有微服务——通常是 UI 和 API 测试的组合。

应用程序应该在尽可能接近生产环境中运行。理想情况下，测试环境应该包括应用程序通常需要的所有第三方服务，但是有时候，可以对这些服务进行模拟以降低成本或防止滥用。

端到端是模拟用户交互的自动化测试。只有外部第三方服务可能被模拟

正如测试金字塔所描述的，E2E 测试是数量最少的，这很好，因为它们通常是最难运行和维护的。只要我们关注用户的旅程和他们的需求，我们就可以通过少量的 E2E 测试获得大量的价值

结论

一个不同的范式要求改变策略。在微服务体系结构中进行测试比以往任何时候都重要，但是我们需要调整我们的技术以适应新的开发模型。该系统不再由单个团队管理。相反，每个微服务所有者都必须尽自己的一份力量来确保应用程序作为一个整体工作。

有些组织可能认为单元、契约和组件测试就足够了。其他人，不满足于没有端到端和集成测试，可能会选择建立一个 QA 团队来促进跨团队测试覆盖。

感谢您的阅读！

,