看测试老鸟如何把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]
