草帽路飞UU 发表于 2022-8-8 15:07:35

看测试老鸟如何把API 测试玩弄在鼓掌之间(上)

本帖最后由 草帽路飞UU 于 2022-8-8 15:43 编辑

       一、API 的基本步骤
  我介绍过当今互联网产品的测试策略往往会采用菱形结构,即重量级 API 测试,轻量级 GUI 测试,轻量级单元测试,由此可见 API 测试在现今测试中的重要性不言而喻。这篇文章是 API 自动化测试系列的第一篇文章。
  通常来讲,无论采用什么 API 测试工具,API 测试的基本步骤主要包括以下三大步骤:
  1.准备测试数据(这是可选步骤,不一定所有 API 测试都需要这一步);
  2.通过 API 测试工具,发起对被测 API 的 request;
  3.验证返回结果的 response。
  二、早期的基于 Postman 的 API 测试
  早期的 API 测试,往往都是通过类似 Postman 的工具完成的。但是,由于这类工具都是基于界面操作的,所以有以下两个问题亟待解决时,基于界面的 API 测试就显得有些笨拙;
  基于界面操作的测试难以与 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 测试框架,在使用上有很多优点,而且灵活性也很好,主要体现在以下几个方面:
  可以灵活支持多个 API 的顺序调用,方便数据在多个 API 之间传递,即上一个 API 调用返回结果中的某个字段值可以作为后续 API 调用的输入参数;方便在 API 调用之前或者之后执行额外的任意操作,可以在调用前执行数据准备操作,可以在调用后执行现场清理工作等;可以很方便地支持数据驱动测试,这里的数据驱动测试概念和 GUI 测试中的数据驱动测试完全相同,也就是可以将测试数据和测试代码分离解耦;由于直接采用了代码实现,所以可以更灵活地处理测试验证的断言(Assert);原生支持命令行的测试执行方式,可以方便地和 CI/CD 工具做集成。

代码的第 1-12 行,创建了 CreateUserAPI 类,其中包含了 endpoint、操作方法 PUT、InlineParam 和 Param 的设置,并且构建了对应的 request 对象;代码的第 14-19 行,是测试的主体函数。这段函数的逻辑是这样的:首先,构建 CreateUserAPI 的对象;然后,用 CreateUserAPI 对象的 buildRequest 方法结合输入参数构建 request 对象;接着,通过 request 对象的 request() 方法发起了 API 调用;最后,验证 response 中的状态码是不是 200。
  在这段伪代码中,有以下几点需要你特别注意:
  代码中“CreateUserAPI 的父类 RestAPI”“_buildRequest() 方法”“request() 方法”“addInlineParam() 方法”等,都是由 API 测试框架提供的。为了简化代码,这里并没有引入数据驱动的 data provider。但在实际项目中,代码第 14 行的测试输入参数,往往来自于 data provider,即由数据驱动的方式提供测试输入数据。由于测试过程完全由代码实现,所以可以很方便的在测试执行前后增加任意的额外步骤。比如,需要在 CreateUser 前增加数据创建的步骤时,只需要在代码第 15 行前直接添加就可以了。这里的例子只有一个 API 调用,当需要多个 API 顺序调用时,直接扩展 testCreateUser 方法即可,两个 API 之间的数据传递可以通过上一个 API 返回的 response.XXXX 完成。通过这段伪代码,我们可以看到,虽然基于代码的 API 测试灵活性很好,也可以很方便地和 CI/CD 集成,但是也引入了一些新的问题,比如:对于单个 API 测试的场景,工作量相比 Postman 要大得多;对于单个 API 测试的场景,无法直接重用 Postman 里面已经积累的 Collection。在实际工程中,这两个问题非常重要,而且必须要解决。因为公司管理层肯定无法接受相同工作的工作量直线上升,同时原本已经完成的部分无法继续使用,所以自动化生成 API 测试代码的技术也就应运而生了。
  五、自动生成 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 测试用例代码,完成测试工作。
  如图 2 所示,就是一个组装多个由工具转换得到的 API 测试用例代码的例子。其中,代码第 3 行的类“CreateUserAPI”和第 10 行的类“BindCreditCardAPI”的具体代码就可以通过工具转换得到。

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



页: [1]
查看完整版本: 看测试老鸟如何把API 测试玩弄在鼓掌之间(上)