性能测试(三)----loadrunner的使用

Controller:创建运行场景，运行和监控场景，增加虚拟用户数，吞吐量，事务通过率；

1)创建性能测试场景有两种方法:

1.1)在VUG中来针对当前的测试脚本来创建场景

1.2)手动的打开Controller，在Controller里面选择想要进行创建场景的脚本并且添加

2)场景的设置:Degin的页面

2.1)虚拟用户的初始化，在程序秩序执行之前针对每一个用户进行初始化，脚本执行之前，所有用户都进行初始化；

2.2)启动机制:虚拟用户启动机制，down-init-ready-running状态；

2.3)退出机制:虚拟用户退出机制，虚拟用户的退出的机制；

2.4)运行时长的设置:运行脚本的执行时间，性能测试脚本要跑多长时间；

3)查看监控:查看Available Graphs设置展示的图表数，有列表，可以看到各个性能指标

Analysis:分析性能测试结果，可以在Controler进行配置在生成测试报告；

1)测试报告:有事务的一个具体情况，不关注最大值和最小值，只是关心平均值和标准偏差

标准偏差越大，说明系统的性能越差，请求WebTours首页的事务:action事务-login_transaction请求的事务

2)测试报表:运行的虚拟用户，吞吐量(客户端向服务器发送HTTP请求)，点击数(服务器处理完成HTTP请求以后向客户端返回数据)，系统资源的占用情况，还可以将个图表进行合并

平均事务响应时间+响应图是否稳定+事务响应时间是否符合预期+CPU使用时间

+可用的物理内存(已经消耗的物理内存=实际物理内存-可用的物理内存)，实际的物理内存越高，那么消耗的物理内存肯定也比较低

一)Controller的使用:创建场景并执行

1)在VUG中针对写好的脚本创建场景:

 2)手动打开Controller进行脚本的添加并创建场景:

1)直接打开Controller继续进行添加:

选择脚本可以选择一个也可以选择多个

1.2)也可以手动的打开Controller进行脚本的添加和创建场景

点击VUG上面的Tools里面的create Scenario，和打开Controller中的软件系统是上面的

3)针对场景来进行设置:

 Basic schedule:点击这个选项进行设置

可手动修改每个用户组的Quantity来修改并发用户总量

3.1)初始化每一个虚拟用户在运行脚本之前，在脚本执行之前就去初始化所有的虚拟用户；

首先点击虚拟化场景的第一步，是Initialize，双击打开初始化设置弹窗以后，然后就会弹出弹框，表示虚拟化用户，同时虚拟化所有的用户或者是每隔一段时间进行虚拟化用户，或者是在运行之前一个一个的虚拟化用户来执行

3.2)设置启动机制:每隔固定的时间进行启动多少虚拟用户

从start那一栏就可以修改并发用户数 

3.3)设计性能测试脚本的运行时间:

下面是每隔15s启动两个虚拟用户

3.4)设置虚拟用户退出机制:

3.5)看图:

这个场景图表示每隔5S启动一个虚拟用户，最后每隔5S退出一个虚拟用户，程序一共运行的时间是0.2S，从下面的图就可以看到虚拟用户的变化

4)进行运行测试场景:点击下面的run或者是design上面的运行按钮

下面就可以看到虚拟用户在不同状态下面的转变

4.1)当进行点击down的时候，可以发现还没有启动的用户数

下面的这个Reset是让所有的虚拟用户回归到初始状态，也就是未运行状态

 

当前运行的虚拟用户数是多少，运行时间，一共的点击数，出现错误的情况

上面表示性能测试监控的一个状态，蓝色的单词表示可以进行查看的

黑色的数据就是不可查看，没有数据

如果想要在Controller里面进行查看windows系统的资源的图标那么需要进行手动修改配置

1)需要打开任务管理器，找到R对应的服务启动对应的服务

2)打开Controller，选中系统资源图标下面的windows Resource

 3)在下面的空白区域进行右键，选中add Measurements

 4)点击add Measurements之后会弹出以下界面

 5)接下来会出现很多性能监控的指标，可以监控一部分，点击OK

仅仅监控CPU消耗的资源和可用的内存资源，下面图表中只有蓝色的部分可以看到

显示各个监控图标指标的变化:

1)先将下面的列表进行隐藏

2)选择要进行展示的图表的个数:选择想要监控的图表数量

虽然点击了隐藏，但是最终只是显示两个表格

点击右上角的“向下还原”按钮，就可以显示多个图表了

3)最终展示结果:每当我们进行单点击一个监控指标的时候

3.1)在下面的控制台就有相应的数据了，展示资源图的具体详细的内容

3.2)当进行双击的时候，就可以把这个资源图进行放大了

3.3)当我们进行选中下面的四个展示结果的时候，当我们进行双击，上面的资源图的对应的曲线会加粗，就可以看看指标对应的曲线是什么？

分析常见曲线:

1)下面是观看并发用户数，横坐标是程序的执行时间，纵坐标是并发用户数

下面是finished的图型曲线，选中finished会加粗，error表示在程序运行中那些虚拟用户出现了错误，从error里面就可以看到最大运行错误和最小运行错误都是0，就表示没有错误；

1.1)从上面的黄色曲线和蓝色曲线进行交叉可以看出运行的用户不断减少，别忘了看这个

 1.2)点击空白处，可以新进行增加监控指标的图表，进行双击就可以进行添加

在上面的那一段保持运行这三个虚拟用户的状态就是之前在Degin页面中设置的系统稳定运行的时间，超过稳定运行时间以后，会逐渐虚拟用户会退出，finshed代表完成脚本的虚拟用户数，Running代表已经完成的用户，一段时间Running虚拟用户没有迅速退出

也不知道是为什么

 2)HTTP Response per Second这是表示每一秒HTTP响应的数量

黄色的表示HTTP状态码是200的响应数量的变化

蓝色的表示HTTP状态码是500的响应数量的变化

由此可以看出服务都已经被正确的处理了并进行返回了，所以说状态码是正常的

3)下面是每秒事务通过数的一个指标:

下面的四个指标，每一个脚本文件都可以认为是一个事务

3.1)在每秒事务通过数中可以看到途中有三条事务曲线，但是实际上只在action脚本中定义了一个login_transaction，也就是说为什么有三个事务呢？

3.2)LR中认为每一个脚本文件都是一个事务，vuser_init，action，vuser_end三个脚本文件就是三个事务，就是之前在AUG中有三个方法初始化方法，action方法和销毁方法

点击vuser_init的事务运行状态，发现在程序刚刚进行启动的时候不一会就执行完成了，同理vuser_end也是在程序的最后阶段执行一下就退出了，但是action脚本和login+transaction基本是重叠的，action脚本执行的时候肯定包含login_transaction的事务

3.3)可以进行点击每一个事务来查看事务执行状态

4)事务响应时间:

ActionTransaction所做的事情也是非常多的，比如说请求webTours的首页，浏览器进行渲染页面之类的

第一条曲线是Action事务的随时间变化的一个事务响应时间的变化

第二条曲线是loginTransaction事务随时间变化的一个事务响应时间的变化

这两条曲线进行相减就是Action请求WebTours首页的一个响应时间

可以在这里面新增加对应的脚本的虚拟用户数

点击open a New Graph可以新增一些新的监控指标

吞吐量和点击率非常相似，吞吐量指的是客户端发出请求以后，服务器处理完成请求，把响应到客户端的数量；

吞吐率:每一秒服务器接收到的字节数；

点击率:每一次点击发送多次HTTP请求，从下图就可以看到，随着点击率的增加，每一秒钟HTTP请求的数量，吞吐量都在不断地进行增加，如果点击率降低，那么相应的一些字节数，事务相应的数量也会降低，图形和图形之间都有一定的关联关系；如果说吞吐量在某一段时间之内突然达到了一个峰值，这时候就可以观看点击率来进行分析，并发数比较高

还可以看到事务的响应时间，可以看到每一个事务的响应时间，actions里面要做的事情比较多，要请求webtours的首页，还要进行登录，但是整个曲线相对来说比较平稳

响应时间越靠近横轴，性能越高；

设置场景的运行方式:按照场景运行或者是按照组的方式来运行

1)如果来按照场景的方式来运行，无论场景中的脚本数量有多少，所有的脚本统一调度和执行，下面两个脚本的并发用户数之和就是6统一按照Global Schedule的配置方式来运行，就是虚拟用户数的启动方式，退出方式，稳定运行时间配置都是相同，配置都是相同的，当我进行修改配置的时候，修改的是两个脚本的配置

 2)按照Group来进行运行，在不同的脚本场景中有着不同的运行方式，点击上面的ScriptPath就可以根据不同的脚本来设置不同的运行场景了，比如说虚拟用户个数，虚拟用户的启动方式

3)总结:

第一个区域:显示场景中给每一个脚本组的虚拟用户的运行状态，运行状态的变化

第二个区域:是控制场景的运行和显示当前场景的运行状态，运行还是退出，出现的错误是多少，点击率一些信息等等

第三个区域:显示当前可以查看的监控数据，是蓝色的

第四个区域:主要显示第三个区域中可供查看的资源的实时情况最终展现的是一个一个的图标

第五个区域:主要展示资源图上面的各种详细的资料和内容，最大值最小值和平均值

二)Analysis的使用:

1)生成测试报告:

1)先将Controller中的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%-85%，也就是常见的CPU使用率，可以通过任务管理器进行查看，最好进行优化，看看是从硬件方面优化还是软件方向上进行优化；

2)Available Mbytes:可用的物理内存

计算式已经消耗的物理内存=实际内存-可用的物理内存；

可用的物理内存越高，说明消耗的物理内存也越少 

也就是说这个Available Mbytes的曲线越高，那么进行消耗的物理内存肯定也是越低的

了解性能测试的基本概念，了解常见的性能测试指标，并且可以进行一些简单的性能测试