微服务API测试的十大最佳技巧（API测试技巧）

微服务API测试的十大最佳技巧（API测试技巧）

随着微服务和API在现代软件开发中变得越来越普遍，测试和验证这些API对于确保软件质量变得越来越重要。如何在微服务中更好的做好系统及API的测试，很多公司与开发都做出了自己的尝试。

测试API和微服务有很多好处。首先，它们通过模仿客户端会生成的API调用，使您能够轻松测试端到端行为，而不必投入编写和维护基于UI的测试。这样可以进行稳定且易于编写的测试，并且可以帮助您准确确定系统中问题的根源。API测试还可以轻松地作为监视器运行，使您能够在用户使用之前轻松确定中断和性能下降！但是，与端到端测试和单元测试等更常见的测试类别不同，API测试对于许多工程团队来说是一个较新的领域。

为此，本文将帮助您开始测试API。

1）了解组织为何优先考虑API测试

测试您的API的重要性不能被夸大，并且通常，它比其他形式的测试更快地产生价值。这是由于一些因素使API测试引人注目：

模拟用户流-功能性API测试可以遵循普通用户流，并执行这些流将产生的API调用。这些测试可以立即验证系统中的完整用户流，并确保它们在功能上受到支持，这与端到端UI测试非常相似。

测试稳定性— UI测试通常用于测试整个系统流程，但问题是UI更改非常频繁，经常破坏基于UI的测试，并使测试维护成为日益关注的问题。相反，API被构建为稳定的接口，从而使基于API的测试更加稳定，并降低了维护测试的成本。

测试成本—基于API的测试可以轻松地测试大部分功能，同时又可以相对较快地构建。单元测试很容易构建，但是您需要编写很多单元测试才能很好地覆盖系统行为。一些UI测试可以快速覆盖大型系统，但是构建它们非常耗时。

精确问题-通常在出现软件问题时，最难的部分是了解问题的根源。借助API测试，您可以非常快速地剖析系统并了解问题是在API背后（在后端）还是在软件UI中。

2）了解API行为

编写任何API测试的第一步是加深对API的作用及其工作方式的了解。对该API的功能有三级理解：

API范围-基本上，此API提供什么功能？通常，这只是了解API提供的端点（对于RESTful API）或API公开的查询和突变（对于GraphQL API）的形式。

端点功能 -一旦您确定了API中所有可用的端点的范围，现在是时候了解它们的全部功能和工作方式了。从表面上看，这就像知道端点将要做什么一样容易，但是理想情况下，在这一步中，您应该开始对这些端点有一个深入的了解-它们期望什么参数？可能值的范围是多少？什么是边缘情况？发生时会发生什么？最好的方法是仅向每个端点发出请求，以尝试不同的方案和输入，直到您对它的工作原理有了扎实的了解。

用户流-仅了解API的每个部分的作用还不够；还必须了解API如何在应用程序中组合在一起。深入了解使用这些API的应用程序，并确保您了解该应用程序的使用方式以及该使用方式如何利用API。

您真正了解API所花费的时间越多，您就能编写出更好的测试！

3）在API响应上创建断言

当您在测试流程中提出API请求时，不要仅仅对成功的响应感到满意。考虑API预期返回什么以及数据可能采用的格式，并花一些时间确保数据返回确实符合API合同。响应模式损坏或数据丢失会对最终应用程序造成严重破坏—这是一个很好的机会，可以在这些错误发生之前将其捕获！

4）使用API创建功能流

调用API中的每个终结点并确保其能够达到预期的目的是一件好事，但更大的问题是– API是否在功能上正常运行？测试此方法的方法是使用测试创建完整的功能流程-添加数据，通过另一个调用检查它是否存在，对其进行修改，检查所做的修改，等等。您应该使用对最终应用程序的熟悉程度来模仿在应用程序正常使用期间将进行的API调用。

示例： 例如，在eCommerce API中，完整的流程将包括用户注册，产品搜索，将产品添加到购物篮以及签出。

5）封装测试

好的测试是完全封装的-意味着它们不依赖于现有数据来运行。每次测试均应从进行后续步骤所需的API调用开始。

示例： 如果需要用户，第一步应该是创建用户，而最后一步应该是进行API调用以将其删除。

依赖于现有数据的测试可能会因环境变化/数据丢失而失败，并产生错误警报。

6）测试成功和失败方案

在构建测试时，请考虑API应该失败/阻止请求的极端情况和场景。

示例：尝试访问您无权查看的资源，尝试获取不存在的项目，或将格式错误的参数传递给API端点。

这些将有助于确保基本应用程序完好无损的风险，并确保没有问题或潜在的安全隐患潜伏在表面。

7）将API测试集成到CI / CD工作流程中

在更改软件并部署新的代码版本时，API测试可以帮助确保应用程序不会损坏。寻找可以由您的CI / CD工具触发的API测试工具，并确保每次您推送新代码时都运行那些测试。

良好的API测试可以帮助确保您的API在部署之间能够正常工作，并且它们返回的架构没有无意间发生更改-冒着依赖它们的其他应用程序所面临的风险。

8）监控实时API

API测试除了对验证代码有用之外，在监视生产系统方面还具有重要的价值。按设定的时间表针对您的生产环境运行测试，以验证它始终处于运行状态，并根据需要运行。假设您遵循了技巧5（封装了API测试），那么您应该可以轻松地在多个环境中运行它们。更重要的是，一个好的API测试平台将能够随时间测量和分析API调用延迟，并且不仅会在系统崩溃时提醒您，而且还会显着降低性能。

9）定义API测试警报

除非测试为您提供有关系统状态的及时，可行的反馈，否则它们不是很有用。无论它们是定期运行以监视您的生产环境，还是在每个新代码版本的CI / CD管道中运行，您都想立即知道测试失败的时间，以便您纠正这种情况。 良好的API测试平台可让您定义SMS，电子邮件以及其他在测试失败时发出警报的渠道。

10）将测试集成到您的开发周期中

开发测试不应只是一次执行的离散任务，而应是代码库每项改进的一部分。每当您扩展API，添加其他功能或支持新的用户流程时，请确保在开发过程中对其进行测试，并知道自己的API被完全覆盖并不断得到验证，因此请放心。随着时间的流逝，这种方法将使您能够通过测试快速涵盖所有主要功能。

下面介绍在微服务里用到的一种测试方案：契约测试（CDC）。

契约测试(CDC)

契约测试 ，又称之为 消费者驱动的契约测试(Consumer-Driven Contracts，简称CDC)，根据 消费者驱动契约 ，我们可以将服务分为消费者端和生产者端，而消费者驱动的契约测试的核心思想在于是从消费者业务实现的角度出发，由消费者自己会定义需要的数据格式以及交互细节，并驱动生成一份契约文件。然后生产者根据契约文件来实现自己的逻辑，并在持续集成环境中持续验证。后文中消费者驱动的契约测试统一用cdc来代替。

cdc核心原则:

lcdc是以消费者提出接口契约，交由服务提供方实现，并以测试用例对契约进行产生约束，所以服务提供方在满足测试用例的情况下可以自行更改接口或架构实现而不影响消费者。

lcdc是一种针对外部服务的接口进行的测试，它能够验证服务是否满足消费方期待的契约。 它的本质是从利益相关者的目标和动机出发，最大限度地满足需求方的业务价值实现。

契约测试、单元测试、接口测试区别

lAPI测试和单元测试，更强调的是覆盖API内部逻辑。

l契约测试，更强调是组件之间连接的正确性，除了保证组件内部，还要保证组件间的调用是正确的，也就是服务API之间的调用。

契约测试能解决什么问题？

l联调成本过高,要双方开发到某一阶段后放在同一个环境上才能进行，要同时把握双方的进度，造成资源和时间上的浪费。

l对于接口的变动把控相当困难。由于接口变动是普遍存在的，尤其对于调用关系复杂的接口，一旦发生变动，如果没有一套机制进行控制，验证的成本巨大。

l接口不匹配”是指服务依赖于彼此间的接口进行通信，如何保证改变一个服务的接口会对其他所有依赖服务是否造成造成影响。

l在发生契约变化时，提供一种可立即被服务端和消费端发现的方式。

契约测试能给我们带来什么？

l 降低服务集成的难度，把服务集成这个过程分解成了单元测试和接口测试来做，它从消费者的需求为出发点，把消费者的需求作为你的测试用例驱动出一份契约，然后验证提供者端的功能。

l通过使用契约测试，接口调用双方协商接口后就可以并行开发，并且在开发过程中就利用契约进行预集成测试，不用等到联调再来集成调通接口，一旦成熟，在保证质量的前提下，联调的成本可以减低到几乎为0。

l因为契约的存在，让接口的变动有迹可循，即使变动也可以确保变动的安全性和准确性。

l通过契约测试，团队能以一种离线的方式(不需要消费者、提供者同时在线)，通过契约作为中间的标准，验证提供者提供的内容是否满足消费者的期望。