《基于Jmeter的接口自动化测试标准研究与实践》----作者 王如迅 ----2021年《金融电子化》杂志
摘 要
在DevOps模式下，把开发测试运维归结到一起，从开发到运维都由整个团队来执行。开发提交代码之后，马上就可以自动触发构建，然后触发相关的自动化测试脚本，通过测试后直接部署，用户马上就可以拿到产品。加快自动化测试的推广和运用，深化DevOps开发测试运维一体化平台运用，提升快速搭建产品研发交付流水线的能力已经成为业界共识。
目前Jmeter接口自动化测试存在技术框架研究多、技术标准研究少；对内要求多、对外约束少的问题。银行内部人员可以开发Jmeter脚本，如果不对外部人员的Jmeter测试脚本等提交物进行统一规范，容易导致脚本编写风格不统一。不仅增加外部公司人员的学习和实施成本，也给审核带来麻烦、不利于进行回归测试。文章重点介绍Jmeter接口自动化测试提交物标准规范、脚本编写规范、实现步骤和实践效果。
关键词 Jmeter、接口自动化测试、DevOps、Jenkins
一、分行自动化测试存在的问题
自动化测试是指把以人为驱动的测试行为转化为机器执行的一种过程。分行在自动化测试领域存在如下问题：
1、分行在自动化测试领域缺乏指导、力量薄弱。在自动化测试方面起步较迟，测试工作基本处在手工阶段，造成工作效率不高、缺乏测试规范、质量难以保证等困难局面。
2、在测试领域，分行没有成熟的测试设计和实施方法，没有成体系的测试自动化工具。很多测试工作完全依靠科技人员自身的经验和能力，较多的分行特色系统实际上存在着一定的质量和安全隐患。
3、近年来互联网金融浪潮对传统银行业的冲击正在加剧，同时总行“科技引领”战略也在全速推进，分行科技部门作为直接为一线服务的最小科技单元，直接面临着市场和客户带来的激烈竞争和挑战，肩负着更重要的责任。在分行测试领域，传统的方法、流程、制度、工具等都存在与时代脱节的矛盾，缺乏测试全流程平台支持，急需进行工艺革新，助力分行测试工作数字化转型。
二、Jmeter 接口测试提交物标准规范
Jmeter 接口测试提交物包括：接口文档、接口测试用例文档和接口测试报告三部分。其中接口测试用例文档需要注明每个测试用例涉及到的接口。接口测试报告包括三个子文件夹：data、result和script。（1）data用来存放数据处理有关excel。若没有可以为空，若有建议以search.csv和result.csv等命名方式。（2）result用来存放生成的HTMLReport。包括index.html 有关包，用于通过浏览器查看接口测试情况。（3）script需要包括XX.jmx和XX.jtl。XX.jmx为测试框架脚本。XX.jtl为生成的测试结果，可以通过Jmeter查看，也可以通过XX.jtl生成html样式的报告。
三、Jmeter接口自动化测试脚本编写规范
一套标准的Jmeter接口自动化测试脚本框架如图1所示。图1
3.1、预处理文件
需要包含：“HTTP cookie管理器”、“HTTP请求默认值”、“HTTP消息头管理器”、“数据库配置（正式环境）”、“数据库配置（测试环境）”、“查看结果树”、“聚合报告”等预配置文件。此外，根据情况也可以添加“用户定义变量”、“CVS格式数据文件设置”等。 说明：这些组件如果有用不到的地方请选择“禁用”。比如“数据库配置”如果不用，就需要禁用，否则会导致后续测试出错。其中“查看结果树”、“聚合报告”显示的是测试结果情况。“HTTP请求默认值”中填写协议、IP地址、端口号和内容编码是为了避免在HTTP请求中重复填写这些内容。
3.2、单接口测试
需要根据业务模块建立循环控制器，比如后台管理的“热门活动”模块，单独建立一个循环控制器；“热点资讯”模块单独建立一个循环控制器。不能采用一个线程组写完所有的HTTP请求。说明：采用循环控制器去定义模块不仅做到了业务模块之间的逻辑隔离，也便于进行多次回归测试。若写到一起容易引起逻辑混乱，比如针对登录模块进行压力测试，如果和其他HTTP请求写到了一起，还需要手工禁用掉其余所有的HTTP请求。
3.3、业务流程测试
一个业务流程对应一个事务控制器。如果对业务流程进行性能测试，需要在循环控制器下面建立“事务控制器”，这样做是为了统计“事务控制器”下面所有的HTTP请求整体性能指标。
3.4、多环境配置
线程组下面需要有三个“如果（if）控制器”。分别为“开发环境变量”、“测试环境变量”、“生产环境变量”。其中测试计划的用户定义变量必须指明env 对应的是开发环境、测试环境还是生产环境。 三个“如果（if）控制器”中分别需要指明"
e
n
v
"
=
=
"
开
发
环
境
"
、
"
{env}"=="开发环境"、"
env"=="开发环境"、"{env}"==“测试环境”、"
e
n
v
"
=
=
"
生
产
环
境
"
。
“
如
果
（
i
f
）
控
制
器
”
下
面
需
要
有
个
b
e
a
n
s
h
e
l
l
取
样
器
，
对
变
量
进
行
定
义
，
包
括
请
求
协
议
、
请
求
地
址
、
请
求
端
口
等
。
定
义
变
量
方
便
H
T
T
P
请
求
进
行
参
数
引
用
。
说
明
：
这
样
做
是
为
了
一
套
代
码
可
以
复
用
不
同
的
环
境
，
只
需
要
在
三
个
如
果
（
i
f
）
控
制
器
里
面
的
b
e
a
n
s
h
e
l
l
取
样
器
里
定
义
一
次
，
就
可
以
多
次
复
用
。
采
用
“
b
e
a
n
s
h
e
l
l
取
样
器
”
定
义
变
量
操
作
更
加
灵
活
，
有
代
码
编
写
功
能
，
扩
展
性
比
“
用
户
定
义
变
量
”
更
强
。
3.5
、
测
试
计
划
、
循
环
控
制
器
和
H
T
T
P
请
求
的
编
写
规
范
测
试
计
划
命
名
规
范
：
需
要
为
“
测
试
计
划
−
系
统
名
称
”
。
如
：
“
测
试
计
划
−
云
上
X
X
工
作
室
”
。
循
环
控
制
器
的
命
名
规
范
：
（
1
）
单
接
口
测
试
。
需
要
为
：
“
前
台
−
功
能
模
块
”
。
如
：
“
前
台
−
学
生
注
册
”
、
“
后
台
−
学
校
管
理
”
。
（
2
）
业
务
流
程
测
试
。
需
要
为
：
{env}"=="生产环境"。“如果（if）控制器”下面需要有个beanshell取样器，对变量进行定义，包括请求协议、请求地址、请求端口等。定义变量方便HTTP请求进行参数引用。说明：这样做是为了一套代码可以复用不同的环境，只需要在三个如果（if）控制器里面的beanshell取样器里定义一次，就可以多次复用。采用“beanshell取样器”定义变量操作更加灵活，有代码编写功能，扩展性比“用户定义变量”更强。 3.5、测试计划、循环控制器和HTTP请求的编写规范 测试计划命名规范：需要为“测试计划-系统名称”。如：“测试计划-云上XX工作室”。循环控制器的命名规范：（1）单接口测试。需要为：“前台-功能模块”。如：“前台-学生注册”、“后台-学校管理”。（2）业务流程测试。需要为：
env"=="生产环境"。“如果（if）控制器”下面需要有个beanshell取样器，对变量进行定义，包括请求协议、请求地址、请求端口等。定义变量方便HTTP请求进行参数引用。说明：这样做是为了一套代码可以复用不同的环境，只需要在三个如果（if）控制器里面的beanshell取样器里定义一次，就可以多次复用。采用“beanshell取样器”定义变量操作更加灵活，有代码编写功能，扩展性比“用户定义变量”更强。3.5、测试计划、循环控制器和HTTP请求的编写规范测试计划命名规范：需要为“测试计划−系统名称”。如：“测试计划−云上XX工作室”。循环控制器的命名规范：（1）单接口测试。需要为：“前台−功能模块”。如：“前台−学生注册”、“后台−学校管理”。（2）业务流程测试。需要为：{env}-接口测试用例编号-“业务流程中文名”。如：“测试环境-云上XX工作室测试用例01-收藏夹”。说明：需要指明测试接口前后台的哪个模块。每个业务流程测试对应一个测试用例编号。对单接口测试，每个HTTP请求对应一个测试用例编号。如：“热门活动”模块对应增删查改四个HTTP请求，则对应四个接口测试用例。一个订单支付流程对应一个接口测试用例。HTTP请求的命名规范：HTTP请求的命名需要明确是开发环境、测试环境还是生产环境，以及对应的测试用例编号和中文名称。需要为：${env}-接口测试用例编号-“单接口的中文名”。如：“开发环境-云上XX工作室02-后台-业务管理-热门活动-编辑”。说明：这样可以通过观察HTML Report查看什么环境下的具体哪些测试用例执行不成功。
四、Jmeter接口自动化测试的实现步骤和实践效果
4.1 Jmeter接口自动化测试的实现步骤
（1）需求阶段：对程序模块接口进行需求分析描述。（2）详细设计阶段：开发人员在进行系统设计阶段，进行接口概要设计与详细设计描述，提供接口文档。（3）开发阶段：根据接口详细设计描述同步设计测试用例，并对测试用例具体实现，并将Jmeter提交物和源代码一起提交到GitLab。其中Jmeter提交物位于源码中的src/test/Jmeter目录下。（4）测试实施：设定Jenkins自动测试任务，自动从GitLab下载Jmeter脚本ant执行生成自动化测试报告，并自动反馈邮件。（5）自动化测试报告的分析解读：对不成功的用例进行分析解读，比如用例设计不正确、脚本编写错误等问题，并进行反馈。
4.2 Jmeter接口自动化测试的实践效果
对9个系统实施Jmeter接口自动化测试的效果如表格1所示。实践表明我行提供的Jmeter提交物标准不仅可以帮助外部公司人员提高效率，而且可以有效实施回归测试。
系统名称 用例
个数 用例编写
时间 开发阶段
问题数 测试阶段
问题数
云上XX工作室 150 2.5天 5 3
A系统 130 2.5天 10 7
B系统 120 3天 35 12
C系统 260 3天 0 17
D系统 12 0.5天 3 2
E系统 80 1.5天 10 0
F系统 56 1天 0 0
G系统 40 1天 0 0
H接口平台 24 1天 7 0
表格1
五、对Jmeter自动化测试等DevOps技术的实践
自动化测试的本质是通过提升测试效率，进一步提升软件产品的交付效率。原来在开发、测试、部署各阶段都是以手工驱动，手工流转与流程审核成为了提效的障碍。如今引进DevOps平台技术，利用Jenkins+ SonarQube+Jmeter实现自动化部署、自动化代码质量检测和自动化测试。只要开发人员提交代码到版本服务器，通过Jenkins自动部署平台可以将代码自动编译打包到测试环境，SonarQube自动进行代码质量检测，反馈开发人员对漏洞、BUG进行修复、自动生成Jmeter测试报告，然后对源码、执行码以及有关文档实现自动组包版本入库，从而实现开发测试、代码质量管控和版本交付的一体化。
