浅谈接口自动化测试

接口测试大家一定不陌生了，对 QA 来说也是一项比较基础的技能，并且在现代软件开发中，持续集成已经成为一种不可或缺的实践，所以很多项目中都会做 UI 自动化、接口自动化的持续集成。

在实际工作中，个人感觉接口自动化测试比 UI 自动化测试性价比要高得多的多，首先接口测试在整个流程中可以更早介入，更早发现问题并使用低的成本修复，其次是它的一个投入成本，一般来说接口数量都是有限的，并且是在多个场景下使用的，所以从代码编写这块就比 UI 自动化测试要少很多，最后它的维护成本也比较低，因为接口一般来说不会频繁的、大幅度的改动，所以需要维护的时间很少。

在之前的一个项目中，同时写接口和 UI 的自动化测试，会发现 99%的时间都在维护 UI 自动化测试，并且跑 UI 测试的时间比较长，环境还不稳定，反而接口自动化测试能快速频繁的跑并发现一些问题，“性价比”比较高。

逝去的 Postman + Newman + Jenkins

逝去的 Postman + Newman + Jenkins（工具导出脚本）。

我开始接触接口自动化测试持续集成的时候，最早了解到的就是 postman+Newman+Jenkins 这套框架，这套框架相对来说是比较容易上手的，并且 postman 的使用非常之广泛，不过前段时间得知 postman 以后要开始收费并且由于一些安全性因素，不再推荐使用 postman 这个工具。

整体思路

整体思路还是比较清晰的，我们常规的使用 postman 创建一些接口测试 case 之后将测试脚本和环境变量脚本导出，使用 newman 运行，最后 CI/CD 集成生成测试报告。

• 1.首先需要从 postman export 出测试脚本文件以及环境变量脚本文件。

• 2.编写 Newman.js 文件如下

• 3.然后通过 Newman 运行测试集合（Newman 是 postman 推出的 node.js 库，是 postman 的命令行运行程序，能够直接运行和测试 Postman 集合），可以直接运行上面的 js 文件，也可以使用如下指令运行：

newman run learning.postman_collection.json -e baidu.postman_environment.json -r html

（-e 参数为 environment，后面跟环境变量脚本文件，-r 为 report，还有其他一些可选择的参数比如说-g 全局变量文件，-n 迭代次数，-d 数据源文件等等）手动在命令行执行该指令后就会得到一个如下的 html 测试报告：

• 4.一切准备就绪后就可以加入 jenkins 来集成了，创建一个新的 pipeline 来执行 shell 指令，并设置定时触发任务，可以每隔一段时间出发测试，从而达到持续集成的效果。

优缺点小结

可以看到这种框架的学习成本还是比较低的，也不用编写大量代码，基本只要熟练使用几种工具就可以快速完成接口自动化测试的持续集成，并且测试用例的管理也是比较容易、清晰的，这也是它之前广泛被使用的原因。

但是它同时也存在一些缺点：

• a.比如说不能读写数据库、不支持配置测试用例优先级且仅支持 node.js 语言。在实际项目的自动化测试中，读写数据库还是很实用的，比如对于一些数据依赖性较强的 case，需要做一些前置或者后置的数据操作，就可以使用数据库操作（当然也可以调用接口来实现数据准备和后续清理工作）。

• b.维护成本相对来说比较大的，你试想在项目中当有接口变更时，都需要重新导入 json 文件到 Newman 中。

• c.基本在所有项目中，测试环境都有很多，我们也会在不同的测试环境来手动测试或者自动化测试，并且不同的测试环境可能会有些许的差异，但是这种框架是不支持运行时动态传入环境变量的，框架的扩展性比较差。

综上来看，postman+newman+jenkins 这套框架比较适合业务逻辑并不复杂的小项目，一旦碰到比较大、逻辑比较复杂的项目，就不那么适用了，同可替代工具还是蛮多的，之前也有同事推荐过一些。

所以 postman 不能再使用了好像也没那么令人难以接受。

其他测试框架

其他测试框架（自定义编写测试脚本）。

除了使用 postman 这样的工具，也可以编写自定义的 HTTP 请求和验证脚本来执行接口测试，比如说比较流行的 Unittest+Request+HTMLRunner 框架，虽然学习成本相对高一丢丢，但是它足够灵活强大，甚至我们在 UI 自动化测试中常见的 selenium 也可以用于接口的自动化测试，在项目中可以和 UI 自动化测试在同一个代码仓库中一起维护，像常用的 java、js、python 都可以使用。

下面我们简单聊下 Unittest+Request+HTMLRunner 这套框架。

首先我们来解释下这几个关键词。unittest 是 Python 的一个测试框架，用于编写、组织和运行测试用例。Requests 用于发送 HTTP 请求。HTMLTestRunner 是一个用于生成 HTML 测试报告的工具。

unittest 提供了很多功能，比如常用的测试套件（test suite）、一系列断言方法、assertRaises 预期异常等等，所以我们可以使用这些功能来编写对应的脚本，网络上能找到的学习资料还是比较多的，unittest 官网也详细介绍了很多使用方法，感兴趣的朋友可以参考下官网链接：https://docs.python.org/3/library/unittest.html#。

下面是一个基础的流程：

• 1.创建配置文件，存储一些公共参数，比如 url、测试报告文件路径、测试数据文件路径等等。

  并且可以将获取接口的 url、请求头、参数等方法封装成类并写入 base.py 中，用于测试框架中测试集的直接调取。

• 2.然后发送 request，得到接口返回的数据。

• 3.得到接口返回结果后，需要与预期结果做对比也就是我们常说的断言，判断用例执行结果。

• 4.接着编写测试集，使用到上面的请求方法、断言方法。

  def testcase1(self):  
      # get url and request  
      self.url = BasePage(self.driver).get_api()  
      actualresult = RequestPage(self.driver).post_requests(self.url).json()  
        
      # get expected data  
      expectresult = eval(BasePage(self.driver).get_cell(1, 2))  
        
      # assertion  
      CheckPage(self.driver).check_value(actualresult, expectresult)  # 假设check_value方法接受两个参数

• 5.最后生成测试报告并进行 CICD 集成。

优缺点小结

可以看到和直接 postman 工具相比，流程基本都是一致的，自己编写脚本无非就是把原本用工具构建的一个个测试用例以代码的方式呈现出来。

这类自己编写测试脚本的框架虽然上手略难并且代码较为冗长，但是优点也是显而易见的：

• a.由于是自定义脚本，所以写者可以完全按照自己的逻辑和项目需求来定制流程来满足不同的需求。

• b.后续可扩展性和复用性比较强，可以进行分层测试、数据驱动、数据库交互，按照不同的业务逻辑将测试模块化，因此可维护性也很高。

• c.并且自定义脚本可以处理一些不能通过自动化测试工具实现的特殊场景。

所以在大型的、业务逻辑复杂的项目中，还是比较推荐这种方式，一步到位，后面会轻松很多。

总结

总的来说，接口测试的自动化收获/投入比还是很高的，在项目中的作用也很大，能够快速反馈发现并修复问题。

不管是用什么样的框架、语言、工具，其实接口自动化测试的核心思路都是一致的，从确认测试目标和范围、接口的入参和预期结果，再到最后的持续集成、生成测试报告，变的只是使用的工具和语言。

如果大家有其他比较好用的测试框架，也可以来推荐一波～