22|从0到1:API测试怎么做?常用API测试工具简介 [操作系统入门]
从 0 到 1 设计一个 API 测试用例,通过这个测试用例,你可以体会到最基本的 API 测试是如何进行的,并介绍几款常用的 API 测试工具。
API 测试的基本步骤
API 测试的基本步骤主要包括以下三大步骤:
准备测试数据(这是可选步骤,不一定所有 API 测试都需要这一步);
通过 API 测试工具,发起对被测 API 的 request;
验证返回结果的 response。
测试的API介绍
基于主流 Spring Boot 框架开发的简单 Restful API。
这个 Account API 的功能非常简单,就是基于你提供的 ID 值创建一个 Account 对象,并返回这个新创建 Account 对象。比如,如果你的请求是“account/ID008”,那么返回的 response 就应该是“{“id”:“ID008”,“type”:“friends”,“email”:“[email protected]”}”。
源码:
使用 cURL 命令行工具进行测试
curl -i -H "Accept: application/json" -X GET "http://127.0.0.1:8080/account/ID008"
参数的含义如下:
第一个参数“-i”,说明需要显示 response 的 header 信息;
第二个参数“-H”,用于设定 request 中的 header;
第三个参数“-X”,用于指定执行的方法,这里使用了 GET 方法,其他常见的方法还有 POST、PUT 和 DELETE 等,如果不指定“-X”,那么默认的方法就是 GET。
最后“ http://127.0.0.1:8080/account/ID008 ”,指明了被测 API 的 endpoint 以及具体的 ID 值是“ID008”。
当使用 cURL 进行 API 测试时,常用参数还有两个:
“-d”:用于设定 http 参数,http 参数可以直接加在 URL 的 query string,也可以用“-d”带入参数。参数之间可以用“&”串接,或使用多个“-d”。
“-b”:当需要传递 cookie 时,用于指定 cookie 文件的路径。
Session 的场景
curl -i -H "sessionid:XXXXXXXXXX" -X GET "http://XXX/api/demoAPI"
Cookie 的场景
// 将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"
使用图形界面工具 Postman 进行测试
具体的操作,主要包括:
发起 API 调用;
添加结果验证;
保存测试用例;
基于 Postman 的测试代码自动生成。
你希望将你的测试 request 作为回归测试用例集成到 CI/CD 的流程中,这就要求可以通过命令行的方式执行你的测试。为了达到这个目的,目前有两种做法:
- 将 Postman 中的测试 request 用自动化的方式直接转换成 API 测试的代码。
- 利用 Newman 工具直接执行 Postman 的 Collection
你需要先将 Postman 中的 Collection 导出为 JSON 文件,然后执行以下命令行。
newman run examples/sample-collection.json;
如何应对复杂场景的 API 测试?
测试场景一:被测业务操作是由多个 API 调用协作完成
一个单一的前端操作可能会触发后端一系列的 API 调用,存在后一个 API 需要使用前一个 API 返回结果的情况,以及需要根据前一个 API 的返回结果决定后面应该调用哪个 API 的情况。
直接用代码来处理这些场景
通过代码将上个 API 调用返回的 response 中的某个值传递给下一个 API,再比如根据上一个 API 的返回结果决定下一个应该调用哪个 API 等。
如何才能高效地获取单个前端操作所触发的 API 调用序列?
通过网络监控的手段,捕获单个前端操作所触发的 API 调用序列。
比如,通过类似于 Fiddler 之类的网络抓包工具,获取这个调用序列;
又比如,目前很多互联网公司还在考虑基于用户行为日志,通过大数据手段来获取这个序列。
测试场景二:API 测试过程中的第三方依赖
API 之间是存在依赖关系的,比如你的被测对象是 API A,但是 API A 的内部调用了 API B,此时如果由于某种原因,API B 在被测环境中处于不可用状态。
启用 Mock Server 来代替真实的 API。
测试场景三:异步 API 的测试
异步 API 是指,调用后会立即返回,但是实际任务并没有真正完成,而是需要稍后去查询或者回调(Callback)的 API。
对异步 API 的测试主要分为两个部分:一是,测试异步调用是否成功,二是,测试异步调用的业务逻辑处理是否正确。
异步调用是否成功,这个还比较简单,主要检查返回值和后台工作线程是否被创建两个方面就可以了。
但是,对异步调用业务逻辑的测试就比较复杂了,因为异步 API 通常发生在一些比较慢的操作上,比如数据库 I/O、消息队列 I/O 等,此时测试往往需要去验证数据库中的值、消息队列中的值等,这就需要测试代码具有访问和操作数据库或者消息队列的能力。
在实际工程项目中,这些能力一般会在测试框架级别提供,也就是说要求 API 测试框架中包含对应的工具类去访问和操作数据库或者消息队列等。
来源于 极客时间 茹炳晟 软件测试52讲
22 | 从0到1:API测试怎么做?常用API测试工具简介
以上是 22|从0到1:API测试怎么做?常用API测试工具简介 [操作系统入门] 的全部内容, 来源链接: utcz.com/z/518369.html