知其然亦知其所以然，接口测试没有那么复杂，但也没有那么简单。

本文作者：张敏，软件测试工程师，就职于一家容器平台解决方案公司，负责 DevOps 产品的测试。

什么是 API

API(Application Programming Interface)是一些预先定义的函数，或指软件系统不同组成部分衔接的约定。也可以理解为是两个应用程序之间通信的机制，或者使用一组规则和协议的组件或计算机硬件。

提供应用程序与开发人员基于某软件或硬件得以访问一组例程的能力，而又无需访问源代码，或理解内部工作机制的细节。

API 被编写并使用在以下几个地方：

基于 Web 的应用程序
电脑操作系统
数据库系统
计算机硬件
软件库

上面是很广义的 API 的概念，包含了硬件和软件，但我们常说的 API 其实是很狭义的 Web Service 或者说 Web API 。

Web Service

Web Service 是一个平台独立的，低耦合的，自包含的、基于可编程的 web 的应用程序，可使用开放的 XML(标准通用标记语言下的一个子集)标准来描述、发布、发现、协调和配置这些应用程序，用于开发分布式的交互操作的应用程序。
百度百科

Web Service 是 API 的实现，用于通过网络(通常是 http/https)在 2 个应用程序之间进行通信。

所以 Web Service 和 Web API 是两个概念：

Web Service 是包装在 HTTP 中的 API
Web Service 需要网络，然而，API 不需要网络
所有的 Web Service 都是 APIs，但是并不是所有的 API 都是 Web Service

而实现 Web Service 的方式有三种：

【面向方法】RPC 远程过程调用的架构：包括 XML-RPC/JSON-RPC 协议
【面向消息】SOA 面向服务的架构：包括 SOAP 协议
【面向资源】REST 表现层状态转化的架构

REST & RESTful

我们大多数时间最常接触到的就是 REST 风格的 Web Service

REST 是 Web 服务的一种架构风格，一种设计风格，是一种思想，非协议也非规范。

简单看一下传统 API 设计以及 REST API 设计：

非 REST 设计：

# 查询用户http://localhost:8080/admin/getUser# 新增用户http://localhost:8080/admin/addUser# 更新用户http://localhost:8080/admin/updateUser# 删除用户http://localhost:8080/admin/deleteUser

结论：以不同的 URL(主要为使用动词)进行不同的操作。

REST 架构：

# 查询用户GET http://localhost:8080/admin/user # 新增用户POST http://localhost:8080/admin/user # 更新用户PUT http://localhost:8080/admin/user # 删除用户DELETE http://localhost:8080/admin/user

结论：URL 只指定资源，以 HTTP 方法动词进行不同的操作。用 HTTP STATUS/CODE 定义操作结果。

RESTful 是一种常见的 REST 应用，是遵循 REST 风格的 Web 服务，REST 式的 Web Service 是一种 ROA(面向资源的架构)。并且有以下几个特点：

每一个 URI 代表一种资源；
客户端和服务器之间，传递这种资源的某种表现层；
客户端通过四个 HTTP 动词(get、post、put、delete)，对服务器端资源进行操作，实现“表现层状态转化”。

标准的 RESTful 只有这四种操作 GET、POST、PUT、DELETE。这四种动作对应资源的增删改查操作。

查 GET
增 POST
改 PUT
删 DELETE

而我们还常接触的 HEAD、PATCH 其实不属于标准的 RESTful，可以理解为是开发人员以 RESTful 为标准约定的一种简单的方法。

所以目前我们所接触的应用是没有完全按照 RESTful 风格进行开发的，都是基于 RESTful 风格进行开发。

幂等性：对同一REST接口的多次访问，得到的资源状态是相同的。

安全性：对该REST接口访问，不会使服务器端资源的状态发生改变。

URI & URL

提到了 URI，就简单了解一下 URI 和 URL 的区别

URI：统一资源标识符
URL：统一资源定位符

所有的 URL 都是 URI。

举个简单的例子，我们知道百度的地址是 https://www.baidu.com/，但如果我们想阅读一篇关于 API 的文章，不能通过 https://www.baidu.com/ 这个地址去浏览想要阅读的文章，需要在后面加上一定的参数，比如文章的 ID 等等。

所以，https://www.baidu.com/ 就是一个 URI，它只是标识了一个资源，但是并没有定位到某一具体的资源。而某篇文章的具体地址就是 URL ，它定位了一个资源，我们可以通过这个 URL 找寻到该文章的位置。

所以 REST 架构是面向资源的架构，它的每一条 URL 代表的就是一个具体的资源。

什么是 API 测试

直接测试应用程序编程接口(API)，并作为集成测试的一部分来确定它们是否满足功能、可靠性、性能和安全性的期望。这就是 API 测试。

API 测试的优势

更早期的测试

一旦实现了逻辑，就可以构建测试来验证响应和数据的正确性，而不必等待构建前端。

更简单的测试维护

UI是不断变化的，但是 API 没有这样的挑战，API 测试现在被认为是自动化测试的关键，因为 API 现在是应用程序逻辑的主要接口。

更快的解决问题

当 API 测试失败时，我们确切地知道系统哪里坏了，哪里可以找到缺陷。

更快的测试速度和更广的覆盖范围

300 个UI测试可能需要 30 小时才能运行。300 个 API 测试可能在 3 分钟内运行。这意味着将在更短的时间内发现更多的 Bug，同时也将立即修复它们。

API 测试的内容

如何进行 API 测试

API 测试的开始时间并非在完成产品之后，在获得接口文档以后，就可以开始 API 测试。
API 测试的测试用例需要根据接口文档进行撰写，所以 API 测试十分依赖接口文档，因此需要确保接口文档的正确性。
测试前需要准备测试环境，如果没有正式的测试环境，可以先进行 Mock。
API 测试的范围很广，包括异常情况测试，性能测试等等，需要根据测试的内容选择合适的测试工具，抓包类的工具包括 Charles，Fiddler，Wireshark 等，测试脚本可以用过多种语言编写，包括 Python，Java，Go 等，测试工具包括 JMeter，Postman，ACCELQ 等等。
测试执行时，一旦出现问题，可以十分快速的定位出现问题的部分，及时反馈给开发人员进行修复。
测试完成后，需要完成测试报告，对 API 测试进行整体的归纳总结。

API 测试评判标准

往更细的说，我们经常接触的 API 测试其实就是对 URL 资源的操作。简单来说，一个 URL 就是一个接口，而 URL 则由以下几部分组成：

业务功能覆盖是否完整
业务规则覆盖是否完整
参数验证是否达到要求(边界、业务规则)
接口异常场景覆盖是否完整
接口覆盖率是否达到要求
代码覆盖率是否达到要求
性能指标是否满足要求
安全指标是否满足要求(SQL 注入)

单个 API 测试

往更细的说，我们经常接触的 API 测试其实就是对 URL 资源的操作。简单来说，一个 URL 就是一个接口，而 URL 则由以下几部分组成：

请求协议：

http — 普通的 http 请求
https — 加密的 http 请求，传输数据更加安全
ftp — 文件传输协议，主要用来传输文件

请求 IP：服务器地址
请求端口：服务器所开放的端口，不填写默认为80
接口路径：被操作的资源路径
接口参数：参数在接口路径后，使用 “?” 与路径进行区分，参数间使用 “&” 间隔

除以上部分，需要测试一个 API，还需要知道以下部分:

http 请求方式：包括 GET /POST/PUT/DELETE 等
http 请求头：请求头包含许多有关的客户端环境和请求正文的有用信息。例如，请求头可以声明浏览器所用的语言，请求正文的长度。示例：

Accept: application/json, text/plain, */*Content-Type: application/json;charset=UTF-8Authorization:eyJhbGciOiJIUser-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/84.0.4147.105 Safari/537.36