使用LoadRunner不容易解决的问题

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

　　LoadRunner 的特点

　　轻松创建虚拟用户

　　使用 LoadRunner 的 Virtual User Generator，您能很简便地创立起系统负载。该引擎能够生成虚拟用户，以虚拟用户的方式模拟真实用户的业务操作行为。它先记录下业务流程，然后将其转化为测试脚本。利用虚拟用户，您可以在 Windows，UNIX 或 Linux 机器上同时产生成千上万个用户访问。所以 LoadRunner 能极大的减少负载测试所需的硬件和人力资源。另外，LoadRunner 的 TurboLoad 专利技术能提供很高的适应性。TurboLoad 使您可以产生每天几十万名在线用户和数以百万计的点击数的负载。

　　创建真实的负载

　　Virtual users 建立起后，您需要设定您的负载方案，业务流程组合和虚拟用户数量。用 LoadRunner 的 Controller，您能很快组织起多用户的测试方案。Controller 的 Rendezvous 功能提供一个互动的环境，在其中您既能建立起持续且循环的负载，又能管理和驱动负载测试方案。而且，您可以利用它的日程计划服务来定义用户在什么时候访问系统以产生负载。这样，您就能将测试过程自动化。同样您还可以用 Controller 来限定您的负载方案，在这个方案中所有的用户同时执行一个动作---如登陆到一个库存应用程序——来模拟峰值负载的情况。另外，您还能监测系统架构中各个组件的性能——包括服务器，数据库，网络设备等——来帮助客户决定系统的配置。

　　Loadrunner无疑是一个强大有力的压力测试工具。它的脚本可以录制生成，自动关联;测试场景可以面向指标，多方监控;测试结果图表显示，拆分组合。相信有人这样想象过：拿着一张性能指标标准列表和测试数据相比较，如同PH试纸一样，遇碱则蓝，遇酸则红，一目了然，之后就可以大声地喊道：我找到了软件系统的性能瓶颈!

　　然而，我们无论在loadrunner前面加多少个“强大”、“智能”的形容词，别忘了其最终修饰的只是一个名词-“工具”。《大话西游》中也有相当精辟的论断：官兵?最多也只是个长了痔疮的官兵!把loadrunner比喻成长了痔疮的官兵有点粗俗，但loadrunner它是个工具，那么是否能够找到性能瓶颈就取决于使用工具的人，而不是工具本身。要做一个成功的性能测试，仅读懂和精通了loadrunner的使用手册是不够的，还需要对被测软件系统的方方面面都要有了解，比如软件体系构架，网络拓扑等知识。这就如同一个技艺高超的木匠，并不是因为他背熟了凿子，锤子的说明书，而是他能结合木材的质地和尺寸，用凿子和锤子这些工具做出一把精巧的椅子来。那么在性能测试中，人的智慧活动体现在哪里呢?

　　一.首先性能测试也是测试的一种，这就意味着做性能测试也要写测试案例。你所作的性能测试能不能足以支持找出性能测试瓶颈，和你在初期设计的测试案例关系甚为重要。我曾写过对一个软件系统的不下十个性能测试场景案例，等后来运行时却发现我必须增补几个案例才能找到瓶颈，而原来十多个案例其实重复甚多。如果你要写出好的不重复的性能测试案例来，你就得对被测软件系统有一定的了解。

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

　　对于性能测试来讲，我个人认为，测试人员倒不一定非要有开发经验，但是应该有一个对软件体系结构了解全面的知识。为什么呢?做性能测试时，如果从客户端施压一次就符合性能指标，碰到这种情况您就偷着乐吧，因为在你的指标场景下，软件系统中就不存在性能瓶颈，您也就不用费心去找了。但是大多数情况下，我们在做性能测试时，都不能顺利达到性能指标，可能server响应超时了，也可能是用户死掉了，在日志里抛出了一堆error，这种情形是非常常见，所以在我们在一开始设计性能测试方案时，就应该考虑为寻找性能瓶颈而设计测试案例。这时我们就需要知道在整个软件系统中，有哪些节点，在哪些地方可能存在瓶颈，比如一个B/S系统就有IE client→物理网络→web server→app server→DB这样的一个压力流串。每个节点的每个模块都有可能成为瓶颈。瓶颈的产生可能由于模块配置引起，也可能由于模块本身引起。这都需要我们设计测试案例来发现的。一般地，我自己常用的感觉也比较方便的方法是，设计一组性能测试案例来验证一个节点是否存在瓶颈，这组case中尽量保持其他节点不变，来改变这个节点的配置，并监控此节点的各种指标。这里说起来就有很多话了，不是一言两语能说得清的。以后有时间可以找个专题来慢慢跟大家讨论。

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

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

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

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

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

　　在这里我想要说的是，开发一个好的脚本是成功性能测试的必要条件。一个好的脚本应该能够最大程度再现client程序行为。如上面那个例子，脚本只模拟了client端的部分行为，有一些没有模拟到，那么client的瓶颈就有可能被忽略了。我曾吃过一个亏，自己写了一个java socket脚本去联server，但是忽略了client端的界面下的业务逻辑，用我的脚本做性能测试通过，全部OK，但是真实用户一上线，client终端界面接受了大量的server信息，导致client进程死掉了。痛哉，痛哉。

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

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

　　1. 确认在VU里SUSI(单用户单循环次数single user & single iteration)

　　2. 确认在VU里SUMI(单用户多循环次数single user & multi iteration)

　　3. 确认在controller中MUSI(多用户单循环次数multi user & single iteration)

　　4. 确认在controller中MUMI(多用户多循环次数 multi user & multi iteration)

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

原文转自：http://www.ltesting.net