51Testing软件测试论坛
标题:
做过性能测试的进来看
[打印本页]
作者:
dengcainiao
时间:
2004-8-6 09:34
标题:
做过性能测试的进来看
最近我作为验收方和实施方在做性能测试时对“并发”的概念存在分歧,各位帮我分析一下。我做测试用的工具为LOADRUNNER,脚本录制中涉及三个主要操作分别为,登陆,下载课件,在线考试。其中在每个操作执行前设置了聚合点,同时请求同一操作。这是我所理解的并发。但是需要指出我的上述操作都用的是同样的用户名进行的。
实施方认为我这样的并发与实际情况不符,会增大对同一资源的过分请求,他认同的并发情况是将用户分布在不同的事务上,比如有300个用户,各有100个用户同时请求三个不同的操作。他们要求不在脚本中设置聚合点,通过增大循环次数的方式使不同的操作上同时都有人在做请求。
大家说说看。。。
作者:
oldsidney
时间:
2004-8-6 10:52
作效能測試規劃需要考量的因素很多,如 current user 的數量、執行哪些 business process、new user 與熟練的 user 等等。
假如要了解系統上線後的效能,就要考量 scenario 是不是與上線後的情形會一致,不過除非是舊系統改版,否則一般都沒有資料可供分析,這時就要去合理的推測。
例如 300 用戶,同時按下登陸按鈕,您認為系統以後上線,會常常有這樣的情形發生嗎?假如不是,那就不需要在登陸動作前加上聚合點。
其實就我看起來,實施方的 scenario 比較合理。
作者:
dengcainiao
时间:
2004-8-6 12:20
这样的话,我如何能够知道每一步操作到底能够承受多少人并发操作呢?
作者:
oldsidney
时间:
2004-8-6 12:49
作效能測試的目的不同,就會有不同的作法。
假如你想要知道每一步操作到底能够承受多少人并发操作,可能就會是用你設計的 scenario。不過問題是知道後又怎樣,在現實的情形,會有 300 位用戶同時按下登陸嗎?我不知道,這要你自己去判斷囉。
假如效能測試的目的是要了解系統上線後的效能,那一般會盡可能模擬上線後的使用情形,建議您可以和實施方,甚至是委託方,一起討論到底什麼樣的 scenario 會比較接近系統上線後的使用情形,才能設計出有意義的 scenario。
作者:
skinapi
时间:
2004-8-6 21:51
我赞成实施方的理解。性能测试是否可以从以下几个角度考虑:
1。多个用户同时进行完全相同的操作(多个用户同时进行登陆我觉得是可能的,至少站在系统攻击者的角度有可能出现)。
2。如oldsidney所说考虑实际情况,看在接近实际情况的条件下性能如何。
3。如果想知道系统所能支持的在线用户数的上下限,可将操作按照对系统资源的占用情况来进行排序,选择占用最少和最多的操作分别进行测试。
作者:
firemonth
时间:
2006-8-23 20:12
每帖必看!
看帖必回!
疯狂的刺猬
作者:
金子快来
时间:
2006-8-25 13:58
我认为性能测试应该这样来做:
1:要考虑系统的负载情况,即会有每数注册用户。 用户的使用习惯是什么(这个可以了解到那个测试关键点使用频率比较高)。然后利用2/8原则来设置并发量。
2:测试过程中当然要考虑最大并发。这就如楼主所说,300人并发一个性能测试点,但要求其他测试点没有测试压力。(首先要确定300为最大并发量),这个测试需要加集合
3:把300人平均分配到各个测试点上的测试也是有必要的。这个测试是否加集合均可。
4:还有人说在考虑功击的问题。这就看软件设计之初是否有这个非功能测试需求了。 另外有的一般是要求在路由等方面来考虑这个问题。如果有这个需求当然也要测试了。 主要是考虑最大功击上来后,系统是否可以把恶意的功击屏蔽掉。
作者:
wgs0923
时间:
2006-8-25 15:46
如果从概念上说,LZ的说法是严格意义上的并发;但从模拟真实性的角度来说,实施方的做法更加可取;最后看你们双方的决定吧!
作者:
zhaojc0451
时间:
2006-8-26 16:27
这是典型的测试计划的问题。在做性能测试之前,要根据系统的部署和业务的应用情况制定性能测试计划,此计划要与用户进行很好的协商与探讨,制定我们的目标,否则执行的测试作用可能不大。
并发其实有2种:
1、从业务上的并发:200人同时在线。
2、从服务器上的并发:200人同时向服务器发出请求。200人同时做一个提交的操作,服务器接受到多少请求。
我们要根据实际的需要选择用哪一种并发。个人认为采用第2种时,并发的用户数不应该设置太高,也就是实际使用中不可能这么多用户同时进行提交。
欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)
Powered by Discuz! X3.2