30个小时发现loadrunner严重的bug

zengyixun

我觉得，LR调用DLL的内容就应该要考虑清楚，有的东西是不应该如此调用的，我这边也有这种问题，我用LR写出来的测试代码就发现recv是不对的，但人家开发用VC自己写的就总是对的，结果证明，他们的测试想法是不对的，今天大批量发现了recv接收不到的问题，用LR做测试，代码我认为是越少越好，简单最重要，另外要尽可能的模仿客户程序的动作，不要写多余代码！

zengyixun

如果客户用了bind,甚至select，当然就要自己写了，但我就不明白一个客户端软件，一般来说都是send与recv了，比如登陆，一定是一个用户在登陆界面上点了登陆，然后等着吧收返回的数据验证结果吧，客户端用bind，select的情况很少吧！一般都是服务程序才用。以接收为例，我们开发人员写的就是select的方式判断，问题是我们一个用户谁会在一台机器上开100个客户端，然后还要开一个单的线程来检测recv？什么客户端程序是这样运作的？这么一来这个测试就已经同原来客户程序的行为大大不相同了，除了能测试出服务器的问题外，如果以用户视角来看，这个测试就有问题了嘛！

zengyixun

loadrunner是没办法实现非阻塞的
之所以LR不实现这个，我想一个是可以DLL，另一个原因，也是LR是客户端的数据模拟吧！
  真实的情况下会用异步模式的，所以。。。。,我说我怎么总有收不到的呢，我问问看，可能他们就是在客户断用了异步接收吧！
我想用IP欺骗来解决这个问题，不知道行不行，下午来试，再不行，就考虑你说的了！

[ 本帖最后由 zengyixun 于 2008-12-2 14:34 编辑 ]

zengyixun

webking？从名字看是web的？我们现在在谈c/s问题
试过了，不行，接收的量一上去，就收不到了，另用VC写了个异步监控的，就能看到服务器程序确实是发送了的，真XXOO！看来要另想办法了。也用你的方法吧！
WSAAsyncSelect应该可以解决这个问题！

[ 本帖最后由 zengyixun 于 2008-12-2 15:26 编辑 ]

zengyixun

我觉得你的方案有两个问题：
1、如果只测试send，以此总方式来测试丢包率的话，视角是服务器视角，其实就少了一半，应该用用户视角来测试，应该是算上客户端程序真实发送了多少，最终又接收到了多少个应答，也可能服务端接到了，也发送了，但这个过程也还有丢包的可能，甚至是服务端收到了很多，而在发送中丢到了发送缓冲就算成功了，但时间性呢？对客户端来说，你来晚了也是不可以的。可以一个详细的测试过程，还包括从recv中分析取值，再成为后一个send的输入参数，所以还有很多recv上的事情要处理的。
2、写文件的方式总是不太好，这样搞得你自己这边的磁盘成瓶颈了，是不是用一些变量来保存计算数量值要好些。另外是不是也可以用LR提供的相关输出函数来记录？

[ 本帖最后由 zengyixun 于 2008-12-2 15:45 编辑 ]

zengyixun

LR做c/s是挺烦的，一个测试工具这么多bug，是不是他们公司自己的测试做得不好造成的，让我们怎么相信他们呢，呵呵，我这几天也在测UDP的的应用，send是还简单的啦，我都没有你的烦恼，如果你这种只关系到服务器的话，又只是send，我觉得应该不用搞这么复杂，我现在头大的就是要处理recv的情况，接收一多，length就为0，接收要为0的话，我还怎么分析数据呀！唉，头大！

zengyixun

是的，我也就是开开玩笑随便一说，因为无论LR，Winrunner,QTP还是以前用IBM 的工具，感觉工具自身的稳定性都不是太好，不过最核心的问题，人家还是解决了的！原来每50个就会启一个进程，这就解释了LZ的疑惑了！多谢winmeeasy，我这人就是立场不坚定！