【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之列软件的操作，但是问题就在于结果的分析，因为当我们得出一个报告之后，需要借助图表的知识，或者说需要丰富的经验，才有可能得出恰当的结论。文章来源：https://www.toymoban.com/news/detail-455337.html
一个小白，对着好多个图表，真的有点发懵，因此，学习完LR的基本操作，只能算是一个很小的开始，后面还得继续深入学习。文章来源地址https://www.toymoban.com/news/detail-455337.html
到了这里，关于【Loadrunner】学习loadrunner——Controller与Analysis的使用（三）的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！
