API 测试

初探

API 测试基本步骤

无论采取什么 API 测试工具，API 测试的基本步骤是一致的：

1. 准备测试数据【可选，不是所有的 API 测试都需要准备这一步】
2. 通过 API 测试工具发起北侧 API 的请求
3. 验证响应

API 测试工具：命令行工具 cURL、图形化界面公管局 Postman 或 SoapUI、API 性能测试工具 JMeter。

使用 cURL

curl 是常用的命令行工具，用来请求 Web 服务器。它的名字就是客户端（client）的 URL 工具的意思。但是 curl 只能发起 API 调用，其本身并不具备结果验证能力。

基本用法

curl -i 'Accept: application/json' -X GET 'URL'

• -i : 说明需要显示响应的 header 信息
• -I : 向服务器发出 HEAD 请求，然会将服务器返回的 HTTP 标头打印出来。
• -H : 设定请求中的 header
• -e : 用来设置 HTTP 的标头 Referer，表示请求的来源。
• -X : 指定执行的方法，常用 GET 或 POST。不指定默认为 GET
• -x : 指定 HTTP 请求的代理。
• -G : 用来构造 URL 的查询字符串。
• -d : 用于指定 http 参数，http 参数可以直接加在 URL 的查询字段中，也可以 -d 代入参数。参数之间可以用 '&' 串接，或使用多个 -d 参数
• --data-urlencode : 参数等同于-d，发送 POST 请求的数据体，区别在于会自动将发送的数据进行 URL 编码
• -b : 当需要传递 cookie 时，用于指定 cookie 文件的路径
• -c : 将服务器设置的 Cookie 写入一个文件
• -A : 指定客户端的用户代理标头，即 User-Agent。curl 的默认用户代理字符串是 'curl/[version]'
• -F : 用来向服务器上传二进制文件
• -k : 指定跳过 SSL 检测
• -L : 会让 HTTP 请求跟随服务器的重定向。curl 默认不跟随重定向
• --limit-rate : 用来限制 HTTP 请求和回应的带宽，模拟慢网速的环境
• -o : 将服务器的回应保存成文件，等同于 wget 命令
• -O : 将服务器回应保存成文件，并将 URL 的最后部分当作文件名
• -s : 将不输出错误和进度信息
• -S : 指定只输出错误信息，通常与 -s 一起使用
• -u : 用来设置服务器认证的用户名和密码
• -v : 输出通信的整个过程，用于调试

Postman

Postman 是目前使用较为广泛的 http 请求模拟工具之一。早期的 Postman 是以 Chrome 浏览器的插件形式存在得，最新版本的已是独立的应用。

Postman 基本操作步骤：

1. 发起 API 调用
2. 添加结果验证功能
3. 保存测试用例
4. 自动生成基于 Postman 的测试代码

结果验证

code 可以将测试请求直接转为 API 测试代码

API 测试框架

早期基于 Postman 的 API 测试工具，存在两个问题 : (1) 当需要频繁执行大量测试用例时，这类测试工具就有些笨拙 (2) 基于图形界面操作的 API 测试难以与 CI/CD 流水线集成。

基于 Postman 和 Newman 的 APi 测试 : 对于需要连续调用多个 API 并且传递参数的情况下就不再是理想方案。

基于代码的 API 测试

为了解决以上问题，出现了基于代码的 API 测试框架。典型的有基于 JAVA 的 OkHttP 和 Unireset、基于 Python 的 http.client 和 Requests、基于 Node.js 的 Native 和 Request 等。

优势：

1. 可以灵活支持多个 API 顺序调用，方便数据在多个 API 之间传递，即上一个API调用返回结果中的某个字段可以作为后继 API 调用的输入参数
2. 方便在 APi 调用之前或之后执行额外的任意操作，可以在调用前准备数据，调用后处理现场等
3. 可以很方便支持数据驱动测试，就是可以将测试数据和代码分离，解耦
4. 因为直接采用代码实现，所以可以更灵活地处理测试验证的断言
5. 支持命令行的测试执行方式，可以方便地和 CI/CD 工具集成

劣势：

1. 对于单个 API 测试的搽干净，工作量比 Postman 大得多
2. 无法直接重用 Postman 里面已经激积累的 Collections

自动生成 API 测试代码

自动生成 API 测试代码是指，基于 Postman 的 Collection 生成基于代码的 API 测试用例。

如果直接使用这个功能，存在两个问题：

1. 测试中断言部分不会生成代码，即测试代码的生成只支持发起请求的部分，而不自动生成测试验证点的代码
2. Postman 不支持自己开发的 API 测试框架

基于以上问题，理想方案是自己实现一个代码测试工具，输入是 Postman 中 Collection 的 JSON 文件，输出是基于自己开发的 API 测试框架的测试代码，而且同时将测试的断言一并转为代码。这个工具的本质是解析 Collection JSON 文件，并根据自己的 API 测试框架进行变量替换。

但是还存在问题：测试验证中的断言。

响应结果发生变化时的自动识别

对于 API 测试，有一个很重要的概念：向后兼容性。API 的向后兼容性是指，发布新的 API 版本应该兼容老版本的APi，这要求 API 调用参数不变，响应字段不变。

响应结果发生变化时的自动识别就是解决这个问题，具体思路: 在 API 测试框架中引入一个内建数据库，推荐为 MongoDB，用这个数据库记录每次滴啊用的请求和响应的组合。当下次发送请求时，API 测试框架自动和上次的响应做差异检测，对变化字段给出警告。同时需要设置一个白名单，把动态值的字段排除在外。