测试微服务的4个最佳实践

随着微服务架构的出现，应用程序堆栈发生了根本性的变化，这对软件测试产生了连锁反应。每天多次发布微型版本，软件测试更加精细，它与开发同时发生，并且与测试单体应用程序有根本的不同。

1.单元测试和微观服务 - 类似于PB＆J

单元测试始终是QA策略的重要组成部分，但对于微服务则更是如此。微服务架构将单体应用程序分解为较小的相互依赖的服务。每个服务都运行一个功能，或者至少是目标 - 尽管最初将整体转换为微服务时，在单个服务中包含多个功能是正常的。假设单个服务仅运行一个功能，单元测试完全适合此模型，因为它们需要测试代码片段的最基本功能。单元测试在应用程序的最小组件级别运行。

单元测试有助于将测试范围仅限于一个功能区域。这样，每个单元测试都有一个明确定义的单一目标。虽然在单块中很难确定测试失败的根本原因，但是在微服务上运行单元测试，识别失败变得更加容易。

避免误报有助于提高测试质量，这是通过将微服务与单元测试相结合来实现的。限制测试范围也使测试运行得更快。凭借焦点和速度的双重优势，单元测试对于微服务来说是不可或缺的。

2.测试服务之间的集成

比单元测试更高一级，我们进入集成测试，它仍然在微服务中占有一席之地。集成测试用于检查每个服务如何与其他服务以及外部组件一起使用。他们并不关心内部每项服务的行为，而是关注服务之间的通信。它们还可用于测试数据库等外部组件。

在单元测试有足够的覆盖率之后，应该进行集成测试。它们应该在引入新功能时运行，因为它们确保新功能与应用程序的其他部分兼容。

服务到服务通信的另一个重要方面是跟踪。通常，任何请求都会触及多个服务，然后再通过响应回送给用户。在这种情况下，跨服务的请求的可观察性和监控非常重要。跟踪是实现这一目标的好方法。像Jaeger这样的新开源 工具 有助于将单个请求分解为易于查看的视觉效果，显示其接触的服务数量以及每项服务的持续时间。这对于解决延迟和识别瓶颈非常有用。

3.计划失败

部署后，确保应用程序的可靠性非常重要。微服务架构已经通过将服务彼此隔离来帮助解决这个问题，这样即使一个服务发生故障，它也不会消除相邻服务。更进一步，你可以通过练习混乱工程来建立弹性 - 这是Netflix在宣布他们的混沌猴子工具时流行的一个概念。该工具会随机杀死实例和服务，并迫使工程师做出响应并确保很少或没有停机时间。失败是不可避免的，混乱工程可以帮助您随时为失败做好准备。

但是，你不能马上开始。你需要从小规模开始建立一个完整的混乱工程实践。最初，您可能会手动使服务和实例失败，然后逐渐以随机，自动的方式引发故障。

要实现这一点，您可以使用像Chaos Monkey这样的独立工具。您还可以使用像Istio这样的微服务网络工具。Istio可以自动路由流量，导致故障和延迟进入HTTP请求。Istio的HTTPFaultInjection功能使您可以有意延迟或中止请求。

4.作为GITOPS的一部分进行测试

虽然持续集成已经存在了一段时间，但今天，大部分创新都围绕着持续部署 - 特别是GitOps（一种从GitHub存储库开始自动部署的方式）。GitOps介绍了DevOps一直以来的自动化和速度，但现在才在Jenkins X，Helm和Grafeas等云原生工具的帮助下实现。

虽然GitOps在拉取请求之后自动执行每一步，但在测试时很容易妥协。但是，要使GitOps模型成功，需要进行测试自动化，以便在“合并”之前对每个部署进行测试和批准。如果没有这个，就无法保持所部署内容的质量。Helm和Jenkins X等工具加速了软件交付流程，但他们需要专注于测试自动化。

总之，微服务通过将整体分解为众多微服务，为应用程序架构带来了根本性的变化。这些服务需要进一步细分并通过单元测试进行测试。一旦进行了适当的单元测试，集成测试应检查服务之间的通信。部署后，混沌工程可以帮助构建更具弹性的应用程序。此外，测试自动化是实现成功GitOps的关键。