API 测试就是接口测试。
对于现在大多的互联网公司来说，API 测试可以实现良好的投入产出比，因此应该成为互联网产品的测试重点，也就是形成了菱形的测试策略。
原则是：
- 重量级 API 测试。
- 轻量级 GUI 测试。
- 轻量级单元测试。
一、API 测试的基本步骤
API 测试说简单也很简单，基本上就是三步走：
- 准备测试数据（也可能有现成的）。
- 使用工具，对待测试 API 发起请求。
- 验证返回的结果 response。
请求工具就很多了，常见的有：Postman、JMeter、cURL，还有代码里的请求库，比如 python 中的 requests、java 中的 okhttp 等等。我们通常根据业务特点和所处阶段，选用最适合的测试工具。
二、多 API 调用的复杂场景
除了我们最常见的单接口测试之外，还会遇到某些业务涉及调用多个 API 来完成的场景。
通常这个时候，我们需要知道多个 API 的调用顺序，这些可以借助工具（比如fiddler）或者系统日志来辅助我们完成。
对于有值传递的情况，比如 接口B 需要先调用接口A 并且使用 A的返回，当做入参。现在也是很好处理，不管是使用 GUI 工具，或者代码都可以完成。
我个人偏向使用代码，更加灵活轻便。
三、API 对第三方有依赖
API 之间是存在依赖关系的，比如你的被测对象是接口 A，但是接口 A 的内部调用了接口 B。此时如果由于某种原因，接口 B 处于不可用状态，那么接口 A 的测试就会受到影响。
在单体应用里，通常只有涉及到第三方 API 集成的场景中才会遇到这个问题，数量不会很多。
但是在当下的微服务架构下，API 间相互耦合的依赖问题就会非常严重。
如何解耦，还是得用Mock Server。核心思路是，启用 Mock Server 来代替真实的 API。
现在也有不少开源的 mock 引擎，可以根据需要进行选用。当然了，有条件的话也可以自研一个，方便实现定制化。
四、异步 API 的测试
这里之前还跟奇哥讨论过一番，给了我一些不错的建议。
异步 API 是指，调用后会立即返回，但是实际任务并没有真正完成，而是需要稍后去查询或者回调（Callback）的 API。
比如，被测 API A 完成的是下订单的操作。这个 API A 完成下订单操作要通过调用另外一个 API B 将订单信息写入到消息队列中去。
而真正下订单成功指的是消息队列中的消息被后续服务正确处理并且成功了。此时，这里的后续消息处理就是异步的操作了。
那么现在测试这个 API A，通常情况下：
- 我只需要验证它是否正确地发起了对 API B 的调用即可。
- 不用关心 API B 的具体行为结果。
具体点描述就是，只关注 API A 是否以正确的参数调用了 API B 即可。而无需关注 API B 是否正确地执行了将订单信息写入消息队列的操作。更不用关注，消息队列中的消息被异步处理的结果。
而对于异步处理的结果，我觉得可以放在一些典型的测试场景里去覆盖。
