周六来求助一下...关于同时在线的问题

让测试飞起来

大家好！
同五时陪第三方测评公司做了项目的性能测试，对10个业务分别做了大并发测试，事务时间都是很好。 这10个业务的性能测试都通过的
也做了5W的同时在线的测试，当时测评人员没说结果  是否通过
今天收到经理的电话，说第三方测评人员说  这个同时在线的时间太长了....

同时在线我是这么做的脚本

登录   在vuser_init
打开几个菜单页面 ---界面有40多个请求 ，脚本没添加事务----在Action 中
END  没有
就是这样，场景跑了10分钟，他的场景设置了，每个脚本都为一个事务，导致Action 平均时间为100秒了。 就说这个时间太长了。

现在问题是不知道下周一要怎么做才可以让这个时间缩短？
上面的100秒能说明什么样的问题呢？
其实我是觉得，这个“同时在线” 只要系统不宕机，运行不出慢，页面不报500就说明是正常了，通过的。

希望各位好友说明一下，说说想法！！！！！！！
也可以加我Q1300115774！！

让测试飞起来

大伙还没起床～～～？？

yinxiaodan

个人看法
1、脚本上应设置合理的事务，不是整个action
2、响应时间100s实在是太长，一般超过5s内，超过就是测试不通过，不同系统指标会有差别
3、不是不报错就是测试通过，还要评估系统资源使用率

szyszy2000

界面有40多个请求 是否从业务上是你们需要测试的事务，事务是对一组对业务来说有意义的请求，如果可以缩小范围，在ACTION里面定义一个你们要测试的transaction

xinyuzxx

把一个Action作为事务来看时间一般是不合理的，需要根据具体情况来加事务，而且还要考虑执行过程是否使用了思考时间等因素，个人觉得最好在测试业务开始处和结束处进行添加开始事务和结束事务步骤。
另外，事务响应时间问题，一般按用户体验来说有个3-5-8原则，即打开一个网页在3s内很快，3-5s比较快，5-8s可以接受，8s之后不能接受，楼主说的100s确实长，不知道里面包含有多少个页面跳转。
最后说明下，性能测试的目的是为了系统性能调优，给用户更好的体验，如果只是系统不宕机，运行不出错，页面不报500，但是系统反应很慢，这个系统对用户来说是很槽糕的，打个比方说浏览一个网页打开需要2分钟，感觉会如何呢？！如果是我，我会找其他同类反应比较快的网站，而不是在哪儿坐等打开。

jingzizx

要分析下40多个请求分别的响应时间如何，再进行判断