51Testing软件测试论坛

标题: 关于Webservice的几个问题，请指教 [打印本页]

作者: cjp110212 时间: 2010-6-24 19:56
标题: 关于Webservice的几个问题，请指教
公司需要对系统的接口部分做性能测试，在用Webservice录制脚本，回放都没有问题，但是在场景中运行的时候出现了大量的错误。如下：
一、VUser的错误：“Abnormal termination, caused by mdrv process termination.”
1、对于这个问题，我在设置并发数为10的时候，报这种错误，但是很少。当设置并发为75时，甚至显示Error数为358,想不明白。
2、在run-time setting中设置按进程运行时，并发数同样设为75,这时的错误数只有35,难道是我们公司的服务器撑不住？

二、我录制的脚本是一个往数据库中添加记录的脚本。因为记录的ID不能重复，我对其做了参数化，根据添加一次记录的时间，我算出了运行十分钟大概会添加986条记录，然后我根据二八原则做了1200个参数。
1、这时有个问题，我设置的场景运行十分钟，并发数是一分钟内达到75个，可是我看结果时，场景运行了16分37秒，怎么会多出这么多呢，跟VUser中的错误有关吗。我的理解是，到达十分钟时，即使参数没有全部用完，场景也该停止。
2、我在录制Webservice脚本时，看见有一个【Import SOAP】的按钮（我用的是LR9.5），从头到尾我都没用到。可是我看生成的代码中有“SOAPMethod”之类的字段（是包含在web_service_call()函数中的）

请大家指教，谢谢！我的QQ：308817858

作者: ganlan 时间: 2010-6-24 21:32
第一个问题1，前人好像遇到过很多，可以在51上查看下是否有可行的办法；
第一个问题2，跑的时候要监控你的主机资源，就纯粹看这个错误哪能判断你的服务器是否挂了呢。
第二个问题1，设置并发用户数，最后将参数值设大点，最好能成倍数，因为在参数化设置后LR会给每个用户分配参数值，或者总数够，但是不一定每个用户都够了，因为开始执行的时间不一样，要知道最早的并发用户用多少的话，就按照最早执行那个并发使用的参数值，固定给每个并发用户分配就可以。
第二个问题2，不懂。

作者: cjp110212 时间: 2010-6-25 09:38
不能沉啊，大侠们快来帮忙，我都郁闷了两天了。查了很多方法，都不管用。用进程方式运行还有减小并发用户数，这样错误数虽然会减小，但感觉并没有解决问题。还有一个问题，就是当我用三台负载机做测试，平均每台负载25个VUSser，此时大量的VUser错误都来自负载机，而LOCALHOST产生的VU错误就会很少。当只用本机做负载时，同样会产生大量的错误

作者: cjp110212 时间: 2010-6-28 08:48
没人管？我自己顶，不要沉下去，这问题让我很困惑

作者: tttrrryyy 时间: 2010-6-28 11:45
mdrv进程是客户端的问题，webservice有没有对请求的来源做限制，比如说IP地址，MAC地址，或者说测试机自己已经到某个瓶颈了，特别你说以进程方式运行，很难想象你的客户端能支撑那么多并发。除了某些不支持线程的协议，干嘛要以进程模式？
运行十分钟，是说在这十分钟内都会提交请求，实际运行了16分钟，是说你提交的最后一个请求在16分钟才得到响应。

作者: archonwang 时间: 2010-6-29 15:40
之前做过类似的测试，我想问下，是不是ws返回的内容很大？

作者: cjp110212 时间: 2010-6-29 17:53
标题: 回复 5# 的帖子
我用了三台测试机，这样每台只负载25个VU，就算以进程方式运行，那么一台机器生成25个mdrv进程，也是可以承受的，所以我觉得是客户机问题的可能性不大。
关于为什么要用进程的方式，我是在用线程方式大量报错时，用了下进程的方式，发现错误量少了很多。

作者: cjp110212 时间: 2010-6-29 17:56
标题: 回复 6# 的帖子
你好，

我想问一下，怎么查看我的WS返回的内容是否很大，我跟公司接口人员沟通时，说如果业务成功，只返回一个字段的值，这应该很小才对啊。所以我觉得我是没看懂6楼的意思，有时间请指教，谢谢

作者: cjp110212 时间: 2010-6-30 14:31
今天同事用LR8.1跑，竟然不会出现跟我一样的错误，晕啊，怎么会这么惨，9.5的混的还不如8.1，而且那个8.1还是汉化版的

作者: cjp110212 时间: 2010-7-3 16:02
谁能告诉我一下，9.5的报错，可是8.1的却不报错。是因为9.5的需要打什么补丁？

作者: 云层 时间: 2010-7-3 17:31
其实老版本问题，新版本不稳定，确实如此。。。哎。淡定

作者: cjp110212 时间: 2010-7-7 15:30
标题: 回复 11# 的帖子
哇，没想到我的帖子会得得云层老师的回复，

，现在我测接口时就用8.1，其它的还用9.5

作者: cjp110212 时间: 2010-7-7 15:44
标题: 关于LR结果分析中事务摘要的问题，请指教
在我用LR做结果分析时，发现这样一个问题，事务摘要中有一个事务的通过数，我想知道这个通过数是按什么计算的。
比如说吧：１、我的脚本是一个“登录－添加项目－登出”的脚本，其中只有“添加项目” 是放在Ａction中的，且在run-time setting中取消了自动定义事务。
　　　　　２、用目标场景运行这个脚本，并发数设的是75个，时间是10分钟，Pacing设是的每15秒发出一次请求。
　　　　　３、场景运行完毕，运行时间为10分22秒，收集结果。
上述的三步都没有什么问题吧？可是我在收集到的结果中发现，事务的通过数是1509个，失败数为0，停止数为0，然后我去数据库中查询时，发现数据库中实际上只添加了300多个项目（具体多几个记不清了），所以我觉得很费解，在我看来，添加的项目数与事务的通过数应该是相等的呀。请问这个事务的通过数是按什么计算得来的?请大家多指教

作者: 云层 时间: 2010-7-7 17:49
每一个事务函数完成就是一个事务通过，但是事务的完成应该是逻辑验证而不是返回验证，所以事务完成数和真实完成数差距很大很正常。

作者: dionysus 时间: 2010-7-7 21:41

原帖由云层于 2010-7-7 17:49 发表
每一个事务函数完成就是一个事务通过，但是事务的完成应该是逻辑验证而不是返回验证，所以事务完成数和真实完成数差距很大很正常。

同意，lz需要在脚本中加入返回值的判断，返回错误的transaction设置为fail，同时用lr_error_message()把错误返回值输出来方便查看。
PS：前一阵刚做完一个WebService协议的项目^_^

作者: cjp110212 时间: 2010-7-13 16:48
多谢大家的帮助，可是我还是不太明白是什么意思，能说的再详细点吗？或是举个例子都可以。多谢多谢

作者: kuangquanshui 时间: 2010-7-14 10:06
了解下

作者: cjp110212 时间: 2010-8-9 11:14
嗯，这个问题已经解决了，正如楼上所说，LR的验证是逻辑验证，而非返回值验证，在事务中插入对返回值的判断，这样就可以做到事务的成功数与业务的成功数相等了

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