Jmeter接口测试入门到精通
一、接口介绍
1.1 接口概念介绍
软件接口的由来
- 软件系统中,前端和后端是两大重要组成部分
- 前端主要用于与用户交互,用户通过前端页面,操作 ->查看结果显示
- 后端主要用于处理数据,用户提交了数据 ->处理好逻辑 ->与数据库交互
接口大体分类
- 硬件接口(USB口/网口/GA视频接口/HDMI接口等)
- 软件接口(软件测试只关注软件接口)
概念
有规范,且用于通信的管道
作用
数据交互
软件接口的分类
按照客户端划分
- web接口
- app接口
- 小程序接口
按照协议划分
- http接口
- TCP接口
- socket接口
- webservice接
按开发人员归属划分
- 自研接口
- 第三方接口
1.2 接口测试
为什么我们要做接口测试?
提前测试接口,解决接口的 bug,能为后面功能测试节省很多时间,减少功能测试的bug 数量,因为一个接口很可能被多个前端页面功能调用,如果一个接口有 bug,可能在多个功能页面场景下都有同样的 bug,所以是减少了隐患,。
接口测试三要素
- 定位接口资源 (通过路径找到接口)
- 提交测试数据
- 判断响应结果
接口测试分类
按测试目的进行划分
- 接口功能测试
- 接口回归测试
- 接口冒烟测试
按是否自动化运行划分
- 接口(手工)测试
- 接口自动化测试
1.3 接口测试环境
环境分析
1.项目 (后端), 案例由Java编写,需要编译后才能运行,依赖的内容有:
- JDK
- IDE(开发需要的)
- Tomcat (这里我们直接给出编译打包后的文件,内置了tomcat)
- MySQL
2.测试工具,如:
- 浏览器
- postman
- jmeter
项目部署和运行
后端
- 在jar文件所在目录,命令行运行java-jar api1.0.jar 即可
数据库
- 创建一个名为api test的数据库(root/123456)0
- 运行api test.sql。
测试工具
- 浏览器,本身只能帮助测试get方式的请求(不算插件)
- postman:主流工具之一,功能强大
- jmeter: 开源, 支持多种协议,免安装, 可做性能测试
二、Jmeter接口测试基础
2.1基本流程
需求
使用jmeter 访问项目案例的查询接口
使用步骤
- 1.启动 jmeter 并搭建基本框架,添加线程组 +HTTP请求+查看结果树
- 2.设置接口测试三要素(URL+请求方式+协议+端口号+请求提交数据)
- 3.运行并查看结果
组件与元件
组件: 是Jmeter 中的一些功能点实现(比如: 线程组、http请求、查看结果树 …..)元件: 对组件按照性质归类分组,作用:方便管理组件
2.2 组件-线程组
2.2.1 总体介绍
概念
- 进程: 正在运行的程序
程序启动,进程创建,程序关闭,进程释放,反之,进程释放,程序关闭
- 线程: 程序中的执行线索(路径)
迅雷中每一部电影下载,游戏中的每一个角色
- 线程组: 对线程分类归组
层级关系:
进程>线程组>线程 ===一个进程可以包含多个线程组,一个线程组可以包含多个线程
- 并发执行:多个线程同时执行=== 多部电影同时下载==== 线程的启动顺序和结束顺序不一定一致
- 顺序执行:多个线程按照顺序依次执行===电影下载后播放====线程的启动顺序和结束顺序一定一致
作用
方便管理线程
2.2.2 层级关系
2.2.3 Jmeter的一些设置介绍
选中这个选项后可以让请求响应变成有序的
线程组的设置
特殊线程组
setup 线程组:最先执行的线程组,一般用于初始化操作tearDown 线程组:最后执行的线程组,一般用于资源销毁举例
添加: 右键 测试计划 ->添加 ->线程 (用户)->可以找到特殊线程组
查看结果树的作用域
查看结果树显示线程组内取样器的执行结果的,查看结果树添加位置不同,对应生效的取样器也不同
- 添加在测试计划下:对所有线程组的所有取样器生效
- 添加在线程组下: 只对当前组内取样器生效
- 添加在取样器下: 只对当前取样器生效
2.3 Jmeter实战练习
需求:使用Jmeter进行接口的增删改查
2.3.1 JSON格式参数
如果是提交JSON格式,需要声明提交的数据类型
2.3.2 http请求默认值
随着调试接口的数量增加,发现多数http请求中IP,端口,编码基本相同,可以使用HTTP请求默认值简化脚本
2.3.3 用户定义的变量
不同环境的 ip/端口 是不同的,当需要修改环境的时候,逐个修改每个请求的 ip/端口 是低效的,即便使用HTTP请求默认值,修改起来也稍有繁琐,可以使用用户定义的变量来简化操作
引用变量
使用 ${变量名}的方式对变量进行引用
使用场景
切换不同测试环境时,可以以如下方式来使用:
1.分别使用两个组件用户定义的变量,来定义两个环境的变量
2.在HTTP请求默认值中引用变量
3.通过控制用户定义的变量组件的启用/禁用,来控制请求的是哪个环境的接口
2.4 接口测试的流程
1.需求分析,需求评审
2.编写测试计划
3.编写测试用例以及发起用例评审-->可以协助开发联调接口(通过性测试),接口功能测试
4.[可选]搭建测试环境
5.系统测试,编写测试报告
a.冒烟测试
b.第一轮--新功能测试
c.第二轮--bug回归
d.第三轮--bug回归
f.最后一轮旧功能回归-->可以用接口回归测试来替代6.验收测试,编写测试报告
7.线上,点点点
三、Jmeter单接口测试
应用场景
前后端编码/联调阶段,后端接口相继写好,测试人员可以协助联调接口
- 特点1:难度较高, 需要自己造数据
- 特点2: 测试目的是看接口通不通,交互的数据是否正确
- 前后端编码/联调阶段,测试人员设计各种正向+逆向的用例,对接口功能进行验证
3.1 接口功能测试
含义
模拟用户的多样性操作,查看实际结果是否符合预期
原则
设计各种正向+逆向的测试用例
接口覆盖率达到100%
测试流程
1.根据API文档,编写测试计划
2.根据API文档, 设计接口功能测试用例, 并发起评审
3.使用工具 (如,Jmeter)编写测试脚本,执行测试用例
4.输出测试报告
3.1.1 设计测试用例
主要从功能、业务逻辑、异常和安全4个方面设计接口用例
- 功能方面:功能正常且和需求一致。例如,接口的功能是否正常,入参和出参的值是否成功入库,且数据流程是否正确。
- 业务逻辑方面:单接口和多接口的测试,多接口有依赖关系,接口鉴权,接口关联,是否有调用第三方接口。例如,接口调用之前需要调用登录接口,如果不登录也能请求成功则有 bug,因为没有做鉴权。
- 异常方面:分为参数异常和数据异常。参数异常通常有空(是否必填)、多一个参数少一个参数、错误参数等。数据异常通常有空、长度限制、错误数据(特殊字符,中英文数字等)、数据类型(本来是 int,能传 string 就是有 bug)等。
- 安全方面:从 cookie、密码明文及密文等。cookie 中考虑存在与不存在 cookie 的情况密码是否是明文发送,接口是否有越权的隐患等,
3.1.2 编写测试脚本
实现方式
核心知识
csv文件,用于存储数据
- csv 文件其实就是格式化的txt文件,直接改后缀可以相互转换。
- csv 用英文逗号分隔值,是程序中常见的数据存储格式
- csv 文件中一行代表一条数据,一列代表一个字段
核心组件: CSV数据文件设置,用于读取数据
6.2.4 输出测试报告
接口用例模板.x1sx补充了测试结果,测试人,测试时间,备注等字段后,可以视为接口功能验证表
3.2 参数化
3.2.1 概述
目前已经用到的参数化方式
用户定义的变量
- 提前定义变量,需要时引用,修改方便,常用于环境参数配置
csv数据文件设置
- 接口功能测试,多条测试用例,动态读取数据
参数化的概念
将静态数据转换为动态数据的过程,用于动态的生成,设置或导入数据
作用
- 高效
- 提高脚本的编写质量,可维护性更好
3.2.2 实现方式
Jmeter中常用的参数化实现方式
- 用户定义的变量
- csv数据文件设置
- 函数
三者互补,重点是csv数据文件设置
3.3 Jmeter函数
需求
访问查询area接口20次,在结果树为请求添加标号
步骤
1.编写脚本
2.打开jmeter 内置的 函数助手
3.选择所需函数(counter),输入参数后, 点击 生成4.调用, 复制粘贴生成后的结果即可
记得把线程组的循环次数设置为20
常用函数介绍
- counter()->计数器, 参数1:TRUE|FALSE
TRUE,一个线程对应一个单独的计数器
FALSE,所有线程共用一个计数器
- random()->随机数,参数1:最小值,参数2: 最大值
- time() -> 时间函数,参数1:格式化时间 yyyy/MM/dd HH:mm:ss 相当于年/月/日 时:分:秒
3.4 Jmeter断言
概念
程序代替人工,判断响应结果是否符合预期
作用
- 高效
- 安全
常用断言方式
响应断言,判断响应数据中包含预期结果
- 如果包含,断言成功 (说明本条测试用例执行是通过的)
- 如果不包含,断言失败 (说明本条测试用例执行是不通过的)
实现步骤
1.准备脚本
2.添加断言(响应断言,同时添加断言包含的字符串内容)
3.运行并查看结果
- 通过,没有提示
- 不通过,有错误提示
断言应用示例
- 1.准备脚本(使用新增一个学院信息的测试脚本)
- 2.在 接口功能测试数据_优化_增加断言.csv 中增加一列数据,数据内容是需要断言的内容
- 3.在jmeter脚本中引用数据文件, 并在响应断言中动态的引用断言的内容
3.5 连接数据库
原理
jmeter连接数据: jmeter ->驱动 ->数据库
应用场景
比如测试新增一个area信息的接口,可以去数据库查看该数据是否新增成功, 用于断言比如执行测试用例后,需要清除垃圾数据, 就需要连接数据库,并执行删除表数据的操作,用于销毁测试数据
需求案例
新增一个area信息,查询数据库并断言新增成功
实现步骤
1.导入第三方驱动包,在测试计划下
2.配置数据库连接信息 (配置元件中找到对应的组件)
3.核心: 向数据库发送SQL语句,并接收响应结果
注意
JDBC请求中,返回的数据是一个列表,如果你定义的变量名是 name,那么引用结果的方式为 ${name_N}假设我引用一个结果,那么引用方式为 ${name_1}
四、Jmeter多接口测试
常见的接口回归测试的策略
基于模块,回归每个模块的核心接口
- 接口覆盖率高
- 工作量较大,项目迭代更安全
基于业务流,回归核心业务流程
- 接口覆盖率低
- 工作量较少,项目迭代更高效
可以看出,不论是哪一种接口回归的策略,都涉及多个接口,也叫多接口测试
多接口测试的原则
- 接口覆盖率没必要100%,只需要测试重要的接口.
- 只需要设计正向的测试用例
- 脚本需要重复执行
4.1 接口鉴权(依赖登录的接口测试)
1、先请求登录接口,通过JSON提取器获取token
2、给依赖登录的接口添加一个HTTP信息头管理器
需求
在之前基础上,把请求A和请求B设置到不同的线程组,再实行一次
- 结果: 请求B接口失败,无法引用token
- 原因: 变量作用域不对
- 解决: 将局部变量转换成全局变量
步骤
- 1.通过setProperty函数,建立局部变量和全局变量的对应关系
- 2.通过BeanShell取样器,执行setProperty函数, 生成全局变量(属性)
- 3.下游线程组通过Property函数引用全局变量即可
如何查看 jmeter 中的全部变量?
可以通过一个辅助性组件 属性显示:测试计划 …>添加 …>非测试元件 …->属性显示
五、Jmeter小结
5.1 文件上传问题
假如接口需要上传文件,怎么进行测试
5.2 接口加解密测试
需要加密的接口测试,此处说的不是接口具备加密功能,而是为了安全考虑,请求的某些参数需要加密
- 如,最常见的,登录密码需加密
- 如,支付信息需加密
常见加密方式了解
- MD5:一种简单的哈希算法,将任意长度数据通过算法生成一个固定长度的值,速度快,但安全性较差SHA-256:比MD5更安全,但也有安全隐患,比之更安全的是 SHA-256加盐
- 此外还有AES,RSA等加密算法
以MD5加密为例,说明imeter如果解决需要对数据进行加密的问题
- jmeter中的内置函数
- 自己写加密代码,在 Beanshell 中执行
- 也可以调用开发写的代码,在 Beanshell 中调用
5.3 第三方接口测试
利用一些 Mock工具(如 fastMock,Easy Mock)来模拟第三方接口的数据返回,最大限度地降低对第三方接口的依赖。其实就是自己用工具模拟一个第三方接口的返回数据我们只要去调用该接口的地址,就会返回和第三方接口一样的数据,进而达到数据 mock的效果.
假设 A接口需要调用第三方的 B 接口,B 接口可能存在的情况有:1、B 接口还没有开发完成,这样 Mock B 接口能大大缩短开发联调的等待时间,2、B 接口的一些场景很难去模拟,比如接口不稳定,经常超时等所以我们才会去用 fastmock 模拟接囗数据。
5.4 Jmeter作用域
作用范围,在jmeter中专指当前组件对哪些范围的取样器生效
分类
1.取样器自身: 无所谓作用域,在作用域概念中作为参考物存在
2.大多数组件: 如,査看结果数, http信息头管理器, csv数据文件设置, json提取器....
- 测试计划下: 对所有线程组中的所有取样器生效
- 线程组下: 对当前线程组中的所有取样器生效
- 取样器下: 对当前取样器生效
5.5 执行顺序
jmeter 的组件有默认的执行顺序:(imeter中组件的执行顺序与添加顺序无关)
1)配置元件(config elements): http请求默认值、信息头管理器、JDBC配置特点:配置初始化数据
2)前置处理器(Pre-processors):用户参数
特点:设置取样器执行所需数据
3)定时器(timers):常量吞吐定时器、同步定时器
特点:设置取样器的执行规则4)取样器(sampler):http请求、JDBCRequest
特点:核心北
5)后置处理程序(Post-processors):JSON提取器特点:从响应结果提取数据
6)断言(Assertions):响应断言
特点:判断响应结果
7)监听器(Listeners):查看结果树、聚合报告
特点:显示最终的运行结果
5.6 图形化测试报告
jmeter支持以图形化的方式显示脚本的运行结果
应用场景
- 对测试报告有更高的要求时
- 执行性能测试时,命令行执行的方式比图形化界面占用更少的资源
使用方式
#生成图形化测试报告,命令:
jmeter-n-t脚本文件-1日志文件-e -0 目录
-n:无图形化界面的方式运行
-t:指定被执行的脚本
-1 :结果写入的日志文件
-e:生成测试报告
-0:讲测试报告输出到某个目录
注意:
1.执行命令时,日志文件应不存在,需执行后生成
2.执行命令时,报告输出目录应为空 或 不存在
北软清