让loadrunner走下神坛(全）
作者： sunshinelius（转载请注明作者）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而不出问题。
场景是把虚拟用户和交易数按一定规则组织起来去模拟真实世界的业务行为。这其实是把单个用户的行为复制，连接。场景的组织通常和真实世界的业务规则有很大关系。
做个如下可能并不恰当的比喻：
脚本像演员，场景就像表演的舞台，而测试工程师是导演，多少个演员，怎么在舞台上演出，都由导演说了算，而剧情又不能离谱，脱离现实，否则就要砸锅了。注意，导演的职责不光是确保演出能顺利结束，而且还要同时观察和收集观众的反馈信息，以确认这次演出是否成功。
同样的也是，性能测试人员不光是看场景是否得到顺利的执行，同时还要收集各个server的反馈信息，以确认软件系统的性能表现是否正常。
在真实世界中的用户业务规则要转换到可操作的性能指标是需要分析和计算的。当然这通常是市场需求分析人员干的活，但我觉得测试人员应该在做性能测试时，对这些指标进行理解，知道为什么要这样做。有时有的性能指标并不清楚和准确，还需要测试人员来分析。比如一个性能指标：要求软件系统支持每分钟700用户的登陆行为。这对于测试人员来说，其实是一个不确切的性能需求。这指的是瞬时并发用户700，在一分钟的响应时间要求下登陆系统？还是在一分钟内陆续有700个用户登入软件系统即可？这两种场景其实对软件系统的压力是不同的，第一种显然大，第二种要小一些。甚至有的性能需求就是支持50000注册用户，这种需求就更需要分析了，还要引入一些业务发生概率算法模型来做。这已经不是性能测试人员的职责了，但由于目前有不少软件公司流程不规范，或者有流程没执行，这些工作都要测试人员来做了，不过也好，正好是锻炼的机会。
四．分析结果数据，找到软件系统性能瓶颈
上面说了，做了那么多，就是为了本步骤－寻找软件系统性能瓶颈。
个人认为寻找性能瓶颈是一个非常有挑战性的工作，毛主席曾经说过：一个优秀的指战员就是能够根据已有的客观形势，制定作战计划，然后在作战过程中，发现计划与执行不符的地方，分析，然后调整作战计划，缩小计划和战势的误差。简明一句：就是一个理论和实践结合的过程，一个人的主观思想和客观现实的结合过程（注明：本人是毛主席老人家的忠实fans）。
在性能测试中，测试方案就是我们的作战计划，执行性能测试就是我们的作战战场。在性能测试中，可能会发现种种意想不到的问题。当然一个经验足够丰富的性能测试专家可能会在测试之前就能考虑全面，使测试方案吻合测试执行实际情况，并一举找出性能瓶颈。我sunshinelius不是专家水平，当然就要匆忙应对和分析性能测试中出现的问题，并有可能会修改测试方案，增加必要的test case，删除没用的test case。总之，性能测试是一个不断修改测试方案，反复执行test case的过程，直至越来越逼近性能瓶颈。在此过程中，需要了解很多的知识，知识了解得越多，就越接近软件系统运行的真相，也就能找出性能瓶颈了。
比如：loadrunner要是调用程序员的程序，服务器资源占用情况可能是追查瓶颈的一个线索，但如果是标准中间件，那就没那么简单了，比如oracle数据库的某项参数设得不对，照样会造成数据库瓶颈，应用程序调用数据库的API写法不对，比如未使用软解析变量，也有可能导致数据库瓶颈。这些瓶颈都不会反映在cpu，内存使用量上等指标上的。
对于这种情况，一方面需要对中间件有一定的了解，知道哪些参数有什么作用，怎么可调的，另外还可能使用中间件的专有监测工具，来分析。lr的性能计数器是不够用的。
个人体会，查找瓶颈的难易程度，由易到难
服务器硬件瓶颈-〉网络瓶颈-〉应用瓶颈-〉服务器操作系统瓶颈（参数配置）-〉中间件瓶颈（参数配置，数据库，web服务器等）
记忆比较深刻的一次，用lr做了两天性能测试，指标上不去，后来使用oracle数据库的图形化性能检测工具才发现某个表的查询处理时间超长，原来索引创建得不合理，把表的索引改了之后，性能稍有提高，但还是上不去。再次排查，发现应用中有一个sql语句写得有问题，长而且耗时，改了之后，测试指标还是上不去
经过至少四轮的排查，才大功告成，最后一个除掉的瓶颈是操作系统问题（开始没有想到它，后来看系统消息，才发现已经有错误报出）
五．我再说两句
每个系统的性能测试都是一个全新的挑战！
sunshinelius恭祝loadrunner版的老朋友新朋友（你们的名字我都记得）2004年元旦快乐！2005年收获更多！
[ Last edited by sunshinelius on 2004-12-27 at 09:59 ] 在学习loadrunner的过程中，早已察觉到对性能测试方案制定执行更为重要。看了本文，这种思路更加清晰和明确。但是，不得不承认，现在做测试的，甚至是性能测试的朋友，对系统，对网络的知识远远不足以解决“人”进行“智慧活动”的需要。作为测试队伍新进人员，更想了解的是 该怎样进行性能测试，性能测试的工作如何开展，性能测试的得到的数据应该怎样分析等等。在lr的学习中，曾放下对最后analys部分的学习，留意论坛网络中的这些资料，但是结果很让人失望，这方面的言论和资料是微乎其微的。因此，看了sunshinelius的这部分文章，就希望论坛以后能出现更多的关于压力测试如何开展和进行的好文出来 分析的不错。
对于我们测试人员来说，可以手写一些功能和性能脚本的确可以提高我们自己。可是一个比较大的问题在于，我们手写出来的脚本也是一个编码的过程，谁来对我们的脚本进行测试呢？现在有很多业务逻辑性强的项目，选择录制VU脚本的初衷可能就在于，我们测试员对于项目所涉及的业务的认知程度。有时直接导致脚本本就是错的，无法真实反映系统运行的场景，以至于测了也是白测。
说出了心里话
目前大多数公司的测试队伍很薄弱，一个很大的项目只有一个测试员，工作强度可想而知并且好多测试员的编程水平很低，所以手写的测试脚本难免会有好多BUG，这样一来，导致的错误就不好分析了。 楼子写得非常好!工具是其次,主要还是人!
数据是死的,
思想才是活,
怎么想,怎么做,都在测试人员的身上,
所以做测试人员在各方面能力都要很强! 怎么区分哪些是业务级的代码哪些是协议级的代码？
我对LR的代码不太熟悉，录了（web）一个脚本，都是以web_url（... LAST）组成的。如果想循环一段脚本，怎么写啊？难度用for循环吗？LR好像不能用for。哪怎么编写循环的脚本呢？
望高手赐教！ 楼主的大部分观点都赞同，但是如果要求测试人员自己编写测试脚本的话，一个很长的操作流程编写成脚本需要多长时间？而且在编写过程中会不会出现bug，这些都是需要考虑的问题。我认为如果逻辑简单的case可以直接编写脚本，以后改也方便，而那些流程很复杂的case最还还是用录制的方式，只要能读懂脚本，配合适当的参数也可以达到很好的测试目的，我想没有那个项目能留给测试人员很多的时间去调试脚本的，我所碰到的情况大多数都是一天录制编译脚本，一天测试生成结果报告，主要的时间还都是在场景设计和测试用例的编写上。 我到是觉得楼主所说 的client的问题应该放 到功能测试来 做。 上面client端的问题在功能测试中是发现不了的。而且我们要做的是整个系统的性能测试，clent端也是一部分。当然，很多的分布式系统在设计时就能避免在client端出现瓶颈，但是如果client端嵌入了一些业务逻辑，那就要考虑瓶颈是否会出现在clent端。 实在不好意思，论坛上朋友的问题不能及时跟贴。
由于年终工作比较忙，不能经常挂在网上，往往来了看看大家就走。另外，大家的loadrunner水平提高了很多，提的问题有的我也不能解答了。在此，向各位道个歉，在2005年，sunshinelius要努力地不让大家失望。 sunshinelius，应该是我们大家向你致谢了。很多个国内论坛，这里是讨论loadrunner最热闹的其中一个。看了你的整篇文章，真的很有收获，致谢了~~ “在目前测试界总在争论测试人员需不需要懂编程，需不需要有开发经验这种问题，这完全是本末倒置，忘记了测试人员的目标是什么，测试目标就是写出好的测试案例，好的测试案例就是发现了一个原来未曾发现的软件bug。”
斑竹这篇文章说到我心里去了，实在很经典！
帮你顶！ 就要接触性能测试,还不知道应该做哪些准备工作(脸红), ,LoadRunner以前有看过,学习中........,希望给与建议, 谢谢先 大家新年好！
刚刚入门，现在老大要求我们自学LoadRunner，但是感觉一头雾水，以后还要多请教各位。 为什么右边的文章有两三个字节看不清楚？
是51TESTING的问题吗？ 佩服楼主！
个人使用LoadRunner也超过3年。总是觉得很多东西还是没有弄懂，比如说到编程那一块儿。从我做过的Case来看，一般情况是，如果能够方便通过录制解决，就直接使用VU录制，当然是在客户认可测试脚本能够符合他们要求的前提下。如果很多情况下不能够直接模拟录制脚本，那就需要使用相关的模板直接编写脚本。手写脚本的时候真正需要的就是对业务过程的清晰了解以及对于编程语言的熟练掌握。
说起Loadrunner，真的好多心里话想说，还是有机会和大家一块探讨共同进步吧。 精辟
楼主我要崇拜你了 写的非常好，但对我这个初学者来说，感觉实现很难，只有希望2005年努力一把，也希望版主多贴些好贴，让我们这些新人成长的快点：） 楼主总结的太精辟了,,值得学习啊!
不知道楼主能否贴几个性能测试的测试用例上来啊!
万分感谢啊!
请问：我想测试c/c++的exe如何进行测试呢？
to sunshinelius你的内容很精辟，我在应用中多次测试网页，但是对于C/C++的exe,一直找不到一个妥善的方法，特别包含语音这些东西，有空可以向你请教，QQ：4594712
