API 测试的基本步骤

1. 准备测试数据（可选，不一定所有 API 测试都需要这一步）；
2. 通过 API 测试工具，发起对被测 API 的 request；
3. 验证返回结果的 response。

Postman操作步骤

1. 发起 API 调用；
2. 添加结果验证；
3. 保存测试用例；
4. 基于 Postman 的测试代码自动生成。

        为了将测试 request 作为回归测试用例集成到 CI/CD 的流程中，这就要求可以通过命令行的方式执行测试。为了达到这个目的，目前有两种做法：

1. 将 Postman 中的测试 request 用自动化的方式直接转换成 API 测试的代码。
2. 利用 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的测试主要分为两部分：

        1. 测试异步调用是否成功（主要检查返回值和后台工作线程是否被创建两个方面就可以了）

        2. 测试异步调用的业务逻辑处理是否正确（异步 API 通常发生在一些比较慢的操作上，比如数据库 I/O、消息队列 I/O 等，此时测试往往需要去验证数据库中的值、消息队列中的值等，这就需要测试代码具有访问和操作数据库或者消息队列的能力）

异步API测试：

        创建操作后，循环执行查询状态操作，等到发现状态正常后再进行后续操作，或者状态异常/超时后报错。