微服务测试方法

 

Microservices策略是一种通过将应用程序拆分成更小的服务来开发应用程序的方法，其中每个模块在其自己的进程中运行，并以轻量级机制相互通信。这些服务是独立部署和完全自动化的。

微服务测试是一个新术语，它改变了软件开发的体系结构，而且改变了团队的工作文化，改变了团队合作的方式。

微服务测试策略是什么？

微服务架构将复杂的应用程序划分为更小的模块。这比单片架构提供了许多好处。

微服务架构独立于其他模块部署。微服务将这种方法应用于独立服务。有了微服务，我们将很容易更快地采用技术，并了解新的进步可能对我们有何帮助。

简而言之，Microservices体系结构风格是一种将单个应用程序开发为一组小型服务的方法，每个服务都在自己的进程中运行，并与轻量级机制（通常是HTTP资源API）通信。

这些服务是围绕业务能力构建的，可以通过完全自动化的部署机制进行独立部署。对这些服务的集中管理是最低限度的，这些服务可以用不同的编程语言编写，并使用不同的数据存储技术。

图像源——Thoughtworks

多个服务协同工作形成整个应用程序，服务A、服务B、服务C等服务独立工作，协同工作形成整个应用程序。这些服务协作以实现应用程序的功能。这些服务块称为微服务。

如何对微服务采用自动化测试？

有五种策略用于成功地测试微服务。

文件优先战略

遵循文档优先的方法，大部分文档都是在Git中标记的。API文档保持开源，所以它是公共的。在这一点上，在任何人编写任何API更改或其他API之前，首先刷新文档，对更改进行调查，以确保它按照API约定和标准进行调整，这些API约定和标准都被记录在案，并确保不存在中断性更改。确保它也符合命名约定等。

全堆栈即插即用策略

整个stack-in-a-box策略需要在本地复制云环境，并在一个vagrant实例（“$vagrant up”）中测试所有内容。

AWS测试策略

第三种方法是创建一个Amazon Web Services（AWS）框架来部署和运行测试。这是一种更适合于全堆栈即插即用策略的方法。一些人称之为个人部署（策略），每个人都有自己的AWS帐户。将工作站上的代码在大约十分钟内推送到AWS中，然后像真正的系统一样运行它。

共享测试实例策略

第四种策略是在全堆栈收件箱和AWS测试之间进行交叉。这是因为它需要在自己的本地工作站上工作，同时在测试过程中使用不同的、共享的微服务实例来指向本地环境。有些运行微服务的不同实例只是为了测试本地构建。然而，本地构建器将指向运行在Google基础设施中的测试图像解析器。

存根服务策略

微服务的标记或“存根”的行为类似于正确的服务，并在服务发现中作为真正的服务进行宣传，但这是一个虚拟的模仿。例如，测试服务可能要求服务意识到用户执行一组任务。对于存根服务，假设用户任务的执行没有伴随着这些任务而来的典型复杂性。与运行整个服务相比，这种方法更轻量级。

实现微服务自动化测试的好处

微服务的好处是多种多样的。这些好处中的许多可以放在任何分布式系统的门口。然而，微服务倾向于在更大程度上实现这些好处，主要是因为它们在分布式系统和面向服务的体系结构的概念背后走了多远。

实现微服务的自动化测试有以下好处-

• 激励更好地隔离服务和设计更好的系统。
• 它对程序员施加了一定的设计压力，使其以易于使用的方式构造API。
• 测试可以作为应用程序公开的API的出色文档。
• 单独测试每个服务。
• 测试应用程序的不同功能部件。
• 监控以评估变更的影响。
• 监视应用程序的持续性能。

独立部署

微服务最重要的好处是它独立于其他模块部署。如果需要对模块进行更改，其他模块将不受影响。如果一个模块停止工作，那么整个应用程序将不会受到影响，只有一个模块会受到影响。

并行开发

将应用程序分解成更小的模块，并行地开发，不同的开发人员在不同的模块上工作，并行地开发所有的模块。

微服务测试和测试自动化的需求

测试微服务是非常重要的，因为要对为每个服务所做的假设非常有信心，即它将按照它所说的去做。微服务测试是使服务对用户可靠的第一步。对于微服务的内部功能依赖性，测试对于服务保持强大更为重要。

自动化测试如何工作？

单独测试每个服务

测试自动化是测试离散微服务的工具。很容易创建一个简单的测试工具，重复调用服务并将一组已知的输入与预期的输出进行比较。无论如何，就其本身而言，它在测试方面不会走得太远。它将使测试团队能够集中精力进行更复杂的测试。

测试应用程序的不同功能部件

认识到应用程序中的关键功能元素后，应该像传统的集成测试那样，尝试测试这些元素。这里测试自动化的优势显而易见。每次刷新一个微服务时，都会运行快速构建测试脚本。将新代码的输出与以前的输出进行比较，快速确定是否有任何更改。

不要在小环境下测试

有些经理有能力保留测试组的资源。但对于基于微服务的应用程序，这会适得其反。与试图在小型本地登台环境中测试代码不同，应该考虑利用基于云的测试。这里根据测试需要动态地分配资源，在测试完成时释放它们。因此，测试自动化在这里不会有直接的帮助。

尝试跨不同设置进行测试

建议使用多个环境来测试代码，类似于web应用程序的跨浏览器测试。其思想是将代码公开给库版本、底层硬件等方面的任何微小变化，这些变化可能会在部署到生产环境时影响代码。实现这一点的一种方法可能是动态地创建登台环境。利用Kubernetes，可以创建一个测试环境，用来自已知源的数据填充它，加载代码，然后运行测试。其优点是，每次自动暴露在可能存在的任何差异中时，都会重新创建环境。当然，另一方面，诊断任何错误的根本原因变得更加困难。

尽可能使用金丝雀测试

Canary测试是一种方法论，在这种方法中，一小部分用户呈现代码中的更改，并将他们的体验与那些仍在运行旧代码的用户的体验进行对比。这种方法对于测试微服务特别有用。它使用监视来调查改变。它视图错误率、服务负载、响应性和类似的度量可以通过采用一种策略来判断新代码是否具有负面影响，在这种策略中，一次更新一个服务实例可以快速、自动地进行金丝雀测试。

Canary测试是一种方法，在这种方法中，一些客户机对代码中的更改进行了安排，并对比了这些客户机在运行旧代码时的经验和遭遇。这种方法尤其有助于测试微服务。它使用检查来调查更改的效果。它查看错误率、收益负荷、响应性和比较度量，以揭示新代码是否具有不利影响。通过在一个管理案例令人耳目一新的时候采用一个过程，不需要太多的扩展，从而进行金丝雀测试。

人工智能测试

人工智能或人工智能用于完全自动化微服务应用程序的金丝雀测试。像深度学习这样的人工智能方法可以识别新代码激活的变化和问题。很少有用户迁移到新的框架，人工智能将用户体验与现有用户的体验进行比较。因为这是自动实现的，所以它将替换循环中的人。

可调试代码

编写可调试的代码包括稍后进行查询的能力，这反过来又涉及-

正确的代码检测。

了解选择的可观测性安排（无论是指标、日志或独特的案例跟踪、跟踪或这些的组合）及其优缺点。

在给定服务需求、依赖关系的操作特性和良好的工程直觉的情况下，选择最佳可观测性安排的能力。

微服务测试方法

微服务应用程序的构建必须了解如何对其进行测试。拥有良好的测试覆盖率可以让您对代码更有信心，并产生更好的连续交付管道。

由于这是一种新的体系结构方法，因此需要一种新的方法来进行自动化测试和质量保证。新方法划分了特定的测试层。有五层测试在微服务上执行-

什么是单元测试？

测试单个类或一组紧密耦合的类。这些单元测试可以使用单元与之交互的实际对象运行，也可以使用测试双重对象或模拟对象运行。

在单元测试中，可测试软件的最小部分在应用程序中进行测试，以确定它是否按预期运行。测试通常在类级别或围绕一小组相关类运行。在单元测试中，一个重要的区别在于被测单元是否与其合作者隔离。

单元测试通常由程序员使用他们的常规工具编写，唯一的区别是使用了相同的单元测试框架。

单元测试还有两种类型的测试

社会单元测试

单独单元测试

社会单元测试

它关注于通过观察模块状态的变化来测试模块的行为。这将被测单元视为完全通过其接口测试的黑盒。

单独单元测试

它查看对象与其依赖项之间的交互和协作，这些交互和协作被测试双倍替换。

假设您正在测试order类的price方法。price方法需要调用产品类和客户类上的一些函数。如果您希望您的单元测试是单独的，那么您不希望在这里使用真正的产品或客户类，因为客户类中的错误将导致order类的测试失败。相反，您可以为协作者使用Test double。

单靠单元测试并不能保证系统的行为。单元测试涵盖了每个模块的核心测试，但是，当这些模块协同工作以与远程依赖项交互时，没有覆盖测试。

为了确保每个模块在远程依赖项下正常工作，需要进行更细粒度的测试。

什么是集成测试？

集成测试用于测试服务之间的通信。这些测试旨在测试网络边界上的基本成功和错误路径。

不同的组件因其功能依赖性而相互作用，而集成测试则验证组件之间的通信路径并检测接口缺陷。

在这里，所有的测试模块集成在一起，作为一个子系统进行测试。它检查子系统之间的通信路径在与其对等方交互时是否正常工作。在微服务体系结构中，它们通常用于验证集成代码层与其集成的外部组件之间的交互。

当为与外部组件交互的模块编写自动化测试时，基本目标是验证模块是否与外部组件充分交互。

很难触发异常行为，例如来自外部组件的超时或慢速响应。编写特殊测试以确保测试在意外情况下按预期响应

持久性集成测试保证代码所假定的模式与数据存储中可用的模式匹配。

通过单元测试和集成测试，我们可以确信组成微服务的各个模块中包含的逻辑的正确性，但我们不能确定微服务是否作为一个整体一起工作以满足业务需求。

什么是组件测试？

测试单个微服务的全部功能。在这种类型的测试中，对外部服务的任何调用都以某种方式模拟。

组件是大型系统中任何封装良好、连贯且可独立更换的部分。在微服务架构中，组件是服务本身。

通过将组件与其对等方隔离，可以避免组件的复杂行为，同时隔离有助于控制组件的测试环境。

什么是合同测试？

为微服务提供的api和其他资源测试约定的契约。

在外部服务的边界处，进行集成契约测试，以验证消费服务所期望的契约。此测试验证组件是否符合约定。

编写测试套件是为了只验证正在使用的生产服务的那些方面。服务的行为没有经过深入测试，当服务调用的输入和输出包含必需的属性时，响应延迟和吞吐量应该在可接受的限制内。

这个测试由每个测试使用团队编写，然后打包。此测试的主要目的是了解维护人员所做的更改对使用者的影响。

什么是端到端测试？

端到端测试，测试通过应用程序或微服务的完整流。通常用于测试黄金路径或验证应用程序是否满足外部需求。

端到端测试对整个系统进行端到端的测试。验证了整个系统满足了外部需求，最终达到了预期目标。不用担心应用程序的内部架构，业务目标应该在端到端测试之前实现。

系统已完全部署，并被视为一个黑匣子，并执行测试。通过gui和API的公共干扰，系统被操纵。端到端测试更面向业务。

此测试验证防火墙、代理和负载平衡器是否正确配置。

在微服务体系结构中，对于一个行为，有许多微服务相互作用以响应该行为，端到端测试通过增加系统之间的间隙覆盖率来提供价值。

微服务测试策略实施中的挑战

Microservices体系结构包括许多相互集成形成整个应用程序的微小的独立服务。这些微服务在生产环境中相互作用以实现应用程序的功能，尽管这些小微服务在相互通信时非常简单，但会产生许多复杂性。随着应用程序粒度的增加。

微服务体系结构概述

微服务架构是一种分布式方法，旨在克服传统单片架构的局限性。它有助于在提高周期时间的同时扩展应用程序和组织，然而，它们也带来了一些挑战，这些挑战可能会导致额外的体系结构复杂性和操作负担。

微服务架构的好处之一是灵活性。因为每个服务都有一个集中的范围和独立的生命周期，所以将新功能作为微服务实现、测试并部署到生产环境中所需的时间更少。