API 测试的基本步骤
- 准备测试数据(可选,不一定所有 API 测试都需要这一步);
- 通过 API 测试工具,发起对被测 API 的 request;
- 验证返回结果的 response。
Postman操作步骤
- 发起 API 调用;
- 添加结果验证;
- 保存测试用例;
- 基于 Postman 的测试代码自动生成。
为了将测试 request 作为回归测试用例集成到 CI/CD 的流程中,这就要求可以通过命令行的方式执行测试。为了达到这个目的,目前有两种做法:
-
将 Postman 中的测试 request 用自动化的方式直接转换成 API 测试的代码。
-
利用 Newman 工具直接执行 Postman 的 Collection。 你需要先将 Postman 中的 Collection 导出为 JSON 文件,然后执行以下命令行。
newman run examples/sample-collection.json;
如何应对复杂场景的API测试?
场景1:被测业务是由多个API调用协作完成
此场景会涉及到一系列 API 的调用,并且经常存在后一个 API 需要使用前一个 API 返回结果的情况,以及需要根据前一个 API 的返回结果决定后面应该调用哪个 API 的情况。通过API调用和结果解析的代码化就可以灵活处理该场景。
通过抓包的方式可以获取单个操作触发的API调用序列。
场景2:API测试过程中的第三方依赖
启用mock server来代替真实API就能实现
场景3:异步API的测试
异步API指的是调用后立即返回,但是任务没有完成,需要后续去查询或者回调的API.
异步 API 测试都是 API 测试中比较困难的部分,异步API的测试主要分为两部分:
-
测试异步调用是否成功(主要检查返回值和后台工作线程是否被创建两个方面就可以了)
-
测试异步调用的业务逻辑处理是否正确(异步 API 通常发生在一些比较慢的操作上,比如数据库 I/O、消息队列 I/O 等,此时测试往往需要去验证数据库中的值、消息队列中的值等,这就需要测试代码具有访问和操作数据库或者消息队列的能力)
异步API测试:
创建操作后,循环执行查询状态操作,等到发现状态正常后再进行后续操作,或者状态异常/超时后报错。