性能测试(三)----loadrunner的使用
Controller:创建运行场景，运行和监控场景，增加虚拟用户数，吞吐量，事务通过率；
1)创建场景:
1.1)在VUG中来针对当前的测试脚本来创建场景
1.2)手动的打开Controller，在Controller里面选择想要进行创建场景的脚本
2)场景的设置:
2.1)虚拟用户的初始化，在程序秩序执行之前针对我们的每一个用户进行初始化
2.2)启动机制:虚拟用户启动机制
2.3)退出机制:虚拟用户退出机制
2.4)运行时长的设置:运行脚本的执行时间
3)查看监控:查看Available Graphs，看到具体的图标，有列表，可以看到各个性能指标
Analysis:分析性能测试结果，生成测试报告；
1)测试报告:有事务的一个具体情况，不关注最大值和最小值，关心平均值和标准偏差
标准偏差越大，说明系统的性能越差；
2)测试报表:运行的虚拟用户，吞吐量，点击数
一)Controller的使用:
1)在VUG中针对写好的脚本创建场景:
2)手动打开Controller进行脚本的添加并创建场景:
点击完成之后直接打开Controller所在的组件
3)针对场景来进行设置:
Basic schedule:点击这个选项进行设置
可手动修改每个用户组的Quantity来修改并发用户总量
3.1)初始化每一个虚拟用户在运行脚本之前，在我们的脚本执行之前就去初始化我们所有的虚拟用户；
3.2)设置启动机制:每隔固定的时间进行启动多少虚拟用户
从start那一栏就可以修改并发用户数
3.3)设计性能测试脚本的运行时间:
3.4)设置虚拟用户退出机制:
3.5)看图:
这个场景图表示每隔5S启动一个虚拟用户，最后每隔5S退出一个虚拟用户，程序一共运行的时间是0.2S
4)进行运行测试场景:点击下面的run或者是design上面的运行按钮
下面就可以看到虚拟用户在不同状态下面的转变
下面的这个Reset是让所有的虚拟用户回归到初始状态，也就是未运行状态
上面是点击率和吞吐量
上面表示性能测试监控的一个状态，蓝色的单词表示可以进行查看的
黑色的数据就是不可查看，没有数据
如果想要在Controller里面进行查看windows系统的资源的图标
那么需要进行手动修改配置
1)需要打开任务管理器，启动对应的服务
2)选中系统资源图标下面的windows Resource
3)在下面的空白区域进行右键，选中add Measurements
4)点击add Measurements之后会弹出以下界面
5)点击OK
显示各个监控指标的变化:
1)先将下面的列表进行隐藏
2)选择要进行展示的图表的个数:选择想要监控的图表数量
3)最终展示结果:每当我们进行单点击一个监控指标的时候
3.1)在下面的控制台就有相应的数据了，展示资源图的具体详细的内容
3.2)当我们进行双击的时候，就可以把这个资源图进行放大了
3.3)当我们进行选中下面的四个展示结果的时候，当我们进行双击，上面的资源图的对应的曲线会加粗，就可以看看指标对应的曲线是什么？
分析常见曲线:
1)下面是观看并发用户数，横坐标是程序的执行时间，纵坐标是并发用户数
下面是finished的图型曲线
1.1)从上面的黄色曲线和蓝色曲线进行交叉可以看出运行的用户不断减少，别忘了看这个
1.2)点击空白处，可以新进行增加监控指标，进行双击就可以进行添加
2)下面我们来进行观看一下
HTTP Response per Second这是表示每一秒HTTP响应的数量
黄色的表示HTTP状态码是200的响应数量的变化
蓝色的表示HTTP状态码是500的响应数量的变化
由此可以看出，我们的服务都已经被正确的处理了并进行返回了，所以说状态码是正常的
3)下面是每秒事务通过数的一个指标:
下面的四个指标，每一个脚本文件都可以认为是一个事务
3.1)在每秒事务通过数中可以看到途中有三条事务曲线，实际上只在action脚本中定义了一个login_transaction；
3.2)LR中认为每一个脚本文件都是一个事务，vuser_init，action，vuser_end三个脚本文件就是三个事务；
3.3)我们可以进行点击每一个事务来查看事务执行状态
4)事务响应时间:
ActionTransaction所做的事情也是非常多的，比如说请求webTours的首页，浏览器进行渲染页面之类的
第一条曲线是Action事务的随时间变化的一个事务响应时间的变化
第二条曲线是loginTransaction事务随时间变化的一个事务响应时间的变化
这两条曲线进行相减就是Action请求WebTours首页的一个响应时间
我们可以在这里面新增加对应的脚本的虚拟用户数
场景的运行方式:
1)如果我们来按照场景的方式来运行，无论场景中的脚本数量有多少，所有的脚本统一调度和执行，下面两个脚本的并发用户数之和就是6统一按照Global Schedule的配置方式来运行
2)按照Group来进行运行，在不同的脚本场景中有着不同的运行方式
3)总结:
二)Analysis的使用:
1)生成测试报告:
1)先将results中的Auto load Analysis和Auto Collate Results进行勾选，在Controller中勾选上自动化分析性能测试并自动生成测试报告
2)当我们的脚本在指定场景规则下执行完成，就会自动地打开analysis组件并展示测试报告和测试结果
3)在Controller中将我们的场景运行完成之后，进行点击ctrl+s，来进行保存
4)当我们的程序自动地打开Analysis之后，再次点击ctrl+s进行保存:保存analysis文件
5)打开测试报告:
1)这里面的Std.Deviation表示标准方差，表示如果这个值越小，说明事务运行越稳定，标准偏差
2)不要看最大值和最小值，要看平均值和标准偏差，如果标准偏差的值越大，说明越不稳定，如果标准偏差的值越小，说明越稳定
2)分析测试报表:
2.1)运行的虚拟用户图:显示并发用户数
1)显示性能测试的每一秒的期间执行的Vuser脚本的Vuser数量及其状态
可以通过此图可用于确定任何给定时刻的服务器上面的Vuser负载
2)就可以有效地看出哪一个时刻服务器的压力更大，负载数更多
2.2)点击率:1)显示的是我们在性能测试场景期间内，虚拟用户给WEB服务器在每一秒内给WEN服务器发送的HTTP请求的数量；
2)点击数越大，发送的HTTP请求的数量就越高
3)看看点击量增大的时候，吞吐量有没有增大，一般来说，点击率增加，吞吐量也会增加
4)显示性能测试场景中运行期间的每一秒内向HTTP服务器请求数量，帮助我们根据点击次数对Vuser生成的负载量进行评估，可以将此图和平均事务响应时间的图进行比较，查看点击次数对于事务的影响，因为请求数量增多可能会导致响应时间会变长
5)点击空白处，进行右键:
最后就会生成这个:
2.3)吞吐量:吞吐量的图表示的是负载测试场景中每一秒服务器的吞吐量，以字节为单位
此图可以帮助我们根据服务器的吞吐量对Vuser生成的负载量进行评估，对平均事务的响应时间图进行比较，吞吐量对于事务性能的影响
一)我们的点击率图和吞吐量的图是非常相似的，但是为什么吞吐量的图会稍微滞后一点？
点击数是向HTTP服务器发送请求，而吞吐量表示的是服务器把响应返回给客户端，所以肯定是先请求再响应，因为吞吐量表示的是相应返回之后的资源数量肯定是先有请求，再有返回
二)如果说点击数或者请求变多，但是吞吐量没有什么反应，可能的原因是什么？
2.1)服务器在压力增大的时候，响应速度变慢，来不及响应，导致吞吐量降低
2.2)压力没有到服务器被拦截下来了
2.3)服务器设计了一定的阈值，超过多少了请求就不进行返回响应了，有的服务器为了避免大量的并发导致服务器宕机，直接影响线上服务器的一个使用情况，所以可以在服务器后端设置阈值，可以给用户返回一个服务器繁杂，收到请求直接return;
三)这就是说为什么性能测试比较难，难就难在性能分析，每一个曲线的走向都是需要严格的分析的，有可能是运维的问题，也有可能是一些中间件的问题，还有是架构的选择，不同的系统可能的情况还不一样，需要具有丰富的性能测试经验
四)性能分析的知识面太广:
操作系统性能分析还有调优，CPU，磁盘，网络，进程线程并发，IO操作
JVM性能分析及其调优，JAVA内存分析，JAVA线程诊断
TCP/IP，UDP，连接数，长连接，短链接等等
2.4)平均事务响应时间:
这个图主要显示Vuser性能测试过程中每一秒期间在服务器上面的命中次数，可以帮助我们根据命中次数来进行评估Vuser生成的负载量
主要查看:
1)响应图是否是稳定的
2)查看事务响应时间是否达到了预期
3)也要查看标准方差和平均值
2.5)如果想要查看更多图标，可以右键进行打开:
2.6)系统资源使用情况图:
1)processor Time:CPU使用时间，也就是被消耗的处理器时间数量
服务器可接受的CPU使用最大上限是80%-50%，也就是常见的CPU使用率，可以通过任务管理器进行查看，最好进行优化，看看是从硬件方面优化还是软件方向上进行优化；
2)Available Mbytes:可用的物理内存
计算式已经消耗的物理内存=实际内存-可用的物理内存；
可用的物理内存越高，说明消耗的物理内存也越少
也就是说这个Available Mbytes的曲线越高，那么进行消耗的物理内存肯定也是越低的
了解性能测试的基本概念，了解常见的性能测试指标，并且可以进行一些简单的性能测试
