LoadRunner使用技巧与问题排除技巧.docx

LoadRunner使用技巧与问题排除技巧.docx

《LoadRunner使用技巧与问题排除技巧.docx》由会员分享，可在线阅读，更多相关《LoadRunner使用技巧与问题排除技巧.docx（12页珍藏版）》请在冰豆网上搜索。

LoadRunner使用技巧与问题排除技巧

让LoadRunner走下神坛

Loadrunner无疑是个强大有力的压力测试工具。

他的脚本能录制生成，自动关联;测试场景能面向指标，多方监视;测试结果图表显示，拆分组合。

相信有人这样想象过：

拿着一张性能指标标准列表和测试数据相比较，如同PH试纸相同，遇碱则蓝，遇酸则红，一目了然，之后就能大声地喊道：

我找到了软件系统的性能瓶颈!

　　然而，我们无论在loadrunner前面加多少个“强大”、“智能”的形容词，别忘了其最终修饰的只是个名词-“工具”。

《大话西游》中也有相当精辟的论断：

官兵?

最多也只是个长了痔疮的官兵!

把loadrunner比喻成长了痔疮的官兵有点粗俗，但loadrunner他是个工具，那么是否能够找到性能瓶颈就取决于使用工具的人，而不是工具本身。

要做一个成功的性能测试，仅读懂和精通了loadrunner的使用手册是不够的，还需要对被测软件系统的方方面面都要有了解，比如软件体系构架，网络拓扑等知识。

这就如同一个技艺高超的木匠，并不是因为他背熟了凿子，锤子的说明书，而是他能结合木材的质地和尺寸，用凿子和锤子这些工具做出一把精巧的椅子来。

那么在性能测试中，人的智慧活动体目前哪里呢?

　　一.首先性能测试也是测试的一种，这就意味着做性能测试也要写测试案例。

你所作的性能测试能不能足以支持找出性能测试瓶颈，和你在初期设计的测试案例关系甚为重要。

我曾写过对一个软件系统的不下十个性能测试场景案例，等后来运行时却发现我必须增补几个案例才能找到瓶颈，而原来十多个案例其实重复甚多。

如果你要写出好的不重复的性能测试案例来，你就得对被测软件系统有一定的了解。

　　在这里，我顺便插一句，在目前测试界总在争论测试人员需不必懂编程，需不必有研发经验这种问题，这完全是本末倒置，忘记了测试人员的目标是什么，测试目标就是写出好的测试案例，好的测试案例就是发现了一个原来未曾发现的软件bug。

那么一个测试人员知识体系是否够用的标准就是能不能写出一个好的测试案例。

而针对不同类型的测试，所需的知识深度是不相同的，有的是不需编程知识，比如界面测试;有的是必须有研发经验的，比如接口测试，不能一概而论。

　　对于性能测试来讲，我个人认为，测试人员倒不一定非要有研发经验，不过应该有一个对软件体系结构了解全方面的知识。

为什么呢?

做性能测试时，如果从客户端施压一次就符合性能指标，碰到这种情况你就偷着乐吧，因为在你的指标场景下，软件系统中就不存在性能瓶颈，你也就不用费心去找了。

不过大多数情况下，我们在做性能测试时，都不能顺利达到性能指标，可能server响应超时了，也可能是用户死掉了，在日志里抛出了一堆error，这种情形是非常常见，所以在我们在一开始设计性能测试方案时，就应该考虑为寻找性能瓶颈而设计测试案例。

这时我们就需要知道在整个软件系统中，有哪些节点，在哪些地方可能存在瓶颈，比如一个B/S系统就有IEclient→物理网络→webserver→appserver→DB这样的一个压力流串。

每个节点的每个模块都有可能成为瓶颈。

瓶颈的产生可能由于模块设置引起，也可能由于模块本身引起。

这都需要我们设计测试案例来发现的。

一般地，我自己常用的感觉也比较方便的方法是，设计一组性能测试案例来验证一个节点是否存在瓶颈，这组case中尽量保持其他节点不变，来改动这个节点的设置，并监视此节点的各种指标。

这里说起来就有非常多话了，不是一言两语能说得清的。

以后有时间能找个专题来慢慢跟大家讨论。

　　二.使用loadrunner的VU生成脚本。

脚本的生成方式就两种，一种是自写或嵌入原始码，一种是录制生成。

常常听见有人说，这两种方式中最佳选择录制生成脚本，因为他简单且智能化。

但我个人总觉得手写脚本要好一些，因为：

　　1.可读性好，流程清晰，检查点截取含义明确。

业务级的代码读起来总比协议级的代码更易让人理解，也更容易维护，必要时可建立一个脚本库。

而录制生成的代码大多没有维护的价值，现炒现卖。

　　2.手写的程式相比录制的脚本更能真实地模拟应用运行。

因为录制的脚本是截获了网络包，生成了协议级的代码，而略掉了client端的处理逻辑。

举个例子，用VU录制一个运行script和applet的IE行为，他只会生成http协议的API，在IE中运行的applet和script不会被模拟到，这就不是个完整的系统。

　　3.手写程式相比录制脚本更能增加测试人员的技术含量。

研发和测试能力双重提高，何乐而不为呢?

loadrunner提供了javauser，vbuser，cuser等语言类型的脚本，就是给我们研发脚本用的，而不是录制用的。

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

　　在这里我想要说的是，研发一个好的脚本是成功性能测试的必要条件。

一个好的脚本应该能够最大程度再现client程式行为。

如上面那个例子，脚本只模拟了client端的部分行为，有一些没有模拟到，那么client的瓶颈就有可能被忽略了。

我曾吃过一个亏，自己写了一个javasocket脚本去联server，不过忽略了client端的界面下的业务逻辑，用我的脚本做性能测试通过，全部OK，不过真实用户一上线，client终端界面接受了大量的server信息，导致client进程死掉了。

痛哉，痛哉。

　　三.组建并执行性能测试场景。

　　从VU运行成功到controller运行成功，一般需要以下几个步骤（我也是从英文论坛上看到的，觉得不错，拿出来共享）：

　　1.确认在VU里SUSI（单用户单循环次数singleuser&singleiteration）

　　2.确认在VU里SUMI（单用户多循环次数singleuser&multiiteration）

　　3.确认在controller中MUSI（多用户单循环次数multiuser&singleiteration）

　　4.确认在controller中MUMI（多用户多循环次数multiuser&multiiteration）

　　做这样一个步骤划分是有道理的，第一步骤是验证脚本编写的正确，第二步骤能验证数据池是否正常运作。

第三步骤验证并发功能，第四步骤是最终目的，验证软件系统的性能。

在论坛上看到一些朋友提的问题，有一些就是于此的，在controller中运行场景时出现问题，首先得确保VU中运行成功，这是个显然的逻辑。

软件工程中把软件研发的种种行为都要制定一个proccess，即过程，性能测试也是如此，按照过程来调试脚本和场景，能及早发现问题和定位问题。

除非是高手，烂熟于心中，才能超越proccess而不出问题。

　　场景是把虚拟用户和交易数按一定规则组织起来去模拟真实世界的业务行为。

这其实是把单个用户的行为复制，连接。

场景的组织通常和真实世界的业务规则有非常大关系。

　　做个如下可能并不恰当的比喻：

　　脚本像演员，场景就像表演的舞台，而测试工程师是导演，多少个演员，怎么在舞台上演出，都由导演说了算，而剧情又不能离谱，脱离现实，否则就要砸锅了。

注意，导演的职责不光是确保演出能顺利结束，而且还要同时观察和收集观众的反馈信息，以确认这次演出是否成功。

　　同样的也是，性能测试人员不光是看场景是否得到顺利的执行，同时还要收集各个server的反馈信息，以确认软件系统的性能表现是否正常。

　　在真实世界中的用户业务规则要转换到可操作的性能指标是需要分析和计算的。

当然这通常是市场需求分析人员干的活，但我觉得测试人员应该在做性能测试时，对这些指标进行理解，知道为什么要这样做。

有时有的性能指标并不清晰和准确，还需要测试人员来分析。

比如一个性能指标：

需求软件系统支持每分钟700用户的登陆行为。

这对于测试人员来说，其实是个不确切的性能需求。

这指的是瞬时并发用户700，在一分钟的响应时间需求下登陆系统?

还是在一分钟内陆续有700个用户登入软件系统即可?

这两种场景其实对软件系统的压力是不同的，第一种显然大，第二种要小一些。

甚至有的性能需求就是支持50000注册用户，这种需求就更需要分析了，还要引入一些业务发生概率算法模型来做。

这已不是性能测试人员的职责了，但由于目前有不少软件公司流程不规范，或有流程没执行，这些工作都要测试人员来做了，不过也好，正好是锻炼的机会。

　　四.分析结果数据，找到软件系统性能瓶颈

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

　　个人认为寻找性能瓶颈是个非常有挑战性的工作，毛主席原来说过：

一个优秀的指战员就是能够根据已有的客观形势，制定作战计划，然后在作战过程中，发现计划和执行不符的地方，分析，然后调整作战计划，缩小计划和战势的误差。

简明一句：

就是个理论和实践结合的过程，一个人的主观思想和客观现实的结合过程（注明：

本人是毛主席老人家的忠实fans）。

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

在性能测试中，可能会发现种种意想不到的问题。

当然一个经验足够丰富的性能测试专家可能会在测试之前就能考虑全方面，使测试方案吻合测试执行实际情况，并一举找出性能瓶颈。

我sunshinelius不是专家水平，当然就要匆忙应对和分析性能测试中出现的问题，并有可能会修改测试方案，增加必要的testcase，删除没用的testcase。

总之，性能测试是个不断修改测试方案，反复执行testcase的过程，直至越来越逼近性能瓶颈。

在此过程中，需要了解非常多的知识，知识了解得越多，就越接近软件系统运行的真相，也就能找出性能瓶颈了。

　　比如：

loadrunner要是调用程式员的程式，服务器资源占用情况可能是追查瓶颈的一个线索，但如果是标准中间件，那就没那么简单了，比如oracle数据库的某项参数设得不对，照样会造成数据库瓶颈，应用程式调用数据库的API写法不对，比如未使用软解析变量，也有可能导致数据库瓶颈。

这些瓶颈都不会反映在cpu，内存使用量上等指标上的。

　　对于这种情况，一方面需要对中间件有一定的了解，知道哪些参数有什么作用，怎么可调的，另外还可能使用中间件的专有监测工具，来分析。

lr的性能计数器是不够用的。

　　个人体会，查找瓶颈的难易程度，由易到难

　　服务器硬件瓶颈-〉网络瓶颈-〉应用瓶颈-〉服务器操作系统瓶颈（参数设置）-〉中间件瓶颈（参数设置，数据库，web服务器等）

　　记忆比较深刻的一次，用lr做了两天性能测试，指标上不去，后来使用oracle数据库的图像化性能检测工具才发现某个表的查询处理时间超长，原来索引创建得不合理，把表的索引改了之后，性能稍有提高，但还是上不去。

再次排查，发现应用中有一个sql语句写得有问题，长而且耗时，改了之后，测试指标还是上不去

　　经过至少四轮的排查，才大功告成，最后一个除掉的瓶颈是操作系统问题（开始没有想到他，后来看系统消息，才发现已有错误报出）

　　五.我再说两句

　　每个系统的性能测试都是个全新的挑战!

如何在LoadRunner中快速获得毫秒数

1、打开Loadrunner，进入VUser录制脚本界面；

2、进入ParameterList界面，New一个参数出来，参数名自定义，我在这里定义为sec；

3、ParameterType选择为Date/Time；

4、Date/Timeformat选择为%Y-%m-%d%H:

%M:

%S.000；

5、删除前面的%Y-%m-%d%H:

%M:

%S，只留下.000；然后在小数点前面再加个0吧；

6、这样子，Format就变成0.000；

7、OK，回到脚本编辑界面，键盘一敲，输入：

    lr_log_message（lr_eval_string（"{sec}"））;

    return0;

8、run一下，看到结果：

     StartingactionAction.

     0.698

     EndingactionAction.

其中参数名：

{sec}左右的括号需要在工具—常规选项—参数化中进行设置即可。

loadrunner中thinktime如何运用随机时间，并要把时间定在毫秒级

1.把lr_think_time参数设置为0.1，并把runtime-setting的Replaythinktime设置为：

userandompercentageofrecordedthinktime，并把范围设置在1%~1000%之间，那么范围就是在1~1000毫秒间了；

2.二、方法二，利用随机函数，生成1~1000的数，再除以1000

3.运行提示：

4.打开runtime-setting的log设置里的Replaythinktime的Asrecorded

5.//============代码如下=================

6.Action（）

7.{

8.longa,b;

9.floatfnum;

10.inti,imax,time_x;

11.imax=10;

12.srand（time（NULL））;//随机种子，以防止生成相同数

13.for（i=0;i

14.fnum=rand（）;//利用自动类型转换，取得随机数

15.a=clock（）;//取得当前的时间，保存到a

16.lr_think_time（fnum/100000）;//把随机数换算到毫秒级

17.b=clock（）;//取得当前的时间，保存到b

18.time_x=（int）（b-a）;//取间隔时间

19.lr_error_message（"间隔时间为：

%d毫秒",time_x）;

20.lr_error_message（"Think_time的参数是：

%lf",fnum/100000）;

用JavaScript判断您所使用的浏览器是何种类型，并给出版本号

学会看懂LoadRunner分析报表

发现现在有相当一部分使用LoadRunner的朋友面对LoadRunner的一大堆测试结果常常无所适从，不知道如何把这些测试结果真正利用起来。

因此我把我个人学习LoadRunner的一些笔记和心得贴在这里，它到目前为止还是一堆很杂乱的东西，并没有形成一个系统的东西，而且其中可能会存在很多错误，希望各位测试同行能多多批评指教。

　　一、WebPageBreakdown

　　DNS解析时间：

显示使用最近的DNS服务器将DNS名称解析为IP地址所需的时间；DNS查找度量是指示DNS解析问题或DNS服务器问题的一个很好的指示器；

　　Connect时间：

显示与包含指定URL的Web服务器建立初始连接所需的时间；Connect度量是一个很好的网络问题指示器；它还可表明服务器是否对请求做出响应；

　　Firstbuffer时间：

显示从初始HTTP请求到成功收回来自WEB服务器的第一次缓冲时为止所经过的时间；Firstbuffer度量是很好的Web服务器延迟和网络滞后指示器；

　　SSLHandshakingtime：

显示建立SSL连接所用的时间

　　ReceiveTime：

显示从服务器收到最后一个字节并完成下载之前经过的时间；接收度量是很好的网络质量指示器；

　　FTP验证时间：

显示验证客户端所用的时间。

　　ClientTime：

显示因浏览器思考时间或其他与客户端有关的延迟而使客户机上的请求发生延迟时，所经过的时间。

　　Error时间：

显示从发出HTTP请求到返回错误消息这期间所经过的平均时间

　　二、关于TPS（TransactionsperSecond）：

每秒处理事务数

　　这个值可以说明系统在特定的负载情况下，每秒可以处理多少个客户端请求，这是一个衡量服务器端性能的重要指标，相信各位在进行性能测试的时候经常会用到这个指标。

但是一直以来我都有一个疑问，到底这个值是怎么算出来的。

既然是每秒事务数，那算法自然是“事务数/时间”。

事务数很好理解，执行了多少就是多少，关键是这个时间。

是整个场景执行的时间，还是仅仅是在服务器端执行的时间？

因为我们知道，这两个时间肯定是有区别的，前者还包括thinktime的时间、pacing的时间以及在网络上耗费的时间等等。

　　为了弄明白这个问题，我今天特地查了一下帮助文档，看到上面是这么说的：

“每秒事务数图显示在场景或会话步骤运行的每一秒中，每个事务通过、失败以及停止的次数。

”如果按照这句话去理解，那么上面那个问题的答案应该是后者，也就是说，在TransaactionsperSecond这张图中，LoadRunner是针对场景运行过程中的每一个时间点取样一次，显示在这个时间点上每个事务的通过、失败以及停止的个数。

　　另外，我还在Analysis里面找了一下，发现图表的时间显示粒度也是可以设置的。

具体方法为：

在图表上点击右键->选择“SetGranularity”或者直接按Ctrl+G。

我试着把时间粒度调成以毫秒为单位，结果LoadRunner提示当前不支持以毫秒为显示粒度，由此我推断LoadRunner对于TransactionsperSecond这张图，最小的取样粒度为1秒。

　　三、事务响应时间（百分比）图

　　这个图显示的是事务响应时间范围的分布情况。

在场景的执行中，每个定义的事务可能会不止被处理一次（因为设置了持续时间或者迭代次数），LoadRunner会为每个事务实例的处理分别记录响应时间。

在SummaryReport中，LoadRunner会针对每个事务的响应时间数据集合，分别取它的最大值、最小值和平均值，通常我们会关注响应时间的平均值。

然而很多时候，单单是平均响应时间可能是不够的，因为一旦最大值和最小值出现较大的偏差，即便平均响应时间处在可以接受的范围内，但并不意味着整个系统的性能就是可以接受的，我们有必要再借助其它的分析报表来进一步分析，此时事务响应时间（百分比）图就派上用场了。

　　事务响应时间（百分比）给出的是每个事务的响应时间按百分比的分布情况，它告诉我们本次测试有多少个事务的平均响应时间是落在我们可以接受的时间范围之内。

如果最大响应时间非常长，但是绝大多数事务（通常情况下以95%为参考）的响应时间具有可以接受的响应时间，则我们认为整个系统的性能还是可以接受的。

　　注意：

Analysis将对每个可用事务百分比的事务响应时间取近似值。

因此Y轴的值可能并不准确。

　　四、事务响应时间（负载下）图

　　这个图显示的是事务响应时间随着场景中虚拟用户的逐渐增长的变化趋势图，该图可以帮助我们查看Vuser负载对性能问题的影响。

当我们需要了解某个事务的响应时间随着虚拟用户的增加而产生的变化时，可以通过在控制台中设置一个渐变负载的场景的方式来实现。

例如每5分钟加载10个用户等，然后考察得到的这张图表，就能够对此有一个比较好的理解。

Loadrunner参数化策略

参数化要做一些准备，主要是参数化数据的准备，例如TXT文本、EXCEL表格以及数据库中的表都可以作为参数的数据集载体，而且LR都是支持的。

具体的参数化流程如下：

1、录制脚本

2、准备参数的数据集（也可以不准备，让LR自己生成固定格式参数）

3、把对应的变量参数化

4、选择对应的参数化策略

准备文件：

参数化数据文本文件，写在一txt文件里面，如截图所示：

，Vuser中参数列表中新建2个参数aaabbb，参数类型选择：

文件，选择txt数据文件的路径，选择列按编号进行选择。

Action（）

{

char*a="{aaa}";//获得参数赋值给a

char*b="{bbb}";//获得参数赋值给b

lr_log_message（"%s,%s,%s,",lr_eval_string（a）,lr_eval_string（b）,ctime（&t））;//打印结果

return0;

}

运行时设置：

设置action的迭代次数为30（runtime-setting的RunLogic里）

SelectNextRow

UpdateValueOn

ReplayResult

顺序（Sequential）

每次迭代（Eachiteration）

a1,b1

a2,b2

a3,b3

…,…

a30,b30

顺序（Sequential）

每次出现（Eachoccurrence）

a1,b1

a2,b2

a3,b3

…,…

a30,b30

顺序（Sequential）

只取一次（once）

a1,b1

a1,b1

…,…

a1,b1

随机（Random）

每次迭代（Eachiterati