SoapUI中提供的不同負載策略允許您模擬各種類型的負載，隨時間的變化，您可以在許多條件下輕松測試目標服務的性能。由於SoapUI還允許您同時運行多個LoadTests（參見下文的示例），可以使用LoadTests的組合來進一步斷言您的服務的行為。從LoadTest窗口中的Strategy工具欄中選擇所需的LoadTest策略：

我們來看看可用的不同負載策略，看看如何使用它們來進行不同類型的負載/性能測試。

簡單的策略 - 基準，負載和SOAK測試

簡單策略運行指定數量的線程，每次運行之間具有指定的延遲，以模擬服務器的間隔空間。例如，如果要運行具有10秒延遲的10個線程的功能測試，則將線程設置為10，延遲到10000並隨機到要隨機化的延遲（即將其設置為0.5將導致5-10之間的延遲）。當創建新的LoadTest時，這是默認策略，並設置在相對較低的負載（5個線程，1000ms延遲）。

簡單的策略是完美的基線測試。使用它來聲明您的服務的基本性能，並驗證沒有線程或資源鎖定問題。當您想要進行更精細的負載測試或使用長期運行的浸泡測試策略時，可以增加線程數。

既然這不意味著讓您的服務癱瘓，像這樣的設置可以用於持續的負載測試，以確保您的服務在適度的負載下按預期運行; 設置基準測試，不隨機化延遲，添加LoadTest斷言，作為安全網絡的意外結果，並在命令行中使用LoadTest或Maven插件自動執行。

2.Fixed Rate策略

簡單策略不能做的一件事就是在一定時間內保證一些執行，例如，如果您希望每秒啟動TestCase 10次，無論執行多長時間。使用簡單策略，您可以設置10個線程和一個延遲，但是隨著時間的推移，這將非常不可靠。應該使用Fixed-Rate策略; 根據需要設置比率（在我們的情況下為10）運行; 該策略將自動啟動所需數量的線程維持TPS的值接近比率。

如標題所示，這裏有一些曲折：如果我們的TestCase需要超過一秒的時間才能執行？為了保持配置的TPS值，該策略將在內部啟動新線程以補償這一點; 過了一會兒，由於原來的線程沒有在設定的比率內完成，所以可能有10個以上的線程運行。毫不奇怪，這可能導致目標服務變得更慢，從而導致越來越多的線程開始使用配置的TPS值被超越。你可能猜到“Max Threads”設置是為了防止在這種情況下SoapUI超載（本身和目標服務），在這裏指定一個值將限制SoapUI允許啟動的最大線程數維護配置的TPS，

“Request Level”設置將嘗試將TPS維護不在TestCase執行級別，而是依賴於請求級別，例如，如果您具有數據驅動的LoadTest或具有許多請求的TestCase，則希望TPS設置不應用在整個TestCase的執行級別，但在請求級別。

在任何情況下，如果您沒有遇到上述“線程擁塞”問題，Fixed-Rate策略對於基線，加載和保溫測試非常有用。另一方面，您可能會引起擁塞（甚至可能與另一個LoadTest結合使用），以了解您的服務如何處理此問題，或者在擁塞處理後如何恢復。

可變策略

有幾種策略可以用於隨時間，每次模擬不同類型的行為而變化負載（線程數）。它們可用於恢復和壓力測試，但同樣適用於基線測試，無論是自己的還是與其他策略相結合：

運行此策略時間間隔設置為5000，線程數將每5秒更改一次：

該圖顯示活動的突發。還要註意，分辨率已經更改為250ms（從默認的“數據”值），否則我們在執行“睡眠”期間不會有任何圖表更新（因為不會收集數據）。

該Thread策略可以讓你線性的改變線程數從一個層次運行到另一個。例如找到哪個線程數量可以實現最大TPS或BPS，或者找到哪個線程數量功能測試錯誤開始發生。啟動和啟動結束線程值（例如5到50），並將持續時間設置為相對較長的持續時間（我使用至少30秒每線程值，在這個例子中為1350秒），以獲得準確的測量。

兩個值都相對於LoadTest的持續時間和實際的ThreadCount存儲; 如果您更改這些，則相應的Grid Strategy值將被重新計算。運行測試顯示以下輸出：

腳本策略 - 腳本策略是最終的定制可能性; 您指定的腳本會定期調用（LoadTest選項對話框中的“Strategy Interval”設置），並且應在當前時間返回所需的線程數。返回當前值以外的值將啟動或停止線程以進行更改。這允許線程數量的任何種類的變化，例如以下腳本隨機化5到15之間的線程數。

這裏的可能性是無止境的。

4.統計計算和線程數更改

例如。說你已經跑5個線程了，平均到500ms。使用線程策略可以逐漸增加線程數; 當運行6個線程時，平均增加到600ms，但是由於針對5個線程收集的“舊”值仍然存在，這些將總體導致較低的平均值。有兩種方法可以解決這個問題：在LoadTest選項對話框中選擇“Reset Statistics”值，或使用LoadTest工具欄中的相應按鈕手動重置統計信息; 在任何一種情況下，舊的統計信息將被丟棄。要看到這一點，我們來做一個線程測試，從10到20個線程，300秒（每線程30秒），下面你可以看到結果，這個設置未被選中，然後檢查;

在後一種情況下，當線程數量發生變化時，每次重置統計信息時，都會看到“跳轉”，逐漸調整為新值。以20線程計算的最終TPS在這兩者之間差異在10％左右，顯示較低的結果“影響”較高的TPS。

5.同時運行多個負載測試

好的，我們來看一下這個; 我們將使用簡單的策略和少量線程創建一個基線測試，同時運行突發策略，以了解基準測試性能在突發之後如何“恢復”

在這裏，您可以看到簡單的策略（底圖）在每次加載突發之後逐漸恢復。

最後的話

希望您對SoapUI中可用的不同負載策略有一個很好的了解，以及如何使用它們來模擬不同的負載測試覆蓋情況。您可能已經註意到，SoapUI更側重於“行為”（了解您的服務如何處理不同的負載），而不是確切的數字，無論如何都難以計算，因為有太多的外部因素影響它。

soapui接口性能測試（二）---- 模擬不同類型的負載