这是我购买的"极客时间"上的一套课程的笔记，总共52讲，定期对其中的内容做一笔记，巩固学习内容。
23 知其然知其所以然：聊聊API自动化测试框架的前世今生
早期的基于Postman的API测试
主要问题：
- 频繁执行大量测试用例时，基于界面的API测试比较笨拙。
- 难以与CI/CD流水线集成。
基于Postman和Newman的API测试
对于需要连续调用多个API并且有参数传递的情况，这并不是理想的测试方案。
基于代码的API测试
小型企业，会选用成熟的API测试框架。
中大型企业，一般会自己开发更适合自身业务的API测试框架。
这种根据公司业务上下文开发实现的 API 测试框架，在使用上有很多优点，而且灵活性也很好，主要体现在以下几个方面：
- 可以灵活支持多个 API 的顺序调用，方便数据在多个 API 之间传递，即上一个 API 调用返回结果中的某个字段值可以作为后续 API 调用的输入参数；
- 方便在 API 调用之前或者之后执行额外的任意操作，可以在调用前执行数据准备操作，可以在调用后执行现场清理工作等；
- 可以很方便地支持数据驱动测试，这里的数据驱动测试概念和 GUI 测试中的数据驱动测试完全相同，也就是可以将测试数据和测试代码分离解耦；
- 由于直接采用了代码实现，所以可以更灵活地处理测试验证的断言（Assert）；
- 原生支持命令行的测试执行方式，可以方便地和 CI/CD 工具做集成。
然后作者提供了一个伪代码示例来说明，可以去看原文。
自动生成API测试代码
Postman 工具本身已经支持将 Collection 转化成测试代码，但如果直接使用这个功能的话，还有两个问题需要解决：
- 测试中的断言（assert）部分不会生成代码，也就是说测试代码的生成只支持发起 request 的部分，而不会自动生成测试验证点的代码；
- 很多中大型互联网企业都是使用自己开发的 API 测试框架，那么测试代码的实现就会和自研 API 测试框架绑定在一起，显然 Postman 并不支持这类代码的自动生成。
鉴于以上两点，理想的做法是自己实现一个代码生成工具，这个工具的输入是 Postman 中 Collection 的 JSON 文件，输出是基于自研 API 框架的测试代码，而且同时会把测试的断言一并转化为代码。
作者也提供了相应的例子，不再赘述。
Response结果发生变化时的自动识别
问题：到底应该验证API返回结果中的哪些字段？
不可能对返回结果中的每一个字段都写assert。
而API测试中，有一个很重要的概念是向后兼容。是指，发布的新API版本应该能够兼容老版本的API。
因此，需要找到一个方法，既可以不对所有的response字段都去写assert，又可以监测到response的结构以及没有写assert的字段值的变化。
于是，诞生了“Response结果变化时的自动识别”技术。也就是说，即使没有针对每个Response字段都去写assert，仍然可以识别出哪些Response字段发生了变化。
思路：在API测试框架中引入一个内建数据库，推荐非关系型数据库（比如MongoDB），然后用这个数据库记录每次调用的request和Response的组合，当下次发送相同的request时，API测试框架就会自动和上次的Response做差异检测，对于有变化的字段给出告警。
那么对于每次API调用都不同的字段，比如token、session ID、时间戳等，可以通过规则配置设立一个“白名单列表”，把动态值的字段排除在外。
【心得】
最有用的是Response结果发生变化时的自动识别这块啊！自己在项目中遇到过类似的问题，虽然采取了一定的措施，但是没有想到作者这个解决方案。准备顺着作者的思路捋一捋，看看如何具体实现。
