LoadRunner 11 中Analysis分析

原文:http://www.cnblogs.com/Chilam007/p/6445165.html

analysis简介

分析器就是对测试结果数据进行分析的组件，它是LR三大组件之一，保存着大量用来分析性能测试结果的数据图，但并不一定要对每个视图进行分析，可以根据实际情况选择相关的数据视图进行分析，分析结果可以生成一些不同格式的测试报告。

一、设置选项

analysis中的数据是怎么得到的呢？其实在场景运行的时候，默认情况下，所有的vuser信息都保存在该vusr的负载机上。只有当场景运行结束后，这些数据才会自动进行整理或合并，这时负载机上所有vuser的信息和数据都将被传输到结果目录中。默认情况下，在controller控制器中，results->auto collate results是被选中的，也就是说默认情况下，当场景运行结束后，这些数据会被自动整理或合并。但当没有选中这项时，场景运行结束后，可以在controller控制器中选择results->collate results 进行手动整理。

在进行数据视图分析前，有必要将分析图中涉及的一些选项加以设置，过滤掉不需要的数据，方便对数据进行分析。

下面介绍一些常用的设置选项：

1、结果目录设置

在controller控制器中选择results->results setting，如图1所示：

a.每执行一次场景都生成一份结果文件，结果文件的命名方式为res后接一个序号（如res0），每执行一次序号依次加1；

b.每执行一次场景，将执行后的结果覆盖以前的结果。（为了防止意外发生，一般会选择第一种结果保存方式）。

图1（结果目录设置）

2、result collection设置

在LR处理这些数据时，可以查看这些数据的摘要，具体怎样查看摘要数据，需要在result collection选项中进行设置，如图2所示：

图2

data source：

a.表示仅查看摘要数据。如果选中该选项，那么analysis还会处理数据以用于筛选和分组等高级用途。且data aggregation项是不可以设置的。

b.表示仅查看经过处理的完整数据，但是不显示摘要数据。

c.表示在处理完整数据时，查看摘要数据。

data aggregation：

a.表示使用内置数据聚合公式聚合数据，以优化性能

b.表示使用内置数据聚合公式仅仅聚合与web相关的数据

c.表示用户自定义来设置聚合数据，如图3所示：

aggregate data (available only for complete data)：用于设置聚合数据的类型，这里只适用于完整数据，可以选择需要聚合数据的图的类型，这样可以减小数据库的容量。

select the graph properties to aggregate：指定要聚合的图属性。

web data aggregation only：表示仅聚合web的数据，在这里可以设置聚合的粒度。

图3

3、configure measurements 设置

在分析图时，发现分析图的Y轴幅值过小时，就可以在这里进行设置，对Y轴进行适当的放大或缩小操作，如图4所示：

a.手动设置一个比例值；b.使用优化的自动比例来显示图中每个度量；c.将图中所有度量比例都设置为1；d.查看所有度量的趋势。

默认值 为1，即按原始比例进行显示，有时波形显示的幅值太小，那么就需要适当地调整放大比例。

图4

4、设置筛选条件

如图5所示：在录制测试脚本过程中，如果执行脚本时没有忽略think time时间，那么analysis分析器在统计分析结果时会把think time包含进去，这样当think time存在于用户事务的开始与结束之间时，相关事务统计情况会受到影响。因此，很多时候需要过滤用户的思考时间，在下拉框中删除include think time选项即可，分析结果中就会自动滤掉思考时间。

图5

二、analysis图

analysis分析器中提供了丰富的分析图，如图6所示：

常见的有8类：

1）vuses图：在方案执行过程中，vuser在执行事务时生成数据。使用vusers图可以确定方案执行期间vuser的整体行为。它显示vuser状态和完成脚本的vuser的数量。主要包括正在运行的vuser图和vuser摘要图

2）错误图：主要统计方案执行时的错误信息。主要包括error statistics(by description)、error per second(by description)、error statistics和error per second四种图。

3）事务图：描述了整个脚本执行过程中的事务性能和状态。主要包括平均事务响应时间图、每秒事务数图、每秒事务总数、事务摘要图、事务性能摘要图、事务响应时间（负载下）图、事务响应时间（百分比）图和事务响应时间（分布）图。

4）web资源图：主要提供有关web服务器性能的一些信息。使用web资源图可以分析方案运行期间每秒点击次数、服务器的吞吐量、从服务器返回的HTTP状态代码、每秒HTTP响应数、每秒页面下载数、每秒服务器重试次数、服务器重试摘要、连接数和每秒连接数。

5）网页细分图：主要提供一些信息来评估页面是否影响事务响应时间。包括网页细分、页面组件细分、页面组件细分（随时间变化）、页面下载时间细分、页面下载时间细分（随时间变化）和已下载组件图

6）系统资源图：主要监控场景运行期间系统资源使用率的情况。可以监控windows资源、UNIX资源、SNMP资源、Antara Flame Thrower资源和SiteScope资源

7）web服务器资源图：主要用来捕捉场景运行时web服务器的信息。主要用来分析microsoft IIS服务器、apache服务器、iplanet/netscape服务器和iplanet(SNMP)服务器。

8）数据库服务器资源图：主要显示数据库服务器的统计信息。目前支持DB2、oracle、sql server和sybase数据库。

图6

摘要报告

一、概要部分

二、统计部分

三、事务统计部分

第一行统计场景运行时所有事务通过、失败、停止的数量。而表格里则是显示了所有事务执行时的详细信息：

1）transaction name（事务名）；2）minimum（事务运行的最短时间）；3）average（事务运行的平均时间）；4）maximum（事务运行的最长时间）；

5）std.deviation（标准方差）：方差描述一组数据偏离其平均值的情况，方差值越大，说明这组数据就越离散，波动性也就越强；反之，则说明这组数据就越聚合，波动性也就越小；

6）90 percent：在controller运行场景时，并不会显示这个值，因为它是对整个一系列数据统计的结果。表示一个事务在执行过程中的90%所花费的时间，比如，一个事务执行了100次，对这100次事务响应时间进行升序排序，第90%即90次事务运行时间；

7）pass（通过的事务个数）；8）fail（失败的事务个数）；9）stop（停止的事务个数）：在执行场景时，若用户手工停止场景的执行，事务没有自己的状态，那么就是停止状态。

注：事务的通过率一定要大于95%，也即失败率应该小于5%，因为如果事务失败率过高，就说明客户在使用系统时很容易出现错误，这样无论事务响应时间多么短也是不符合要求的，因为客户最基本的需求都没有被满足，功能都不能正确的处理，那么更无法谈性能了。

四、SLA

SLA（service level agreement，服务水平协议）可在性能测试过程中，定义性能测试的目标和度量性能，在性能测试过程中LR会收集和保存性能的相关数据，在分析运行结果时，分析器分将收集的数据与SLA中定义的度量数据进行比较，并将分析结果显示在分析器中，SLA三种状态分别是：

a.pass：表示SLA获得该项测试数据，并且该数据达到目标要求；b.fail：表示SLA获得该项测试数据，但是测试结果未达到目标要求；c.no data：表示SLA未获得该项测试数据，所以无法确定是通过还是失败。

SLA配置步骤如下：

1、在摘要视图中单击如图7所示的按钮：

图7

2、单击new，定义SLA目标，如图8所示：

图8

3、设置待度量的目标。这里以事务响应时间为例，如图9所示。

关于事务响应时间的目标有两种方式，一种是按百分比来度量（即设置百分之多少的事务响应时间不能超过目标时间）；另一种是按平均事务响应时间来度量。等下依次介绍这2种方式。

图9

4、选择事务。（注：在脚本中一定要插入事务，否则在该步选择事务时，无法选择待度量的事务），如图10所示：

图10

5、设置百分比阈值。如果是以百分比模式来度量事务响应时间时，如图11所示：

图11

该步骤需要设置好百分比和事务响应时间阈值，设置的百分比为90%，事务响应时间为2s，即是只要90%的事务响应时间不超过2s，那么SLA的报告结果即为PASS，否则结果为FAIL。如图12所示。

图12

百分比模式，可以在analyze transaction按钮进入分析事务界面，查看详细的分析信息，如图13所示：

图13

下面讲一下按平均事务响应时间来度量：

1、设置负载标准。如果选择按平均事务响应时间来度量，则如图14所示：

选择负载标准，即通过什么指标来衡量事务响应的变化情况，以运行的虚拟用户数为例，需要设置在不同运行虚拟用户数下事务的响应时间。

图14

2、设置阈值。

选择好负载标准后，需要设置在不同的负载标准情况下，事务响应时间情况，这里即需要设置在不同运行虚拟用户下事务的响应时间情况，如图15所示。

设置为当虚拟用户数少于10个时，事务响应时间应该不超过1s，当虚拟用户数大于10个时，事务响应时间不超过1.5s。

图15

设置到这里就已经全部完成了，可以看出 SLA从本质上来说它是一种目标，是一种度量测试结果是否达到目标的一种手段，与目标场景的设置很相似，原理几乎一致。

完成SLA设置后，在分析器中会显示出每个度量事务在不同时间域中的结果表现，如图16所示：

图16

在此可以选择不同事务、不同时间域进行详细的分析，以查看机票信息为例进行分析，单击analyze transaction按钮分析器会显示出该事务的详细信息，详细分析信息主要包括事务摘要信息、事务相关、错误信息和快照视图。

1）事务摘要信息

2）事务相关联信息（主要包括显示分析事务时可能需要关联的相关信息：脚本运行时的一些错误信息、系统资源消耗情况、web资源消耗情况和数据库资源消耗情况。）

注：我的报告中只显示了web资源消耗情况，其实还有上面所提到的其他几种信息的。

3）错误信息（主要显示整个场景运行过程中出现的错误信息，这在与场景运行过程中产生的错误输出信息类似。详细地记录了错误的类型、错误代码、事务名称、脚本、错误代码行数、运行过程中哪个虚拟用户出错 等一些相关的信息）。

注：因我的脚本运行过程中没有错误，所以在报告中就没有显示错误信息，可自己去操作看一下。

4）快照视图（主要是描述分析的时间域中事务响应时间的情况），如图17所示。

横坐标表示场景执行的时间，纵坐标表示事务响应时间，图中有3条曲线，红色的表示场景运行时的虚拟用户数，绿色为场景运行时事务的响应时间，黑色表示SLA定义的阈值。如果绿色的线超过了黑色线则说明该点的SLA失败，那么SLA的状态将会置为失败。反之则成功，SLA的状态将置为通过。

图17

注：按百分比模式与按平均模式的结果显示会有点不同，具体可自行操作分析。

五、HTTP响应统计

HTTP是一种通信协议，它允许将超文本标记语言（HTML）文档从web服务器传送到web浏览器。HTML是一种用于创建文档的标记语言，这些文档包含到相关信息的链接。可以单击一个链接来访问其他文档、图像或多媒体对象，并获得关于链接项的附加信息。（关于HTTP请求响应机制与HTTP响应状态码的含义，可自行百度，这里就不说了。）

analysis常见图分析

在LR分析器中对资源使用的情况分析得很少，因为通常在性能测试过程中很少使用LR来监控系统资源的使用，特别是UNIX、LINUX和ALX操作系统，几乎不使用LR来监控，更多的是借助第三方工具来监控，当然如果服务器是windows操作系统，那么使用LR进行监控比较简单。

一、vuser图

它显示vuser状态和完成脚本的vuser的数量。将这些图与事务图结合使用可以确定vuser的数量对事务响应时间产生的影响。

X轴表示从方案开始运行以来已用的时间，Y轴表示方案中的vuser数，vuser图显示在测试期间的每一秒内执行vuser脚本的vuser数量及其状态。可以帮助确定任何给定环境中服务器上的vuser负载。默认情况下，此图仅显示为running的vuser。

二、点击率图

显示在方案运行过程中vuser每秒钟向web服务器提交的HTTP请求数。借助此图可以依据点击次数来评估vuser产生和负载量。一般会将此图与平均事务响应时间图放在一起进行查看，观察点击数对事务性能产生的影响。X轴表示方案从开始运行以来所用的时间，Y轴表示服务器上的点击数。

注意：点击率并不能衡量服务器的真实处理能力，也不能仅仅通过点击率来衡量服务器的处理能力，因为服务器即使出现 了瓶颈也还会影响到这个值的变化，因为LR其实也是一个代理录制的工具，将录制过程中提交的请求录制成脚本，在回放时模拟用户重新提交这些请求，那么在提交的时间LR可以对HTTP请求进行统计，进而生成点击率视图。但是这并不代表LR画出来的点击率视图一定正确，假如客户端实际提交的HTTP请求为2000个/s，但点击率视图画出来的值为1000个/s，这说明客户端提交的请求根本就没有完全发送到服务器，那么这种情况最有可能是在网关处请求出现超时，因为每个网关端口都有一个允许其访问的最大值，当这个值过大时，网关也会出现排队现象，如果队列过长就会导致一些请求出现超时现象，最后导致统计出来的点击率的值不正确。

三、平均事务响应时间图

显示方案在运行期间执行事务所用的平均时间。X轴表示从方案开始运行以来已用的时间，Y轴表示执行每个事务所用的平均时间（s）。平均事务响应时间最直接地反映了事务的性能情况，一般会将平均事务响应时间图与vuser图对照着看，来观察vuser运行对事务性能的影响。可以右键选择show transaction breakdown tree查看子事务或者所有的事务每个页面所花费的时间。

平均事务响应时间图直接反映系统的性能情况，这也是客户眼中的性能，在需要时必须明确地定义好业务的响应时间，在分析时一般先分析的响应时间，当平均事务响应时间符合定义时，也仅仅说明响应时间能达到要求，但是此时并不代表系统达到客户要求，因为LR统计出来的事务响应时间不一定正确，所以当事务响应时间达到要求后，也一定要分析一些其他的数据，需要确定的是业务是否都做成功了，如果业务都做成功了，并且事务响应时间达到要求，这样才能说明事务响应时间达到客户的要求；如果平均事务响应时间达不到要求，就需要进一步分析，是哪些原因导致事务响应时间过长，这样才能进一步优化系统的性能。

四、吞吐量图

显示方案运行过程中服务器上每秒的吞吐量。吞吐量的单位为字节，表示 vuser在一秒时间内从服务器获得的数据量。借助此图可以依据服务器吞吐量来评估vuser产生的负载量，可以和平均事务各应时间图对照观察，以查看吞吐量对事务性能产生的影响。

X轴表示 方案从开始运行以来已用的时间，Y轴表示服务器的吞吐量（以字节为单位）。吞吐量直接反映了服务器的处理能力，如果服务器处理的吞吐量的值越大，说明服务器处理业务的能力越强，但是在测试过程中不可能一次就测试出服务器吞吐量的值，必须经过多次测试才能找到吞吐量的值，即测试过程中一定要找到吞吐量的拐点，这样才能找到服务器处理业务时的最大吞吐量，亦即服务器处理的最大能力。

analysis报告

一、HTML报告

二、SLA报告

三、自定义报告

四、使用报告模板定义报告