LoadRunner自带订票网站性能分析报告

一、所测试网站网址

http://localhost:1080/MercuryWebTours  

注：本次测试是将本机作为服务器测试性能的

二、所测试的功能

1、登陆  2、订一张票  3、再订一张票  4、删除所有订票  5、返回主界面 6、注销登录

以上功能已经正确实现

三、性能测试基本信息

性能测试完成时间：

测试用机的信息：

CPU：Intel(R) Core(TM) i5-2500 CPU @ 3.30GHz

内存：2.99GB

硬盘：120GB

操作系统：Windows XP SP3

机型：台式

LR的版本号：8.0

四、脚本信息

Action 迭代3次

两个个集合点 login（登陆）、tuichu(退出系统)

三个事务 denglu（登陆） dingpiao（订第一张票）、quxiao（取消全部订票）

以上集合点和事务均在action中

场景中集合策略 login为2个用户到达后释放

               quxiao为全部用户到达80%后释放

虚拟用户10个

加压规则 没15秒up2个，每20秒down2个，持续2分钟

硬件监控

physical disk->disk time  磁盘使用率

processor->proscessor time  CPU使用率

memory->pages/second  内存使用率

memory->page/reads sec  页面读取

physical disk->avg.disk queue.length  磁盘队列平均数

processor->processor  queue length CPU队列长度

processor->%DPC time  CPU网卡DPC时间

图1 运行场景过程结中Vusers的状态图

分析：ID 3、6的Vusers的状态都是Action的迭代运行尚未完成，但持续时间已到，强制停止。

      ID 2、4、5的Vusers的状态是准备退出。

      ID 7的Vusers的状态是到达集合点准备集合

      ID 1、8、9、10Vusers的状态是正常运行

图2 总体概述图

分析：

场景运行的持续时间：21分钟50秒

场景中的虚拟用户数：10（与场景设定中的一致）

总吞吐量：3361963 bytes

总点击数：1238

共运行了120个事务，通过了119个，终止了1个，失败了0个

从图中可以看出，Action Transaction最费时，平均用276.233秒（标准差399.727，数值偏大，所以选用均值）

HTTP Response中只有HTTP 200，说明所有的都成功了。

五、图形数据分析

对以下几张场景分析图进行有关信息的分析

吞吐量和平均响应事务时间：

分析：此图可以看出最拖实践的事务是flights。最小时间4345，平均时间4483，最大时间是4666，平局差0.121。事务del也差不多，平均值为3355

吞吐量和点击率：

分析：从图中可以看出，Throughput和Hits per Second基本同频，说明服务器已及时地接受客户端的请求。

总体图

Dingpiao:

分析：从以上两种图可以看出，事务login耗时较多，我们在针对login做具体分析，可以看出，在login中，元素dingpiao耗时比较多。

事务综述图：

分析：有1个ID在Action_Transaction中终止，其他都是正常通过。说明脚本的设定还是相对稳定的，26个事物，pass：25 stop：1 有96%的事物都正常通过了，说明系统的事物处理能力较稳定

六、总结性分析

Vuser和系统资源：

分析依据：

1.cpu max 即最大使用率，如果此值持续大于95%，则必为系统瓶颈

另外，如果processor queue length 持续>2，很可能说明处理器堵塞。

分析依据：

3.如果(1)增加时(2)未同步下降，则说明内存不足（但尚不能证明内存是否有泄漏）

(1)内存的磁盘平均队列（avg.disk queue）

(2)页面读取操作率（page/reads sec）

4.DPC time max>50%并持续增加，同时CPU 使用率也很高，说明网卡是系统瓶颈，应换一快更好的网卡，或增加网卡

5.（物理内存大小-可用物理内存大小）/物理内存大小=内存使用率，这个值的大小要得出。

分析：

1.因为页面读取操作率（page/reads sec）的max 值低下，磁盘使用率（disk time (physical disk)）持续增高，内存的磁盘平均队列（avg.disk queue）持续增高，所以磁盘为系统瓶颈。

2.DPC time max<50%并未持续增加，同时CPU 使用率也不是很高，说明网卡不是系统瓶颈

3.队列长度（Avg.Disk Queue Length）增加的同时页面读取速率（Page Reads/sec）并未降低，所以内存不足

4. processor queue length 持续<2，很可能说明处理器未堵塞。

第二篇：软件测试loadrunner

软件测试论文

1.软件性能测试

软件性能测试是为了描述对象与性能相关的特性并对其进行评价，而实施和执行的一类测试。性能测试主要检验软件是否达到需求规格说明中规定的各类性能指标，并满足一些性能相关的约束和限制条件。

中国软件评测中心将性能测试概括为三个方面：应用在客户端性能的测试、应用在网络 上性能的测试和应用在服务器端性能的测试。

本文主要关注应用在客户端性能的测试。

应用在客户端性能测试的目的是考察客户端应用的性能，测试的入口是客户端。它主要包括并发性能测试、疲劳强度测试、大数据量测试和速度测试等，其中并发性能测试是重点。 并发性能测试的过程是一个负载测试和压力测试的过程，即逐渐增加负载，直到系统的瓶颈或者不能接受的性能点，通过综合分析交易执行指标和资源监控指标来确定系统并发性能的过程。负载测试是确定在各种负载下系统的性能，目标是测试当负载逐渐增加时，系统组成部分的相关输出项，例如通过量、响应时间、CUP负载、内存使用等来决定系统的性能。负载测试是一个分析软件应用程序和支撑架构、模拟真实环境的使用，从而来确定能够接受的性能过程。压力测试是通过确定一个系统的瓶颈或者不能接受的性能点，来获得系统能提供的最大服务级别的测试。

并发性能测试的目的主要体现在三个方面：以真实的业务为依据，选择有代表性的、关键的业务操作设计测试案例，以评价系统的当前性能；当扩展应用程序的功能或者新的应用程序将要被部署时，负载测试会帮助确定系统是否还能够处理期望的用户负载，以预测系统的未来性能；通过模拟成百上千个用户，重复执行和运行测试，可以确认性能瓶颈并优化和调整应用，目的在于寻找到瓶颈问题。

2.基于JAVA的WEB应用程序性能测试策略

软件测试就是在受控制的条件下对系统或应用程序进行操作并评价操作结果的过程，所谓控制条件应包括正常条件与非正常条件。对任意一个程序进行的测试，无论使用自动化的测试工具或是手动测试，穷尽测试是不可能。任何一个经过严格测试的程序，也不能保证其百分之百的正确。

因此，为了较少这种不必要的错误。测试之前一定先要制定其测试策略，测试计划，选用合适的测试工具，从而设计出高效的测试用例。只有这样，一个好的测试策略和好的测试计划才能做到事倍功半的作用。

基于JAVA的web应用程序性能测试重点在于并发测试。并发测试一般使用虚载测试的方法,即通过一个控制器发送测试信息给多个参与测试的主机，在每台机器上模拟多个用户的操作（使用多个进程或线程）向服务器发送用户请求，使系统运行起来。

基于以上的工作原理，其性能测试采用的策略主要有：

（1）脚本的个数、负载生成器和每个组中包括的VUSER数为固定数。

（2）脚本的个数、负载生成器和每个组中包括的Vuser 数可以以一定的百分比进行改变。

（3）可以固定虚拟用户数、每秒事务数、每分钟也面数及事务的响应时间。

（4）可以设置脚本的种类

（5）设置不同的操作系统，模拟真实的用户现象。

3.性能测试的实现

性能测试，大多数的测试只有借助测试工具才能完成。目前，广泛使用的性能测试

工具大多是商业软件，如mercury interactive公司的loadrunner、Astra LoadTest，Compuware公司的QA Load，IBM Rational公司的TeamTest。本文选用的用Mercury公司的自动化性能测试工具loadrunner，在Windows XP, My Sql数据库的测试环境下进行性能测试。

（1）性能测试设计

Loadrunner是一个可以进行自动化测试执行，并对测试的数据进行分析，从而得到系统瓶颈的行业标准的性能测试解决方案。有以下三部分组成：VuGen用来录制虚拟用户的脚本。Controller 用来执行脚本并且对整个测试过程进行监控。Analysis 提供图和报表来显示测试结果。

具体方法：首先通过使用VuGen（虚拟用户生成器）录制用户在客户端应用程序中执行的典型业务流程来开发Vuser脚本。VuGen 还可以运行脚本，为了成功的把脚本集成到LoadRunner 方案中，在录制了基本的Vuser脚本以后，还要对脚本进行增强及编辑，设置好运行时环境后，以独立模式运行Vuser脚本。其次通过Controller从一个单一的控制点简单有效地控制所有的Vuser。导入测试脚本，在方案（描述测试会话期间发生的事情）中配置好Vuser 的计算机列表、运行Vuser脚本的列表以及在方案执行期间运行的指定数量的Vuser或Vuser组。执行方案时，Controller将该方案中的每个Vuser分散到负载生成器，负载生成器是执行Vuser脚本，从而使Vuser可以模拟实际用户操作的计算机。在运行的同时，还可以用LoadRunner 的性能监视器来监视方案的执行。最后，Analysis 把在方案执行期间，LoadRunner纪录下来的不同负载下的应用程序性能，以图和报表显示出来。从而可以方便的分析出应用程序的性能。

(2)性能测试数据的准备

通过使用最少的硬件资源，为所有VUSER提供一致的、可重复并可度量的负载，像实际用户一样使用开发的应用程序，这是Loadrunner的一大特点及优势。在提供负载时，除了准备一些比较有代表性的数据，还要注意测试脚本的重用问题。一个是关联，即通过参数化，来实现测试用例的充分利用。另一个是ip欺骗因为当运行场景时，虚拟用户使用它们所在的负载生成器的固定的IP 地址。每个Load Generator 上（同时）运行大量的虚拟用户，这样就造成了大量的用户使用同一IP 同时访问一个网站的情况，这种情况和实际运行的情况不符，并且有一些网站会限制同一个IP 的登陆。为了更加真实的模拟实际情况，LoadRunner允许运行的虚拟用户使用不同的IP 访问同一网站，这种技术称为“IP 欺骗”.

（3）性能测试执行

在测试计划、测试环境及测试数据准备好以后就可以进行测试。Controller 通过远程代理调度程序启动负载生成器计算机上的应用程序。通过代理Controller和负载生成器互相通信。运行方案时，Controller指示远程代理调度程序启动LoadRunner代理。该代理根据从Controller接受到的指令来初始化、运行、暂停和停止各个Vuser。同时，该代理还将各个Vuaer的状态数据传回Controller。

（4）性能测试评估

在应用程序的测试测试结束后，可以对应其各个性能指标来分析系统的可用性。 有许多因素能够影响系统的性能指标，如，测试环境、网络、应用的数据库和中间件的使用及它们之间的关联应用。其中任何一个环节都可能造成整个系统的可用性。Loadrunner Controller通过隔离并标识潜在的客户端、网络和服务器瓶颈。监视负载下的网络和服务器资源，检查出现性能延迟的地方：网络或客户端延迟、CPU性能、I/O延迟、数据锁定或服务器上的其他问题。在进行web应用测试中，LOADRUNNER提供的性能指标有每秒点击次数吞吐量每秒HTTP响应数、每秒下载页面数每秒连接数。同时。用户通过在LOARUNNER ANALYSIS中看到这些性能指标的图或报表，很方便的分析各部分的性能状况。

4.总结

任何软件的测试结果都不是只与应用程序本身有关，特别是性能测试，还与其测试硬件环境、软件环境、测试方法及测试工具有关，因此在进行测试之前、一定要了解应用程序的使用及运行的约束条件。Loadrunner Controller通过使用虚拟用户技术来达到并发的目的，这个测试属于黑盒测试，测试人员不需要对程序代码有很深刻的了解。通过模拟真实用户对系统的访问，可以帮助系统分析员提早发现系统的瓶颈，从而优化各部分的软硬件配置。

参考文献：

①张大陆，伟力《基于WEB应用系统的评测方法和技术》计算机工程第29卷第四期。 ②陈战华杨斌《Client/Server结构软件的性能测试测试技术》。

③啄木鸟部落《如何选择性能测试工具》。

④中国软件评测中心测试中心《性能——软件测试的重中之中》。

⑤LOADRUNNER使用手册。