API测试基本步骤
1、准备测试数据（这是可选步骤，不一定所有 API 测试都需要这一步）；
2、通过 API 测试工具，发起对被测 API 的 request；
3、验证返回结果的 response。
对 API 的测试往往是使用 API 测试工具，比如常见的命令行工具 cURL、图形界面工具 Postman 或者 SoapUI、API 性能测试的 JMeter 等。
一、使用 cURL 命令行工具
需要下载安装 cURL，然后通过以下命令发起 Account API 的调用。
curl -i -H "Accept: application/json" -X GET "http://127.0.0.1:8080/account/ID008"
调用结束后的界面如图 4 所示。
image.png
- 参数“-i”，说明需要显示 response 的 header 信息；
- 参数“-H”，用于设定 request 中的 header；
- 参数“-X”，用于指定执行的方法，这里使用了 GET 方法，其他常见的方法还有 POST、PUT 和 DELETE 等，如果不指定“-X”，那么默认的方法就是 GET。
- 链接 ，指明了被测 API 的 endpoint 以及具体的 ID 值是“ID008”。
当使用 cURL 进行 API 测试时，常用参数还有两个：
- “-d”：用于设定 http 参数，http 参数可以直接加在 URL 的 query string，也可以用“-d”带入参数。参数之间可以用“&”串接，或使用多个“-d”。
- “-b”：当需要传递 cookie 时，用于指定 cookie 文件的路径。
注：这些参数都是大小写敏感的。
最常用的 cURL 命令以及使用的场景，包括 Session 的场景和 Cookie 的场景。
Session 场景
如果后端工程师使用 session 记录使用者登录信息，那么后端通常会传一个 session ID 给前端。之后，前端在发给后端的 requests 的 header 中就需要设置此 session ID，后端便会以此 session ID 识别出前端是属于具体哪个 session。
此时 cURL 的命令行如下所示：
curl -i -H "sessionid:XXXXXXXXXX" -X GET "http://XXX/api/demoAPI"
Cookie 场景
如果是使用 cookie，在认证成功后，后端会返回 cookie 给前端，前端可以把该 cookie 保存成为文件，当需要再次使用该 cookie 时，再用“-b cookie_File” 的方式在 request 中植入 cookie 即可正常使用。
具体的 cURL 的命令行如下所示：
// 将 cookie 保存为文件
curl -i -X POST -d username=robin -d password=password123 -c ~/cookie.txt "http://XXX/auth"
// 载入 cookie 到 request 中
curl -i -H "Accept:application/json" -X GET -b ~/cookie.txt "http://XXX/api/demoAPI"
总结：cURL 只能发起 API 调用，而其本身并不具备结果验证能力（结果验证由人完成），所以严格意义上说 cURL 并不属于测试工具的范畴。但是由于 cURL 足够轻量级，经常被很多开发人员和测试人员使用。
二、使用Postman测试
具体可通过下方链接细读
使用 Postman 进行接口测试（入门）
使用 Postman 进行接口测试（续）
使用 Postman 进行接口测试（cookie设置）
Postman全局变量设置和运用
Postman 搭建mock服务
如何应对复杂场景的 API 测试？
1：被测业务操作是由多个 API 调用协作完成
很多情况下，一个单一的前端操作可能会触发后端一系列的 API 调用，由于前端测试的相对不稳定性，或者由于性能测试的要求，必须直接从后端通过模拟 API 的顺序调用来模拟测试过程。
这时，API 的测试用例就不再是简单的单个 API 调用了，而是一系列 API 的调用，并且经常存在后一个 API 需要使用前一个 API 返回结果的情况，以及需要根据前一个 API 的返回结果决定后面应该调用哪个 API 的情况。
如何才能高效地获取单个前端操作所触发的 API 调用序列？
核心思路是，通过网络监控的手段，捕获单个前端操作所触发的 API 调用序列。
比如，通过 Fiddler 之类的网络抓包工具，获取这个调用序列；
又比如，目前很多互联网公司还在考虑基于用户行为日志，通过大数据手段来获取这个序列。
2：API 测试过程中的第三方依赖
API 之间是存在依赖关系的，比如被测对象是 API A，但是 API A 的内部调用了 API B，此时由于某种原因，API B 在被测环境中处于不可用状态，那么 API A 的测试就会受到影响。
在单体架构下，通常只会在涉及到第三方 API 集成的场景中才会遇到这个问题，所以还不算严重。但是，在微服务架构下，API 间相互耦合的依赖问题就会非常严重。
核心思路是，启用 Mock Server 来代替真实的 API。
3、异步 API 测试
异步 API 是指，调用后会立即返回，但是实际任务并没有真正完成，而是需要稍后去查询或者回调（Callback）的 API。
对异步 API 的测试主要分为两个部分
- 测试异步调用是否成功
异步调用是否成功，这个还比较简单，主要检查返回值和后台工作线程是否被创建两个方面就可以了 - 测试异步调用的业务逻辑处理是否正确
对异步调用业务逻辑的测试比较复杂，因为异步 API 通常发生在一些比较慢的操作上，比如数据库 I/O、消息队列 I/O 等，此时测试往往需要去验证数据库中的值、消息队列中的值等，这就需要测试代码具有访问和操作数据库或者消息队列的能力。
网友评论