性能測試過程中，目標不同，需要選擇的性能測試場景也有很大的差異，今天以HyperPacer為例，簡單說說并發測試、負載測試、壓力測試到底都是什么怎么個含義。

?

并發測試

所謂并發測試就是模擬一群人同一時間做事。在性能測試工具還未普及的暗黑歲月，并發測試都是一群人盯著電腦，一個人喊開始，大家便在同一時間點開始操作的那種，點完之后還得每個人看響應，報時間，一群人玩兒的不亦樂乎，做個性能測試順道還能交流交流，聯絡聯絡感情，看著挺好玩，但效率上保證不了。而且并發量不是非常大這樣還能玩的起來，并發量要是成百上千的話，就沒法這么弄了。

之后有了性能測試工具介入之后，這種好玩的場景便銷聲匿跡了。并發測試開始了新的篇章，不會有沒反應過來慢半拍的同事，都是一水兒的穩準狠。還能對并發操作進行精細的調整控制，以便更好的模擬真實的場景。

瞎扯的說那么多，現在上干貨。并發測試就是對被測系統的并發處理能力進行考察的一種測試手段，一般都是看在絕對并發的情況下，系統能承載多大的并發量，或者在一定的并發量下，系統的響應時間是否是可接受的。

由于是絕對并發對服務器的瞬時壓力非常大，性能測試人員在開展并發性能測試之前，一定要調查清楚實際的測試需求是不是真正的絕對并發，絕對并發量到底有多少。有時候需求人員在不知道確定概念之下，把相對并發的那種場景也按絕對并發說，往往得到的結果是系統不能有效支持，而實際卻是絕對并發場景的含義兩邊理解的不一樣。

舉個形象的例子，12306春運期間的放票，一到放票開始，N多的用戶在同一時間點對服務器發起買票的請求。比如8:00放票時段，有100萬用戶對12306發起了買票的請求。由于各自請求經過的路由不完全一樣，到達服務器時的順序也是有先有后。實際同一時間點對該服務的壓力只有100萬中的一部分,假如是5萬個用戶請求，剩下的略慢到達的95萬用戶請求，才陸陸續續到達，都在后面排隊等待處理。此時票務處理過程第一波的絕對并發就不是那100萬發起請求的用戶數，而是真正得到處理的那5萬個的用戶，等這5萬個之中有處理完成的，再放一部分用戶的請求進來處理。（由于不是鐵路系統內相關系統的操作人員，這個只是為了舉例而假想的場景，知情人士可一笑而過）。這其中的5萬用戶才是票務處理系統實實在在的絕對并發用戶量，而不是實際參與的100萬都要算進來。

需要做并發測試時，在LoadRunner里有集合點，在HyperPacer里叫做同步定時器，都是對這種場景模擬時用到的同一個東西。作用是當累積到的用戶量符合釋放條件時，就所有用戶一起釋放，模擬大家一起操作的場景。如果不加集合點/同步定時器的話，則是早到的早開始，晚到的晚開始，達不到絕對并發的那種效果了。

如果需要測試的場景不是嚴格意義上的絕對并發，而是在一定的時間范圍內進行釋放，則可在同步定時器后面再加泊松隨機定時器或高斯隨機定時器一類的元件來模擬。

?

壓力測試

壓力測試是在接近用戶承載量極限以下一些（還不足以把系統壓垮的用戶量），較長時間不間斷執行的性能測試，是檢查系統穩定性，系統性能瓶頸的一種常用場景。

由于性能測試通常都要盡可能模擬實際用戶使用場景，在壓力測試過程中，用戶的加載策略，操作方式等就需要盡量模擬真實情況下的操作用數量和上下線策略。比如在早上半個小時內，會有500個用戶登錄，完成登錄后就一直操作；下班前15分鐘，則陸續退出系統。當然實際的系統的用戶登錄上線和下線不一定那么規律整齊劃一。可通過不同分組設置相應的用戶數量、采用不同延時，不同的持續時間來模擬。關于用戶初始和用戶結束之類的加載策略由于超出了本文的范圍，此處一筆帶過，將來有機會再表。

?

負載測試

負載測試和壓力測試經常有人弄混，出個加載策略圖和前一個場景的加載策略圖比較一下就明白了。

?

所謂負載測試，從圖上直觀上看就是一批一批的加用戶，待到當前在線用戶執行穩定后，再加下一批的用戶，像這樣不停的持續加壓，直至系統性能明顯下降或系統崩潰為止。是測試系統用戶上限，查找系統性能瓶頸的重要手段。通常在還不知道系統能承載多大業務量的情況下，為找到用戶承載量極限或為了快速定位系統性能瓶頸時，會采用此種方式進行測試。

?

總結

雖然性能測試工具提供了多種的性能測試場景來做性能測試過程的調度，但在實際性能測試過程中，依然是按照實際性能測試需求為準，盡量模擬用戶的實際行為。在充分了解了性能測試目標的情況下有的放矢，從容選擇。而不是無論那種性能測試需求，都先用負載測試的場景測到系統崩潰再說。

轉載于:https://www.cnblogs.com/youngchance/p/5233866.html

總結

以上是生活随笔為你收集整理的性能测试场景浅析的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。