关于设计场景时对于脚本的运行时设置的规则
在设置场景的选择脚本的时候，可以设置脚本的运行时设置，而这里有2个设置会导致测试结果的完全不同第一个步的设置，默认是当前一个迭代结束后立刻开始，
还有就是思考时间，默认使用录制时的思考时间
这是一个典型场景的设置，可这里的设置有什么规则和技巧不？
在网上看到有的时候，这个与吞吐量设置有关。
如当并发用户为300，要求吞吐量为10 page/s ,就设置VU的迭代间隔为300/10＝30秒。
网上关于这个的帖子不多，有人说为了提高压力，应该间隔和思考时间均为0，我却不认为，提高压力的重点在于增加并发用户，而不是破环真实情况。
望各位大侠发表看法或给予指点
[ 本帖最后由 tanwen321 于 2010-5-20 18:08 编辑 ] :'( ，为什么都没人说说呢？是问题提的不够清楚？还是很少有人考虑这方面的设置？ 并发应该由集合点控制，减少think time会改变负载模式，当然如果算清楚可以用少量的用户来模拟大量的负载
回复 3# 的帖子
那负载的大小有个什么样的判断标准？一样的脚本，比如5个人忽略think time和Pacing(都设为零)，和10个人设置了think time和Pacing来比较，究竟那个负载大呢？由点击率、吞吐量或者其他来判断？回复 1# 的帖子
其实是差不多的，设置间隔和思考时间为0，真实场景中也有的，想淘宝高速登陆，1个账号1天卖家酒登陆几十次，这个很正常，如果用集合点来加压也是可以的，只不过从不同方向去施压。都行。回复 5# 的帖子
其实，设置think time和Pacing都设为零，就像3楼说的，很多人认为通过这种方式能加大负载，我只是觉得不合理，因为一般的情况，拿WEB测试来说，我们浏览网页很少会狂点（没有think time），而如果忽略了，的确能产生更高的负载，这这样做往往破环了真实的业务流程，测试出的结果往往是不准确的，甚至是错误的。而我的另一个问题是，评价一次测试的负载高低的标准到底是什么？
页:
[1]
