接口自动化框架对比 | 质量工程

一、前言

自动化测试是把将手工驱动的测试行为转化为机器自动执行，通常操作是在某一框架下进行代码编写，实现用例自动发现与执行，托管在CI/CD平台上，通过条件触发或手工触发，进行回归测试&线上监控，代替部分的手工测试；

不同的项目适合的自动化框架也是不同的，自动化系列文章将逐个介绍实际工作中使用的自动化框架。

自动化接口测试使用到的框架：

• Postman+Newman+Allure+Jenkins/极库云

• Httprunner+Request+Pytest+Alluret+Jenkins

• JMeter+Ant+Allure+Jenkins

• Pytest+Request+Allure+Jenkins

自动化UI测试使用到的框架：

• Selenium+Pytest

• Appium+WDA+TestNG

• Minium+pytest

本章节先对自动化接口测试的四个框架进行对比介绍，后续系列文章介绍详细搭建过程和封装过程。

二、自动化接口测试简介

1、接口测试的必要性

接口测试有着极为高效的成本收益比，是测试左移的重要环节。

接口测试为高复杂性的平台带来高效的缺陷检测和质量监督能力，平台复杂，系统越庞大，接口测试的效果越明显。

总的来说，接口测试是保证高复杂性系统质量的内在要求和低成本的经济利益驱动作用下的最佳方案，主要体现在如下三个方面：

• 节省了测试成本

• 接口测试不同于单元测试

• 收益更高

2、自动化接口测试的必要性

自动化测试是把以人为驱动的测试行为转化为机器执行的一种过程，主要是编写代码、脚本，让软件自动运行，发现缺陷，代替部分的手工测试；

当服务端改动功能、添加新功能时、测试环境切换时、新发布程序后，避免新代码导致已有功能不可用，都需要进行接口的全量回归。人工触发不及时且容易遗漏。

接口自动化接入持续集成，服务端发布触发接口测试代码运行，尽早发现问题

抽取部分接口测试用例，定时运行程序，对线上常用的业务操作进行监控，及时发现修复。

3、自动化接口测试适用场景

• 提测前冒烟测试

• 预生产/上线前回归测试

• 服务端底层逻辑变更后的回归测试

• 线上服务器可用性监控

4、成果物

通过自动化测试，进行线上可用性监控 和 回归测试，可以节约大量手工测试时间，降本增效。线上线下均发现过较多问题。

三、自动化接口测试框架概览

1、几种框架对比

还有很多其他框架，本次只针对实际工作中应用到的几种框架进行对比。

2、自动化接口测试框架的必要性

• 提供统一的用例模板，简化业务接入的成本

• 处理脚本中一些异常和错误处理工作

• 实现一些通用的功能，简化脚本开发的过程

• 测试场景恢复

• 测试结果/报告输出

四、自动化接口测试框架对比

1、Postman+Newman框架

①简介

postman是谷歌浏览器的扩展工具，也有独立的客户端产品。

postman非方便日常的调试，使用简单。

主要功能包含接口请求的发起，测试的断言，设置前置条件，支持后置操作，支持使用全局变量/环境变量/集合变量/内部变量，参数化应用、接口关联、postman结合newman+jenkins实现简单的接口自动化并进行持续集成等操作。

postman高级的功能可以付费进行定制化。

②优缺点

优点:

• 免费版就已经非常强大了，门槛低，上手快，跨平台

• 使用门槛低，只需要简单的编程能力，一些复杂的断言可能需要了解js语法;

• 支持不同的认证机制，包括Basic Auth、Digest Auth、OAuth1.0、OAuth2.0

• 可以发送大多数类型的HTTP/HTTPS请求，如GET、POST、PUT、PATCH、DELETE、   TRACE等；

• 支持数据驱动，读取数据文件,json,csv

• 支持设置环境变量：方便切换不同的环境进行接口测试工作，而不用修改变量或代码；（同一套测试用例，可以通过切换环境变量运行在不同的环境中，如生产环境/预发布/测试环境）

• 无重复工作量，接口测试的case可以直接导出形成测试用例；

• 接口测试转换成自动化case非常方便，运行也比较简单;

• postman是google维护，可靠;

 缺点:

• 仅支持Node.js语言，而js不具有通用性；

• 不能操作文件相关的操作，不能读写数据库，不能使用非HTTP协议

• 不支持配置测试用例优先级、测试用例分组功能，只能按顺序执行；

• 测试用例中动态数据/测试准备功能/测试断言都必须提前定义好，不能满足所有场景的要   求(如数据库交互) ;

• 测试用例是json格式，查阅、维护及更改都十分不变；

• 测试用例维护成本高，当有变更时，需要再次导入到newman工程中；

• 框架的扩展性差，postman的CI集成以及扩展封装都需要单独的开发新的项目兼容post   man本生的框架语言

• 不支持运行时动态传入环境变量

• 不支持失败重试

• 仅适合业务逻辑不复杂的小型项目

③使用要求

•  对http协议有基本的了解

•  了解接口测试概念

•  工具的基本使用

•  请求头，请求体能分清即可

④适用业务

•  业务中接口量大

•  业务场景独立，关联关系弱

•  小型API项目的自动化

•  短期项目的API回归测试

•  编码能力较弱的测试团队或初学者

⑤环境依赖

•  需要 Node.js 执行环境

•  需要安装newman ，npm install -g newman

•  安装用到的插件，如htmlextra，allure等

⑥应用步骤

a.用例要求：接口用例中做了较完善的接口管理、全局变量/环境变量定义、动态参数应用、请求参数化、实现了接口关联、所有的接口均有状态/性能断言+业务断言

b.生成项目：导出接口测试用例、环境变量、全局变量、数据驱动文件等

c.配置项目：框架单独章节再行介绍具体配置过程

运行项目

• 本地使用CLI执行自动化

•  配置到jenkins job中

d.查看报告 （其他框架都是使用Allure输出报告，不再赘述）

代码上传gitlab/github

e.接入持续集成，并配置定时任务（其他框架都支持通过极库云或jenkins做任务调度，不再赘述）

• 接入极库云流水线

• 接入 Jenkins

2、JMeter+Ant框架

①简介

JMeter可以用于性能测试，在性能测方面很强大，也可以用于自动化接口测试。

②优缺点

优点：

•  支持参数化

•  不需要写代码

•  支持协议较多，如HTTP、FTP、soap、websocket、jdbc、thrift、dubbo等

•  支持数据库操作

缺点：

•  创建接口用例效率不高

•  学习成本高

•  需要会jmeter工具的基本使用

•  会数据库基本操作及编写SQL语句

•  了解用到的非http协议，如项目【自研长连接】使用的websocket协议

③使用要求

 jmeter的学习成本主要在jmeter工具的使用上

 对于已经掌握工具使用的人，利用jmeter进行自动化测试只要会Ant配置即可

④适用业务

 涉及数据库操作

 涉及非https接口的业务

 业务需要进行性能测试，已完成主要接口脚本编写

⑤环境依赖

 不同版本JMeter对Java版本的要求不尽相同。比如：JMeter3.3仅支持Java 8，

 JMeter4.0要求Java 8+（表示大于等于Java 8版本），JMeter5.0以上要求Java 8+

 安装ant插件

⑥应用步骤

• 用例要求：接口用例中做了较完善的接口管理、恰当的组件使用、动态参数应用、请求参数化、实现了接口关联、所有的接口均有状态断言+业务断言

• 生成项目：编写测试用例、导出测试用例，数据驱动文件等

• 配置Ant 的 build.xml文件

• 运行项目

  本地使用ant执行自动化

  配置到jenkins job中

3、HttpRunner+request

①简介

HttpRunner 是一款面向 HTTP(S) 协议的通用测试框架，只需编写维护一份 YAML/JSON 脚本，即可实现自动化测试、性能测试、线上监控、持续集成等多种测试需求。

 支持 HTTP(S) / HTTP2 / WebSocket /thrift  /dubbo 等网络协213议，涵盖接口测试、性能测试、线上监控、持续集成、数字体验监测等测试类型。

 简单易用，功能强大，具有丰富的插件化机制和高度的可扩展能力。

 只需编写维护一份 YAML/JSON 脚本

 前身 ApiTestEngine (2016年)，2017年正式更名HTTPRunner，并PyPI托管

②优缺点

设计理念和主要特征在官网有详细列出，不再赘述。这里主要列举一下优缺点。

优点:

•  基于YAML/JSON格式，专注于接口本身的编写

•  接口录制功能，操作简单，只需3步即可完成测试，对于较为简单的场景尤其方便

•  接口编写简单，容易上手，对代码编写能力要求较低

•  生成测试报告，可以自动生成测试报告，框架自带的测试报告模板基本满足需求，支持自定义测试报告的模板

•  分层机制，适合冒烟流程测试，无需重复编写接口，只要根据需求灵活调用即可

缺点:

•  HttpRunner 没有编辑器插件，本身就是一个配置文件，所以只要是合法的YAML/JSON格式，就算写错了看没有校验也不出来，只有运行起来才知道

•  框架推出时间相对较短，官方文档没有特别详细的说明，且网上资料相对其他主流测试框架较少

•  扩展不方便，数据驱动需要依赖其他接口返回,且有先后顺序，这个比较麻烦,暂时框架不支持很优雅的解决这种情况.可以通过分步来解决这个问题

•  由于用例的数据导出只能在一个测试周期中,所以我们还要解决测试数据传递的问题

•  通过写入文件的方式解决.接口返回的测试数据写入文件,然后需要的地方通过读取文件的方式读回数据

③使用要求

 有一定的python基础，会使用charles/fiddler/postman， 对request框架有基本了解，至少会get、post请求

④适用业务

 接口关联关系弱、业务逻辑分支多，场景多、 接口/场景复用性高

⑤环境依赖

 python V3.6+

 pycharm

 httprunner 3.1.11以下(！重要，httprunner V4已经去掉了startproject脚手架，不适合新手快速接入)

 Anacanda

⑥框架实现功能

• 概述

二次封装采用了V2.0和V3.0结合的方式：

a.使用V2.0的分层理念，降低场景case编写的重复性和后期维护成本

b.在V3.0上运行。使用了V3.0集成的pytest功能，包括parameters、fixture 、hooks、allure以及其他pytest生态的众多插件

c.用例管理仍旧使用yaml，使用V2.0的har2case方法生成yaml用例，对代码基础薄弱的同学相对友好

d.保留了V3.0的链式调用和语法检查，对有代码基础的同学编，提供了智能语法提示写用例时，提供语法检查

e.报告的生成使用了V3.0引入的allure，报告更加美观详细

f.可移植性，支持conda虚拟环境+requirements.txt 复制环境

• 主要功能已实现，后续功能根据业务需要持续更新

参数化、业务断言、数据驱动、测试分层、util封装、环境变量、配置管理、场景测试用例、 setup/teardown，不同作用范围、 热加载、 动态参数、 报告、 持续集成

• 整体运转流程 

图片来源：debugtalk的github readme

⑦应用步骤

用例要求：

 a.所有基础的接口都要录制全

 b.提前设计好要覆盖的场景，录制用例时，不要做多余的操作

 c.放入指定的用例存放目录

将har文件转换成yaml用例或者pytest用例

配置好ini文件

运行项目

• 本地执行

• 配置到jenkins job中运行

4、pytest+requesty

①简介

Pytest是Python的一种第三方单元测试框架，全功能且非常成熟，同自带的Unittest测试框架类似，相比于Unittest框架使用起来更简洁，效率更高。它的目的是让单元测试变得更容易，并且也能扩展到支持应用层面复杂的功能测试。

②优缺点

优点：

•  能够支持简单的单元测试和复杂的功能测试

•  pytest具有丰富的插件生态，并且可以自定义扩展

•  可以很好的和jenkins集成

•  report框架----allure 也支持了pytest

•  自动识别测试模块和测试函数

•  支持参数化

•  模块化夹具用以管理各类测试资源

•  对 unittest 完全兼容

•  社区繁荣，文档丰富，文档中有很多实例可以参考

缺点：

•  学习成本高

③使用要求

•  对pytest框架有基本了解

•  对request有基本了解

•  要求python基础

•  了解封装

•  了解虚拟环境

④适用业务

 项目接口多，但是入参大同小异

 大部分接口都做了鉴权

⑤环境依赖

 python V3.9以上

 pycharm

 Anacanda

⑥框架实现功能

a.测试类基类封装：基类实现了所有测试case通用的方法如打印请求/响应、日志管理、断言等，所有测试case类继承基类

b.统一请求封装：

• 全局维护一个session对象，自动实现cookie/session管理功能，无需每个接口单独进行鉴权

• 接口通用参数提取，无需每个接口单独处理。如base_url、referer、headers处理，ssl处理等

• 提供全局统一发起请求方法，屏蔽不同请求方法的底层实现细节

c.配置化实现：通过全局配置文件，实现公共参数管理

d.参数化实现：测试用例脚本与测试数据分类，通过yaml进行用例管理

e.公共util：实现断言、日志管理、数据库驱动、邮件封装、文件读取等

举例说明

以有钱联盟小程序为例，在postman中进行接口测试时，所有的接口都需要在header中封装cookie 和 referer，即使在环境变量中实现了参数化可以统一管理，但这个接口添加仍然很繁琐。

转化成自动化接口测试脚本，以某个接口为例，封装前的代码如下： 

封装后如下，所有的接口case都是统一的一套代码

只需要每个接口单独实现yaml用例即可

⑦应用步骤

a.用例要求：使用yaml编写测试用例，用例需要包含基本字段，如name、des、request、validata

b.准备运行配置ini文件：主要包含用例路径、用例自动识自定义前缀、用例分组、运行参数设置等

c.准备项目配置ini文件：主要包含公共参数的全局录入、日志路径及格式、数据库连接信息等

d.运行项目

五、总结

没有最好的框架，只有最合适的框架。

根据项目特点、技术栈、业务需要、迭代频率、组员技术水平等，综合进行自动化接口测试框架的选择，降低接入成本 和 维护成本，才能做好自动化测试的持续性。

自动化系列二将对自动化UI框架进行对比介绍。