以下是在51testing論壇上的討論貼：

Zee：
關于集合點，我一直覺得沒有什么可爭議的，這兩天看到幾個帖子在說這個東西。有一點我想大家都是認同的：集合是相對的集合。
集合是在產生負載的機器上的集合。如果考慮網絡，中間件等等的因素。到服務器肯定不會是同一時間點，那于是就有人希望能更接近在服務器端實現并發的操作。認為這才是真正的并發。
我覺得首先要做的是分析應用系統，到底你想做的是什么。
比如說，你想讓某個URL能達到1000個同時請求的目的。這樣的目標就比較明確了。
而在討論集合點的時候，大家很少拿具體的東西來舉個例子。這樣有點說不清楚。要想達到并發。我覺得應該更具體的分析應用。再來定下目標來做。而不是一直在討論LR如何能實現。

xingcyx：
因為在實踐中，我經常會碰到這樣的情況：
測試需求說，該系統應支持200個并發用戶。

那么我們就開始測，錄制好腳本，下一步就是在場景中執行了，在控制臺中設置某腳本并發用戶數為200，測試結果為通過或未通過。此時爭議就來了：這200個用戶的腳本如果執行通過，測試結果可以接受，是否可以說這個系統支持了200個并發呢？

Zee：
你說的是不是太過泛泛？如果用戶說這系統要支持200個并發。那做性能測試的人知道這句話有很大的出入。

大漠飛鷹：
測試前肯定要了解需求，或者說是測試目的。
就說明“該系統應支持200個并發用戶。”， 這種需求嚴格意義上來說是不合格的需求，因為描述不夠清晰，過于模糊等。
當然，在實際中，這類需求到了我們測試人的手里也是常有的，一般就當普遍的情況來出來。
比如，web系統，就按2/5/8，或者2/5/10來處理，如果能通過就pass，否則就讓開發人員調優。

xingcyx：
那么樓上的兩位就請說說，你們實際的工作中，需求是怎么提出來的，或者你們是怎么去確定出來的，到了最后確定了的測試需求是個什么樣子？給出來大家參考一下。

Zee：
從集合點到并發數的確定。我覺得這其中的轉換最主要的地方在于分析業務。

比如用戶說了：要求200個用戶并發。
那要問清楚的就是，200個用戶是個什么樣的比例，有多少人在干這個，有多人在干那個，按百分比，用不同的腳本來跑。
那再來想一下客戶。他關心的是200個用戶在服務器上同時點同一個URL或者某一個相同的資源？這個客戶我想大多不會關心。而他想要的就是我有200個用戶在線的時候。響應時間不至于讓人不可接受。至于多少才不可接受。按平常人的心理承受能力來衡量就可以了。再或者有其他的說法，就是200人同時點同一 URL或者請求同一資源，我想可以通過計算來增加vuser的數量或者集合呀，或者其他的方法來努力的向這個目標靠近。

如果說非要在服務器上這個時間并發這么多的用戶。我覺得只能盡量把它縮小到一個時間段內。而這樣做我覺得并不是從分析業務出發的

xingcyx：
樓上說的是最常見的一種情況，在這種測試需求下，我會設置一個混合場景來測試，也就是按照做不同事情的用戶的百分比去設置。
但會有另外一些時候，并不是一個實際的應用系統，可能是一個開發平臺，或者工作引擎等，它涉及的性能的概念會更偏向底層一些，這個時候可能就不是像一般的應用系統那樣，設置一個混合場景來測試那么簡單了。

大漠飛鷹：
一般說的并發數指的是業務并發，而不是服務器端得并發數。

cc_lion：
一個業務并發，一個服務端最大并發數，針對測試目標不一樣選擇其中

測最大并發數可能有意外收獲哦！！資源爭用，DEADLOCK，等

網友 大漠飛鷹：

并發中有兩個概念，一個是業務并發數，指的是客戶端的訪問用戶量；
還有一個是服務器端的并發數，指的是服務器端的處理數量；

實際操作中，我們比較方便控制客戶端的并發數，而服務器端的則幾乎無法控制和操作，因此我們平時說的并發數指的都是業務并發數。

Q：性能測試有哪些測試類型？有何異同？
A：性能測試是一個涵義很廣的概念，它包括負載測試、壓力測試、強度測試、可伸縮性/擴展性測試等。
1.負載測試：通過逐步增加系統負載，最終確定在滿足性能指標的情況下，系統能承受的最大負載量的測試。 2.壓力測試：通過逐步增加系統負載，最終確定在什么負載條件下系統性能將處于崩潰狀態，以此獲得系統能提供的最大服務級別的測試。 3.強度測試：又稱疲勞強度測試，在系統穩定運行的情況下能夠支持的最大并發用戶數，持續執行一段時間業務，通過綜合分析，確定系統處理最大工作量強度性能的過程。4.可伸縮性（Scalability）是衡量一個系統處理能力或容量的屬性，舉個例子說，就是當為一個系統增加了資源——特別是硬件資源后，系統可以承受更大的負載，并獲得更大的 吞吐量，這個系統可以被稱為 Scalable System （可伸縮的系統）。例如測試一個使用了負載均衡和集群技術的系統，測試當增加新的 Cluster 之后是否可以承受更大的負載，并獲得相應的吞吐量提升。


Q：“并發用戶數”在英文中是如何表示的？
A：并發用戶數量：the number of concurrent users
最佳并發用戶數量：the optimum number of concurrent users
最大并發用戶數量：the maximum number of concurrent users
峰值并發用戶數量：the peak number of concurrent users
平均并發用戶數量：the average number of concurrent users

Q：“注冊用戶數”和“最大并發用戶數”有聯系嗎？
A: 注冊用戶數和最大并發用戶數之間本身沒有必然聯系。一般根據特定時間段的峰值來進行計算。如注冊用戶數為2000，按照行業標準一般峰值使用人數為5％－10％，也可以通過前期項目進行統計后，得到較為準確的百分數。

關于并發用戶數和集合點補充的一些看法；
并發用戶是從一個更大的概念上說的，可以說是在一個用戶層次，而集合點是在事務層次的，這一點在沒有運行腳本終可以設置集合點；
如果對于一個事務有10用戶并發設置集合點也在次事務，此時設置不設置沒有區別，但是如果有一個腳本有多個事務，而又對一個事務設置了集合點的話，這樣就會又確別，對于此腳本中的其他事務用戶可能不是并發，但是對于集合點的事務一定是并發的。

并發用戶數 SimUsers（Vusers）前一個是Avalache里邊的并發用戶數（仿真用戶數）后一個是LR的并發用戶數（虛擬用戶數）；
以下是Avalache用戶手冊中對于SimUsers的解釋：
An abbreviation for simulated or virtual users. SimUser applies to a user processing through an Action list one time. This load specification generates enough load to reach and maintain a target number of concurrent simulated users. It allows you to determine the maximum number of concurrent users your device, infrastructure, or system can handle.
Use this specification if you want to keep applying load even after the device under test fails. The amount of traffic generated depends on the performance of the device under test. As the system slows down due to overloading, generally each user takes longer to process through the URL list, and the load "throttles back" and generates fewer new users.

注冊用戶數，首先是以個論壇的或系統的容器的量，它要看你的后臺數據庫能夠支持的用戶注冊能力，可能約束的又用戶ID（如果又長度比如十位，并且不能重復）那么應該可以注冊 的用戶數為10的10次方個用戶；
并發用戶數是指系統的提供服務的能力，即同時能夠支持的在線用戶數量；從測試的角度來講，需要模擬足夠多的用戶去同時訪問DUT，來確認最大并發用戶數。