测试微服务的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的关键。