23 | 知其然知其所以然：聊聊API自动化测试框架的前世今生

该思维导图由 AI 生成，仅供参考

API自动化测试框架的发展历程经历了由简入繁的过程。早期的API测试依赖于界面操作工具，如Postman，但随着测试用例数量增多和CI/CD集成需求的提出，基于命令行执行的API测试方案迫在眉睫。随后，基于Postman和Newman的集成方案应运而生，但对于复杂的测试场景仍存在不足。为了解决这些问题，基于代码的API测试框架应运而生，提供了更灵活的测试方式和更好的集成性。然而，基于代码的测试也引入了一些新的问题，如工作量增加和无法重用Postman中已有的Collection。为了解决这些问题，自动生成API测试代码的技术应运而生，通过解析Postman中的Collection JSON文件，生成基于自研API框架的测试代码，同时将测试的断言一并转化为代码。这一技术的出现，使得API自动化测试框架的发展达到了一个相对成熟的阶段。 在实际的工程项目中，开发了大量的基于代码的API测试用例后，一个让人很纠结的问题是：到底应该验证API返回结果中的哪些字段？针对这一问题，诞生了“Response结果变化时的自动识别”技术，通过内建数据库记录每次调用的request和response的组合，实现自动和上次的response做差异检测，对于有变化的字段给出告警。同时，通过规则配置设立一个“白名单列表”，排除动态值的字段，解决了动态值带来的问题。 总结来看，API测试框架经历了从基于界面操作到基于代码的发展阶段，解决了测试用例开发效率低下和无法重用Postman中Collection的问题。随着基于代码的API测试框架的成熟，又出现了基于配置文件的API测试框架，如HttpRunner，使得测试用例本身往往成为纯粹的配置文件。这一技术发展历程和新兴趋势，为读者提供了对API自动化测试框架的全面了解和思考。