聊一聊 API 接口测试
知其然亦知其所以然，接口测试没有那么复杂，但也没有那么简单。
本文作者：张敏，软件测试工程师，就职于一家容器平台解决方案公司，负责 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。这四种动作对应资源的增删改查操作。
| HTTP 方法 | 对应操作 |
|---|---|
| GET | 查 |
| POST | 增 |
| PUT | 改 |
| DELETE | 删 |
而我们还常接触的 HEAD，PATCH 其实不属于标准的 RESTful，可以理解为是开发人员以 RESTful 为标准约定的一种简单的方法。
所以目前我们所接触的应用是没有完全按照 RESTful 风格进行开发的，都是基于 RESTful 风格进行开发。
| HTTP 方法 | 资源操作 | 幂等 | 安全 |
|---|---|---|---|
| GET | SELECT | 是 | 是 |
| POST | INSERT | 否 | 否 |
| PUT | UPDATE | 是 | 否 |
| DELETE | DELETE | 是 | 否 |
幂等性：对同一 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 测试评判标准
- 业务功能覆盖是否完整
- 业务规则覆盖是否完整
- 参数验证是否达到要求（边界、业务规则）
- 接口异常场景覆盖是否完整
- 接口覆盖率是否达到要求
- 代码覆盖率是否达到要求
- 性能指标是否满足要求
- 安全指标是否满足要求（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-8 Authorization:eyJhbGciOiJI User-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 -
http 请求体：API 发送的 body 数据，有多种格式
- json格式
- xml格式
- html格式
- 二进制格式( 多数用于图片 )
- 字符串格式
当了解 API 的整个请求结构后，就能进行 API 测试了。而 API 测试主要测试的内容也是 API 的参数，设计测试用例时完全可以采用功能测试设计用例的方法来设计，比如正常发送请求，或者参数不传值，传值类型不正确等等多种异常情况。
API 测试步骤如下:
- 发送带有必要输入数据的请求
- 获取具有输出数据的响应
- 验证响应是否按要求返回
该 API 测试的验证方式就是通过 HTTP 响应码，返回数据格式 ，返回数据类型，返回数据信息这四部分进行验证。
- HTTP 响应码：1xx（临时响应） 、2xx （成功） 、3xx （重定向） 、4xx（请求错误） 、 5xx（服务器错误）
- 返回数据格式：json、xml
- 返回数据类型：string、int、Booleans
- 返回数据信息：检验是否符合预期，根据测试要求选择是否比对数据库数据，保证测试结果的准确性
总结一下
进行 API 测试的时候，可以考虑以下几个方面:
- 理解 API 的需求
- 指定 API 输出状态（响应状态代码）
- 关注小型函数 API（登录 API、获取令牌 API、健康检查 API）
- 对 API 进行分组（同一类别的 API 共享一些公共信息，如资源类型、路径等）
- 利用自动化功能进行 API 测试
- 选择合适的自动化工具
- 选择合适的验证方法
- 创建正面测试和负面测试
- 现场测试过程
- 不要低估 API 自动化测试
开始愉快的 API 测试之旅吧～
