API自动化测试篇

API测试步骤

常来讲，无论采用什么 API 测试工具，API 测试的基本步骤主要包括以下三大步骤：

1、准备测试数据（这是可选步骤，不一定所有 API 测试都需要这一步）；
2、通过 API 测试工具，发起对被测 API 的 request；
3、验证返回结果的 response。
对 API 的测试往往是使用 API 测试工具，比如常见的命令行工具 cURL、图形界面工具 Postman 或者 SoapUI、API 性能测试的 JMeter 等。

使用curl

cURL 只能发起 API 调用，而其本身并不具备结果验证能力（结果验证由人完成），所以严格意义上说 cURL 并不属于测试工具的范畴。但是由于 cURL 足够轻量级，经常被很多开发人员和测试人员使用，所以我在这里做了简单的介绍。

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

具体的操作，主要包括：
发起 API 调用；
添加结果验证；
保存测试用例；
基于 Postman 的测试代码自动生成，利用 Newman 工具直接执行 Postman 的 Collection。
postman可以批量执行，Newman的目的是为了可以从命令行发起测试，的确是为了持续集成

测试场景一：被测业务操作是由多个 API 调用协作完成
可以将前一个API接口返回结果的值传给下一个API

如何才能高效地获取单个前端操作所触发的 API 调用序列？
通过网络监控的手段，捕获单个前端操作所触发的 API 调用序列。比如，通过类似于 Fiddler 之类的网络抓包工具，获取这个调用序列

测试场景二：API 测试过程中的第三方依赖
在微服务架构下，API 间相互耦合的依赖问题就会非常严重
解决这个问题的核心思路是，启用 Mock Server 来代替真实的 API

测试场景三：异步 API 的测试
异步 API 是指，调用后会立即返回，但是实际任务并没有真正完成，而是需要稍后去查询或者回调（Callback）的 API。一直以来，异步 API 测试都是 API 测试中比较困难的部分。在我看来，对异步 API 的测试主要分为两个部分：一是，测试异步调用是否成功，二是，测试异步调用的业务逻辑处理是否正确。异步调用是否成功，这个还比较简单，主要检查返回值和后台工作线程是否被创建两个方面就可以了。但是，对异步调用业务逻辑的测试就比较复杂了，因为异步 API 通常发生在一些比较慢的操作上，比如数据库 I/O、消息队列 I/O 等，此时测试往往需要去验证数据库中的值、消息队列中的值等，这就需要测试代码具有访问和操作数据库或者消息队列的能力。在实际工程项目中，这些能力一般会在测试框架级别提供，也就是说要求 API 测试框架中包含对应的工具类去访问和操作数据库或者消息队列等

API自动化测试框架的前世今生

基于postman的API测试

基于 Postman 的 API 测试 当需要频繁执行大量的测试用例时，基于界面的 API 测试就显得有些笨拙；基于界面操作的测试难以与 CI/CD 流水线集成。

基于postman和newman的API测试

基于 Postman 和 Newman 的 API 测试 对于需要连续调用多个 API 并且有参数传递的情况，Postman+Newman 似乎就不再是理想的测试方案了。

基于代码的 API 测试

比较典型的是，基于 Java 的 OkHttP 和 Unirest、restassured、基于 Python 的 http.client 和 Requests、基于 NodeJS 的 Native 和 Request 等。
小型的互联网企业，往往会根据自己的业务需求，选用这些成熟的 API 测试框架。
对于中大型的互联网企业，一般都会自己开发更适合自身业务上下文的 API 测试框架，比如 eBay，为了实现代码化的 API 测试，开发了自己的 HttpClient，后期为了使 API 测试的代码更简洁易懂，就基于 Rest-Assured 封装了全新的 API 测试框架。
这种根据公司业务上下文开发实现的 API 测试框架，在使用上有很多优点，而且灵活性也很好，主要体现在以下几个方面：
可以灵活支持多个 API 的顺序调用，方便数据在多个 API 之间传递，即上一个 API 调用返回结果中的某个字段值可以作为后续 API 调用的输入参数；
方便在 API 调用之前或者之后执行额外的任意操作，可以在调用前执行数据准备操作，可以在调用后执行现场清理工作等；
可以很方便地支持数据驱动测试，这里的数据驱动测试概念和 GUI 测试中的数据驱动测试完全相同，也就是可以将测试数据和测试代码分离解耦；
由于直接采用了代码实现，所以可以更灵活地处理测试验证的断言（Assert）；原生支持命令行的测试执行方式，可以方便地和 CI/CD 工具做集成。

自动生成 API 测试代码

对于单个 API 测试的场景，工作量相比 Postman 要大得多；对于单个 API 测试的场景，无法直接重用 Postman 里面已经积累的 Collection。在实际工程中，这两个问题非常重要，而且必须要解决。因为公司管理层肯定无法接受相同工作的工作量直线上升，同时原本已经完成的部分无法继续使用，所以自动化生成 API 测试代码的技术也就应运而生了。
自动生成 API 测试代码是指，基于 Postman 的 Collection 生成基于代码的 API 测试用例。

测试中的断言（assert）部分不会生成代码，也就是说测试代码的生成只支持发起 request 的部分，而不会自动生成测试验证点的代码；很多中大型互联网企业都是使用自己开发的 API 测试框架，那么测试代码的实现就会和自研 API 测试框架绑定在一起，显然 Postman 并不支持这类代码的自动生成。
鉴于以上两点，理想的做法是自己实现一个代码生成工具，这个工具的输入是 Postman 中 Collection 的 JSON 文件，输出是基于自研 API 框架的测试代码，而且同时会把测试的断言一并转化为代码。这个小工具实现起来并不复杂，其本质就是解析 Collection JSON 文件的各个部分，然后根据自研 API 框架的代码模板实现变量替换。
具体来讲，实现过程大致可以分为以下三步：
首先，根据自研 API 框架的代码结构建立一个带有变量占位符的模板文件；
然后，通过 JSON 解析程序，按照 Collection JSON 文件的格式定义去提取 header、method 等信息；
最后，用提取得到的具体值替换之前模板文件中的变量占位符，这样就得到了可执行的自研框架的 API 测试用例代码。

有了这个工具后，建议你的工作模式（Working Model）可以转换成这样：
对于 Postman 中已经累积的 Collection，全部由这个工具统一转换成基于代码的 API 测试用例；
开发人员继续使用 Postman 执行基本的测试，并将所有测试用例保存成 Collection，后续统一由工具转换成基于代码的 API 测试用例；
对于复杂测试场景（比如，顺序调用多个 API 的测试），可以组装由工具转换得到的 API 测试用例代码，完成测试工作。
（原来这里解决过，我还以为要写两遍）

Response 结果发生变化时的自动识别

即使我们没有针对每个 response 字段都去写 assert，我们仍然可以识别出哪些 response 字段发生了变化。具体实现的思路是，在 API 测试框架里引入一个内建数据库，推荐采用非关系型数据库（比如 MongoDB），然后用这个数据库记录每次调用的 request 和 response 的组合，当下次发送相同 request 时，API 测试框架就会自动和上次的 response 做差异检测，对于有变化的字段给出告警。

基于配置文件的 API 测试框架

基于配置文件的 API 测试框架，比如典型的 HttpRunner （原来2018年就出现了，我2023年才知道）
来自《软测52讲》

他山之石

A:用postman转python或者java测试脚本还是太慢了，而且需要一定编程技能，感觉已经是上一代了，我现在根据httprunner的yml的脚本规则，加上一些开源的组件，做了一个web页面可以进行代理抓包，测试人员无论从web页面还是app操作只要设置代理过来，就可以看到自己的所有请求，然后选择想自动化的请求，后台自动转成测试脚本，再在管理界面上通过拖拽等性质组装成自动化测试集，并可以执行调试、定时任务等。这样的自动化程度基本对编程技能降到了最低，而且生成测试脚本的成本比上一代低了很多

B：response结果变化的自动识别，我目前项目使用了大量的json schema验证 效果还不错 （原来这里就有这个方案了）

C：使用过robotframework进行API测试，一个API测试都需要填写较长的表单，用起来感觉很复杂，冗余，在公司内部也不好做推广。目前，我还是比较喜欢用fiddler+jmeter，感觉使用起来还是蛮方便的，jmeter还可以集成到Jenkins下。对于老师说的自己封装API测试框架，很可惜，待的公司都项目较多的有很多的接口，自己封装API测试工程量太大，都没有实施的。

D：有了api自动化集成测试平台，还要代码生成工具有啥用