You cannot select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

13 KiB

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

你好我是茹炳晟今天我和你分享的主题是“知其然知其所以然聊聊API自动化测试框架的前世今生”。

在上一篇文章中我以一个简单的Restful API为例分别介绍了cURL和Postman的使用方法相信你已经对API测试有个感性认识了。

但是我们不能仅仅停留在感性认识的层面还需要熟悉并掌握这些测试方法完成相应的API测试工作。所以也就有了我今天分享的主题希望可以通过对API自动化测试框架发展的介绍让你理解API测试是如何一步一步地发展成今天的样子以“知其所以然”的方式加深你对API自动化测试的理解。

接下来我将会遵循由简入繁的原则为你介绍API测试框架以发现问题然后解决问题的思路为主线展开今天的分享。

早期的基于Postman的API测试

早期的API测试往往都是通过类似Postman的工具完成的。但是由于这类工具都是基于界面操作的所以有以下两个问题亟待解决

  1. 当需要频繁执行大量的测试用例时基于界面的API测试就显得有些笨拙

  2. 基于界面操作的测试难以与CI/CD流水线集成。

所以我们迫切需要一套可以基于命令行执行的API测试方案。这样API测试可以直接通过命令行发起与CI/CD流水线的整合也就方便得多了。

基于Postman和Newman的API测试

于是就出现了集成Postman和Newman的方案然后再结合Jenkins就可以很方便地实现API测试与CI/CDl流水线的集成。Newman其实就是一个命令行工具可以直接执行Postman导出的测试用例。

用Postman开发调试测试用例完成后通过Newman执行这个方案看似很完美。但是在实际工程实践中测试场景除了简单调用单个API以外还存在连续调用多个API的情况。

此时往往会涉及到多个API调用时的数据传递问题即下一个API调用的参数可能是上一个API调用返回结果中的某个值。另外还会经常遇到的情况是API调用前需要先执行一些特定的操作比如准备测试数据等。

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

基于代码的API测试

为了解决这个问题于是就出现了基于代码的API测试框架。比较典型的是基于Java的OkHttP和Unirest、基于Python的http.client和Requests、基于NodeJS的Native和Request等。

小型的互联网企业往往会根据自己的业务需求选用这些成熟的API测试框架。

但是对于中大型的互联网企业一般都会自己开发更适合自身业务上下文的API测试框架比如eBay我们为了实现代码化的API测试开发了自己的HttpClient后期为了使API测试的代码更简洁易懂就基于Rest-Assured封装了全新的API测试框架。

这种根据公司业务上下文开发实现的API测试框架在使用上有很多优点而且灵活性也很好主要体现在以下几个方面

  1. 可以灵活支持多个API的顺序调用方便数据在多个API之间传递即上一个API调用返回结果中的某个字段值可以作为后续API调用的输入参数

  2. 方便在API调用之前或者之后执行额外的任意操作可以在调用前执行数据准备操作可以在调用后执行现场清理工作等

  3. 可以很方便地支持数据驱动测试这里的数据驱动测试概念和GUI测试中的数据驱动测试完全相同也就是可以将测试数据和测试代码分离解耦

  4. 由于直接采用了代码实现所以可以更灵活地处理测试验证的断言Assert

  5. 原生支持命令行的测试执行方式可以方便地和CI/CD工具做集成。

这里我给出了一段伪代码示例用于展示如何用代码实现一个简单的API测试。

图1 基于代码的API测试的伪代码示例

  • 代码的第1-12行创建了CreateUserAPI类其中包含了endpoint、操作方法PUT、InlineParam和Param的设置并且构建了对应的request对象

  • 代码的第14-19行是测试的主体函数。这段函数的逻辑是这样的

    • 首先构建CreateUserAPI的对象
    • 然后用CreateUserAPI对象的buildRequest方法结合输入参数构建request对象
    • 接着通过request对象的request()方法发起了API调用
    • 最后验证response中的状态码是不是200。

在这段伪代码中,有以下几点需要你特别注意:

  1. 代码中“CreateUserAPI的父类RestAPI”“_buildRequest()方法”“request()方法”“addInlineParam()方法”等都是由API测试框架提供的。

  2. 为了简化代码这里并没有引入数据驱动的data provider。但在实际项目中代码第14行的测试输入参数往往来自于data provider即由数据驱动的方式提供测试输入数据。

  3. 由于测试过程完全由代码实现所以可以很方便的在测试执行前后增加任意的额外步骤。比如需要在CreateUser前增加数据创建的步骤时只需要在代码第15行前直接添加就可以了。

  4. 这里的例子只有一个API调用当需要多个API顺序调用时直接扩展testCreateUser方法即可两个API之间的数据传递可以通过上一个API返回的response.XXXX完成。

通过这段伪代码我们可以看到虽然基于代码的API测试灵活性很好也可以很方便地和CI/CD集成但是也引入了一些新的问题比如

  • 对于单个API测试的场景工作量相比Postman要大得多
  • 对于单个API测试的场景无法直接重用Postman里面已经积累的Collection。

在实际工程中这两个问题非常重要而且必须要解决。因为公司管理层肯定无法接受相同工作的工作量直线上升同时原本已经完成的部分无法继续使用所以自动化生成API测试代码的技术也就应运而生了。

自动生成API测试代码

自动生成API测试代码是指基于Postman的Collection生成基于代码的API测试用例。

其实,在上一篇文章《从0到1API测试怎么做常用API测试工具简介》最后的部分我已经提到过Postman工具本身已经支持将Collection转化成测试代码但如果直接使用这个功能的话还有两个问题需要解决

  1. 测试中的断言assert部分不会生成代码也就是说测试代码的生成只支持发起request的部分而不会自动生成测试验证点的代码

  2. 很多中大型互联网企业都是使用自己开发的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测试用例代码完成测试工作。

如图2所示就是一个组装多个由工具转换得到的API测试用例代码的例子。其中代码第3行的类“CreateUserAPI”和第10行的类“BindCreditCardAPI”的具体代码就可以通过工具转换得到。

图2 多个API顺序调用的测试用例代码

至此基于代码的API测试发展得算是比较成熟了但在实际应用过程中还有一个痛点一直未被解决那就是测试验证中的断言也是我接下来要和你一起讨论的话题。

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

在实际的工程项目中开发了大量的基于代码的API测试用例后你会发现一个让人很纠结的问题到底应该验证API返回结果中的哪些字段

因为你不可能对返回结果中的每一个字段都写assert通常情况下你只会针对关注的几个字段写assert而那些没写assert的字段也就无法被关注了。

但对API测试来说有一个很重要的概念是后向兼容性backward compatibility。API的后向兼容性是指发布的新API版本应该能够兼容老版本的API。

后向兼容性除了要求API的调用参数不能发生变化外还要求不能删减或者修改返回的response中的字段。因为这些返回的response会被下游的代码使用如果字段被删减、改名或者字段值发生了非预期的变化那么下游的代码就可能因为无法找到原本的字段或者因为字段值的变化而发生问题从而破坏API的后向兼容性。

所以我们迫切需要找到一个方法既可以不对所有的response字段都去写assert又可以监测到response的结构以及没有写assert的字段值的变化。

在这样的背景下诞生了“Response结果变化时的自动识别”技术。也就是说即使我们没有针对每个response字段都去写assert我们仍然可以识别出哪些response字段发生了变化。

具体实现的思路是在API测试框架里引入一个内建数据库推荐采用非关系型数据库比如MongoDB然后用这个数据库记录每次调用的request和response的组合当下次发送相同request时API测试框架就会自动和上次的response做差异检测对于有变化的字段给出告警。

你可能会说这种做法也有问题因为有些字段的值每次API调用都是不同的比如token值、session ID、时间戳等这样每次的调用就都会有告警。

但是这个问题很好解决,现在的解决办法是通过规则配置设立一个“白名单列表”,把那些动态值的字段排除在外。

总结

为了让你可以更好地理解今天的API测试框架我从其发展历程的角度进行了分析

早期的基于Postman的API测试在面临频繁执行大量测试用例以及与CI/CD流水线整合的问题时显得心有余而力不足。为此基于命令行的API测试实践也就是Postman+Newman具有很好的灵活性解决了这两个问题。

但是Postman+Newman的测试方案只能适用于单个API调用的简单测试场景对于连续调用多个API并涉及到参数传递问题时这个方案就变得不那么理想和完美了。随后API测试就过渡到了基于代码的API测试阶段。

一些小型企业则往往会选择适合自己业务的成熟API测试框架。中大型的互联网企业一般都会根据自己的业务上下文在成熟API测试框架的基础上封装自己的API测试框架提升测试效率和灵活性。

但是不管是采用现成的还是自己去开发API测试框架都会遇到测试用例开发效率低下以及无法直接重用Postman中积累的Collection的问题为此我分享了两个比较好用的方法也就是自动生成API测试代码和Response结果变化的自动识别并给出了这两个方法的实现思路。

希望我分享的这些内容,可以帮你解决在实际测试项目中遇到的问题。

思考题

目前基于代码的API测试框架已经比较成熟了所以在此基础上又出现了基于配置文件的API测试框架比如典型的HttpRunner在此类API测试框架的支持下测试用例本身往往就是纯粹的配置文件了。你是否有接触过这类API测试框架对此又有什么看法呢

欢迎你给我留言。