API 是“应用程序编程接口”的缩写,是一种允许不同应用程序之间相互通信和交换数据的接口。就好像在餐厅点餐一样,你只需要告诉服务员你想要的食物,而不需要了解厨房中的具体操作,服务员会把你的订单传递给厨房,然后将厨师烹饪好的食物提供给你。在这个过程中,服务员扮演的就是一个 API 的角色。同样地,当你使用 API 时,你只需要调用所需的功能和服务,而不需要了解底层的代码实现。因此,API 就像是应用程序和其他软件之间的“中间人”,使它们能够相互通信和交互。
随着数字化的不断深入,软件系统变得越来越复杂,传统的单体架构已经无法满足业务发展的需求。因此,微服务架构应运而生,它将单体架构中的功能分解成多个小型的、自治的服务,每个服务都具有独立的数据存储、业务逻辑和用户界面。这种架构的优点在于,不同的服务可以独立地进行开发、测试和部署,从而加快了软件开发的速度和灵活性。
微服务架构的诞生也使得 API 的数量激增。在单体架构中,整个应用程序只需要一个 API 来实现所有的功能。但在微服务架构中,每个服务都需要一个 API 来与其他服务进行通信,而且服务的数量可能会非常庞大。因此,API 在微服务架构中的作用愈加重要。
随着 API 数量的激增, API 的质量也变得愈加重要,任何一个错误的 API 都可能会对整个系统产生严重的影响。
API 测试可以检测 API 的功能正确性、可靠性、安全性等方面的问题,帮助开发者在代码部署到生产环境之前,检测和修复潜在的问题,从而提高整个系统的可用性和可靠性。除此之外,API 测试还可以帮助开发者更快地响应业务需求。尤其是在微服务架构中,不同的服务可能会频繁地进行版本迭代和更新,相对于界面测试,API 测试可以更早开始,让系统更快地响应业务需求。
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…
其中:
通过请求 URL,客户端可以向服务器发送请求并获取相应的资源。
请求方法
标准的 RESTful 只有 GET、POST、PUT、DELETE 这四种操作。
方法 | 描述 |
---|---|
GET | (查询)发送请求来获得服务器上的资源,请求体中不会包含请求数据,请求的数据会附在URL之后,以?分隔。 |
POST | (新增)向服务器提交资源( 例如提交表单或上传文件 )。数据被包含在请求体中提交给服务器。 |
PUT | (修改)向服务器提交资源,并使用提交的新资源,替换掉服务器对应的旧资源。 |
DELETE | (删除)请求服务器删除指定的资源。 |
请求头
请求头(Request Header)是在 HTTP 请求中,客户端向服务器发送请求时所携带的一些附加信息,用于告诉服务器一些客户端的信息和需求。请求头通常包括一些标准的 HTTP 头部字段,例如 User-Agent、Accept、Accept-Encoding、Cookie 等等。这些头部字段可以帮助服务器了解客户端的类型、能力和需求,从而更好地响应客户端的请求。
如在上例中的请求报文中的请求头中:
请求体
请求体(Request Body)是在 HTTP 请求中,客户端向服务器发送请求时,携带的一些数据信息,用于告诉服务器客户端需要提交的数据。请求体通常用于 POST、PUT 等请求方法中,用于向服务器提交数据,例如表单数据、JSON 数据等等。
请求体的格式和内容通常由请求头中的 Content-Type 字段指定,例如 application/x-www-form-urlencoded、application/json 等等。服务器可以根据请求体中的数据信息,进行相应的处理和响应。
响应报文
HTTP 响应报文的结构也由三部分组成:状态行、响应头和响应体。其中,状态行包含 HTTP 协议版本、状态码和状态描述;响应头包含一些附加信息,例如响应的内容类型、响应的长度等;响应体则包含响应的具体内容,例如 HTML 页面、JSON 数据等。
以下是一个 HTTP 响应报文的示例:
API 测试工作主要流程有:
接口测试是对系统中的各个接口进行测试,以验证接口的功能、性能、安全等方面是否符合需求和规范。
1. 功能测试
验证接口的功能是否正确实现了、接口是否按照设计文档中来实现。
单接口功能测试:
多接口的业务场景功能测试:
针对一个或多个业务场景,测试多个接口之间的交互和协作是否正常。这种测试通常需要模拟真实的业务场景,包括多个接口的调用顺序、参数传递、返回结果等,以确保整个业务流程的正确性和稳定性。在测试过程中,需要对每个接口进行单独测试,同时也需要对多个接口之间的交互进行测试,以发现潜在的问题和缺陷。
2. 性能测试
验证接口在高并发、大数据量等情况下的性能表现,包括响应时间、吞吐量、并发数等。
3. 安全测试
测试接口的安全性,包括其防护能力、认证授权、数据加密等方面的测试。
对于安全测试,需要针对不同的安全风险和威胁,采用不同的测试方法和技术进行测试。同时,也需要考虑测试环境的安全性,如测试数据的保护、测试过程中的安全管理等。为了提高测试效率和覆盖率,可以使用安全测试工具来辅助测试,如漏洞扫描工具、代码静态分析工具等。
这里使用 AREX 进行演示,首先我们需要创建一个接口请求:
添加请求 URL
在地址栏中输入你要发送请求的接口地址。
选择请求方法
新建请求后,请求方法默认选择为 GET,GET 请求将从服务器获取信息。
添加查询参数
Query Parameters 即 URL 中 ? 后的参数,通过 & 分隔多个参数,可以向 Web 应用程序传递附加信息。
配置请求头
如需要随请求发送特定的请求头信息,可以添加请求头键值对。
Body 参数
当你需要将数据从客户端发送给 API 时,则需要随请求发送请求体数据。通常在 PUT 、POST 和 PATCH 请求中会使用到请求体。
使用脚本
脚本分为前置脚本和后置脚本两种,分别对应 API 请求前和返回数据后的两个阶段。
前置脚本是在 API 请求前执行的 JavaScript 代码,可以使用前置脚本添加认证信息、设置请求超时时间、检查请求参数的格式等。AREX 提供了常用的前置脚本,可直接点击使用。
后置脚本(Tests)是在 API 请求返回数据后执行的 JavaScript 代码。主要用来测试(断言)请求返回结果的正确性。
配置好请求参数后,点击发送即可获取响应。
返回响应
响应框的上方可以看到请求的状态码、请求时间和请求大小。
Response Body 是响应的正文,即从服务器返回的响应内容,内容的数据格式默认为 JSON。
Raw 视图可以查看原始的响应体内容。
Headers 可以看到响应头信息。
如果设置了后置脚本,则可以在 Results 中查看执行脚本的结果。