微服务的测试策略 _微服务

作者 | Tomas Fernandez
译者 | 平川
微服务应用程序是一组通过网络进行通信的分布式程序，有时也会与第三方服务和数据库交互。微服务是网络化的，与传统的单体应用程序相比，它的故障点更多。为此，我们需要一种不同的、涉及面更广的测试方法。那么，我们该如何测试一个微服务应用程序？测试金字塔还有效吗？当涉及到第三方服务并可能出现网络中断时，我们该如何测试？在这篇博文中，我们将尝试回答所有这些问题。
本文最初发布于 semaphore 博客。
微服务应用程序是一组通过网络进行通信的分布式程序，有时也会与第三方服务和数据库交互。微服务是网络化的，与传统的单体应用程序相比，它的故障点更多。为此，我们需要一种不同的、涉及面更广的测试方法。
那么，我们该如何测试一个微服务应用程序？测试金字塔还有效吗？当涉及到第三方服务并可能出现网络中断时，我们该如何测试？在这篇博文中，我们将尝试回答所有这些问题。
微服务测试面临的挑战
微服务架构是一种意义深远的范式变迁，我们必须重新考虑传统的测试技术。与经典的单体架构相比，微服务在许多方面都有所不同：

分布式：微服务部署在多台服务器上，地理位置可能也不一样，这会增加延迟，而且会受网络中断所影响。测试要依赖网络，即使代码没问题，也可能会失败，导致 CI/CD 管道中断，开发受阻。
自治：只要不破坏 API 兼容性，开发团队就可以随时部署他们的微服务。
测试区域扩大：每个微服务都至少会暴露数个 API 端点，因此，测试覆盖面要更大。
多语言：开发团队可以选择最适合其微服务的语言。在一个大型系统中，可能无法找到一个适用于所有组件的测试框架。
产品是一个活动目标：由于微服务是由自治团队单独部署和构建，所以需要额外的检查和边界，以确保它们部署后仍然可以正常运行。

所有这些特点都让我们不得不考虑新的测试策略。
微服务测试金字塔
测试金字塔是自动化软件测试的规划工具。传统的金字塔包含 3 种类型的测试：

单元测试
集成测试
端到端测试。

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

文章插图
这是微服务测试金字塔的一个版本。其他版本可能顺序上会有所不同。有些版本可能将契约测试包含在了集成层。事实上，金字塔更多的是一份指南，而非一成不变的东西。
接下来，我们将对金字塔的每一层做进一步的介绍。
微服务的单元测试
单元测试是粒度最小（数量最多）的测试形式之一。单元由可以单独测试的类、方法或函数组成。单元测试是开发实践中不可分割的一部分，比如测试驱动开发或行为驱动开发。
与单体相比，微服务中的单元可能更需要通过网络调用来完成其功能。这时候，我们可以让代码访问外部服务——就得接受延迟和不确定性，也可以调用测试替身，因此，我们有如下两种处理微服务依赖的方法：

独立单元测试（Solitary unit tests）：如果我们需要测试结果始终是确定的，就应该使用这种方法，通过模拟（mocking）或存根（stubbing）来隔离要测试的代码和外部依赖。
社交单元测试（Sociable unit tests）：社交测试允许调用其他服务。在这种模式下，我们把测试的复杂性推到了测试或过渡环境。社交测试是非确定性的，但如果测试通过，我们对结果会更有信心。