51Testing软件测试论坛

标题: 让loadrunner走下神坛(全） [打印本页]

作者: sunshinelius 时间: 2004-12-9 11:40
标题: 让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 ]

作者: wghong 时间: 2004-12-9 14:06
在学习loadrunner的过程中，早已察觉到对性能测试方案制定执行更为重要。看了本文，这种思路更加清晰和明确。但是，不得不承认，现在做测试的，甚至是性能测试的朋友，对系统，对网络的知识远远不足以解决“人”进行“智慧活动”的需要。作为测试队伍新进人员，更想了解的是该怎样进行性能测试，性能测试的工作如何开展，性能测试的得到的数据应该怎样分析等等。在lr的学习中，曾放下对最后analys部分的学习，留意论坛网络中的这些资料，但是结果很让人失望，这方面的言论和资料是微乎其微的。因此，看了sunshinelius的这部分文章，就希望论坛以后能出现更多的关于压力测试如何开展和进行的好文出来

作者: plumtina 时间: 2004-12-9 16:07
分析的不错。
对于我们测试人员来说，可以手写一些功能和性能脚本的确可以提高我们自己。可是一个比较大的问题在于，我们手写出来的脚本也是一个编码的过程，谁来对我们的脚本进行测试呢？现在有很多业务逻辑性强的项目，选择录制VU脚本的初衷可能就在于，我们测试员对于项目所涉及的业务的认知程度。有时直接导致脚本本就是错的，无法真实反映系统运行的场景，以至于测了也是白测。

作者: zhangfh 时间: 2004-12-11 14:15
标题: 说出了心里话
目前大多数公司的测试队伍很薄弱，一个很大的项目只有一个测试员，工作强度可想而知并且好多测试员的编程水平很低，所以手写的测试脚本难免会有好多BUG，这样一来，导致的错误就不好分析了。

作者: QA_BAY 时间: 2004-12-12 13:44
楼子写得非常好!
工具是其次,主要还是人!
数据是死的,
思想才是活,
怎么想,怎么做,都在测试人员的身上,
所以做测试人员在各方面能力都要很强!

作者: 飞飞 时间: 2004-12-16 19:50
怎么区分哪些是业务级的代码哪些是协议级的代码？
我对LR的代码不太熟悉，录了（web）一个脚本，都是以web_url（... LAST）组成的。如果想循环一段脚本，怎么写啊？难度用for循环吗？LR好像不能用for。哪怎么编写循环的脚本呢？
望高手赐教！

作者: Rico.Wang 时间: 2004-12-17 17:55
楼主的大部分观点都赞同，但是如果要求测试人员自己编写测试脚本的话，一个很长的操作流程编写成脚本需要多长时间？而且在编写过程中会不会出现bug，这些都是需要考虑的问题。我认为如果逻辑简单的case可以直接编写脚本，以后改也方便，而那些流程很复杂的case最还还是用录制的方式，只要能读懂脚本，配合适当的参数也可以达到很好的测试目的，我想没有那个项目能留给测试人员很多的时间去调试脚本的，我所碰到的情况大多数都是一天录制编译脚本，一天测试生成结果报告，主要的时间还都是在场景设计和测试用例的编写上。

作者: zengyixun 时间: 2004-12-24 21:11
我到是觉得楼主所说的client的问题应该放到功能测试来做。

作者: sunshinelius 时间: 2004-12-27 09:29
上面client端的问题在功能测试中是发现不了的。而且我们要做的是整个系统的性能测试，clent端也是一部分。当然，很多的分布式系统在设计时就能避免在client端出现瓶颈，但是如果client端嵌入了一些业务逻辑，那就要考虑瓶颈是否会出现在clent端。

作者: sunshinelius 时间: 2004-12-27 09:45
实在不好意思，论坛上朋友的问题不能及时跟贴。
由于年终工作比较忙，不能经常挂在网上，往往来了看看大家就走。另外，大家的loadrunner水平提高了很多，提的问题有的我也不能解答了。在此，向各位道个歉，在2005年，sunshinelius要努力地不让大家失望。

作者: wghong 时间: 2004-12-27 11:22
sunshinelius，应该是我们大家向你致谢了。很多个国内论坛，这里是讨论loadrunner最热闹的其中一个。看了你的整篇文章，真的很有收获，致谢了~~

作者: songfun 时间: 2005-1-2 16:03
“在目前测试界总在争论测试人员需不需要懂编程，需不需要有开发经验这种问题，这完全是本末倒置，忘记了测试人员的目标是什么，测试目标就是写出好的测试案例，好的测试案例就是发现了一个原来未曾发现的软件bug。”

斑竹这篇文章说到我心里去了，实在很经典！
帮你顶！

作者: 非猫 时间: 2005-1-5 08:55
就要接触性能测试,还不知道应该做哪些准备工作(脸红), ,LoadRunner以前有看过,学习中........,希望给与建议, 谢谢先

作者: wangying1982_0 时间: 2005-1-5 16:52
大家新年好！
刚刚入门，现在老大要求我们自学LoadRunner，但是感觉一头雾水，以后还要多请教各位。

作者: THOR0066 时间: 2005-1-6 13:08
为什么右边的文章有两三个字节看不清楚？
是51TESTING的问题吗？

作者: loadtest 时间: 2005-1-6 13:39
佩服楼主！
个人使用LoadRunner也超过3年。总是觉得很多东西还是没有弄懂，比如说到编程那一块儿。从我做过的Case来看，一般情况是，如果能够方便通过录制解决，就直接使用VU录制，当然是在客户认可测试脚本能够符合他们要求的前提下。如果很多情况下不能够直接模拟录制脚本，那就需要使用相关的模板直接编写脚本。手写脚本的时候真正需要的就是对业务过程的清晰了解以及对于编程语言的熟练掌握。
说起Loadrunner，真的好多心里话想说，还是有机会和大家一块探讨共同进步吧。

作者: 阳光柳叶 时间: 2005-1-8 19:33
精辟
楼主我要崇拜你了

作者: secat 时间: 2005-1-18 11:04
写的非常好，但对我这个初学者来说，感觉实现很难，只有希望2005年努力一把，也希望版主多贴些好贴，让我们这些新人成长的快点：）

作者: sunflowers 时间: 2005-1-25 10:01
楼主总结的太精辟了,,值得学习啊!
不知道楼主能否贴几个性能测试的测试用例上来啊!
万分感谢啊!

作者: firefly200 时间: 2005-2-20 22:25
标题: 请问：我想测试c/c++的exe如何进行测试呢？
to sunshinelius

你的内容很精辟，我在应用中多次测试网页，但是对于C/C++的exe,一直找不到一个妥善的方法，特别包含语音这些东西，有空可以向你请教，QQ：4594712

作者: sunnyhatcn 时间: 2005-3-7 14:34
楼顶的主对于测试这部分了解的真的很深刻了。应该是测试圈里面较为突出的一员了吧！
谢谢，楼主！测试的路还是很远呐！

作者: super 时间: 2005-3-8 17:17
谢谢楼主了

作者: asdfghjk 时间: 2005-3-10 15:23
对我很有帮助

作者: xihong2004 时间: 2005-3-10 19:39
我想测试c/c++的exe如何进行测试呢？

在录脚本的时候，要选什么协议？

作者: chenpeng908 时间: 2005-3-11 14:09
只是刚刚开始用

作者: chenpeng908 时间: 2005-3-11 14:09
谁能告诉我看那些书好呀

作者: hxf 时间: 2005-3-14 16:15
我现在还是一个初级的性能测试员，希望大家多指教。

作者: 解放军 时间: 2005-3-18 17:00
多多努力，谢谢斑竹

作者: zension 时间: 2005-3-22 19:05
标题: 多谢了
从中我收获了不少东西，正好我们要开展性能测试方面的工作

作者: raindrop 时间: 2005-3-23 18:20
标题: 版主的这篇文章每次阅读的体会都不一样...
深刻!

作者: 0421 时间: 2005-3-24 13:21
版主：您好！可以给我些测试案例吗？？越多越好，你可以把你的必要的东西清除了，我写了些案例，只有几个，主要是统计方面的，对于性能还没做过，如果你能给我一些，哪就不胜感激了！！！我的联系方式：afei1154883@hotmail.com,信箱：afei-115@163.com;其他人能给我一些，也十分感谢！！

作者: xubt 时间: 2005-3-28 11:01
标题: 妙
脚本像演员，场景就像表演的舞台，而测试工程师是导演，多少个演员，怎么在舞台上演出，都由导演说了算，而剧情又不能离谱，脱离现实，否则就要砸锅了。注意，导演的职责不光是确保演出能顺利结束，而且还要同时观察和收集观众的反馈信息，以确认这次演出是否成功。
同样的也是，性能测试人员不光是看场景是否得到顺利的执行，同时还要收集各个server的反馈信息，以确认软件系统的性能表现是否正常。

楼主 :的这个比喻这是恰倒好处啊,妙

作者: xubt 时间: 2005-3-28 11:05
标题: 不明白验证数据池是否正常运作?
确认在VU里SUMI（单用户多循环次数single user & multi iteration）

以验证数据池是否正常运作
对于这一点
我不是很明白,楼主说得再具体一些呢?

作者: xubt 时间: 2005-4-4 11:33
标题: 请楼主出来回答呢?
上一贴子

作者: dongdai 时间: 2005-4-13 10:47
标题: 一通屁话
最恨看你这样的人，拿起筷子吃肉放下筷子骂娘的。
有种你不用，不好？你用他干吗？说那么多废话，有点意思的有没有？发贴不是臭现，不是用来体现你的高大全的，技术是做的不是说的。说些无实质的话不如不说。

作者: sunshinelius 时间: 2005-4-15 09:42
第一次听见批评的话，喜出望外。
楼上，您有没有对软件技术上的一些理解和体会，大家一起交流交流。不限于测试。

作者: xubt 时间: 2005-4-15 11:48
标题: 不为版主不回我的贴子???只回人家骂人的??????
确认在VU里SUMI（单用户多循环次数single user & multi iteration）

以验证数据池是否正常运作
对于这一点
我不是很明白,楼主说得再具体一些呢?

作者: sunshinelius 时间: 2005-4-18 09:15
如果在你的transaction中读取了数据池，那么单用户多循环中，就可以查看读取数据池是否正确。要是你的脚本根本不操纵数据池，那就无从检验了。

作者: sunshine_luo 时间: 2005-5-19 10:43
好久都没有到论坛上来了，看到楼主的这篇文章真是佩服啊！
我对“确认在VU里SUMI（单用户多循环次数single user & multi iteration）”的理解就是在脚本的模式下检查你的参数化是否成功或者说是否达到了你设计的初衷

作者: su_pay 时间: 2005-5-24 15:35
好的，谢谢，

作者: 爱情鸟 时间: 2005-5-24 16:21
xiexie

作者: sunxv 时间: 2005-5-25 16:03
标题: 刚入道的老鸟
嗯,不错,值得参考,谢谢!

作者: zjm0326 时间: 2005-6-8 13:51
毛主席他老人家还说过，美国佬是一只纸老虎，同样LR就是一只纸老虎，没什么可怕；需要的是像楼主一样能横扫千军，扫杀敌于无形中的指战员，做他手下应该是一件荣幸的事儿。实践是检验真理的唯一标准，在楼主的指引，我们去实践吧。

作者: wangzhc 时间: 2005-6-13 16:14
很有道理啊

作者: 嘻嘻哈哈 时间: 2005-7-7 21:42
很好，近期在学习LR,对我很有帮助，非常谢谢斑竹！

作者: 朝阳-海淀 时间: 2005-7-21 10:30
我是个新手，我想问问大家各位都是如何学习load runner 和win runner的？需要非常系统的学习吗？自学是否可以达到效果？

有谁能和我讲讲mercury这个公司的影响力是否很广，前景是否广阔。

谢谢各位了。

作者: gaogao 时间: 2005-7-29 13:21
写得很好，我现在还有做过这方面的测试。这篇文章对我很有帮助。谢谢楼主　：）

作者: DS 时间: 2005-7-30 00:45
长长漫路的明灯啊~~good for you

作者: damocau 时间: 2005-8-5 14:03
标题: 好文，好人，好贴。收获！感谢！
好文，好人，好贴。收获！感谢！

作者: wujialin1984722 时间: 2005-8-10 14:46
谢谢了,真有帮助

作者: thunder 时间: 2005-8-10 22:50
好人好贴，楼主不错。我也是做测试的，刚上路，还不熟悉lr，希望在这里多学点东西

作者: rien2128 时间: 2005-8-11 11:24
真是精屁啊。

作者: alier 时间: 2005-8-15 08:35
请问谁有Loadrunner7.8的用户使用手册，我是个新手急需，谁有上传一份或是发到我的邮箱里，在这里谢谢了！^_^

邮箱:buwawa80727@163.com

作者: irene 时间: 2005-8-15 16:33
的确是盏明灯，每一次看都有不一样的收获

作者: alier 时间: 2005-8-16 13:38
怎么没有人有呀，有的大家共享一下呀

作者: gcl 时间: 2005-8-18 15:09
偶也想要一个Loadrunner7.8的用户使用手册，哪位能给一个，不胜感激

邮箱：gchunlan1068@126.com

作者: wub 时间: 2005-8-19 09:01
分析得很不错！

作者: 甜栗子 时间: 2005-8-23 15:21
很有体会吗，不错

作者: phlsbg 时间: 2005-9-9 09:52
对初学者一样有帮助

作者: gslcn897 时间: 2005-9-13 13:17
获益多多，谢谢！

作者: GIGI456 时间: 2005-9-13 17:42
我刚加入，我想问一下版主，可不可以讲一下lr特点及可测的语言？

作者: rngr 时间: 2005-9-23 14:57
标题: 跪求一个Loadrunner7.8的用户使用手册
想要一个Loadrunner7.8的用户使用手册，哪位能给一个，不胜感激
rngr@tom.com

作者: zhipengli 时间: 2005-10-3 16:28
标题: 我有Loadrunner7.8的用户使用手册
我有Loadrunner7.8的用户使用手册，可惜我们公司现在不能上外网，要的话QQ加我，有机会的话我可以传给你们。我现在刚开始用8.0版本的，可是没8.0的使用手册。谁有的话传给我，我也感激不尽。呵呵。。。
QQ：46267238
email：

baige700@163.com

作者: fubaiciti 时间: 2005-10-9 14:12
很有道理
同样的脚本，在不同的测试人员手中，可以搭配出更多的场景，可以发挥出完全不同的作用，因此就更有可能发现系统的性能问题所在。
而且，对于客户需求的了解，明白客户究竟想测试什么，才可能用好工具，更好的完成工作。
还是那句话，工具是死的，人是活的。

作者: hujq 时间: 2005-10-10 18:30
标题: henhao,xiexie
henhao,xiexie

作者: evanhuang 时间: 2005-10-11 22:40
虽然自己也用过，但是从来没有这么深的了解

作者: gzqq_test 时间: 2005-10-13 10:05
标题: 写得太长啦!!!!!!!!!!!!
写得太长啦!!!!!!!!!!!! 这么多比喻,看得都累!

作者: sarine_song 时间: 2005-10-13 15:31
任何事情都不能绝对的吧,作为工具,他的产生有他的原因,还是有优点的吧

作者: pride 时间: 2005-10-14 14:31
标题: opinion
在我看来在整个测试的周期中，作为是面向客户的案例分析是极为重要的。还有一点是在最后的测试及过分析中，还得一案例分析为基础，从客户的角度去分析，经验是非常重要的！这一点我还很弱，正努力向大家学习呢

作者: sbandbt 时间: 2005-10-18 17:27
好贴~~~受益匪浅~~~~~顶~~~~

作者: bjhz 时间: 2005-10-21 15:32
写的好，真是好贴。
顶！顶！顶！

作者: lxfeng 时间: 2005-10-28 18:07
标题: 谁有LoadRunner8.0的操作手册请发一个给俺.非常感谢!
谁有LoadRunner8.0的操作手册请发一个给俺.非常感谢!

作者: vivian84 时间: 2005-11-8 13:46
我刚开始学lLoadRunner，都快让我发疯了，因为它的页面太多了，配置感觉很麻烦，有时候每一项都不知道什么意思，怎么办呢？

作者: zyhlk126 时间: 2005-11-10 14:35
标题: 很有感觉的
看看很有感觉的，虽然我只是接触loadrunner两天。觉的有很多东西要学习的

作者: hardyth 时间: 2005-12-5 11:37
支持！写的好！！！

作者: lvyingjiemm 时间: 2005-12-5 15:13
标题: 顶一个吧～～～
顶一个吧～～～，以前看过一个同标题的文章，这个很不错

作者: 恋恋冬季 时间: 2005-12-14 11:41
值得收藏。

作者: yangbing3411 时间: 2005-12-17 14:07
标题: 好东西
写的不错，希望能有更好的文章能学习到

作者: Koffer 时间: 2005-12-17 22:01
都是废话！
这么概括的一个文章，而且题目也太夸张吧！
不如提供点资料看看！
真是浪费时间看了9页的评论！

作者: lijia0912 时间: 2006-2-6 17:31
楼主说的好啊，人是万能的我支持你的说法

作者: summergk 时间: 2006-2-8 10:12
标题: 时隔一年，相逢恨晚
时隔一年，相逢恨晚

作者: weiping2000 时间: 2006-2-10 15:23
毛主席曾经说过：一个优秀的指战员就是能够根据已有的客观形势，制定作战计划，然后在作战过程中，发现计划与执行不符的地方，分析，然后调整作战计划，缩小计划和战势的误差。

真是说的太对了

作者: hicome 时间: 2006-2-11 17:57
很好帖子，希望以后楼主多写点实战经验案例，给我们这些新手借鉴借鉴那就完美了：）。。。

作者: email 时间: 2006-2-17 17:04
LR,就是易用性比较强，可是深度比较低。

作者: valentine 时间: 2006-2-20 22:39
楼主的话够精辟，赞一个！

作者: 亲亲 时间: 2006-2-23 17:52
标题: 我也要！
谁有LR8.0的使用说明，也给我一份。联系：tansun1205@hotmail.com

作者: yuanlj 时间: 2006-3-6 14:55
楼主如果能结合实际中的案例会精彩，更容易让大家理解！

作者: wuwjb1119 时间: 2006-3-21 11:21
很精彩的论点，值得学习。

作者: netcom3g 时间: 2006-3-22 12:15
拜读大作

强！

作者: 火鸟 时间: 2006-3-23 10:06
太谢谢楼主了

作者: xiaojing23 时间: 2006-4-12 18:10
标题: 好贴
学习提高

作者: 月上梅稍 时间: 2006-4-14 16:43
性能测试接触的不多，不是很领会lz！谢谢！

作者: zhou104 时间: 2006-4-20 11:41
想问一下如何用LR来自己编写测试脚本，楼主可否提供一个测试的案例出来让大家共享呢。用LR测试C/S和B/S的有什么分别没有。

作者: flsyaoair1 时间: 2006-4-28 13:11
版主：您好！你的文写的有理，心动。能给我一些用例，和相应的脚本代码，要我学学，lr初接触，不能运用！邮箱flsyaoair◎yahoo.com.cn 谢谢

作者: ayaa 时间: 2006-4-29 12:16
标题: 回复 #15 THOR0066 的帖子
希望你还可以看到这个帖子,新手想向你请教问题,感激不尽

作者: ayaa 时间: 2006-4-29 12:19
标题: 哪位有loadrunner可以提供,先谢谢了:偶得MSN:rleilei888@hotmail.com
偶是新手,望楼上的多指教

作者: 李才军 时间: 2006-4-29 14:14
感触的很多，也不知道是干吗的

作者: 沙巴克 时间: 2006-5-10 10:41
标题: 好文章~
sunshinelius说的很经典,可以补充到lr教科书里面了,工具毕竟是工具,人的主观能动性才是最关键的.

作者: Hunter 时间: 2006-5-23 01:23
能把这件事情说的如此朴实、易懂，楼主应该是对LR不是一般的熟悉了，其实在几乎完全熟悉一样东西或工具的时候，你以后做的事情都已经是超脱这个工具了！就像初学时候，我们被工具的复杂、学习资料少、入门困难所困扰，而当完全掌握他的基本功能后，剩下的就是玩转于你的鼓掌，让你的思维在工具支持的基线上飞扬！

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)