这是我购买的"极客时间"上的一套课程的笔记，总共52讲，定期对其中的内容做一笔记，巩固学习内容。

22 从0到1：API测试怎么做？常用API测试工具简介

API 测试的基本步骤

1. 准备测试数据（可选）；
2. 通过API测试工具，发起对被测API的request；
3. 验证返回结果的response。

基于Spring Boot 构建的API

这里作者提供了一个api的代码，用于说明如何测试它。笔记就不写了。

使用cURL 命令行工具进行测试

主要介绍了一下参数的用法，然后参数都是大小写敏感的。具体我就不照抄了，大家去看原文。

接下来分析了，Sesison、Cookie的场景下，如何用cURL工具测试。

使用图形界面工具Postman进行测试

这块关注一下：保存测试用例和基于Postman的测试代码自动生成。如何安装、发送请求啥的没什么好做笔记的，看原文就好。

1. 保存测试用例

可以用Collection来分类管理保存多个测试request。如果申请注册了账号，还可以在多个环境中共享这个Collection。

2. 基于Postman的测试代码自动生成

有两种做法：

• 将Postman中的测试request用自动化的方式直接转换成API测试的代码。目前Postman支持这个功能，将保存的测试request自动化转换成常见测试框架直接支持的代码，并且支持多语言哦！（是不是很强大）
• 利用Newman工具直接执行Postman的Collection。
  先把Postman的Collection导出成JSON文件，然后执行命令：
  newman run examples/sample-collection.json;

如何应对复杂场景的API测试？

测试场景一：被测业务操作是由多个API调用协作完成。

实现了API调用和结果解析的代码华，就可以很灵活的直接用代码来处理这些场景了。

那么，如何才能高效地获取单个前端操作所触发的API调用序列？
解决这个问题的核心思路是，通过网络监控的手段，捕获单个前端操作所触发的 API 调用序列。比如，通过类似于 Fiddler 之类的网络抓包工具，获取这个调用序列；又比如，目前很多互联网公司还在考虑基于用户行为日志，通过大数据手段来获取这个序列。

测试场景二：API 测试过程中的第三方依赖

在单体架构下，通常只会在涉及到第三方 API 集成的场景中才会遇到这个问题，所以还不算严重。但是，在微服务架构下，API 间相互耦合的依赖问题就会非常严重。

解决这个问题的核心思路是，启用 Mock Server 来代替真实的 API。

测试场景三：异步API的测试

一直以来，这都是比较困难的部分。作者看来，对异步API的测试主要分为两个部分：
一是，测试异步调用是否成功；
二是，测试异步调用的业务逻辑处理是否正确。

• 异步调用是否成功，这个还比较简单，主要检查返回值和后台工作线程是否被创建两个方面就可以了。
• 但是，对异步调用业务逻辑的测试就比较复杂了，因为异步 API 通常发生在一些比较慢的操作上，比如数据库 I/O、消息队列 I/O 等，此时测试往往需要去验证数据库中的值、消息队列中的值等，这就需要测试代码具有访问和操作数据库或者消息队列的能力。
• 在实际工程项目中，这些能力一般会在测试框架级别提供，也就是说要求 API 测试框架中包含对应的工具类去访问和操作数据库或者消息队列等。

【心得】
Postman原来还有测试代码自动生成的功能嘛，看来要好好发掘一下。
关于异步API的测试，目前还没有做过，值得思考。
关于Mock Server的部分，作者后续会详细展开，这块也是我目前比较关注的。