聊聊 API 自动化测试框架的前世今生
早期的基于 Postman 的 API 测试
特点：基于界面操作
存在问题：
-
当需要频繁执行大量的测试用例时，基于界面的 API 测试就显得有些笨拙；（效率低下）
-
基于界面操作的测试难以与 CI/CD 流水线集成。（无法集成）
基于 Postman 和 Newman 的 API 测试
用 Postman 开发调试测试用例，完成后通过 Newman 执行。
Newman 其实就是一个命令行工具，可以直接执行 Postman 导出的测试用例。
存在问题：
对于需要连续调用多个 API 并且有参数传递的情况，Postman+Newman 似乎就不再是理想的测试方案了。
基于代码的 API 测试
为了解决这个问题，于是就出现了基于代码的 API 测试框架。比较典型的是，基于 Java 的 OkHttP 和 Unirest、基于 Python 的 http.client 和 Requests、基于 NodeJS 的 Native 和 Request 等。
小型的互联网企业，往往会根据自己的业务需求，选用这些成熟的 API 测试框架。
对于中大型的互联网企业，一般都会自己开发更适合自身业务上下文的 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 结果发生变化时的自动识别
API测试存在的问题：到底应该验证 API 返回结果中的哪些字段？
API一般需要后向兼容。API 的后向兼容性是指，发布的新 API 版本应该能够兼容老版本的 API。
后向兼容性除了要求 API 的调用参数不能发生变化外，还要求不能删减或者修改返回的 response 中的字段。因为这些返回的 response 会被下游的代码使用，如果字段被删减、改名或者字段值发生了非预期的变化，那么下游的代码就可能因为无法找到原本的字段，或者因为字段值的变化而发生问题，从而破坏 API 的后向兼容性。
我们迫切需要找到一个方法，既可以不对所有的 response 字段都去写 assert，又可以监测到 response 的结构以及没有写 assert 的字段值的变化。
解决方法 ：“Response 结果变化时的自动识别”技术。
具体实现的思路是，在 API 测试框架里引入一个内建数据库，推荐采用非关系型数据库（比如 MongoDB），然后用这个数据库记录每次调用的 request 和 response 的组合，当下次发送相同 request 时，API 测试框架就会自动和上次的 response 做差异检测，对于有变化的字段给出告警。
每次 API 调用都是不同的字段，比如 token 值、session ID、时间戳等，通过规则配置设立一个“白名单列表”，把那些动态值的字段排除在外。
基于配置文件的 API 测试框架
比如典型的 HttpRunner，在此类 API 测试框架的支持下，测试用例本身往往就是纯粹的配置文件了。
来源于 极客时间 茹炳晟 软件测试52讲