微服务测试策略

这是“微服务持续交付”系列的第二篇文章。在上一篇文章中，我概述了在微服务架构上构建持续交付流水线的五个注意事项。在这篇文章中，我们将深入探讨测试策略。

测试策略

微服务架构涉及许多活动部件，它们各自拥有不同的保障和故障模式。与测试传统的单体应用相比，这些系统的测试和验证更加细致入微，也更加复杂。有效的测试策略既需要考虑单独测试各个服务，也需要考虑验证整体系统的行为。测试大致可以分为两类：生产前测试以及生产环境中的监控和测试。

服务的生产前测试

这里有一个简单的示例，您为多个服务构建了流水线，并且正在单独测试其中一项服务。在这种情况下，传统的测试金字塔有助于在不同类型的测试之间保持平衡。

在典型的测试金字塔中，您有：

单元测试

涵盖软件中可测试功能的最小部分。

集成测试

在这种情况下，集成测试处理服务内组件的测试集成和接口缺陷；这些是更细粒度的测试。

组件测试：

当你查看微服务的组件测试时，组件就是暴露某些功能的服务。因此，微服务的组件测试可以只是服务的验收测试，你的测试需要验证服务是否提供了其承诺的功能。

契约测试

另一类非常适用于微服务的测试是契约测试。它们测试服务 API 的契约，以检查 API 是否有效，或者微服务是否遵守其 API 的约定。这些契约测试的一个很酷的变体是消费者驱动的契约测试。这些测试由 API 的消费者服务编写；消费者将契约规范化，编写成一套测试，并在 API 的每次变更时运行。这样，如果 API 的变更违反了某个消费者预期的契约，那么这一重大变更就会在持续交付 (CD) 流水线的早期阶段被捕获。

端到端测试：

我们之前讨论的测试套件适用于测试单个服务。然而，端到端测试粒度更粗，旨在测试整个系统的功能。根据您要采用的部署架构，如果您以聚合方式将所有服务部署到预生产环境中，则可以在那里运行端到端测试。由于端到端测试通常比较脆弱且耗时较长，因此您通常希望尽可能减少这类测试的数量。如果您拥有完全独立的微服务，并且没有部署到预生产测试环境，那么可以考虑在生产环境中进行测试。

生产中的监控和测试

这种传统的测试方式有其局限性。有些类型的错误你无法在测试环境中真正模拟出来。这类问题的例子包括高度分布式系统中的最终一致性问题，以及导致系统部分功能失效的硬件和网络故障。你必须在传统的测试技术之外，添加一些能够有效地分析和监控生产环境中的系统，并在出现问题时能够采取补救措施的技术。在本文中，我将重点介绍生产环境中的测试，并在本系列的后续文章中介绍补救策略。

生产中有一类测试称为故障注入，它以受控的方式在生产中引入错误，以查看您的系统是否能够承受这些错误。

生产测试的变体是这些环境中流行的一些特定部署策略：

金丝雀部署

金丝雀部署是指将新版本发布到生产基础架构的某个子区域，观察其运行情况，并不断增加新服务的覆盖范围，直至完全覆盖。如果遇到问题，可以开始回滚新版本的服务。

蓝绿部署

蓝绿部署类似，你拥有新服务的新实例，然后进行一些测试并通过它路由一些流量。如果一切正常，则将所有流量切换到新的服务实例，否则，保留旧的实例。

多变量测试

这类测试的另一个有趣变体是多变量测试。在多变量测试中，你实际上并非测试新服务是否存在缺陷，而是在 A/B 测试切换开关后对新发布的功能进行 A/B 测试。此类测试的目的是了解这些功能的反响。你可以决定将其推广到所有用户，或在必要时进行修复。

概括

这是我们“微服务持续交付”系列博客的第二部分。我们深入探讨了微服务的测试策略，包括如何将传统的测试金字塔应用于微服务的预生产测试，以及如何应用新的生产监控和测试技术。在我的下一篇文章中，我们将讨论第二个考虑因素：微服务系统的持续交付实践。