哈哈，今天为了帮一个海外的留学生一点指点，竟然找出了我的本科毕业论文《LoadRunner 与性能测试》，现在看看感慨万千，而且发现当时稚气未脱时的自己写的一篇那么差的论文竟然也可以顺利毕业，嘿嘿

献丑了，我贴到了 E测中国的一个帖子上：

http://bbs.5etesting.com/viewthread.php?tid=559&highlight=

 

希望可以帮助到正在想写软件测试类毕业论文的即将面临毕业的学生朋友们，我的论文希望可以给大家指点一些思路，但是不要抄袭噢

第1章 简介

 

1．1 LoadRunner简介

 

MercuryLoadRunner 是一种预测系统行为和性能的负载测试工具。通过以模拟上千万用户实施并发负载及实时性能监测的方式来确认和查找问题，LoadRunner 能够对整个企业架构进行测试。通过使用LoadRunner ，企业能最大限度地缩短测试时间，优化性能和加速应用系统的发布周期。

目前企业的网络应用环境都必须支持大量用户，网络体系架构中含各类应用环境且由不同供应商提供软件和硬件产品。难以预知的用户负载和愈来愈复杂的应用环境使公司时时担心会发生用户响应速度过慢，系统崩溃等问题。这些都不可避免地导致公司收益的损失。HP-Mercury Interactive 的 LoadRunner 能让企业保护自己的收入来源，无需购置额外硬件而最大限度地利用现有的IT 资源，并确保终端用户在应用系统的各个环节中对其测试应用的质量，可靠性和可扩展性都有良好的评价。

LoadRunner 是一种适用于各种体系架构的自动负载测试工具，它能预测系统行为并优化系统性能。LoadRunner 的测试对象是整个企业的系统，它通过模拟实际用户的操作行为和实行实时性能监测，来帮助您更快的查找和发现问题。此外，LoadRunner 能支持广范的协议和技术，能提供特殊的解决方案。

 

1．2 压力测试简介

 

当一个应用程序在少量用户同时使用的时候，程序可能正常运行，但是当大量用户同时使用的时候，可能就会出现功能失效、性能衰减、甚至系统崩溃。

所以我们压力测试做的就是测试在什么样的条件下系统的性能变得不可接受。

从广泛意义上讲性能测试包括：压力测试、稳定性测试、负载能力测试和可扩展性测试等。在不同应用系统的性能测试中，需要根据应用系统的特点和测试目的的不同来选择具体的测试方案，本次“淘才宝”核心业务系统的性能测试主要是采用通常的压力测试模式来执行的，即：逐步增加压力，查看应用系统在各种压力状况小的性能表现。

在性能测试中，压力测试主要是为了获取系统在较大压力状况下的性能表现而设计并实现的，压力测试主要是获取系统的性能瓶颈和系统的最大吞吐率。

 

1．3 性能测试与LoadRunner之我见

 

Loadrunner无疑是一个强大有力的压力测试工具。它的脚本可以录制生成，自动关联；测试场景可以面向指标，多方监控；测试结果图表显示，拆分组合。

然而，我们无论在loadrunner前面加多少个“强大”、“智能”的形容词，别忘了其最终修饰的只是一个名词－“工具”。要做一个成功的性能测试，仅读懂和精通了loadrunner的使用手册是不够的，还需要对被测软件系统的方方面面都要有了解，比如软件体系构架，网络拓扑等知识。那么在性能测试中，人的智慧活动体现在哪里呢？

1．首先性能测试也是测试的一种，这就意味着做性能测试也要写测试案例。你所作的性能测试能不能足以支持找出性能测试瓶颈，和你在初期设计的测试案例关系甚为重要。

对于性能测试来讲，我个人认为，测试人员倒不一定非要有开发经验，但是应该有一个对软件体系结构有全面的了解。为什么呢？大多数情况下，我们在做性能测试时，都不能顺利达到性能指标，可能server响应超时了，也可能是用户死掉了，在日志里抛出了一堆error，这种情形是非常常见，所以在我们在一开始设计性能测试方案时，就应该考虑为寻找性能瓶颈而设计测试案例。这时我们就需要知道在整个软件系统中，有哪些节点，在哪些地方可能存在瓶颈，比如一个B/S系统就有IE client→物理网络→web server→app server→DB这样的一个压力流串(如图1-1)。每个节点的每个模块都有可能成为瓶颈。瓶颈的产生可能由于模块配置引起，也可能由于模块本身引起。这都需要我们设计测试案例来发现的。一般地，我自己常用的、感觉也比较方便的方法是，设计一组性能测试案例来验证一个节点是否存在瓶颈，这组case中尽量保持其他节点不变，来改变这个节点的配置，并监控此节点的各种指标。

图1-1压力流串

2．使用loadrunner的VU生成脚本。脚本的生成方式就两种，一种是自写或嵌入源代码，一种是录制生成。常常听见有人说，这两种方式中首选录制生成脚本，因为它简单且智能化。但我个人总觉得手写脚本要好一些，因为：

(1) 可读性好，流程清晰，检查点截取含义明确。业务级的代码读起来总比协议级的代码更易让人理解，也更容易维护，必要时可建立一个脚本库。而录制生成的代码大多没有维护的价值，现炒现卖。

(2) 手写的程序相比录制的脚本更能真实地模拟应用运行。因为录制的脚本是截获了网络包，生成了协议级的代码，而略掉了client端的处理逻辑。举个例子，用VU录制一个运行script和applet的IE行为，它只会生成http协议的API，在IE中运行的applet和script不会被模拟到，这就不是一个完整的系统。

(3) 手写程序相比录制脚本更能增加测试人员的技术含量。开发和测试能力双重提高，何乐而不为呢？loadrunner提供了java user，vb user，c user等语言类型的脚本，就是给我们开发脚本用的，而不是录制用的。

脚本不管录制也好，还是手写也好，选择的时候应该以脚本模拟程序真实有效为准，结合项目进度，开发难易程度等因素考虑。

3．组建并执行性能测试场景。

在真实世界中的用户业务规则要转换到可操作的性能指标是需要分析和计算的。当然这通常是市场需求分析人员干的活，但我觉得测试人员应该在做性能测试时，对这些指标进行理解，知道为什么要这样做。有时有的性能指标并不清楚和准确，还需要测试人员来分析。比如一个性能指标：要求软件系统支持每分钟700用户的登陆行为。这对于测试人员来说，其实是一个不确切的性能需求。这指的是瞬时并发用户700，在一分钟的响应时间要求下登陆系统？还是在一分钟内陆续有700个用户登入软件系统即可？这两种场景其实对软件系统的压力是不同的，第一种显然大，第二种要小一些。甚至有的性能需求就是支持50000注册用户，这种需求就更需要分析了，还要引入一些业务发生概率算法模型来做。这已经不是性能测试人员的职责了，但由于目前有不少软件公司流程不规范，或者有流程没执行，这些工作都要测试人员来做了，不过也好，正好是锻炼的机会。

4．分析结果数据，找到软件系统性能瓶颈。

上面说了，做了那么多，就是为了本步骤－寻找软件系统性能瓶颈。

个人认为寻找性能瓶颈是一个非常有挑战性的工作，毛主席曾经说过：一个优秀的指战员就是能够根据已有的客观形势，制定作战计划，然后在作战过程中，发现计划与执行不符的地方，分析，然后调整作战计划，缩小计划和战势的误差。简明一句：就是一个理论和实践结合的过程，一个人的主观思想和客观现实的结合过程。

在性能测试中，测试方案就是我们的作战计划，执行性能测试就是我们的作战战场。

总之，性能测试是一个不断修改测试方案，反复执行test case的过程，直至越来越逼近性能瓶颈。在此过程中，需要了解很多的知识，知识了解得越多，就越接近软件系统运行的真相，也就能找出性能瓶颈了。

图1-2 性能测试过程

 

第2章 LoadRunner与性能测试实战

 

2．1 预测系统与预期场景综述

 

2.1.1被测系统简介

被测对象是www.taocaibao.com （淘才宝）。

图2-1 淘才宝LOGO

淘才宝，突出个人关键字，把你的名字与你的特长挂钩，彰显自我独特价值。

淘才宝，便利的个人独特关键字特征，让企业在茫茫人海中，找到特别的你。

在这里，我们保持最新更新的60-70万条职位信息，并主动为个人与企业职位相匹配的双方进行推荐。

在这里，我们设立职业品牌店，让您在现有岗位工作中，逐步树立职业品牌，从而保障您下一份的职业发展需要。

在这里，我们为您设置保密功能，不管您是否在职，您都可以随意设置自己的信息公开程度，再也不会出现您的简历被变卖的情形。

也许你不是某行业专家，也没有过硬的证书或学历，更缺乏吸引大众眼球的业绩；请不要灰心，近5年招聘领域的实践操作经验与你分享：突出真实的自我特征，哪怕再平凡，总有相对应的企业会发现你、适合你。

淘才宝，发现自我特征，创立个人品牌，实现自我价值。让我们一起实现朴实、坚定、积累、创造的过程。立即注册体验。

2.1.2服务器配置

硬盘：                  120GB

内存：                  2GB

操作系统：              Windows Server 2003

其它：                 服务器由中国电信提供光纤接入带宽

2.1.3测试目的

压力测试的目的就是检验系统的最大吞吐量，检验现行的“淘才宝”业务系统在各种压力下的运行状况，检验系统的运行瓶颈，获取系统的处理能力等等。

本次针对“淘才宝”核心业务系统所进行的压力测试的测试目的为：

²        给出“淘才宝”系统当前的性能状况；

²        定位新业务系统性能瓶颈或潜在性能瓶颈；

²        总结一套合理的、可操作的、适合公司现实情况的性能测试方案，为后续的性能测试工作提供基本思路。

具体实施行为：

²        测试服务器在承受100个虚拟用户下的状态；

²        监控并分析服务器的性能指标，测试目的是为了监控性能并找出性能瓶颈。

 

2.1.4预期模拟场景

共100个虚拟用户运行两个脚本,其中45个执行第一个脚本，55个执行第二个脚本。

场景：每5秒加载12个虚拟用户，之后持续运行，直到点击率呈现下滑趋势时，手动停止虚拟用户的执行。

图2-2 预期加载虚拟用户数

 

2．2 测试报告综述

 

2.2.1 测试时间

测试开始于:      30-12-2006     13:56:59

测试结束于:      30-12-2006     13:58:50

持续时间: 持续运行直到手动停止。

加载虚拟用户数:  每00:00:05 (hh:mm:ss) 加载 12 个虚拟用户 。

2.2.2测试脚本

表2-1 测试脚本

Script	Type	File
new_ceshi	QTWeb	F:\Program Files\Mercury Interactive\new ceshi\new ceshi.usr
tao	QTWeb	F:\Program Files\Mercury Interactive\tao\tao.usr

 

2．3 点击率

 

图2-3示为所有虚拟用户数点击率的记录图表。

虚拟用户点击率最高达到474.8/秒。

从图标可以看出，此场景的模拟较真实的反应了现实服务器承受的压力。

图2-3 虚拟用户数点击率

表2-2虚拟用户数点击率图数据

 

2．4 虚拟用户的加载

 

图2-4示为实际监测到的虚拟用户的加载的记录图表。

起始：每00:00:05 (hh:mm:ss) 加载 12 个虚拟用户 ，直到达到100个虚拟用户为止。

停止：手动停止。

图2-4 实际虚拟用户的加载

表2-3实际虚拟用户的加载数据

与预期结果基本相符（下图）

 

图2-5预期加载虚拟用户数

 

2．5 服务器响应时间

 

图2-6示为服务器响应时间的记录图表。

图中紫色为服务器响应时间。

绿色为虚拟用户数执行的查询“人才超市”的频度。

图2-6 服务器响应时间

表2-4服务器响应时间图数据

从图中可以看出服务器响应时间随虚拟用户数执行的查询“人才超市”的频度变化而发生变化。说明此场景能较真实的模拟现实情况。

 

2．6 吞吐率（每秒处理数据量）

 

图表2-7显示在整个测试过程中，虚拟用户吞吐率（每秒处理数据量）。

这张图与“点击率”基本一致，说明通过分析下面要看到的“监控的Windows 系统资源”能够较准确的定位系统瓶颈。

图2-7虚拟用户吞吐率

表2-5虚拟用户吞吐率图数据

 

2．7 监控的Windows 系统资源

 

此图2-8为LoadRunner监控的Windows系统资源（服务器系统资源）。下面的标识只列出了一些关键的监控项。

图2-8 Windows 系统资源

表2-6 Windows 系统资源图数据

Color	Scale	Measurement	Min.	Ave.	Max.	SD
1	% Disk Time (PhysicalDisk _Total):192.168.188.100	0.49	3.386	15.36	3.065
1	% Processor Time (Processor _Total):192.168.188.100	1.042	35.827	65.365	20.172
1	Active Transactions (SQLServer|Databases _Total):192.168.188.100	0.0	0.0	0.0	0.0
10	Applications Running (ASP.NET):192.168.188.100	1	1	1	0.0
0.0001	Bytes Received/sec (Web Service _Total):192.168.188.100	0.0	164709.769	383786.515	116448.02
1E-6	Bytes Sent/sec (Web Service _Total):192.168.188.100	0.0	5896484.592	10973338.616	3633614.31
0.001	Bytes Total/sec (Server):192.168.188.100	3663.779	13411.922	31963.925	3553.087
1E-6	Bytes Total/sec (Web Service _Total):192.168.188.100	0.0	6061194.361	11299102.034	3741287.39
0.001	Bytes Transmitted/sec (Server):192.168.188.100	3593.071	13144.464	31347.049	3484.253
0.001	Current File Cache Memory Usage (Web Service Cache):192.168.188.100	0.0	48996.429	81287	39549.831
1	Current Files Cached (Web Service Cache):192.168.188.100	0.0	25.971	43	20.858
0.0001	URI Cache Hits (Web Service Cache):192.168.188.100	248472	254594.543	263830	4936.349

 

2.8点击率－虚拟用户数 分析

 

下面这张图2-9把“点击率”与“虚拟用户数”合成在一张图里，便于分析。

图2-9点击率－虚拟用户数

表2-7点击率－虚拟用户数图数据

Color	Graph	Scale	Measurement	Graph's Min.	Graph's Ave.	Graph's Max.	Graph's Median	Graph's SD
Hits per Second	1	Hits	0.0	246.035	474.8	227.6	117.606
Running Vusers	1	Run	0.0	51.667	100	60	35.457

点击率随虚拟用户数的上升而上升，当虚拟用户数达到最高100人并持续运行的时候，点击率达到了最高的474.8/秒。

说明本次运行基本达到了预期的描述场景，并较真实的模拟出了现实情况对服务器的施压。

 

2．9 Windows 资源－点击率分析

 

下面这张图2-10把“点击率”与“Windows 资源” 合成在一张图里，便于分析。

目的是要找出“Windows 资源”图里的监控指标明显随“点击率”而波动的项。

图2-10 Windows 资源－点击率

 

2．10Windows 资源－点击率  深入分析

 

通过LoadRunner的比较工具，找出了“Windows 资源”图里的监控指标明显随“点击率”而波动的项（可能就是系统瓶颈）。

图2-11 Windows 资源－点击率

表2-8 Windows 资源－点击率图数据

Color	Graph	Scale	Measurement	Correlation Match	Correlation	Machine Name	Monitor Type	Min.	Ave.	Max.	SD
Windows Resources	Standardized	Anonymous Users/sec (Web Service _Total):192.168.188.100	68	Directly Related	192.168.188.100	Windows Resources	0.0	72.688	137.174	43.235
Windows Resources	Standardized	Bytes Received/sec (Web Service _Total):192.168.188.100	74	Directly Related	192.168.188.100	Windows Resources	0.0	164709.769	383786.515	116448.02
Windows Resources	Standardized	Bytes Sent/sec (Web Service _Total):192.168.188.100	69	Directly Related	192.168.188.100	Windows Resources	0.0	5896484.592	10973338.616	3633614.31
Windows Resources	Standardized	Bytes Total/sec (Web Service _Total):192.168.188.100	70	Directly Related	192.168.188.100	Windows Resources	0.0	6061194.361	11299102.034	3741287.39
Windows Resources	Standardized	Current Connections (Web Service _Total):192.168.188.100	71	Directly Related	192.168.188.100	Windows Resources	11	173.229	208	54.825
Hits per Second	Standardized	Hits	100	Directly Related	N/A	N/A	N/A	253.459	N/A	N/A

在监控的服务器windows资源中，随着点击率的震荡，有以下5项监控指标也紧跟着震荡：

Anonymous Users/sec (Web Service_Total):192.168.188.100

Bytes Received/sec (Web Service_Total):192.168.188.100

Bytes Sent/sec (Web Service_Total):192.168.188.100

Bytes Total/sec (Web Service_Total):192.168.188.100

Current Connections (Web Service_Total):192.168.188.100

以上五项都是正常的响应量。

而服务器的系统响应时间、内存占用量等重要检控指标并没有发生很大震荡。

由此可以通过LoadRunner初步判定：

当服务器持续施压，并发100个虚拟用户，点击率最高达到474.8/秒的情况下，系统不存在任何瓶颈，服务器完全能处理日常业务量的负载而不会崩溃。

 

 

结束语

 

本文介绍了性能测试的基本概念，并实战于对“淘才宝”服务器的性能测试。实际上，性能测试从始至终都应该是相当严谨的一项工程，各个阶段的工作环环相扣，性能测试工程师应该认真对待各个阶段的工作，找出系统可能存在的瓶颈，把好系统正式投入市场化运作的最后一道关。

 

 

参考文献

 

[1] 朴春龙，《LoadRunner实战》，无忧测试电子杂志第四期，2005年8月

[2] 郑人杰，《计算机软件测试技术》，清华大学出版社，1992年12月