51Testing软件测试论坛

标题: QTP可以做压力测试吗? [打印本页]

作者: patton1202    时间: 2008-2-22 16:33
标题: QTP可以做压力测试吗?
弱弱地问,该测试工具可以做压力测试吗?如果可以具体怎样去测呢?
还有麻烦高手指教一下,我想查找我遇到的问题有没有发出的帖子,该怎么快速在本网站快速查找呢?200多页一页一页地翻的话实在是太慢了,初学者提出此弱智的问题请见谅。
作者: kursk    时间: 2008-2-22 17:02
买100个用户的QTP,分别装在100台机器上,当然了虚拟机也可以,然后同时运行脚本,这样就可以模拟100个用户同时登录的操作了

没有什么是不可能的
作者: patton1202    时间: 2008-2-22 17:05
不是吧?那和不用QTP测试工具测试没什么区别呀,再说那家公司会这么做呀?
初学者不懂的地方比较多,请见谅哦!
不过还是很感谢 kursk的回复哦,真诚的谢谢!!

[ 本帖最后由 patton1202 于 2008-2-22 17:20 编辑 ]
作者: 今天有雾    时间: 2008-2-22 17:19
不管能不能做性能测试,每种工具总用其所长吧,就好像没有人愿意用LR测试功能一样
作者: patton1202    时间: 2008-2-22 17:45
哦,i see
谢谢今天有雾的回复哦
作者: 玩不转    时间: 2008-5-24 09:59
我也明白了,QTP不能设置虚拟用户,不过我可以用1个用户不停的执行同一个操作执行几个小时,按说这样也能当成压力测试吧?

另外请教一个问题:
QTP主要用来做功能测试,在录制之前我们要保证录制的功能是可以实现的,要不无法达到想要的效果。
那么用QTP录制的功能自然是正确的了,这时我就有个疑问了手工测试就行了还要录制下来干什么呢?就为了方便以后这样的目的?
但有时候设置脚本却要占用大量的时间和精力,远远比手工测试一遍要费时间~~
那么怎么发挥QTP的最大功效呢?

[ 本帖最后由 玩不转 于 2008-5-24 10:50 编辑 ]
作者: 陈能技    时间: 2008-5-24 11:03
压力测试还是用LoadRunner之类的工具好,QTP的强项是功能自动化测试,虽然可以通过分布测试的方式实现压力测试,但是毕竟比较麻烦。关于分布式测试,QTP不像TC那样专门提供了一个Network Suites对象来实现:
http://blog.csdn.net/Testing_is_ ... /09/04/1772316.aspx
作者: lyscser    时间: 2008-5-24 12:33
原帖由 今天有雾 于 2008-2-22 17:19 发表
不管能不能做性能测试,每种工具总用其所长吧,就好像没有人愿意用LR测试功能一样


不测JSP也可以测EJB啊
作者: 阿妮妲    时间: 2008-5-24 18:03
用脚本不就可以实现了么?比如运行软件几百次,循环重启软件N次,要自己写脚本才可以实现的啊,不过好像用QTP挺复杂的。用一种别的测试工具比较简单阿,呵呵。
作者: 阿妮妲    时间: 2008-5-24 18:05
我是觉得TC比QTP容易点。
作者: 刘莫    时间: 2009-5-8 15:20
看了所有回复,感觉QTP似乎确实没有什么作用
,但是我觉得既然这个大的一个工具肯定有它独特的地方和可以帮到大家更好的做好测试的地方。
作者: walker1020    时间: 2009-5-8 18:01
1, QTP 不适合进行压力测试,LR 正好适合进行压力测试。 所谓各有长短吧。
2,使用QTP进行功能测试最大的好处是节省测试时间和成本。你无法让测试人员 24×7 进行测试,QTP可以做到。
作者: walker1020    时间: 2009-5-8 18:03
原帖由 阿妮妲 于 2008-5-24 18:05 发表
我是觉得TC比QTP容易点。


TC 是测试管理工具, QTP是功能测试工具,两者如何进行比较?
作者: kasimxiao    时间: 2009-5-8 18:27
loadrunner可以调用qtp脚本啊
作者: shenhh    时间: 2010-12-31 09:50
感觉不是这样解释的吧,做压力测试不一定要用LR,QTP也可以做压力测试
用100用户做压力登录测试,在QTP中可以实现,自动化不能代替手工测试,但是自动化可以减轻工作压力,不能减轻工作负担,100用户做压力测试,手工测试是根本无法达到的,但自动可以,这就是区分自动化与手工测试的区别,系统中找BUG,就需要靠手工测试,自动化根本达不到这样,不要错误的理解他们之间的意义
作者: jiangpr_ok    时间: 2011-1-6 17:12
回复 7# 陈能技


    收藏
作者: jiangpr_ok    时间: 2011-1-6 19:09
回复 7# 陈能技


    收藏
作者: jiangpr_ok    时间: 2011-1-6 19:09
回复 7# 陈能技


    收藏
作者: jiangpr_ok    时间: 2011-1-6 19:10
回复 7# 陈能技


    收藏
作者: jiangpr_ok    时间: 2011-1-6 19:10
beg管理,如果不用自动化工具,用什么管理效率较高啊,第一次用的word,用excel比较好吗
作者: cljmagic    时间: 2011-6-30 17:24
学习了
作者: hututu    时间: 2011-8-18 15:31
回复 6# 玩不转
我不知道我理解的对不对,是这样的,QTP用于回归测试,但版本功能确定下来,且不会有改动,就可以对这些确定的功能进行回归测试,想想一台机器上跑着脚本就把整个回归都做了,你只要到最后看结果就行了,已经很省时了。编写脚本的耗时只是暂时的。你可以让QTP做产品固定功能的回归,你在另一台机器上做新功能的最后确认测试,并行处理。此外对于大型网站的固定流程测试,或整个产品的回归测试会有固定的人来做,如果人工耗时很长,可以晚上用QTP跑脚本,早上上班直接看结果。这样看来是省时的,框架如果搭建好,就会省时很多,可是我还没有学到那里,所以我也不能发表什么了
作者: hututu    时间: 2011-8-18 15:31
回复 6# 玩不转
我不知道我理解的对不对,是这样的,QTP用于回归测试,但版本功能确定下来,且不会有改动,就可以对这些确定的功能进行回归测试,想想一台机器上跑着脚本就把整个回归都做了,你只要到最后看结果就行了,已经很省时了。编写脚本的耗时只是暂时的。你可以让QTP做产品固定功能的回归,你在另一台机器上做新功能的最后确认测试,并行处理。此外对于大型网站的固定流程测试,或整个产品的回归测试会有固定的人来做,如果人工耗时很长,可以晚上用QTP跑脚本,早上上班直接看结果。这样看来是省时的,框架如果搭建好,就会省时很多,可是我还没有学到那里,所以我也不能发表什么了
作者: hututu    时间: 2011-8-18 15:31
回复 6# 玩不转
我不知道我理解的对不对,是这样的,QTP用于回归测试,但版本功能确定下来,且不会有改动,就可以对这些确定的功能进行回归测试,想想一台机器上跑着脚本就把整个回归都做了,你只要到最后看结果就行了,已经很省时了。编写脚本的耗时只是暂时的。你可以让QTP做产品固定功能的回归,你在另一台机器上做新功能的最后确认测试,并行处理。此外对于大型网站的固定流程测试,或整个产品的回归测试会有固定的人来做,如果人工耗时很长,可以晚上用QTP跑脚本,早上上班直接看结果。这样看来是省时的,框架如果搭建好,就会省时很多,可是我还没有学到那里,所以我也不能发表什么了
作者: hututu    时间: 2011-8-18 15:31
我不知道我理解的对不对,是这样的,QTP用于回归测试,但版本功能确定下来,且不会有改动,就可以对这些确定的功能进行回归测试,想想一台机器上跑着脚本就把整个回归都做了,你只要到最后看结果就行了,已经很省时了。编写脚本的耗时只是暂时的。你可以让QTP做产品固定功能的回归,你在另一台机器上做新功能的最后确认测试,并行处理。此外对于大型网站的固定流程测试,或整个产品的回归测试会有固定的人来做,如果人工耗时很长,可以晚上用QTP跑脚本,早上上班直接看结果。这样看来是省时的,框架如果搭建好,就会省时很多,可是我还没有学到那里,所以我也不能发表什么了
作者: hututu    时间: 2011-8-18 15:31
回复 6# 玩不转
我不知道我理解的对不对,是这样的,QTP用于回归测试,但版本功能确定下来,且不会有改动,就可以对这些确定的功能进行回归测试,想想一台机器上跑着脚本就把整个回归都做了,你只要到最后看结果就行了,已经很省时了。编写脚本的耗时只是暂时的。你可以让QTP做产品固定功能的回归,你在另一台机器上做新功能的最后确认测试,并行处理。此外对于大型网站的固定流程测试,或整个产品的回归测试会有固定的人来做,如果人工耗时很长,可以晚上用QTP跑脚本,早上上班直接看结果。这样看来是省时的,框架如果搭建好,就会省时很多,可是我还没有学到那里,所以我也不能发表什么了
作者: javaweb2006    时间: 2011-8-18 23:25
做压力测试用loadrunner




欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/) Powered by Discuz! X3.2