还有很多其他框架，本次只针对实际工作中应用到的几种框架进行对比。
自动化测试是把将手工驱动的测试行为转化为机器自动执行，通常操作是在某一框架下进行代码编写，实现用例自动发现与执行，托管在 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、自动化接口测试框架的必要性
● 提供统一的用例模板，简化业务接入的成本
● 处理脚本中一些异常和错误处理工作
● 实现一些通用的功能，简化脚本开发的过程
● 测试场景恢复
● 测试结果/报告输出
3、项目中实际应用的框架
● 项目一 -- 框架 Postman+Newman+Allure+Jenkins/极库云，case 数量：37
● 项目二 -- 框架 JMeter+Ant+Allure+Jenkins，case 数量：2
● 项目三 -- 框架 Httprunner+Request+Pytest+Alluret+Jenkins，case 数量：27
● 项目四 -- 框架 Pytest+Request+Allure+Jenkins，case 数量：19
● 项目五 -- 框架 pytest+request+Allure+Jenkins，case 数量：12
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 集成以及扩展封装都需要单独的开发新的项目兼容 postman 本生的框架语言
不支持运行时动态传入环境变量
不支持失败重试
仅适合业务逻辑不复杂的小型项目
③.使用要求
对 http 协议有基本的了解
了解接口测试概念
工具的基本使用
请求头，请求体能分清即可
④.适用业务
业务中接口量大
业务场景独立，关联关系弱
小型 API 项目的自动化
短期项目的 API 回归测试
编码能力较弱的测试团队或初学者
⑤.环境依赖
需要 Node.js 执行环境
需要安装 newman ，npm install -g newman
安装用到的插件，如 htmlextra，allure 等
⑥.应用步骤
1.用例要求：接口用例中做了较完善的接口管理、全局变量/环境变量定义、动态参数应用、请求参数化、实现了接口关联、所有的接口均有状态/性能断言 + 业务断言
2.生成项目：导出接口测试用例、环境变量、全局变量、数据驱动文件等
3.配置项目：框架单独章节再行介绍具体配置过程
4.运行项目
● 本地使用 CLI 执行自动化
● 配置到 jenkins job 中
5.查看报告（其他框架都是使用 Allure 输出报告，不再赘述）
6.代码上传 gitlab/github
7.接入持续集成，并配置定时任务（其他框架都支持通过极库云或 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 插件
⑥.应用步骤
1.用例要求：接口用例中做了较完善的接口管理、恰当的组件使用、动态参数应用、请求参数化、实现了接口关联、所有的接口均有状态断言 + 业务断言
2.生成项目：编写测试用例、导出测试用例，数据驱动文件等
3.配置 Ant 的 build.xml 文件
4.运行项目
● 本地使用 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 结合的方式：
1.使用 V2.0 的分层理念，降低场景 case 编写的重复性和后期维护成本
2.在 V3.0 上运行。使用了 V3.0 集成的 pytest 功能，包括 parameters、fixture 、hooks、allure 以及其他 pytest 生态的众多插件
3.用例管理仍旧使用 yaml，使用 V2.0 的 har2case 方法生成 yaml 用例，对代码基础薄弱的同学相对友好
4.保留了 V3.0 的链式调用和语法检查，对有代码基础的同学编，提供了智能语法提示写用例时，提供语法检查
5.报告的生成使用了 V3.0 引入的 allure，报告更加美观详细
6.可移植性，支持 conda 虚拟环境 +requirements.txt 复制环境
Ⅱ. 主要功能已实现，后续功能根据业务需要持续更新
参数化
业务断言
数据驱动
测试分层
util 封装
环境变量
配置管理
场景测试用例
setup/teardown，不同作用范围
热加载
动态参数
报告
持续集成
Ⅲ.整体运转流程
⑦.应用步骤
1.用例要求：
所有基础的接口都要录制全
提前设计好要覆盖的场景，录制用例时，不要做多余的操作
放入指定的用例存放目录
2.将 har 文件转换成 yaml 用例或者 pytest 用例
3.配置好 ini 文件
4.运行项目
● 本地执行
● 配置到 jenkins job 中运行
4、pytest+request
①.简介
Pytest 是 Python 的一种第三方单元测试框架，全功能且非常成熟，同自带的 Unittest 测试框架类似，相比于 Unittest 框架使用起来更简洁，效率更高。它的目的是让单元测试变得更容易，并且也能扩展到支持应用层面复杂的功能测试。
②.优缺点
优点：
能够支持简单的单元测试和复杂的功能测试
pytest 具有丰富的插件生态，并且可以自定义扩展
可以很好的和 jenkins 集成
report 框架----allure 也支持了 pytest
自动识别测试模块和测试函数
支持参数化
模块化夹具用以管理各类测试资源
对 unittest 完全兼容
社区繁荣，文档丰富，文档中有很多实例可以参考
缺点：
学习成本高
③.使用要求
对 pytest 框架有基本了解
对 request 有基本了解
要求 python 基础
了解封装
了解虚拟环境
④.适用业务
项目接口多，但是入参大同小异
大部分接口都做了鉴权
⑤.环境依赖
python V3.9 以上
pycharm
Anacanda
⑥.框架实现功能
1.测试类基类封装：基类实现了所有测试 case 通用的方法如打印请求/响应、日志管理、断言等，所有测试 case 类继承基类
2.统一请求封装：
● 全局维护一个 session 对象，自动实现 cookie/session 管理功能，无需每个接口单独进行鉴权
● 接口通用参数提取，无需每个接口单独处理。如 base_url、referer、headers 处理，ssl 处理等
● 提供全局统一发起请求方法，屏蔽不同请求方法的底层实现细节
3.配置化实现：通过全局配置文件，实现公共参数管理
4.参数化实现：测试用例脚本与测试数据分类，通过 yaml 进行用例管理
5.公共 util：实现断言、日志管理、数据库驱动、邮件封装、文件读取等
举例说明
以有钱联盟小程序为例，在 postman 中进行接口测试时，所有的接口都需要在 header 中封装 cookie 和 referer，即使在环境变量中实现了参数化可以统一管理，但这个接口添加仍然很繁琐。
转化成自动化接口测试脚本，以某个接口为例，封装前的代码如下：
封装后如下，所有的接口 case 都是统一的一套代码
只需要每个接口单独实现 yaml 用例即可
⑦.应用步骤
1.用例要求：使用 yaml 编写测试用例，用例需要包含基本字段，如 name、des、request、validata
2.准备运行配置 ini 文件：主要包含用例路径、用例自动识自定义前缀、用例分组、运行参数设置等
3.准备项目配置 ini 文件：主要包含公共参数的全局录入、日志路径及格式、数据库连接信息等
4.运行项目
没有最好的框架，只有最合适的框架。
根据项目特点、技术栈、业务需要、迭代频率、组员技术水平等，综合进行自动化接口测试框架的选择，降低接入成本 和 维护成本，才能做好自动化测试的持续性。
自动化系列二将对自动化 UI 框架进行对比介绍。
