52关于软件测试的讲座笔记-23知道你来自哪里：谈谈API自动化测试框架的历史

52关于软件测试的讲座笔记-23知道你来自哪里：谈谈API自动化测试框架的历史:这是我为《极客小时》买的一套讲稿，共52篇。定期做笔记以加强学习。23。知道你来自哪里：谈谈API测试自动化框架的历史基于Postman的早期API测试主要问题：当频繁执行大量测试用例时，基于接口的API测试可能会很麻烦。难以与CI/CD管道集成。基于Postman和Newman的API测试对于需要连续调用多个API并传递参数的情况，这不是一个理想的测试场景。基于代码的API测试小企业使用成熟的API测试框架。大中型企业，一般都开发自己的API测试框架，更适合自己的业务。本API测试框架是根据公司的业务环境开发和实施的，具有使用方便、灵活性好等优点，主要体现在以下几个方面：它可以灵活地支持多个API的顺序调用，以促进多个API之间的数据传输。换句话说，前一次API调用返回的某个字段的值可以用作后续API调用的输入参数。为方便API调用前后附加任意操作的执行，调用前可以进行数据准备操作，调用后可以进行现场清理工作等；数据驱动的测试很容易得到支持。这里的数据驱动测试的概念与GUI测试中的概念完全相同。由于代码实现的直接采用，您可以更灵活地处理测试验证的断言；本机支持命令行测试执行，易于与CI/CD工具集成。然后作者提供了一个伪代码的例子来说明，你可以去原代码。自动生成API测试代码Postman工具本身已经支持将集合转换为测试代码，但如果直接使用此功能，则需要解决两个问题：测试中的断言部分不生成代码，即测试代码的生成只支持发起请求的部分，不自动生成测试验证点的代码。许多大中型互联网企业使用自己开发的API测试框架，测试代码的实现将绑定到自己开发的API测试框架中。显然，邮递员不支持这种代码的自动生成。鉴于以上两点，理想的方法是自己实现一个代码生成工具，其输入是Postman收集的JSON文件，输出是基于自主开发的API框架的测试代码，同时将测试断言转换为代码。作者还提供了相应的例子，不会重复。响应结果更改时自动识别问题：API返回的结果中应该验证哪些字段？无法为返回结果中的每个字段编写断言。API测试中的一个重要概念是向后兼容性。这意味着新的API版本应该与旧的API兼容。因此，您需要找到一种方法，不为所有响应字段编写断言，而是监视响应的结构以及未编写断言的字段值的变化。因此，“响应结果变化的自动识别”技术应运而生。也就是说，即使没有为每个响应字段编写断言，也可以标识哪些响应字段已更改。想法：在API测试框架中引入了一个内置的数据库，推荐关系型数据库（例如，directing），然后使用数据库记录每次调用请求和响应的组合，下次发送相同的请求时，API测试框架将自动最后给出了响应差检测，以改变报警范围。对于每个API调用不同的字段，例如令牌、会话ID、时间戳等，可以通过规则配置设置“白名单”，以排除具有动态值的字段。【附注】最有用的部分是当响应结果改变时自动识别这一部分。我在这个项目中遇到了类似的问题。虽然我采取了一些措施，但我没有想到作者的解决办法。准备按照作者的思路来澄清，看如何实现。52关于软件测试的讲座笔记-23知道你来自哪里：谈谈API自动化测试框架的历史