測試策略其實是解決壓什麼，怎麼壓的問題

如上圖所示，壓測無非就是模擬客戶端對客戶端併發請求，檢視服務端的響應情況如何，很明顯，對於java後臺介面，壓的就是介面
介面初步可分為兩種型別，一種是單個介面，一種是介面組合
那什麼時候壓測單個介面，什麼時候壓測介面組合呢？

單個介面

• 除錯單個介面的效能瓶頸
• 上下游的介面，可知道上游最大請求下游該介面的併發數
• 針對系統請求量較大的介面的併發數

介面組合
介面組合有兩種方式，一種是依據故事場景的方式，一種是按照線上或者估算的介面請求數佔比組合方式

• 可以測試整個系統處理故事場景的tps
• 測試系統支援主要核型介面的tps

解決了壓什麼，接下來看看怎麼壓的問題

個人理解大致可以分為兩種方式，集合點和持續併發

集合點
集合點可以簡單得理解為一種控制虛擬使用者行為的機制，該機制可以達到在一定時間範圍內將一定數量的虛擬使用者阻擋在一個操作行為點前的位置進行互相等待，在條件（達到虛擬使用者數量或超時）到達後喚醒全部等待中的虛擬使用者，從而達到使得一定數量的虛擬使用者可以同時進入下一個操作行為點的目的。
往往其使用初衷是為了實現最大意義上的併發來考察系統應對此種極端情況的表現
但是，集合點真的就給服務端增大壓力麼？
單獨業務點上雖然看似集合後壓力增大了，但是這個要分析具體情況，首先，在釋放阻塞之前，使用者會處於互相等待的狀態中，對服務端的壓力逐漸減小，服務端的壓力得到明顯緩解
持續併發
持續迴圈執行指令碼，給服務端持續造成壓力，這樣可以測試出服務端的效能情況和在長時間的壓力下是否可以持續穩定的執行