02-LoadRunner

loadrunner性能测试

Web性能测试常用指标：

1.响应时间：2-5-8原则

2.吞吐量：单位时间客户端与服务端传递数据量

3.每秒点击数：每秒请求数

4.并发用户数：正在同时操作的用户数

5.资源使用率：CPU占比、网内存消耗、磁盘I/O、络I/O

安装破解完成之后，主要有三个application

按照适用顺序依次为：Virtual User Generator(VU Gen) ——Controller——Analysis。

1.Virtual User Generator(VU Gen) 脚本（单用户）

1- 脚本录制

Web脚本录制：选择脚本协议(web-Http-Html)——设置录制参数——进行页面操作录制——生成脚本和页面截图

APP脚本录制：安装一个path.4的补丁插件先，否则找不到协议——创建一个WIFY热点供手机连接——选择较本协议(Mobile App-Http-Html)——设置录制选项

开始在手机上操作录制脚本——或者用WireShark抓包工具检测数据包然后导进来转换成脚本

Java编写脚本：安装JDK1.6配置Path——选择脚本协议(Java Vuser)——开始编写脚本

2- 脚本回放 ：验证脚本是否正常运行——运行时设置迭代次数(根据需求定十次票)、迭代次数之间的时间间隔、运行日志显示——关联设置(防止动态ID，回放失

败，录制时一个ID，回放时又是另一个ID值)

3- 增强脚本 ：设置事务(函数)——参数化(设置参数名，添加参数值，迭代一次取一个值)——添加断言(选中页面元素设置断言，脚本中自动生成断言函数)——

错误处理函数(回放错误继续执行函数，暂停函数等)——设置集合点(虚拟用户同时出发一个事务，特殊的并发)

2.Controller负载运行 （多用户）

1- 场景设计

手工场景：单个脚本——设置并发虚拟用户数——设置虚拟并发用户运行(开始、结束)方式(同时并发还是时间间隔阶梯式并发)

多个脚本——scenario:多个脚本按照的场景统一执行

group:多个脚本各自独立设计场景，个脚本之间间隔时间设置

目标场景：设置一个结果目标，有5种目标类型设置，Controller进行自动化负载，输出结果达标则通过——1.并发虚拟用户数、2.每秒请求数、3.每秒事务数、

4.事务的相应时间、5.每分钟页面的刷新次数

2- 运行模式 ：实际计划-设置场景运行时的时间延迟等，等一段时间再开始负载运行-定时器

基本计划-只能在开始设置一次

3- 负载生成器 ：运行脚本的负载引擎，生成虚拟用户进行负载，默认情况下使用本地的负载生成器，

每一个虚拟用户会花费负载生成器2-3M内存，太消耗内存，可以在多台电脑上生成负载生成器，每台电脑虚拟一定的用户，采用分布式集合调用在

主机上

4- 负载运行设置 ：设置迭代次数、迭代间隔时间

5- 运行负载 ：性能资源监测、系统资源监测

3.Analysis测试指标分析

 

LoadRuner性能指标分析

LoadRunner性能分析：

1.    AverageTransaction Response Time(平均事务响应时间)：是性能 测试 中最直观的指标，反应随着时间的变化事务响应时间的变化情况，时间越小说明处理的速度越快，如果和用户的负载生成图合并，就可以分析用户负载增加对系统事务响应时间的影响规律。

2.    TransactionPer Second：TPS，每秒处理的事务数，直接反应服务器服务器的处理能力。TPS值越大，说明服务器处理的能力就越强。

3.      Transactions Summary（事务概要说明）统计事物的Pass数和Fail数，了解负载的事务完成情况。通过的事务数越多，说明系统的处理能力越强；失败的事务数越小说明系统越可靠。

4.      Transaction performanceSummary(事务性能概要)：事务的平均时间、最大时间、最小时间柱状图，方便分析事务响应时间的情况。柱状图的落差越小说明响应时间的波动小，如果落差很大，说明系统不够稳定。

5.      HTTP Responses per Second（每秒HTTP响应）：每秒服务器返回各种状态的数目，一般和每秒点击量相同。点击量是客户端发出的请求数，而HTTP响应数是服务器返回的响应数。如果服务器的响应数小于点击量，那么说明服务器无法应答超出负载的连接请求。

6.      Connections per Second（每秒连接）：统计终端的连接和新建的连接数，方便了解每秒对服务器产生连接的数量。同时连接数越多，说明服务器的连接池越大，当连接数随着负载上升而停止时，说明系统的连接池已满，通常这时候服务器会返回504错误。需要修改服务器的最大连接来解决该问题。

7.      Hits per Second（每秒点击）：每秒用户向服务器提交HTTP请求数，反应的是客户端侧的问题：网络或脚本等出现问题。如果每秒点击数比较小则说明客户端侧出现问题，可以从网络和脚本方面分析。

8.      Throughput（吞吐量）：系统负载下所使用的带宽，该数据越小说明系统的带宽依赖就越小，通过这个数据可以确定是不是网络出现了瓶颈。反应的是一次性能测试过程中，网络上传输的数据量总和，不能直接以吞吐量大小来判断性能 。

上有一篇讲解了性能的重要指标代表什么，下面对LoadRunner性能 测试 结果分析思路做一下介绍：

性能测试结果分析思路：

1.      关注Transaction Summary模块

平均响应时间：当标准差std比较小的时候，选择事务平均响应时间

90%响应时间：当标准差比较大时，可以考虑90%响应时间

Std:标准差比较小，则相对比较平稳，标准差比较大时，浮动比较大

分析事务响应时间，因为响应时间是最直观的指标，查看业务中哪个事务的响应时间有问题，然后接下来对该事务进行具体分析。

2.      根据Vusers中的用户负载生成图分析：如果较多用户未通过，说明脚本或场景设置有问题，如果只有一个或少部分虚拟用户运行正常则有可能是脚本出现问题。比如图中出现用户突然猛的下降等，则不必往后分析，需要修改脚本或者场景。

3.      分析错误统计图和每秒错误统计图

根据错误统计图有时候可以一次定位到问题，有时候只能猜测大概出现在哪个部位。

根据每秒错误统计图可以定位哪一段时间内出现错误比较多

4.      分析事务：

1)     平均事务响应时间：查看哪个事务的平均响应时间响应比较对，对这些事务做标记，然后针对这些事务找出突破口，进行下一步分析

2)     关注TPS:看成功的事务和失败的事务以及TPS的大小：成功的事务越多说明服务器的处理能力越强，失败的事务越小说明系统越可靠。TPS值越大说明服务器处理能力越好，如果值比较小，后期要进行调优。

5.      分析web resources（网络资源统计图）:

1)     首先分析一下Hits Per Second（每秒点击数）：每秒客户端向服务器发送的HTTP请求数，直接反应客户端侧的问题，如果该值比较低，从脚本和网络上分析问题。

2)     分析一下Connections（连接数）：当该值比较低的时候，要对连接数进行调优。当该值比较大，说明服务器连接池越大。

3)     分析一下每秒连接数：统计关闭的连接数和新建的连接数，方便了解每秒对服务器产生的连接数。当随着用户负载的增加连接数而终止，说明系统的连接池已满。需要修改服务器最大连接数的配置来解决问题。

6.      分析web page Diagnostics(网页分析)：

1)     看网页细分图，可以先从First Buffer Time的分解统计图入手，看是网络问题还是服务器问题

2)     继续分析页面组件细分图：根据平均响应时间判断到底是网页上哪个文件或图片出现问题

3)     根据页面下载时间分解图：可以看出每个资源加载的时间，根据平均时间再次判断哪些资源出现问题

4)     根据下载组件的大小分解图：可以看出每个资源的大小，再根据大小判断资源内部是否有问题等。

7.      分析系统资源统计图（System resuorces）:

1)     查看系统资源的情况：关注CPU、IO、内存、队列等重要指标

2)     如果CPU使用率很大，且PQL排队等待CPU的队列比较大，则说明本身服务器资源使用瓶颈烦的，硬件处理能力有待提高