聊一聊 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 风格进行开发。
URI & URL
提到了 URI，就简单了解一下 URI 和 URL 的区别
URI：统一资源标识符
URL：统一资源定位符
所有的 URL 都是 URI。
所以 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 — 文件传输协议，主要用来传输文件
请求端口：服务器所开放的端口，不填写默认为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
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 测试之旅吧～
-- END --