微服务自动化测试详解

什么是微服务？

微服务 - 也称为微服务架构 - 是一种构建方式，它将应用程序构建为松散耦合服务的集合，具有完整的业务功能。微服务架构允许连续交付/部署大型复杂应用程序。本文将概述自动微服务测试工具和最佳实践。

它还使组织能够发展其技术堆栈。微服务逐渐用于创建更大，更复杂的应用程序，这些应用程序作为较小服务的组合得到更好的开发和管理，这些服务可以协同工作以实现更重要的应用程序范围的功能。

大而复杂的应用程序由更直接和独立的程序组成，这些程序可由它们自己执行。这些小程序聚集在一起，提供了大型单片应用程序的所有功能。

同时，我也为大家准备了一份软件测试视频教程（含面试、接口、自动化、性能测试等），就在下方，需要的可以直接去观看，也可以直接点击文末小卡片免费领取资料文档

软件测试视频教程观看处：

华测教育软件测试进阶全套视频教程（2023全网最新版，软件测试进阶自学必备）

什么是微服务测试？

所采用的任何测试策略都应旨在覆盖每层和服务层之间，同时保持轻量级。MicroServices测试需要替代方法 - 测试团队应该制定策略，以便在设计阶段开始测试微服务。测试团队最初参与设计/架构小组，以了解功能，使用情况和未覆盖的界面，这些都将对您有所帮助。除上述内容外，测试人员还应确保所有接口都是通用的，以便其他系统/服务可以毫无障碍地使用。

由于需要自动化所有内容，因此请使用Micro Services测试自动化工具。这些工具有助于验证每个独立服务单元的功能，并通过组合多个这些微服务来执行集成测试。

微服务的自动化测试级别

• 单元测试 - 这是测试单个微服务测试单元的内部工作。这些可以使用自动单元测试框架在每个编程级别自动化。
• 合同测试 - 这是为了测试每个微服务单元是否遵守所建立的合同中提供的给定功能。这里每个服务组件都单独作为黑盒测试。在合同测试中，即使服务发生变化，服务也应该为相同的给定输入提供相同的结果。MicroService Architecture中的每项服务都可以在更长的时间内稳健运行。它保证在不影响现有使用者的情况下为每项服务添加新功能。
• 集成测试 - 检查多个服务是否相互通信，并提供服务功能级别文档中给出的所需结果。这可以是整体微服务架构集成测试，也可以只占用架构和测试的子区域。
• UI功能测试 - 在此，与UI集成的服务和通过UI完成的测试，其中通过UI提供MicroServices所需的输入，并通过UI测试所需的输出。

对于所有这些类型的测试，可以执行自动测试。

对于单元测试，使用基于NUnit或JUnit的单元测试框架，以较少的QA参与自动化测试。

对于合同测试，QA测试自动化工程师参与。此测试在每个服务单元中执行，通过隔离它并命中服务的单个URI。合同中给出的函数将使用测试自动化框架内的自动化脚本集进行测试。

集成测试通过合同测试中使用的相同工具集自动化。这里唯一的区别是将考虑不止一个服务单元，并且自动化脚本触发功能以在这些处理器内提供通信，其中验证了所需的输出。这里的自动化测试还将验证通信消息格式以及处理器之间链接的任何数据库。

UI功能测试使用自动化测试工具自动化，如UFT，Selenium或任何其他基于UI的自动化工具。

在进行Micro Service Automated测试时，可以集成多个工具或框架。将API自动化测试工具框架和基于UI的自动化测试工具框架集成在一起也是一种很好的做法。这是测试自动化的未来。大多数组织使用全局混合测试自动化框架，而不是维护单独的框架。

如何自动化测试工作？

单独测试每项服务

测试自动化是测试离散微服务的工具。很容易创建一个简单的测试工具，重复调用服务并将一组已知输入与预期输出进行比较。无论如何，所有这一切，都不会在测试中变得异常。它将释放测试团队专注于更复杂的测试。

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

在认识到应用程序中的关键功能元素后，应该尝试以传统方式进行集成测试的方式对其进行测试。这里测试自动化的优势很明显。每次其中一个微服务刷新时，都会快速构建测试脚本。将新代码的输出与先前的输出进行比较，快速确定是否有任何变化。

不要在小型设置中进行测试

一些管理人员有能力保留测试组的资源。但是，对于基于微服务的应用程序，这会适得其反。与尝试制作小型本地登台环境以测试代码相反，应该考虑利用基于云的测试。这里动态分配资源作为测试需要它们，在测试完成后释放它们。因此，测试自动化在这里不会直接提供帮助。

尝试跨不同的设置进行测试

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

尽可能使用Canary测试

金丝雀测试是一种方法，其中一小部分用户呈现代码中的变化，并将他们的经验与仍然运行旧代码的用户的体验进行对比。该方法对于测试微服务特别有用。它使用监控来调查变更的影响。它可以通过采用一次一个服务实例更新的策略来快速判断错误率，服务负载，响应能力和类似指标，从而判断新代码是否会产生负面影响。自动做金丝雀测试。

金丝雀测试是一种方法，在这种方法中，客户稍微安排一下代码的变化，对比体验以及那些运行旧代码的客户的遭遇。这种方法对测试微服务特别有用。它利用检查来调查变化的影响。它查看了错误率，利益负担，响应性和比较测量，以揭示新代码是否具有不利影响。通过采用一个程序，当一个管理案例同时令人耳目一新时，可以毫不费力地进行，从而进行金丝雀测试。

人工智能测试

AI或人工智能用于完全自动化微服务应用程序的Canary测试。深度学习等AI方法可识别新代码激活的更改和问题。很少有用户转移到新框架，AI将经验与现有用户的体验进行了比较。由于这可以自动实现，因此它会取代循环中的人。

可调试代码

编写可调试代码包括稍后进行查询的能力，这反过来涉及正确的代码检测。

了解所选择的可观察性安排（无论是指标还是日志或独特的案例追踪器或痕迹或这些的混合）及其优缺点。

根据给定服务的要求，依赖性的操作怪癖和良好的工程直觉，选择最佳可观察性的能力。

微服务自动化测试的好处

测试微服务有以下好处：

1. 激励更好地隔离服务和设计更好的系统。
2. 它对程序员施加了一定的设计压力，以便以易于使用的方式构建API。
3. 测试充当应用程序公开的API的精彩文档。
4. 单独测试每项服务。
5. 测试应用程序的不同功能部分。
6. 监控以评估变更的影响。
7. 监控应用程序的持续性能。

为什么微服务的自动测试很重要？

由于以下原因，微服务测试很重要：

解耦

每个功能都松散耦合，以帮助SaaS / SOA架构。MicroServices通过网络分散在各个平台上，并通过REST over HTTP进行集成。

可维护性

每项服务都是独立维护，升级和测试的，这是SaaS架构的基本要求。这使得微服务成为持续交付的必要推动者，支持频繁发布，同时提供高系统可用性和稳定性。

可扩展性

每个微服务根据用途自动缩放。每个服务都根据资源需求部署在自治硬件上，这在传统的单片设计方法中是不可能的。

可用性

每个微服务都可以自主设计和部署，以实现故障转移和容错。例如，内存和CPU使用等问题在本地传递，而不同的服务通常继续工作。

如何对微服务进行自动化测试？

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

文档优先策略

遵循文档第一种方法，大多数文档都是Git中的markdown。API文档保持开源，所以它都是公开的。此时，在任何人编写任何API更改或不同的API之前，首先刷新文档，调查该更改，以确保它使用完全记录的API约定和标准进行调整，并确保不存在重大更改。确保它符合命名约定等等。

完整的堆栈内置策略

整个堆栈一体化策略需要在本地复制云环境并在一个流浪者实例中测试所有内容（“$ vagrant up”）。

AWS测试策略

第三种方法涉及启动Amazon Web Services（AWS）框架以部署和运行测试。对于完整堆栈盒内策略，这是一种更具适应性的方法。有些人将此称为个人部署[策略]，每个人都拥有自己的AWS账户。在大约十分钟内将工作站上的代码推送到AWS，然后像真实系统一样运行它。

共享测试实例策略

第四种策略是完整堆栈内置和AWS测试之间的交叉品种。这是因为它涉及在自己的本地站工作，同时利用微服务的不同共享实例在测试期间指向本地环境。有些运行微服务的不同实例仅用于测试本地构建。但是，本地构建器将指向在Google基础结构中运行的测试映像解析器。

存根服务策略

微服务的标记或“存根”表现得像正确的服务，并在服务发现中作为真实服务进行宣传，但却是虚拟模仿。例如，测试服务可能要求服务意识到用户执行一组任务。使用存根服务，假设用户任务已经发生，而没有随之而来的典型复杂性。与在整体上运行服务相比，这种方法更轻量级。

自动化微服务测试的最佳实践

隔离测试

微服务很难测试，因为有许多独立服务以许多（通常是未预料到的）方式与其他独立服务进行通信。开始测试自动化工作的一个好地方是直接测试特定微服务的功能。通常，通过使用REST API与服务进行通信以及一些模拟来快速完成，以便单独测试服务，而无需与其他服务进行任何集成。

签订合同

几乎不可能知道消费者使用服务的所有方式。通过消费者驱动的交易，消费者必须提供一套测试，以确定所需的交互类型和格式。然后服务将同意合同并确保合同没有被破坏。这规定了其他服务的条件。此方法还可以验证交易是否在构建时完成。像Pact这样的工具可以更好地理解如何实现这种类型的功能来开发和测试微服务。一旦有了消费者驱动的合同流程，测试微服务的下一步就是转移到以前被禁止的生产世界。

转右 （Shift-Right ）- 投入生产

在DevOps，微服务领域，生产测试成为整体质量计划的必要条件。通过基于微服务架构的流动，移动关系，如何确定许多服务将扩展的方式？如何提前了解服务的行为？如何测试此漏洞？答案是开始在生产中进行测试。

监控和警报

建立密钥检查和警报系统，并在生产中进行跟踪至关重要。如果其中一项服务出现故障或无响应，请立即显示。通过在监控的帮助下识别生产过程中的问题，在用户甚至知道存在问题之前，通常可以轻松地返回到上一个已知的优质服务版本。

最佳自动化微服务测试工具

1. Hoverfly - 模拟API延迟和故障。
2. Vagrant - 构建和维护可移植的虚拟软件开发环境。
3. 录像机 - 一种单元测试工具。
4. 契约 - 框架由消费者驱动的合同测试。
5. Apiary - API文档工具。
6. API蓝图 - 设计和原型API。
7. Swagger - 设计和原型API。
    

写在最后

对于测试人员来说，无论我们处于学习入门阶段、刚入行工作阶段、还是工作有几年的阶段，一定要把黑盒白盒测试的内容学透，同时不断攻克每个细分领域的测试内容，让自己具备更强的专业能力，为自己未来的职业生涯铺好路~

PS：这里分享一套软件测试的自学教程合集。对于在测试行业发展的小伙伴们来说应该会很有帮助。除了基础入门的资源，博主也收集不少进阶自动化的资源，从理论到实战，知行合一才能真正的掌握。全套内容已经打包到网盘，内容总量接近500个G。

☑ 240集-零基础到精通全套视频课程
☑ [课件+源码]-完整配套的教程
☑ 18套-测试实战项目源码
☑ 37套-测试工具软件包
☑ 268道-真实面试题
☑ 200个模板-面试简历模板、测试方案模板、软件测试报告模板、测试分析模版、测试计划模板、性能测试报告、性能测试报告、性能测试脚本用例模板（信息完整）

这些资料，对于做【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴我走过了最艰难的路程，希望也能帮助到你！凡事要趁早，特别是技术行业，一定要提升技术功底。