【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.系统资源使用情况图

1. processor Time
   CPU使用时间。被消耗的处理器时间数量，服务器专用于可接受的最大上限一般是80%~85%，也就是常见的CPU使用率。
2. Available Mbytes
   可用的物理内存。已经消耗的物理内存:实际内存-可用的物理内存

---

3.一点感想

学习完loadrunner的基本操作之后，最大的感想就是性能测试不一般，学的时候，感觉就是很基本的操作，有点像学习word、excel之列软件的操作，但是问题就在于结果的分析，因为当我们得出一个报告之后，需要借助图表的知识，或者说需要丰富的经验，才有可能得出恰当的结论。

一个小白，对着好多个图表，真的有点发懵，因此，学习完LR的基本操作，只能算是一个很小的开始，后面还得继续深入学习。