自动化测试工具LoadRunner.docx

自动化测试工具LoadRunner.docx

《自动化测试工具LoadRunner.docx》由会员分享，可在线阅读，更多相关《自动化测试工具LoadRunner.docx（20页珍藏版）》请在冰豆网上搜索。

自动化测试工具LoadRunner

自动化测试工具LoadRunner

一个系统的成功与否不仅看它是否能达到人们的预期而成功完成某项任务，同时还要看系统的性能是否符合一定标准。

系统的性能是一个很大的概念，覆盖面非常广泛，包括执行效率、资源占用、稳定性、安全性、兼容性、可扩展性、可靠性等等。

而利用自动化工具则可以模拟真实用户来操作系统，通过这种方式来发现系统性能瓶颈的过程就叫作系统的性能测试。

LoadRunner是一种预测系统行为和性能的负载测试工具，通过模拟成千上万名用户和实施实时性能监测来确认和查找问题，LoadRunner能够对整个企业架构进行测试。

通过使用LoadRunner，企业能最大限度地缩短测试时间，优化性能和加速应用系统的发布周期。

4.1LoadRunner特性

轻松创建虚拟用户：

使用LoadRunner的VirtualUserGenerator，我们能很简便地创立起系统负载。

该引擎能够生成虚拟用户，以虚拟用户的方式模拟真实用户的业务操作行为。

它先记录下业务流程（如下订单或机票预定），然后将其转化为测试脚本。

利用虚拟用户，我们可以在Windows，UNIX或Linux机器上同时产生成千上万个用户访问。

创建真实的负载：

Controller的Rendezvous功能提供一个互动的环境，在其中既能建立起持续且循环的负载，又能管理和驱动负载测试方案。

而且，我们还可以利用它的日程计划服务来定义用户在什么时候访问系统以产生负载。

实时监测器：

LoadRunner内含集成的实时监测器，在负载测试过程的任何时候，我们都可以观察到应用系统的运行性能。

这些性能监测器为我们实时显示交易性能数据（如响应时间）和其它系统组件包括applicationserver,webserver，网路设备和数据库等的实时性能。

分析结果：

一旦测试完毕后，LoadRunner收集汇总所有的测试数据，并为我们提供高级的分析和报告工具，以便迅速查找到性能问题并追溯原由。

使用LoadRunner的Web交易细节监测器，我们可以了解到将所有的图象、框架和文本下载到每一网页上所需的时间。

负载测试是一个重复过程。

每次处理完一个出错情况，我们都需要对我们的应用程序在相同的方案下，再进行一次负载测试。

以此检验我们所做的修正是否改善了运行性能。

4.2LoadRunner三大组件：

Vugen（VirtualUserGenerator）

用来录制脚本、编辑脚本

Controller

用来布置和执行测试场景

Analysis

图4.1LoadRunner三大组件

用来对测试结果进行分析

4.3LoadRunner名词解释与分析：

LoadRunner为性能测试工具，在脚本录制编辑过程中的名词以及系统Analysis分析器里面有很多关于系统性能指标的名词，这里列出了一些最为常用的名词。

Rendezvous（集合点）：

集合点用以同步虚拟用户以便恰好在同一时刻执行任务。

在测试计划中，可能会要求系统能够承受1000人同时提交数据，在LoadRunner中可以通过在提交数据操作前面加入集合点，这样当虚拟用户运行到提交数据的集合点时，LoadRunner就会检查同时有多少用户运行到集合点，如果不到1000人，LoadRunner就会命令已经到集合点的用户在此等待，当在集合点等待的用户达到1000人时，LoadRunner命令1000人同时去提交数据，从而达到测试计划中的需求。

Transaction（事务）：

事务就是在脚本定义中定义的某段操作（ACTION），更确切的说，就是一段脚本语句.定义事务时，首先在脚本中找到事务的开始和结束位置，然后分别插入一个事务起始标记，这样，当脚本运行的时候，LoadRunner会自动在事务的起始点计时，脚本在运行到事务结束点时计时结束，系统会自动记录这段操作的运行时间等性能数据；在脚本运行完毕后，系统会在结果信息中单独反映每个事务运行结果。

TransactionsperSecond（每秒通过事务数/TPS）：

显示在场景运行的每一秒钟，每个事务通过、失败以及停止的数量，是考查系统性能的一个重要参数。

通过它可以确定系统在任何给定时刻的时间事务负载。

分析TPS主要是看曲线的性能走向。

将它与平均事务响应时间进行对比，可以分析事务数目对执行时间的影响。

例：

当压力加大时，点击率/TPS曲线如果变化缓慢或者有平坦的趋势，很有可能是服务器开始出现瓶颈。

ResponseTime（响应时间）

从用户的角度，响应时间＝（C1+C2）+（A1+A2+A3）+（N1+N2+N3+N4）；

从系统的角度，响应时间包括（A1+A2+A3）+（N1+N2+N3+N4）。

对于用户能够接受的响应时间，在行业中一般都有369原则，即3s以内响应速度比较快，3s-6s能接受，9s以上不能忍受。

Throughput（吞吐量）：

即每秒处理事务的数量。

可以依据服务器的吞吐量来评估虚拟用户产生的负载量，以及看出服务器在流量方面的处理能力以及是否存在瓶颈。

HitsperSecond（每秒点击数）：

即运行场景过程中虚拟用户每秒向Web服务器提交的HTTP请求数。

通过它我们可以评估虚拟用户产生的负载量，如将其和“平均事务相应时间”图做比较，可以查看点击次数对事务性能产生的影响。

通过对查看“每秒点击次数”，可以判断系统是否稳定。

系统点击率下降通常表明服务器的响应速度在变慢，需进一步分析，发现系统瓶颈所在。

HTTPResponsesperSecond（每秒HTTP响应数）：

是显示运行场景过程中每秒从Web服务器返回的不同HTTP状态代码的数量，还能返回其它各类状态码的信息，通过分析状态码，可以判断服务器在压力下的运行情况，也可以通过对图中显示的结果进行分组，进而定位生成错误的代码脚本。

WebPageBreakdown（页面分解图）：

显示某一具体事务在测试过程的响应情况，进而分析相关的事务运行是否正常。

4.4LoadRunner的工作机制：

LoadRunner是一种企业级测试工具，它的工作机制较为复杂，掌握好LoadRunner的工作机制对于更好地掌握和使用LoadRunner有很大帮助，同时也会加深我们对LoadRunner的理解。

如图4.2为LoadRunner工作机制的分解图。

图4.2LoadRunner工作机制

LoadRunner中的Vugen通过监听IE客户端与服务器之间的通信，捕捉记录两者之间的信息传递来形成脚本。

生成的脚本在Controller之中形成Scenario（场景），按照制定的Schedule来执行场景。

Controller通过控制LoadGenerators来对系统加载虚拟用户，并生成分析图表。

在Analysis中可以对图表进行系统分析，并能以各种格式（Word、Excel、CrystalReports）打印出来。

4.5Vugen

4.5.1脚本产生的过程：

图4.3脚本开发过程

脚本录制具体步骤：

（1）创建一个新的虚拟用户脚本，选择Web（HTTP/HTML）协议来录制基于浏览器的应用系统。

（2）设置录制选项。

（3）点击“Startrecording”按钮。

在“Startrecording”对话框中输入应用系统网址并点击OK按钮。

（4）在Web系统中执行用户操作。

（5）点击“StopRecording”按钮，保存脚本。

此次我们选用的基于浏览器的应用系统，即LoadRunner自带网站“WebTours”。

此网站是一个飞机订票网站，可完成简单的订票操作，操作方便简捷。

考虑到LoadRunner对某一网站测试时需要连接网络，所以选用了“WebTours”，只需开启WebServer即可。

开启方法如图4.4：

图4.4开启web服务器

4.5.2脚本的录制：

打开VirtualUserGenerator，点击新建，在“Category”中选择“Web（HTTP/HTML）”协议。

一般情况下，基于浏览器的应用程序推荐使用HTML-basedScript协议，不是基于浏览器的应用程序推荐使用URL-basedScript，因为我们使用的是LoadRunner自带的示例网站，所以我们选用HTML-basedScript方式对脚本进行录制。

点击“Create”按钮。

图4.5录制选项

设置完毕后点击“OK”，进入“WebTours”登录页面，如图4.6：

图4.6WebTours主页

在进入此页面后LoadRunner工具条会记录下当前页面的事件数量：

图4.7LoadRunner录制工具条1

图4.8添加事物

我们需要对“登录”和“退出”两个功能的响应时间做分析，所以要添加事务对这两个功能进行响应时间的判定。

在登录之前需要对登录功能添加事务即“Transaction”。

点击录制条上的

按钮，输入事务的名称后点击“Login”，然后点击

结束事务。

在点击“Login”进入主页面后，将录制位置改为“Action”。

此时录制到的事件数目也会随之增加。

如图4.9所示。

图4.9LoadRunner录制工具条2

图4.10添加集合点

此时我们需要虚拟用户在进行下一步操作的时候实现同步操作，点击

按钮，如图4.10。

添加集合点完成订票流程后可以看到Invoice页面，表示已经完成订票。

完成订票页面的操作之后，将录制位置改为“vuser_end”。

对“退出”功能使用同样的方法添加事务描述后，点击停止

按钮，结束此次录制过程。

LoadRunner将会形成相应的脚本“Script”以及录制日志“RecordingLog”。

在“Script”中有三个函数分别为“vuser_init”，“Action”以及“vuser_end”。

“vuser_init”为初始化函数与“vuser_end”函数配套使用。

这两个函数不参与迭代过程，在每次脚本执行的时候只运行一次。

而“Action”函数为主体函数，可对主体操作进行多次迭代。

在对网站“WebTour”进行回放过程中我们不希望每次都对登录和退出操作进行多次迭代，所以把登录和退出过程分别放在了“vuser_init”和“vuser_end”函数中，每次运行脚本的时候这两部分不随迭代次数的增加而增

加。

图4.11迭代次数设置

在“Run-timeSettings-General-RunLogic”中我们要对“Action”部分进行迭代次数的设置。

如图4.11所示，可以看出随着迭代次数的增加，只有Action部分会多次迭代，vuser_init和vuser_end部分只执行一次。

在“RecordingLog”中，我们可以看到LoadRunner在录制过程中捕获的关于应用系统客户端与服务器之间的数据通讯：

"GET/WebTours/header.html"表示获取“WebTours/header.html”这样一个网页。

第一行表示客户端向服务器发送请求，大小为625字节；第二行表示服务器向客户端发送164字节的数据包，答复是否接受请求。

第三行表示服务器向客户端发送692字节的数据包，数据包内容为“WebTours/header.html”网页。

4.5.3脚本的回放

点击

进行回放，在LastReplaySummary左侧有回放成功与否的报告，同时在右侧还有录制时和回放时网站的截图（Snapshot）。

在ReplayLog中可以看到关于回放中的迭代的描述，如图4.12所示。

图4.12回放总结

4.6Controller

Controller是LoadRunner最核心的组件，是创建、维护、执行和监控场景的管理中心。

一个场景（Scenario）定义了Vuser执行、测试目标、控制Vuser的电脑、执行压力测试条件等。

场景模式共有两种：

手工场景和面向目标场景。

手动场景：

手工控制多少用户参与运行以及在什么时候运行；在场景执行中，可以添加、启动和停止虚拟用户运行。

面向目标的场景：

目标可能是吞吐量、响应时间、并发用户数；LoadRunner自动地管理虚拟用户；在场景执行中，不能添加、启动和停止虚拟用户运行。

为了能够更精确的控制场景的执行，我们选择手动场景模式。

场景执行计划：

图4.13场景执行计划

4.6.1Design

打开Controller，在Design页面的左上角有控制场景脚本的“ScenarioScripts”，在“LoadGenerator”负载生成器里添加负载的机器名称。

若是本机手动输入“localhost”，若是想在另一台机器上进行加载，则输入该机器的IP地址。

如图4.14所示。

图4.14场景脚本

在Design页面的左下方，是整个场景执行的计划表即“GlobalSchedule”，在这里可以对场景执行的具体方式进行设置。

比如场景运行的时间，虚拟用户加载的个数和方式以及虚拟用户退出执行的方式。

如图4.15所示：

在“Initialize”里面，将场景设置为每一个虚拟用户在场景开始运行的时候就进行初始化。

在“StartVusers”里面，我们设置100个虚拟用户（虚拟用户数根据机器配置及具体项目而定，可高达数十万），并且每5秒钟加载5个虚拟用户。

在“Duration”中场景的执行时间为5分钟，这里对于测试系统稳定性的情况可以设置为24小时或者2天左右的时间。

在“StopVusers”中，场景执行完毕之后每5秒钟撤下10个虚拟用户。

在进行“GlobalSchedule”中设置完毕后，在Design页面的右下角会生成对应的加载虚拟用户的走势图。

如图4.16所示。

图4.15全局计划表

图4.16虚拟用户加载图

4.6.2Run

点击进入“Run”页面中。

在点击“StartScenario”之前，必须要开启“WebTour”网站的“WebServer”服务器，否则将无法打开“WebTours”网站，也就无法让虚拟用户进行登录操作。

在Run页面的左上角是“ScenarioGroups”，里面动态记录着Vusers的状态。

虚拟用户在执行场景时虚拟用户的状态会发生变化。

可以通过

对虚拟用户进行控制和观察。

在Vusers控制器里可以手动停止某个或全部虚拟用户。

如图4.17所示。

图4.17虚拟用户监控

虚拟用户在执行场景时会经过“Down”-“Initializing”-“Ready”-“Running”-“Exiting”-“Stopped”的状态转换。

如果出现错误，将会出现“Done.Failed”状态。

同时在Run页面的右上方可以对全局状态进行观察。

如图4.18：

图4.18场景状态

此次场景的执行共报错130个，点击右侧放大镜图标可查看具体出错信息。

图4.19出错信息

如图4.19所示为虚拟用户执行场景的出错统计。

在里面我们可以找出具体

出错的原因。

比如第一条“FailedtoStop.Reason：

TimeOut”，停止虚拟用户失败的原因是超时，第二条为无法连接上“WebTours”网站，第三条是无法关闭进程或线程。

场景执行的“LoadGenerator”负载生成器为本机，故每台电脑执行场景的情况各有所异。

在本机进行场景执行的时候，CPU的利用率已经达到100%，说明CPU已无法满足加载更多虚拟用户的需求。

所以在越来越多的虚拟用户相继加载之后CPU不堪重负，故发生了上述错误。

在场景执行期间，通过Controller可以观察和搜集统计信息；场景执行完之后，在LoadRunnerAnalysis中关联所搜集的统计信息为分析关键问题做准备；在测试场景执行过程中或场景执行之后，用户通过浏览器可观察到性能监控器，使项目成员之间的协作更容易。

选择那些性能监控器也是测试计划的一部分。

在Run页面的左下方是用于监控和观察的一些项目。

如图4.20：

图4.20添加监控指标

在“AvailableGraphs”里是一些可供观察和分析的项目，可以根据项目具体要求添加想要监控的一些项目。

我们要在“SystemResourceGraphs”下的“WindowsResources”中添加我们要观察的一些关于本机Windows资源的一些参数。

双击“WindowsResources”，在页面上方工具栏中点击“Monitors-AddMeasurements”，在“MonitoredServerMachine”中输入“localhost”。

并在下方“ResourceMeasurementson:

localhost”栏中添加我们要监测的一些项目：

如图4.21：

在Run页面的右下方是对场景执行过程当中的各种资源及指标进行实时监控的窗口，里面可以根据项目需求自定义切换监控的对象，双击可放大观察。

在在对“WebTours”网站做性能测试的时候我们更多的关注一些主要指标对应的图表，例如RunningVusers，TransResponseTime，Throughput，ErroStatistics，Tran/Sec（passed），HitsperSecond等。

图4.21可供监控的图表

在Run页面右侧的观察框中可以根据需要添加要观察的对象。

图4.22虚拟用户加载

如图4.22为虚拟用户加载趋势图，显示的是在Design中对场景进行设计的时候所设定的虚拟用户加载方案。

图4.23事务响应时间

如图4.23为事务响应时间总和统计表。

事务响应时间是通过记录用户发出请求的开始时间和服务器返回内容到客户端的时间的差值来计算用户操作响应时间。

可用于获得某一功能的实现时间或某一页面的加载时间，从而对系统的性能进行衡量。

此处我们对登录和退出两个功能添加了事务。

图中前半段为所有虚拟用户进行登录操作时的事务响应时间总和，后半段为所有虚拟用户进行退出操作时LoadRunner记录的事务响应时间总和。

图4.24吞吐量

如图4.24为吞吐量的统计图。

吞吐量即每秒处理事务的数量。

可以依据服务器的吞吐量来评估虚拟用户产生的负载量，以及看出服务器在流量方面的处理能力以及是否存在瓶颈。

从图中可以看出在虚拟用户加载的初期即登录到系统的阶段系统的吞吐量明显增大，说明此阶段客户端与服务器的交互最为频繁。

可特别针对此阶段进行系统性能的优化。

图4.25错误统计

图3.16

如图4.25为错误统计图。

在所有用户加载完毕并运行时，其所占用的内存和消耗的CPU资源会达到最大值，受负载机配置的限制，可能会发生错误。

常见的就是负载机CPU利用率到达100%导致系统没法响应而出错。

图4.26每秒通过的事务数

如图4.26为每秒通过的事务数，此处的事务包括页面中每一个gif图，或者ActiveX控件，他们都将被视作事务而被统计。

通过详细统计页面中事务数可以用来观察在哪个阶段系统页面的任务量最大。

从而可以对此阶段进行重点观察与分析，以期发现系统的瓶颈。

图4.27点击率

如图4.27为点击率图。

HitsperSecond（每秒点击数即点击率）：

即运行场景过程中虚拟用户每秒向Web服务器提交的HTTP请求数。

通过它我们可以评估虚拟用户产生的负载量，如将其和“平均事务相应时间”图做比较，可以查看点击次数对事务性能产生的影响。

通过对查看“每秒点击次数”，可以判断系统是否稳定。

系统点击率下降通常表明服务器的响应速度在变慢，需进一步分析，发现系统瓶颈所在。

图4.28每秒发生的HTTP响应数

如图4.28为每秒发生的HTTP相应数，其走势与点击率（HTTP请求数）相同，在客户端向服务器发送HTTP请求后，服务器也会向客户端回发HTTP响应数。

若此图与点击率图不一致，则说明服务器未能完全响应客户端的请求。

图4.29每秒下载的页面数

如图4.29为每秒下载的页面数图。

每秒下载页数图显示场景或会话步骤运行的每一秒中从服务器下载的网页数。

使用此图可依据下载的页数来计算Vuser生成的负载量。

和吞吐量一样，每秒下载的页数表示Vuser在给定的任一秒内从服务器接收到的数据量。

与吞吐量图作比较，吞吐量图考虑的是各个资源及其大小（例如，每个.gif文件的大小、每个网页的大小）。

而每秒下载页数图只考虑页数。

4.7Analysis

在使用Controller执行负载测试计划并收集了相关数据之后，可直接在Controller中点击

进入Analysis中并自动生成Analysis报告。

图4.30Analysis目录

在Analysis页面的左侧列出了默认的统计分析表，统计分析表中的一些项可

目以根据需要手动添加进去，如图4.30。

另外在SummaryReport中是对整个场

景执行结果的汇总报告，报告中集中了各项重要指标。

如图4.31：

图3.32

图4.31AnalysisSummary

同时Analysis还给出来具体指标的分析图表。

图3.33

RunningVusers分析表。

图4.32RunningVusers分析表

HitsperSecond分析图

图4.33HitsperSecond分析图

图4.34Throughput分析表

Throughput分析表：

TransactionSummary图表：

图4.35TransactionSummary

LoadRunner作为当今软件行业最为主流的性能测试工具，很有必要对其进行深入的研究。

我们在论文中所探讨的关于LoadRunner的使用只是对于LoadRunner的入门级分析，其中还有很多强大的功能值得我们去研究和使用。

LoadRunner是一款功能强大的软件，不仅对于常见的CS和BS架构的应用程序或网站能够进行性能分析，同时对于基于不同操作系统和不同架构的应用程序都可以进行分析。

LoadRunner还可以对数据库中数据的读取等性能进行分析，比如Mysql和Oracle数据库。

目前行业中对于软件的性能要求也越来越高，学好LoadRunner软件测试人员来说非常必要。