做过性能测试的进来看

dengcainiao

最近我作为验收方和实施方在做性能测试时对“并发”的概念存在分歧，各位帮我分析一下。我做测试用的工具为LOADRUNNER，脚本录制中涉及三个主要操作分别为，登陆，下载课件，在线考试。其中在每个操作执行前设置了聚合点，同时请求同一操作。这是我所理解的并发。但是需要指出我的上述操作都用的是同样的用户名进行的。
   实施方认为我这样的并发与实际情况不符，会增大对同一资源的过分请求，他认同的并发情况是将用户分布在不同的事务上，比如有300个用户，各有100个用户同时请求三个不同的操作。他们要求不在脚本中设置聚合点，通过增大循环次数的方式使不同的操作上同时都有人在做请求。
  大家说说看。。。

oldsidney

作效能測試規劃需要考量的因素很多，如 current user 的數量、執行哪些 business process、new user 與熟練的 user 等等。

假如要了解系統上線後的效能，就要考量 scenario 是不是與上線後的情形會一致，不過除非是舊系統改版，否則一般都沒有資料可供分析，這時就要去合理的推測。

例如 300 用戶，同時按下登陸按鈕，您認為系統以後上線，會常常有這樣的情形發生嗎？假如不是，那就不需要在登陸動作前加上聚合點。

其實就我看起來，實施方的 scenario 比較合理。

dengcainiao

这样的话，我如何能够知道每一步操作到底能够承受多少人并发操作呢？

oldsidney

作效能測試的目的不同，就會有不同的作法。

假如你想要知道每一步操作到底能够承受多少人并发操作，可能就會是用你設計的 scenario。不過問題是知道後又怎樣，在現實的情形，會有 300 位用戶同時按下登陸嗎？我不知道，這要你自己去判斷囉。

假如效能測試的目的是要了解系統上線後的效能，那一般會盡可能模擬上線後的使用情形，建議您可以和實施方，甚至是委託方，一起討論到底什麼樣的 scenario 會比較接近系統上線後的使用情形，才能設計出有意義的 scenario。

skinapi

我赞成实施方的理解。性能测试是否可以从以下几个角度考虑：
1。多个用户同时进行完全相同的操作（多个用户同时进行登陆我觉得是可能的，至少站在系统攻击者的角度有可能出现）。
2。如oldsidney所说考虑实际情况，看在接近实际情况的条件下性能如何。
3。如果想知道系统所能支持的在线用户数的上下限，可将操作按照对系统资源的占用情况来进行排序，选择占用最少和最多的操作分别进行测试。

firemonth

每帖必看!
看帖必回!


疯狂的刺猬

金子快来

我认为性能测试应该这样来做：
1：要考虑系统的负载情况，即会有每数注册用户。 用户的使用习惯是什么（这个可以了解到那个测试关键点使用频率比较高）。然后利用2/8原则来设置并发量。
2：测试过程中当然要考虑最大并发。这就如楼主所说，300人并发一个性能测试点，但要求其他测试点没有测试压力。（首先要确定300为最大并发量）,这个测试需要加集合
3：把300人平均分配到各个测试点上的测试也是有必要的。这个测试是否加集合均可。
4：还有人说在考虑功击的问题。这就看软件设计之初是否有这个非功能测试需求了。  另外有的一般是要求在路由等方面来考虑这个问题。如果有这个需求当然也要测试了。 主要是考虑最大功击上来后，系统是否可以把恶意的功击屏蔽掉。

wgs0923

如果从概念上说,LZ的说法是严格意义上的并发;但从模拟真实性的角度来说,实施方的做法更加可取;最后看你们双方的决定吧!

zhaojc0451

这是典型的测试计划的问题。在做性能测试之前，要根据系统的部署和业务的应用情况制定性能测试计划，此计划要与用户进行很好的协商与探讨，制定我们的目标，否则执行的测试作用可能不大。
   并发其实有2种:
    1、从业务上的并发：200人同时在线。
    2、从服务器上的并发：200人同时向服务器发出请求。200人同时做一个提交的操作，服务器接受到多少请求。
我们要根据实际的需要选择用哪一种并发。个人认为采用第2种时，并发的用户数不应该设置太高，也就是实际使用中不可能这么多用户同时进行提交。