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测试：
创建操作后，循环执行查询状态操作，等到发现状态正常后再进行后续操作，或者状态异常/超时后报错。