06. 性能测试执行
06. 性能测试执行
- 执行流程
- 编写测试脚本
- 建立测试环境
- 性能测试监控
- 执行测试脚本
1. 编写测试脚本
性能测试中Jmeter不要使用数据库断言
接口测试中Jmeter可以使用数据库断言
常用测试元件
- 取样器-HTTP请求
- 配置元件-HTTP请求默认值
- 配置元件-用户定义的变量
- 后置处理器-JSON提取器
- 断言-响应断言
- 断言-JSON断言
- 监听器-察看结果树
- 监听器-聚合报告
JMeter脚本的基本结构
创建测试用例结构
设置HTTP请求默认值
设置http请求默认信息
用户定义的变量
添加监听器-察看结果树
添加监听器-聚合报告
- 使用JMeter实现测试用例
例如:获取首页数据
操作步骤:
在线程组下,添加取样器‘HTTP请求-获取首页数据’,并填写请求数
在取样器下,添加‘响应断言’断言响应状态码
在取样器下,添加‘JSON断言’断言errno和errmsg
发送请求,调试脚本
1. 单接口测试脚本
1. 登录脚本
添加HTTP请求默认值:设置HTTP请求中的默认部分(协议、域名、端口、编码格式)
添加HTTP信息头管理,设置HTTP请求的头域
添加线程组 - 登录
添加HTTP请求 - 登录,填写路径和请求参数
在HTTP请求下添加断言
- 如果做接口测试,必须断言 响应中的业务数据,可以加上状态码和描述信息
- 如果做性能测试,可以只添加状态码和描述信息断言
2. 进入首页、搜索商品、获取商品详情
进入首页
搜索商品
- 断言:
- 状态码、errmsg
- 如果是接口测试脚本,必须针对响应中的商品数量进行断言(数据库)
获取商品详情
- 断言
- 状态码、errmsg
- 如果是接口测试脚本,需要针对响应中的商品的详细数据进行对比(数据库)
- 断言
- 断言:
3. 加入购物车的脚本
添加线程组
添加请求1:登录
添加断言(状态码、errmsg、Nickname)
添加JSON提取器,提取token
将token设置在HTTP信息头管理器中
添加请求2:加入购物车
添加断言
- 状态码、errmsg
- 如果是接口测试脚本, 需要再查询我的购物车,检查我的购物车返回的数据是否与加入购物车返回的数据一致
4. 查看我的购物车、结算下订单、查看我的订单
查看我的购物车
请求:先发送登录请求,提取token信息,添加查看购物车请求,将token信息赋值为X-litemall-Token头域,填写请求路径和参数
- 响应断言
- 状态码、errmsg
- 如果脚本为接口测试脚本,需要断言响应报文中的购物车中的商品总数量或者商品总价值
- 响应断言
结算下订单
- 请求:
- (1)先发送登录请求,提取token信息,
- (2)添加结算请求,将token信息赋值为X-litemall-Token头域,填写请求路径和参数
- (3)添加下订单请求,将token信息赋值为X-litemall-Token头域,填写请求路径和参数(注意地址ID必须与用户ID匹配)
- 响应
- 状态码、errmsg
- 如果脚本为接口测试脚本,需要断言响应报文中的订单数据,与数据库中订单表中我的订单数量一致
- 请求:
查看我的订单
2. 业务流程的测试脚本
将业务流程中的所有单接口的脚本组装在一起
注意所有的脚本组装在一起时,数据是否一致
- 事务控制器
- 事务中会包含一个或多个请求,当含有多个请求时,想看一个事务的测试结果(所有请求的总时间和总的吞吐量等),可以通过事务控制器进行操作
添加事物控制器
- 事务控制器
2. 建立测试环境
1. 性能测试环境的特点
- 独占性:性能测试环境独立使用
- 一致性:尽量保持性能测试环境与真实生产环境的一致性
- 硬件环境一致 - 找运维申请
- 包括服务器环境、网络环境等
- 软件环境一致 - 找开发提供
- 版本一致性:包括操作系统、数据库、被测应用程序、第三方软件等
- 配置一致性:包括操作系统、数据库、被测应用程序、第三方软件等
- 使用场景的一致性 - 测试人员自己准备
- 基础业务数据的一致性
- 业务操作模式的一致性:尽量模拟真实场景下用户的使用情况
- 硬件环境一致 - 找运维申请
2. 如何构造性能测试数据
目的
- 压测环境中的数据量尽量与生产环境中数据量一致
方法
- 为了快速创建大量数据,可以直接操作数据库进行添加
- 准备插入数据的SQL语句
- 循环执行SQL语句来插入数据
- 导包
- 连接数据库
- 创建游标
- 执行SQL语句
- 关闭游标
- 关闭连接
- 为了快速创建大量数据,可以直接操作数据库进行添加
演练
1、通过编写Python脚本,构造10万条商品记录
详见代码
操作步骤
准备插入数据的SQL语句
循环执行SQL语句来插入数据
3. 性能测试监控
1. 如何监控性能测试指标
性能测试的基础指标指标
系统指标:
响应时间
并发数
吞吐量
错误率
服务器资源指标
CPU使用率:一般可接受上限为85%
内存利用率:一般可接受上限为85%
磁盘I/O
网络带宽
4. 执行测试脚本
1. 如何执行性能测试脚本
- 单台测试机执行
- 前提
- 先保证脚本调试通过之后,才能进入正式压测阶段。
- 可以选择Windows或者Linux测试机来执行
- Windows环境:操作界面化、直观、易上手,但是软件占用机器资源较多,导致资源使用率不高;可支 持并发较低。
- Linux环境:命令行操作,结果查看不太方便,但资源利用率相对较高;可支持较高并发。
- 前提
- 分布式执行
- 如果单台压测机的并发量不能够满足要求,则可以通过分布式压测来提高并发量。
- JMeter工具支持分布式压测,即多台机器同时执行同一个脚本,然后统计结果。
2. 扩展
1. 修改脚本 - 使用random函数
使⽤random函数,来保证每次运⾏登录时,使⽤不同的⽤户名进⾏登录
2. 监控性能指标
系统指标:响应时间、吞吐量、错误率、并发数
- 聚合报告
资源指标:CPU、内存、磁盘、⽹络
- PerFMon
3. 模拟并发
如果系统之前进⾏过性能测试,直接模拟TPS20的场景,进⾏性能测试,并监控指标
如果系统之前未进⾏过性能测试,按照负载测试的原则,逐步增加负载量,观察性能的指标。 — 采⽤该⽅法
执⾏
- 模拟5个⽤户并发,观察吞吐量TPS和响应时间
结果分析
⽤例要求登录TPS为20,要求响应时间不超过3s
实际执⾏登录TPS为20.3(达到要求),实际执⾏的响应时间为244ms(达到要求),因此⽤例通过
补充
当前⽤例测试时CPU利⽤率为98%,内存利⽤率为85.62%,超出正常的范围
如果在公司进⾏性能测试时,该⽤例不能算通过,因为资源使⽤率也是⼀个重要指标
在课上由于虚拟机资源不⾜,暂时不关注资源使⽤率
4. ⾸⻚脚本
- 模拟5个并发
- 实际TPS未达到要求TPS100,实际响应时间(1)未超过要求实际5s,⽆法证明是否存在bug,需要进⼀步增加负载量
- 模拟30个⽤户并发
- 实际TPS未达到要求TPS100,实际响应时间(10s)未超过要求实际5s,说明⽤例测试不通过,需要提交bug
5. 加⼊购物⻋脚本
数据准备⼯作
修改待添加的商品库存为⾜够⼤,避免在性能测试过程把商品库存耗尽导致脚本失败
UPDATE litemall_goods_product SET number = '1000000000' where id =2;
脚本修改
可以使⽤随机⽤户登录,并添加购物⻋吗?
- 不可以,添加购物车必须和已登录的账号保持统一
- 使用计数器
运⾏并分析结果
模拟5个⽤户并发
实际TPS41.9达到要求TPS20,实际响应时间59ms未超过要求响应时间3s,⽤例测试通过
6. 结算并下订单脚本
修改测试脚本
设置计数器
修改HTTP请求 - 登录
修改HTTP请求 - 下订单
HTTP信息头管理器(也可以添加到测试计划内)
执⾏测试脚本
模拟5个⽤户并发
实际TPS为29.5达到要求TPS10,实际响应时间为19ms(不超过要求3s),⽤例测试通过
7. 业务流程的测试
步骤
准备测试数据
修改脚本
添加事务控制器,并把所有的脚本都放⼊到事务控制器中,以业务为单位统计,不是以接口统计
添加性能监控
并发执⾏并分析结果
注意
- 在进⾏业务流程的脚本性能测试时,前提必须保证该业务流程中所有的单接⼝性能测试结果都达标
5. 稳定性测试
在单接口和业务测试完成之后进行稳定性测试
1. 稳定性⽤例设计
确定出稳定运⾏的所有业务操作:(同时运⾏)
根据运营数据,分析出每个业务操作对应的虚拟⽤户数
稳定性测试执⾏
所有的脚本同时执⾏(需要解除前后依赖,如多脚本中的token依赖需要修改,放到单个请求中)
每个脚本都是⼀个事务/业务 —— 事务控制器
按照要求设置虚拟⽤户数和运⾏时间
执⾏稳定性测试并监控
补充
- 如果单个接⼝/业务流程还存在性能bug,需要再修复性能bug,再进⾏稳定性测试