什么是API接口测试

什么是 API ？

API 是“应用程序编程接口”的缩写，是一种允许不同应用程序之间相互通信和交换数据的接口。就好像在餐厅点餐一样，你只需要告诉服务员你想要的食物，而不需要了解厨房中的具体操作，服务员会把你的订单传递给厨房，然后将厨师烹饪好的食物提供给你。在这个过程中，服务员扮演的就是一个 API 的角色。同样地，当你使用 API 时，你只需要调用所需的功能和服务，而不需要了解底层的代码实现。因此，API 就像是应用程序和其他软件之间的“中间人”，使它们能够相互通信和交互。

随着数字化的不断深入，软件系统变得越来越复杂，传统的单体架构已经无法满足业务发展的需求。因此，微服务架构应运而生，它将单体架构中的功能分解成多个小型的、自治的服务，每个服务都具有独立的数据存储、业务逻辑和用户界面。这种架构的优点在于，不同的服务可以独立地进行开发、测试和部署，从而加快了软件开发的速度和灵活性。

微服务架构的诞生也使得 API 的数量激增。在单体架构中，整个应用程序只需要一个 API 来实现所有的功能。但在微服务架构中，每个服务都需要一个 API 来与其他服务进行通信，而且服务的数量可能会非常庞大。因此，API 在微服务架构中的作用愈加重要。

为什么要进行 API 测试？

随着 API 数量的激增， API 的质量也变得愈加重要，任何一个错误的 API 都可能会对整个系统产生严重的影响。

API 测试可以检测 API 的功能正确性、可靠性、安全性等方面的问题，帮助开发者在代码部署到生产环境之前，检测和修复潜在的问题，从而提高整个系统的可用性和可靠性。除此之外，API 测试还可以帮助开发者更快地响应业务需求。尤其是在微服务架构中，不同的服务可能会频繁地进行版本迭代和更新，相对于界面测试，API 测试可以更早开始，让系统更快地响应业务需求。

HTTP/HTTPS 协议

API 基于特定协议的通信接口，通过不同的传输协议进行数据传输。在介绍 API 测试之前，还需要了解一下 HTTP 协议的相关特性和规范，这样会更好掌握 API 接口测试。

目前最常见的 Web Service API 包括：SOAP、REST、RPC，我们大多数时间最常接触到的就是 REST 风格的 Web Service。RESTful API 是一种符合 REST 架构风格的 API，它使用 HTTP 协议的请求方法来访问资源，并使用 URIs（Uniform Resource Identifiers）来标识资源。

HTTP 是一种应用层协议，可以支持多种数据格式的传输，包括 JSON、XML 等。HTTPS 则是在 HTTP 上加入 SSL/TLS 加密层的安全传输协议，提供了更高的安全性。HTTP/HTTPS 协议的请求和响应消息都是由报文组成的，请求报文包含请求方法、请求头、请求体等信息，响应报文包含响应状态码、响应头、响应体等信息。

请求报文

HTTP 请求报文的结构一般由三部分组成：请求行、请求头和请求体。其中，请求行包含请求方法、请求 URI（指定客户端请求的资源的URI，包括路径、查询参数等）和 HTTP 协议版本；请求头包含一些附加信息，例如请求的主机名、浏览器类型等；请求体则包含请求的具体内容，例如表单数据、JSON 数据等。

例如，以下是一个 HTTP 请求报文的示例：

请求 URL

请求 URL（Uniform Resource Locator）是用于定位互联网上资源的地址。它通常由协议类型、主机名、端口号、路径和查询字符串等组成。例如：

www.example.com:8080/api/login?p…

其中：

https 是协议类型
www.example.com 是服务器地址
8080 是服务器所开放的端口
/api/login 是被操作的资源路径
param1=value1&param2=value2 是查询字符串

通过请求 URL，客户端可以向服务器发送请求并获取相应的资源。

请求方法

标准的 RESTful 只有 GET、POST、PUT、DELETE 这四种操作。

方法	描述
GET	(查询)发送请求来获得服务器上的资源，请求体中不会包含请求数据，请求的数据会附在URL之后，以?分隔。
POST	(新增)向服务器提交资源( 例如提交表单或上传文件 )。数据被包含在请求体中提交给服务器。
PUT	(修改)向服务器提交资源，并使用提交的新资源，替换掉服务器对应的旧资源。
DELETE	(删除)请求服务器删除指定的资源。

请求头

请求头（Request Header）是在 HTTP 请求中，客户端向服务器发送请求时所携带的一些附加信息，用于告诉服务器一些客户端的信息和需求。请求头通常包括一些标准的 HTTP 头部字段，例如 User-Agent、Accept、Accept-Encoding、Cookie 等等。这些头部字段可以帮助服务器了解客户端的类型、能力和需求，从而更好地响应客户端的请求。

如在上例中的请求报文中的请求头中：

Host：指定了请求的目标服务器地址
User-Agent：指定了发送请求的客户端，即使用 Firefox 58.0 浏览器的 Windows 10 操作系统。
Accept：指定了客户端能够接受的响应数据类型为 json
Content-Type：指定了请求体中的数据类型为 json
Content-Length：指定了请求体的长度为 43 个字节

请求体

请求体（Request Body）是在 HTTP 请求中，客户端向服务器发送请求时，携带的一些数据信息，用于告诉服务器客户端需要提交的数据。请求体通常用于 POST、PUT 等请求方法中，用于向服务器提交数据，例如表单数据、JSON 数据等等。

请求体的格式和内容通常由请求头中的 Content-Type 字段指定，例如 application/x-www-form-urlencoded、application/json 等等。服务器可以根据请求体中的数据信息，进行相应的处理和响应。

响应报文

HTTP 响应报文的结构也由三部分组成：状态行、响应头和响应体。其中，状态行包含 HTTP 协议版本、状态码和状态描述；响应头包含一些附加信息，例如响应的内容类型、响应的长度等；响应体则包含响应的具体内容，例如 HTML 页面、JSON 数据等。

以下是一个 HTTP 响应报文的示例：

如何进行 API 测试

API 测试工作主要流程有：

确定测试目的和范围：首先需要阅读产品设计文档和接口文档，明确要测试的接口的功能和特性，并确定测试的范围，例如测试的是哪些接口、请求和响应的数据格式、参数、返回值等。
设计测试用例：根据该接口参数，构造不同的用例，测试接口在参数合法及非法情况下能否达到预期效果。
使用 API 接口测试工具发送请求并验证响应，如 Postman、AREX 等。

接口测试的测试点

接口测试是对系统中的各个接口进行测试，以验证接口的功能、性能、安全等方面是否符合需求和规范。

1. 功能测试

验证接口的功能是否正确实现了、接口是否按照设计文档中来实现。

单接口功能测试：

兼容性测试：验证接口在不同的操作系统、浏览器、设备等环境下的兼容性。
参数验证：验证接口参数的正确性、完整性、合法性等，包括参数类型、长度、格式、范围等。
接口返回值验证：验证接口返回值的正确性、完整性、合法性等，包括返回值类型、长度、格式、范围等。
异常测试：验证接口在异常情况下的处理能力，包括参数错误、数据异常、网络异常、服务器错误等。

多接口的业务场景功能测试：

针对一个或多个业务场景，测试多个接口之间的交互和协作是否正常。这种测试通常需要模拟真实的业务场景，包括多个接口的调用顺序、参数传递、返回结果等，以确保整个业务流程的正确性和稳定性。在测试过程中，需要对每个接口进行单独测试，同时也需要对多个接口之间的交互进行测试，以发现潜在的问题和缺陷。

2. 性能测试

验证接口在高并发、大数据量等情况下的性能表现，包括响应时间、吞吐量、并发数等。

压力测试：模拟多用户并发访问接口，观察接口的性能表现，如响应时间、吞吐量、错误率等。可以使用一些工具来进行压力测试，比如JMeter、LoadRunner等。
负载测试：测试接口在不同负载下的性能表现。负载测试可以分为静态负载和动态负载两种方式。静态负载是指在预定的并发数下测试接口的性能表现，而动态负载是根据实际负载情况动态地调整并发数，以测试接口在不同负载下的性能表现。
并发测试：测试接口在并发访问下的性能表现。并发测试可以通过多线程的方式实现，模拟多用户同时访问接口，观察接口的性能表现。
容量测试：测试接口能够承受的最大负载量。容量测试可以通过逐步增加负载的方式实现，直到达到系统的极限为止，观察接口的性能表现。
稳定性测试：测试接口在长时间运行中的稳定性表现。稳定性测试可以通过长时间运行的方式实现，观察接口在长时间运行中的性能表现。

3. 安全测试

测试接口的安全性，包括其防护能力、认证授权、数据加密等方面的测试。