文章目录
- 1.controller的使用
- 1.1.创建场景的方式
- 1.2.页面的介绍
- 1.3.场景的设置
- 1.2.1.设置初始化
- 1.2.2.设置启动机制
- 1.2.3.设置性能测试脚本的执行时间
- 1.2.4.设置虚拟用户推出机制
- 1.3.场景的运行
- 1.4.场景的运行方式
- 1.4.1.按照场景的方式运行
- 1.4.2.按照group运行
- 2.analysis的使用
- 2.1.生成测试报告
- 2.2.测试报告
- 2.3.测试报表
- 2.3.1.运行的虚拟用户图
- 2.3.2.点击数图标
- 2.3.3.吞吐量图
- 2.3.4.吞吐量-点击图
- 2.3.5.平均事务响应图
- 2.3.6.查看更多图表的方法
- 2.3.7.系统资源使用情况图
- 3.一点感想
【Loadrunner】学习loadrunner——性能测试基础篇(一)
【Loadrunner】学习loadrunner——性能测试基础篇VUG的使用(二)
了解了脚本是如何写的之后,我们继续学习loadrunner的另外两个组件的使用。
1.controller的使用
1.1.创建场景的方式
1)在VUG中对写好的脚本创建场景
2)手动打开controller进行脚本的添加并创建场景
1.2.页面的介绍
进入到页面之后,有以下场景,
1.3.场景的设置
进入到页面之后,下面讲解四个重要的功能
1.2.1.设置初始化
1.2.2.设置启动机制
1.2.3.设置性能测试脚本的执行时间
1.2.4.设置虚拟用户推出机制
这里需要提一下的是,每当我们修改上面的选项的时候,我们右边的图形也会发生相应的变化:
1.3.场景的运行
点击下图红框处会出现以下页面(会英文很重要)
如果需要查看系统资源图标,需要手动修改配置
1)打开任务管理器,启动对应的服务器
2)开启场景
开启之后运行,运行完成结果如下:
下面对一些场面进行解释:
1.4.场景的运行方式
1.4.1.按照场景的方式运行
不论场景中的脚本数量有多少,所有的脚本统一调度和运行
1.4.2.按照group运行
这个方式场景中有各自设计的运行方式
2.analysis的使用
2.1.生成测试报告
在controller中勾选上自动化分析性能测试并自动生成测试报告。当我们的脚本在指定的场景规则下执行完成,会自动的打开analysis组件并展示测试报告和测试结果。
2.2.测试报告
生成的测试报告长这个样子:
我们都知道,比赛一般都会剔除最大值与最小值,这里也是如此,我们看测试报告主要看平均值和标准偏差,标准偏差越大,说明越不稳定。
2.3.测试报表
2.3.1.运行的虚拟用户图
显示性能测试的每秒期间执行Vuser脚本的Vuser数量及其状态。通过此图可用于确定任何给定时刻的服务器上Vuser负载
2.3.2.点击数图标
显示性能测试场景中运行期间的每一秒内http向服务器发送的HTP请求数。帮助我们根据点击次数对Vuser生成的负载量进行评估。
可以将此图与“平均事务响应时间”图进行比较,查看点击次数对事务的影响。请求数量增多的话响应时间可能会变长。
2.3.3.吞吐量图
此图可以帮助我们根据服务器吞吐量对Vuser生成的负载量进行评估,对平均事务响应时间图进行比较,分析吞吐量对事务性能的影响。
2.3.4.吞吐量-点击图
这个图需要先合并:
吞吐量图和点击数图形状非常相似,但是吞吐量图会稍微滞后一点,这是为什么?
因为吞吐量表示的是响应后返回的资源数量,肯定是先有请求再有返回!
如果请求变多但是吞吐量没有什么反应,可能原因是什么?
1)服务器响应慢了,来不及响应。
2)压力没有到服务器
3)服务器设计一定的阙值,超过多少请求就不返回响应。
2.3.5.平均事务响应图
此图显示Vuser在性能测试的每秒期间在服务器上进行的命中次数。可以帮助根据命中次数评估Vuser生成的负载量。
主要查看:
1)响应图是否稳定
2)查看事务响应时间是否达到了预期。
2.3.6.查看更多图表的方法
2.3.7.系统资源使用情况图
- processor Time
CPU使用时间。被消耗的处理器时间数量,服务器专用于可接受的最大上限一般是80%~85%,也就是常见的CPU使用率。 - Available Mbytes
可用的物理内存。已经消耗的物理内存:实际内存-可用的物理内存
3.一点感想
学习完loadrunner的基本操作之后,最大的感想就是性能测试不一般,学的时候,感觉就是很基本的操作,有点像学习word、excel之列软件的操作,但是问题就在于结果的分析,因为当我们得出一个报告之后,需要借助图表的知识,或者说需要丰富的经验,才有可能得出恰当的结论。
一个小白,对着好多个图表,真的有点发懵,因此,学习完LR的基本操作,只能算是一个很小的开始,后面还得继续深入学习。