30个小时发现loadrunner严重的bug
Loadrunner 调用dll时候，如果dll是线程或进程安全的，但是经过loadrunner调用dll的时候，就会变成线程不安全的，经过30个小时的实验，个人认为95%是loadrunner一个非常严重的bug,因为loadrunner用lr_load_dll(或用全局)装载动态链接库的时候，不止装载一次,无论dll里面的函数和里面的静态、全局变量在内存地址都是不唯一的，详细介绍，附件，如果有好的解决方案或我说错了也可跟我联系,MSN:blzhang1@hotmail.com QQ:652466006. 佩服楼主，看了下楼主的日志，越发觉得编码与测试密不可分。顺便问下，楼主的lr是什么版本的？回复 2# 的帖子
lr8.1 所以说嘛，工具哪这么完美~:lol :lol真得啥都能用工具，早都失业了～ 谢谢楼主的精彩日志～
辛苦了
我觉得这个问题真的很需要大家共同探讨一下 我觉得，LR调用DLL的内容就应该要考虑清楚，有的东西是不应该如此调用的，我这边也有这种问题，我用LR写出来的测试代码就发现recv是不对的，但人家开发用VC自己写的就总是对的，结果证明，他们的测试想法是不对的，今天大批量发现了recv接收不到的问题，用LR做测试，代码我认为是越少越好，简单最重要，另外要尽可能的模仿客户程序的动作，不要写多余代码！回复 7# 的帖子
楼上说的对。但我提出几点：1.真实的场景是不存在的，像我这个除非调用exe,否则无法模拟真实的场景，所以只有调用dll
2.socket有很深的内容，阻塞和非阻塞，同步和异步，loadrunner是没办法实现非阻塞的
3.你那大批量recv是很耗cpu的，因为用的是阻塞模式，所以大批量的recv是收不到的。
真实的情况下会用异步模式的，所以。。。。
4.loadrunner毕竟是个产品，也有好的，也有不好的
5.我那个真实的情况就是在dll函数里面发送100次，至于发了多少次，只有写到文件里面才知道，你要知道1000个用户写到不同的文件然后再看是很麻烦的，那10000个用户你怎么做呢
6.有时我觉得自己写压力测试工具比loadrunner好多了，还可以尽量模拟真实的场景，因为客户是用许多函数凑成进行发包的，你用loadrunner只是简单的模拟哟，举个例子:loadrunner:lrs_create_socket,实际上客户那边用Socket,Bind...这些都是不一样的，用户多的情况下会有许多误差的。。。。
7.loadrunner为什么流行，还不是因为简单么，录脚本，参数化，跑脚本，看结果。。。。个人认为用多线程调用开发写的函数才是非常真实的，
最后我说：loadrunner只能70%进行模拟真实场景，而自己写代码可以90%,因为自己写代码会调用开发写的class或函数呀。。。。 如果客户用了bind,甚至select，当然就要自己写了，但我就不明白一个客户端软件，一般来说都是send与recv了，比如登陆，一定是一个用户在登陆界面上点了登陆，然后等着吧收返回的数据验证结果吧，客户端用bind，select的情况很少吧！一般都是服务程序才用。以接收为例，我们开发人员写的就是select的方式判断，问题是我们一个用户谁会在一台机器上开100个客户端，然后还要开一个单的线程来检测recv？什么客户端程序是这样运作的？这么一来这个测试就已经同原来客户程序的行为大大不相同了，除了能测试出服务器的问题外，如果以用户视角来看，这个测试就有问题了嘛！ loadrunner是没办法实现非阻塞的
之所以LR不实现这个，我想一个是可以DLL，另一个原因，也是LR是客户端的数据模拟吧！
真实的情况下会用异步模式的，所以。。。。,我说我怎么总有收不到的呢，我问问看，可能他们就是在客户断用了异步接收吧！
我想用IP欺骗来解决这个问题，不知道行不行，下午来试，再不行，就考虑你说的了！
[ 本帖最后由 zengyixun 于 2008-12-2 14:34 编辑 ] 大家可以试试webking，不错的！
我到亿道申请的压力测试工具，很不错的～～ webking？从名字看是web的？我们现在在谈c/s问题
试过了，不行，接收的量一上去，就收不到了，另用VC写了个异步监控的，就能看到服务器程序确实是发送了的，真XXOO！看来要另想办法了。也用你的方法吧！
WSAAsyncSelect应该可以解决这个问题！
[ 本帖最后由 zengyixun 于 2008-12-2 15:26 编辑 ] 我觉得你的方案有两个问题：
1、如果只测试send，以此总方式来测试丢包率的话，视角是服务器视角，其实就少了一半，应该用用户视角来测试，应该是算上客户端程序真实发送了多少，最终又接收到了多少个应答，也可能服务端接到了，也发送了，但这个过程也还有丢包的可能，甚至是服务端收到了很多，而在发送中丢到了发送缓冲就算成功了，但时间性呢？对客户端来说，你来晚了也是不可以的。可以一个详细的测试过程，还包括从recv中分析取值，再成为后一个send的输入参数，所以还有很多recv上的事情要处理的。
2、写文件的方式总是不太好，这样搞得你自己这边的磁盘成瓶颈了，是不是用一些变量来保存计算数量值要好些。另外是不是也可以用LR提供的相关输出函数来记录？
[ 本帖最后由 zengyixun 于 2008-12-2 15:45 编辑 ] 会不会和LR的正版/D版有关？
曾经遇到过 LR对字符转义的问题。
回复 13# 的帖子
呵呵1.这是UDP方式不是TCP方式，客户重点说明的。。。。
2.lr_output_message提供写文件功能，但写到不同文件并且还有其他日志，什么MessageID,vuser_init，1000个文件就把你看死，保存变量那怎么输出呢？？？？
项目要的是丢包率，而不是响应时间，所以等等也无所谓 无论我的方法不对，或者想法有问题，总之，调用lr_load_dll应该只能装载一次，在内存地址都是唯一的，loadrunner的出现使大家省去了许多控制线程同步和互斥的，但如果真是我所说的那个问题，毕竟是个严重的bug........
被loadrunner搞的真烦，要是我自己写压力测试工具，早就写好了，，，
刚才发现loadrunner又有个严重的bug,改天跟大家说说。。。。。 LR做c/s是挺烦的，一个测试工具这么多bug，是不是他们公司自己的测试做得不好造成的，让我们怎么相信他们呢，呵呵，我这几天也在测UDP的的应用，send是还简单的啦，我都没有你的烦恼，如果你这种只关系到服务器的话，又只是send，我觉得应该不用搞这么复杂，我现在头大的就是要处理recv的情况，接收一多，length就为0，接收要为0的话，我还怎么分析数据呀！唉，头大！
