关于think time在场景中的设置问题

kevin_swpi

今天尝试了一下，我用一个脚本分别在“忽略think time”和“按照录制时候think time”两个方式进行场景运行
场景设置：用户一个，只运行一次
忽略think time的时候这个值是不到一秒（和实际操作中的时间基本一致）
按照录制时候think time，这个时候时间比较长（17s，和实际中相差很大）

场景设置：20个人，持续时间20分钟
忽略think time的话，将会出现很多超时的Error（60个左右）
按照录制时候think time运行，则只会出现一两个超时的Error

=====
这样就疑惑了
到底在运行场景的时候，think time该如何来设置？
又该注意什么问题

Zee

think time的设置，按业务需求来做。
所以在做之前，场景是如何设置的，决定了脚本中的think time如何设置。
而场景的设置，取决于性能测试的目标。

kevin_swpi

呵呵  ZEE老大在
有救了

先说说我的看法
think time如果忽略的话能给服务端造成比较大的压力
并且如果忽略掉think  time时间 从上面的例子来看也更接近真实值
如果我不忽略think time时间  反而和实际的时间偏差很大
如我上面的实际一次操作时间就不到1秒  但是设置think time后  直接就17秒。。。
这个是不是就不准确了或者说没有撒意义了?

Zee
那能不能你举例说明一下
到底这个think time的设置该如何根据需求的变化而做响应设置？

wangmeng814

你可以按照录制时THINKING TIME去运行脚本，在最后分析结果的时候去掉THINGING TIME 这样的话，服务器的压力情况比较真实，而且响应时间也可以参考

Zee

在实际的性能测试中，think time都是先分析用户的操作习惯来设计的。

比如，半小时内有800用户登录，然后40%的用户去浏览页面，打开一个页面后停留时间在5-10s范围内，这时就应该在打开一个页面的脚本后加上think time,设置随机范围在5-10s内。

如果你直接问，think time应该不应该去掉或者设置为多少是合适的话，那只能去分析你的用户了。

孑非子

版主最后一句话说的很好啊，很多时候我们报告的结果或者具体操作中的设置都是以用户期望为导向的。

joykao

学习中