前言👀~
上一章我们介绍了性能测试的一些基本概念,重要的是性能测试的各项指标,今天我们使用性能测试工具LoadRunner简单的完成一次性能测试
[性能测试Load Runner](#性能测试Load Runner)
如果各位对文章的内容感兴趣的话,请点点小赞,关注一手不迷路,讲解的内容我会搭配我的理解用我自己的话去解释如果有什么问题的话,欢迎各位评论纠正 🤞🤞🤞
个人主页:N_0050-CSDN博客
相关专栏:java SE_N_0050的博客-CSDN博客 java数据结构_N_0050的博客-CSDN博客java EE_N_0050的博客-CSDN博客
性能测试Load Runner
LoadRunner是什么?
LoadRunner是一种适用于许多软件体系架构的自动负载测试工具,可用来模拟用户负载完成性能测试工作,从用户关注的响应时间、吞吐量, 并发用户和性能计数器等方面来衡量系统的性能表现,辅助用户进行系统性能的优化。简单点说就是一个性能测试工具,通过模拟用户负载对系统操作来完成性能测试,然后验证系统的各项性能指标是否符合预期
**原理:**LR启动以后,在任务栏会有一个Agent进程,通过Agent进程,监视各种协议的Client与Server端的 通讯,用LR的一套C语言函数来录制脚本,所以只要LR支持的协议,就不会存在录制不到的,然后LR调用这些 脚本向服务器端发出请求,接受服务器的响应。至于服务器内部如何处理,它不关心
LoadRunner性能测试流程:
LoadRunner安装
这里我就不演示了,安装包在开头拿去下载就行了,如果下载不了私我我发你,因为我已经下载过了,删掉重新装有点麻烦,就是点击可执行文件.exe然后一路安装下去,直到出现HP身份认证设置的时候不勾选接着一路点下去即可
为什么选择LoadRunner:
1.具有强大的录制功能
2.可以设计丰富且灵活的场景
3.能够产出丰富且详细的性能测试报告
LoadRunner三大组件之间的关系:
VUG:录制脚本和生成脚本模拟用户的行为(编写性能测试脚本)
Controller: 针对脚本以及具体场景来设置测试场景,然后执行性能测试脚本(设计场景、运行以及监控场景)
Analysis: 根据性能测试的结果,然后产出性能测试报告
LoadRunner脚本录制
这里我们录制LoadRunner自带的系统webTours(软件/系统)
如何启动webTours?
1.下载完成LoadRunner,找到你安装路径下的webTours文件,然后双击
2.进入选择webTours文件后,双击startServer.bat
3.然后就是下面这样,注意webTours启动后不要关闭
4.接着找到conf文件夹下的httpd文件查询端口号
5.结合刚才打开的webTours中IP地址去我们的浏览器中输入 http://上图中自己的地址IP:1080/WebTours内容即可访问到webTours,然后注册,也可以不用注册使用自带的jojo密码bean
如果要注册点这里
接着创建完后,可以去webTours文件下的cgi-bin文件夹下的user文件夹中就可以看到你刚才创建的账号名和密码了
1.录制基本的用户脚本
首先打开VUG软件,然后创建一个脚本文件
创建好了后,对图中三个脚本文件进行解释
然后开始录制
然后它会自动的跳转到刚才的我们WebTours那个界面去,我们登录后点击停止就会自动生成脚本了
注意:如果录制不到脚本可以试试打开如下图中的选项
2.删减无用脚本
然后删除一些没用的脚本,根据你实际的进行删除,我这边使用的360极速浏览器脚本产生的比较多,之前也用过chrome录制过,脚本内容有点少
3.编译
4.运行(回放)
点击运行后,如果是下图这样的效果就是成功了
但是里面的思考时间没有被执行,如果脚本中有写到思考时间去设置,这样在运行的时候也会被执行,如下图
还要设置一个,设置完这个选项后就能看到运行回放的界面了
LoadRunner脚本加强
为什么要对脚本加强?
1.录制的测试脚本达到不了预期的测试目的(也就是达不到预期的测试效果)
2.缺乏针对性
当录制完一个基本的用户脚本后,在正式使用前我们还需要完善测试脚本,增强脚本的灵活性。通过一些方法来完善测试脚本,如果就单单一个简单的脚本是无法观察到这些性能指标,所以我们需要对脚本进行加强
脚本如何加强?
1.插入事务
**开始事务:**lr_start_transaction("事务名称");
**结束事务:**lr_end_transaction("开始时事务取的名称", LR_AUTO);
添加事务有两者方式:
1.直接在代码手动添加,就把上面的函数写到你要插入的位置即可
2.录制的时候手动插入事务,如下图
日志输出效果
注意:事务函数有开始就有结束,开始事务和结束事务的事务名称必须一致,可以试试不一致,在日志中会有报错信息
2.插入集合点
集合是什么?
就类似军训中一说集合大家同一时间快速集合到一起,但每个人到位置的时间点都不同,所以在使用性能测试工具的时候我们该如何实现集合的效果让用户都集中到一起并且同时请求从而实现并发的效果呢?
集合点
集合点是LoadRunner为了实现并发而进行的一种运行机制,让虚拟用户进行短暂的集合,在满足特定的条件下然后放行达到并发的效果也就产生了并发数
**集合点函数:**lr_rendezvous("集合名称");
和事务一样可以在右侧搜索后进行添加
注意:集合点函数只能放到action中,并且集合点应当放到事务之前
3.插入检查点
什么是检查点?
检查点相当于"断言",在进行压力测试时,为了检查服务器返回的网页是否正确。在VUG中这些检查点验证网页上是否存在指定的Text
**检查点函数:**web_reg_find("Text=想要匹配的关键字",LAST);
日志输出效果
注意:检查点函数一般放在页面请求之前
4.参数化
概念: 使用变量代替脚本中的常量,目的是通过虚拟用真实的模拟现实用户对系统进行操作
右击一个变量后如下操作
注意创建后点No,如果选择yes替换掉所有相同的变量话如果url中带有这个变量的话会出错
然后左侧点击可以看到我们刚才创建的参数,我们还可以添加多个
要想看到参数的具体信息,我们需要修改日志等级
日志输出效果
只有一个参数的具体信息,我们需要设置Action脚本运行次数
日志输出效果
5.打印日志
**函数:**lr_log_message("输入你想要输出的内容");
if(strcmp("jojo",lr_eval_string("{UserName}"))==0){
lr_output_message("OK %s",lr_eval_string("{UserName}"));
}
如果当前登录的用户是对应的TestNan,就输出TestNan**,这个lr_eval_string函数的意思就是把UserName的值输出和前面的进行比较。下面是日志输出效果**
掌握Controller的使用
目的掌握创建场景、运行和监控场景,可以通过Controller设计简单的测试场景,并且可以简单的分析性能测试报告
为什么要把脚本放到Controller中运行,而不是选择在VUG里呢?
什么是性能测试不要忘记了,测试人员借助性能测试工具,模拟系统在不同场景的各项性能指标是否满足需求,所以我们需要观察系统的性能指标 ,在VUG中运行看不到系统的性能指标
1.创建场景的方式
第一种是在VUG中对写好的脚本创建场景
第二种是手动打开Controller进行脚本的添加并创建场景,其实和上面的差不多
2.场景的设置
1.设置初始化
2.设置启动机制
3.设置性能测试脚本的执行时间,这块可以理解为对系统的可靠性测试,因为你可以设置脚本的运行时间
4.设置虚拟用户退出机制
设置场景的运行方式
1.按照场景的方式运行: 不论场景中脚本的数量有多少,所有的脚本都是统一调度和运行的
2.按照Group运行: 场景中脚本有各自设计运行方式,所以根据脚本各自设计的运行方式运行
设置完成后右侧的图表会发生变化
3.场景的运行
下图是运行场景中的各个区域,对于监控区域的数据都是上一篇性能测试中的性能指标介绍的
如下图设置后图表区展示的可多可少
注意:想要查看系统资源图表,需要手动修改配置
1.打开任务管理器,启动对应的服务器
2.选中监控区域中的System Resource Graphs下的Windows Resource,然后在指标详细数据区域右键,选中add Measurements
3.监控指标的选择,选择你要观察的系统资源即可
4.观察设置后的效果
开启场景:
下图是运行起来的效果
运行结束的效果
仔细观察图表各项指标会发现有一共有四个事务,为什么有四个事务呢?
LR中认为每一个脚本文件都是一个事务,图中的vuser_init、action、vuser_end三个脚本文件就是三个事务,其中action是用户自定义事务,ts这个事务就是我们自己加的
分析Controller中的运行时图:
Running这条紫色的折线表示正在进行测试的用户数量,测试初期,需要时间来分配资源或初始化用户,也就是刚开始的时候虚拟用户需要初始化,所以一开始是0随着虚拟用户的启动,折线逐渐上升,随着虚拟用户都启动完成,折线趋于平稳。当运行时间到了,折线逐渐下降
Ready这条棕色的折线代表处于就绪状态但尚未进入测试的用户数量,测试系统开始调用这些就绪的用户进行实际的测试任务,用户的状态从就绪转为运行,这条折线不断下降直至所有的虚拟用户都转为运行状态,最终变为0。这里一开始就在2和我们前面设置了每5秒生成一个虚拟用户有关系,其中一部分用户先进入就绪状态然后被调到测试中,所以Ready这条线先上后降
finished这条黄色的折线代表已经完成测试的用户数量,随着测试即将结束时也就是Running这条折线逐渐下降的时候,finished折线才不断上升,表明所有的虚拟用户几乎在同一时间完成了测试
**注意:**这里设置的虚拟用户和运行时间是我们一开始设置所以根据你设置的观察
掌握analysis的使用(重要)
生成测试报告,分析测试结果
如何生成测试报告?
首先映入眼帘的是汇总报告,汇总报告包含数据摘要、事务摘要、HTTP响应摘要,其中事务摘要,不要看最大最小值,主要看平均值和标准偏差,标准偏差越大,说明系统越不稳定
图表分析
首先知道下面这两个概念
负载的定义: 比较宽广的概念,涵盖了所有影响系统性能的因素,负载更加泛指系统当前的工作状态,它不仅包括负载量,还包括这些负载对系统资源(如CPU、内存、网络等)的使用情况。例如系统的负载可能包括负载量中的用户数,但也会涉及这些用户所执行的操作对服务器硬件的压力
负载量的定义:负载量是负载的一部分 ,通常是指在特定时间段内系统能处理的工作量(这个"工作"可以是请求数、事务、用户操作等),在性能测试中可以通过负载量衡量系统在特定条件下的性能表现,比如每秒处理请求数、每秒处理的事务数等。也这样理解,负载量是一个用来衡量系统能够处理多少工作的指标
1.运行的虚拟用户图: 通过此图可以观察系统运行期间执行脚本的Vuser数量以及状态,可以确定任何给定时刻服务器上Vuser负载,也就是不同时间点系统能处理的并发用户数
2.点击数图: 通过此图可以观察系统运行期间Vuser每秒向服务器发送的http请求数,根据点击次数对Vuser生成的负载量(可以理解为请求数)来衡量系统能够处理多少请求数进行评估,前面提到点击数也属于是性能指标之一。此图可以搭配平均事务响应图进行比较,查看点击次数对事务性能的影响,因为请求数增加相对的响应时间可能会变长
为什么说统计在特定时间段内所有虚拟用户总共发起的请求数量来评估负载量呢?
可以通过用户总共发起的请求数量,告诉我们系统需要处理多少个请求,也反映了系统的并发处理能力 。如果用户发起的请求数远多于系统能有效响应的数量,这可能指示系统需要优化或增强其处理能力。所以通过负载量帮助我们评估系统在不同压力条件下的性能表现
3.吞吐量图: 通过此图我们可以根据服务器的吞吐量对Vuser生成的负载量进行评估,也可以搭配平均事务响应图进行比较,查看吞吐量对事务性能的影响
4.吞吐量和点击数图: 通过此图可以观察Vuser生成的负载量以及服务器的吞吐量,会发现吞吐量在点击数之后,首先吞吐量表示系统处理请求的数量也可以理解为响应后返回的资源数量,所以得先有请求才有返回
注意:点击量上升了,但是吞吐量没有上升的情况,有很多种可能例如服务器处理请求的速度慢或硬件设备的问题,或者可能没有收到请求出现丢包的可能等等原因
补充一下如何将两张图表设置成一张进行观察,右击后选择对应的图表即可
5.平均事务响应时间图: 通过此图可以观察系统在处理事务时的平均响应时间,可以根据平均响应时间对Vuser生成的负载量进行评估。如果响应时间随着负载增加而显著增加,那么就需要对系统进行性能优化
6.系统资源使用情况图: 通过此图查看系统各项资源的使用情况来衡量系统的性能表现,例如运行时cpu使用率、可用的物理内存等
好了以上便是本章的内容,性能测试的内容很多并且不是短时间就能掌握的起码需要几年时间沉淀,并且性能测试的难点就在于性能分析不好分析以及性能优化的解决方案,我们下一章再见💕