前言
文章中还介绍了测试工具，比如cURL、postman，单API如何测试；但这些都是偏基础的东西，且网上教程各式各样，就不再赘述了；这里主要讲的就是关于复杂场景的API测试要如何应对
API测试的流程
- 准备测试数据（这是可选步骤，不一定所有 API 测试都需要这一步）
- 通过 API 测试工具，发起对被测 API 的 request
- 验证返回结果的 response
如何应对复杂场景的API测试？
测试场景一：被测业务操作是由多个API调用协作完成
背景
一个单一的前端操作可能会触发后端一系列的API调用，此时API的测试用例就不再是简单的单个API调用，而是一系列API的调用
存在的情况
- 存在后一个API需要使用前一个API返回结果的情况
- 需要根据前一个API的返回结果决定后面应该调用哪个API
存在问题
高效地获取单个前端操作所触发的API调用顺序
解决上述问题思路
- 通过网络监控手段，捕获单个前端操作时所触发的API调用顺序，譬如Fiddler、Charles等抓包工具
- 也可以通过用户行为日志，通过大数据手段来获取调用顺序
测试场景二：API 测试过程中的第三方依赖
背景
- API 之间是存在依赖关系的，比如你的被测对象是 API A，但是 API A 的内部调用了 API B，此时如果由于某种原因，API B 在被测环境中处于不可用状态，那么 API A 的测试就会受到影响。
- 在单体架构下，通常只会在涉及到第三方 API 集成的场景中才会遇到这个问题，所以还不算严重。但是，在微服务架构下，API 间相互耦合的依赖问题就会非常严重。
解决问题的核心思路
启用 Mock Server 来代替真实的 API
测试场景三：异步 API 的测试
什么是异步API
调用后会立即返回，但是实际任务并没有真正完成，而是需要稍后去查询或者回调（Callback）的 API
对异步 API 的测试主要分为两个部分
- 测试异步调用是否成功：检查返回值和后台工作线程是否被创建两个方面就可以了
- 测试异步调用的业务逻辑处理是否正确
测试异步调用的业务逻辑复杂性
因为异步 API 通常发生在一些比较慢的操作上，比如数据库 I/O、消息队列 I/O 等，此时测试往往需要去验证数据库中的值、消息队列中的值等，这就需要测试代码具有访问和操作数据库或者消息队列的能力。在实际工程项目中，这些能力一般会在测试框架级别提供，也就是说要求 API 测试框架中包含对应的工具类去访问和操作数据库或者消息队列等