使用LoadRunner不容易解决的问题

1、使用LoadRunner不容易解决的问题LoadRunner，是一种预测系统行为和性能的负载测试工具。通过以模拟上千万用户实 施并发负载及实时性能监测的方式来确认和查找问题，LoadRunner能够对整个企业架构进 行测试。通过使用LoadRunner，企业能最大限度地缩短测试时间，优化性能和加速应用系 统的发布周期。LoadRunner是一种适用于各种体系架构的自动负载测试工具，它能预测系 统行为并优化系统性能。LoadRunner 的特点轻松创建虚拟用户使用LoadRunner的Virtual User Generator，您能很简便地创立起系统负载。该引擎能 够生成虚拟用户，以虚拟用户的

2、方式模拟真实用户的业务操作行为。它先记录下业务流 程，然后将其转化为测试脚本。利用虚拟用户，您可以在Windows，UNIX或Linux机器 上同时产生成千上万个用户访问。所以LoadRunner能极大的减少负载测试所需的硬件和人 力资源。另外，LoadRunner的TurboLoad专利技术能提供很高的适应性。TurboLoad使您 可以产生每天几十万名在线用户和数以百万计的点击数的负载。创建真实的负载Virtual users建立起后，您需要设定您的负载方案，业务流程组合和虚拟用户数量。用 LoadRunner的Controller，您能很快组织起多用户的测试方案。Controller的R

3、endezvous功 能提供一个互动的环境，在其中您既能建立起持续且循环的负载，又能管理和驱动负载测 试方案。而且，您可以利用它的日程计划服务来定义用户在什么时候访问系统以产生负 载。这样，您就能将测试过程自动化。同样您还可以用Controller来限定您的负载方案， 在这个方案中所有的用户同时执行一个动作-如登陆到一个库存应用程序一一来模拟峰值 负载的情况。另外，您还能监测系统架构中各个组件的性能一一包括服务器，数据库，网 络设备等一一来帮助客户决定系统的配置。Loadrunner无疑是一个强大有力的压力测试工具。它的脚本可以录制生成，自动关联; 测试场景可以面向指标，多方监控;测试结果图表

4、显示，拆分组合。相信有人这样想象过： 拿着一张性能指标标准列表和测试数据相比较，如同 PH试纸一样，遇碱则蓝，遇酸则 红，一目了然，之后就可以大声地喊道：我找到了软件系统的性能瓶颈！然而，我们无论在loadrunner前面加多少个“强大”、“智能”的形容词，别忘了其最 终修饰的只是一个名词-“工具”。大话西游中也有相当精辟的论断：官兵？最多也只是 个长了痔疮的官兵!把loadrunner比喻成长了痔疮的官兵有点粗俗，但loadrunner它是个工 具，那么是否能够找到性能瓶颈就取决于使用工具的人，而不是工具本身。要做一个成功 的性能测试，仅读懂和精通了 loadrunner的使用手册是不够的，

5、还需要对被测软件系统的 方方面面都要有了解，比如软件体系构架，网络拓扑等知识。这就如同一个技艺高超的木 匠，并不是因为他背熟了凿子，锤子的说明书，而是他能结合木材的质地和尺寸，用凿子 和锤子这些工具做出一把精巧的椅子来。那么在性能测试中，人的智慧活动体现在哪里呢?首先性能测试也是测试的一种，这就意味着做性能测试也要写测试案例。你所作的 性能测试能不能足以支持找出性能测试瓶颈，和你在初期设计的测试案例关系甚为重要。 我曾写过对一个软件系统的不下十个性能测试场景案例，等后来运行时却发现我必须增补 几个案例才能找到瓶颈，而原来十多个案例其实重复甚多。如果你要写出好的不重复的性 能测试案例来，你就得对

6、被测软件系统有一定的了解。在这里，我顺便插一句，在目前测试界总在争论测试人员需不需要懂编程，需不需要 有开发经验这种问题，这完全是本末倒置，忘记了测试人员的目标是什么，测试目标就是 写出好的测试案例，好的测试案例就是发现了一个原来未曾发现的软件bug。那么一个测 试人员知识体系是否够用的标准就是能不能写出一个好的测试案例。而针对不同类型的测 试，所需的知识深度是不一样的，有的是不需编程知识，比如界面测试;有的是必须有开发 经验的，比如接口测试，不能一概而论。对于性能测试来讲，我个人认为，测试人员倒不一定非要有开发经验，但是应该有一 个对软件体系结构了解全面的知识。为什么呢?做性能测试时，如果从

7、客户端施压一次就符 合性能指标，碰到这种情况您就偷着乐吧，因为在你的指标场景下，软件系统中就不存在 性能瓶颈，您也就不用费心去找了。但是大多数情况下，我们在做性能测试时，都不能顺 利达到性能指标，可能server响应超时了，也可能是用户死掉了，在日志里抛出了一堆 error，这种情形是非常常见，所以在我们在一开始设计性能测试方案时，就应该考虑为寻 找性能瓶颈而设计测试案例。这时我们就需要知道在整个软件系统中，有哪些节点，在哪 些地方可能存在瓶颈，比如一个B/S系统就有IE client物理网络web serverapp server -DB这样的一个压力流串。每个节点的每个模块都有可能成为瓶颈

8、。瓶颈的产生可能由 于模块配置引起，也可能由于模块本身引起。这都需要我们设计测试案例来发现的。一般 地，我自己常用的感觉也比较方便的方法是，设计一组性能测试案例来验证一个节点是否 存在瓶颈，这组case中尽量保持其他节点不变，来改变这个节点的配置，并监控此节点的 各种指标。这里说起来就有很多话了，不是一言两语能说得清的。以后有时间可以找个专 题来慢慢跟大家讨论。使用loadrunner的VU生成脚本。脚本的生成方式就两种，一种是自写或嵌入源代 码，一种是录制生成。常常听见有人说，这两种方式中首选录制生成脚本，因为它简单且 智能化。但我个人总觉得手写脚本要好一些，因为：可读性好，流程清晰，检查点

9、截取含义明确。业务级的代码读起来总比协议级的代 码更易让人理解，也更容易维护，必要时可建立一个脚本库。而录制生成的代码大多没有 维护的价值，现炒现卖。手写的程序相比录制的脚本更能真实地模拟应用运行。因为录制的脚本是截获了网 络包，生成了协议级的代码，而略掉了 client端的处理逻辑。举个例子，用VU录制一个 运行script和applet的IE行为，它只会生成http协议的API，在IE中运行的applet和 script不会被模拟到，这就不是一个完整的系统。手写程序相比录制脚本更能增加测试人员的技术含量。开发和测试能力双重提高， 何乐而不为呢?loadrunner提供了 java user

10、，vb user，c user等语言类型的脚本，就是给我们 开发脚本用的，而不是录制用的。脚本不管录制也好，还是手写也好，选择的时候应该以脚本模拟程序真实有效为准， 结合项目进度，开发难易程度等因素考虑。在这里我想要说的是，开发一个好的脚本是成功性能测试的必要条件。一个好的脚本 应该能够最大程度再现client程序行为。如上面那个例子，脚本只模拟了 client端的部分行 为，有一些没有模拟到，那么client的瓶颈就有可能被忽略了。我曾吃过一个亏，自己写 了一个java socket脚本去联server，但是忽略了 client端的界面下的业务逻辑，用我的脚本 做性能测试通过，全部OK，但是

11、真实用户一上线，client终端界面接受了大量的server信 息，导致client进程死掉了。痛哉，痛哉。组建并执行性能测试场景。从VU运行成功到controller运行成功，一般需要以下几个步骤（我也是从英文论坛上 看到的，觉得不错，拿出来共享）：确认在VU里SUSI（单用户单循环次数single user & single iteration）确认在VU里SUMI（单用户多循环次数single user & multi iteration）确认在 controller 中 MUSI（多用户单循环次数 multi user & single iteration）确认在 controller

12、 中 MUMI（多用户多循环次数 multi user & multi iteration）做这样一个步骤划分是有道理的，第一步骤是验证脚本编写的正确，第二步骤可以验 证数据池是否正常运作。第三步骤验证并发功能，第四步骤是最终目的，验证软件系统的 性能。在论坛上看到一些朋友提的问题，有一些就是于此的，在controller中运行场景时出 现问题，首先得保证VU中运行成功，这是一个显然的逻辑。软件工程中把软件开发的种 种行为都要制定一个proccess，即过程，性能测试也是如此，按照过程来调试脚本和场 景，能及早发现问题和定位问题。除非是高手，烂熟于心中，才能超越proccess而不出问 题。场

13、景是把虚拟用户和交易数按一定规则组织起来去模拟真实世界的业务行为。这其实 是把单个用户的行为复制，连接。场景的组织通常和真实世界的业务规则有很大关系。做个如下可能并不恰当的比喻：脚本像演员，场景就像表演的舞台，而测试工程师是导演，多少个演员，怎么在 舞台上演出，都由导演说了算，而剧情又不能离谱，脱离现实，否则就要砸锅了。注意， 导演的职责不光是确保演出能顺利结束，而且还要同时观察和收集观众的反馈信息，以确 认这次演出是否成功。同样的也是，性能测试人员不光是看场景是否得到顺利的执行，同时还要收集各 个server的反馈信息，以确认软件系统的性能表现是否正常。在真实世界中的用户业务规则要转换到可操

14、作的性能指标是需要分析和计算的。 当然这通常是市场需求分析人员干的活，但我觉得测试人员应该在做性能测试时，对这些 指标进行理解，知道为什么要这样做。有时有的性能指标并不清楚和准确，还需要测试人 员来分析。比如一个性能指标：要求软件系统支持每分钟700用户的登陆行为。这对于测 试人员来说，其实是一个不确切的性能需求。这指的是瞬时并发用户700，在一分钟的响 应时间要求下登陆系统?还是在一分钟内陆续有700个用户登入软件系统即可?这两种场景 其实对软件系统的压力是不同的，第一种显然大，第二种要小一些。甚至有的性能需求就 是支持50000注册用户，这种需求就更需要分析了，还要引入一些业务发生概率算法

15、模型 来做。这已经不是性能测试人员的职责了，但由于目前有不少软件公司流程不规范，或者 有流程没执行，这些工作都要测试人员来做了，不过也好，正好是锻炼的机会。分析结果数据，找到软件系统性能瓶颈上面说了，做了那么多，就是为了本步骤-寻找软件系统性能瓶颈。个人认为寻找性能瓶颈是一个非常有挑战性的工作，毛主席曾经说过：一个优秀 的指战员就是能够根据已有的客观形势，制定作战计划，然后在作战过程中，发现计划与 执行不符的地方，分析，然后调整作战计划，缩小计划和战势的误差。简明一句：就是一 个理论和实践结合的过程，一个人的主观思想和客观现实的结合过程（注明：本人是毛主席 老人家的忠实fans）。在性能测试中

16、，测试方案就是我们的作战计划，执行性能测试就是我们的作战战 场。在性能测试中，可能会发现种种意想不到的问题。当然一个经验足够丰富的性能测试 专家可能会在测试之前就能考虑全面，使测试方案吻合测试执行实际情况，并一举找出性 能瓶颈。我sunshinelius不是专家水平，当然就要匆忙应对和分析性能测试中出现的问题， 并有可能会修改测试方案，增加必要的test case，删除没用的test case。总之，性能测试是 一个不断修改测试方案，反复执行test case的过程，直至越来越逼近性能瓶颈。在此过程 中，需要了解很多的知识，知识了解得越多，就越接近软件系统运行的真相，也就能找出 性能瓶颈了。比如：loadrunner要是调用程序员的程序，服务器资源占用情况可能是追查瓶颈的 一个线索，但如果是标准中间件，那就没那么简单了，比如oracle数据库的某项参数设得 不对，照样会造成数据库瓶颈，应用程序调用数据库的API写法不对，比如未使用软解析 变量，也有可能导致数据库瓶颈。这些瓶颈都不会反映在 cpu，内存使用量上等指标上 的。对于这种情况，一方面需要对中间件有一定的了解，知道哪些参数有什么作用， 怎么可调的，另外还可能使用中间件的专有监测工具，来分析。lr的性能计数器是不够用 的。个人体会，查找瓶颈的难易程度，由易到难服务器硬件瓶颈-网络瓶颈-应用瓶颈-服务器操作系统