SOAPUI壓力測試的引數配置
效能測試在 soapUI 中稱為 Load Test, 針對一個 soapUI 的 TestCase, 可以建立一個或多個 LoadTest, 這些 LoadTest 會自動的把 TestCase 中的所有步驟都新增到其中， 在執行的時候，soapUI 會自動的使用多個執行緒來執行這些 TestStep，同時也會監控它們的執行時間， 例如最短時間，最長時間，平均時間等等。這樣使用者能夠很直觀的看到 REST 服務的響應時間，從而對效能進行調優。
建立 LoadTest 非常簡單，只需要在“Load Tests”上點選右鍵， 選擇"New LoadTest", 然後輸入名稱即可，下圖是一個針對 GetBookList 的效能測試， 可以看到有兩個 TestStep : "GetBookList_xml" 和"GetBookList_json" , 100 個執行緒併發執行， 時間限制是 60 秒。最後的結果是，最短時間 4 毫秒，最長時間 1204 毫秒，平均時間 20.54 毫秒。
圖 8. 效能測試
效能測試還支援斷言，使用者可以對一個 TestStep 或 TestCase 設定執行時間要求，例如平均時間大於 2 秒就認為失敗，點選圖 8 中中的“LoadTest Assertions”就可以設定。 當然根據需要，使用者也可以編寫指令碼來做一些準備工作，或者清除工作。 參見圖 8 中的"Setup Script"和“TearDown Script”。
可用不同的載入策略soapUI和soapUI Pro可以模擬各種型別的負載隨著時間的推移,使您輕鬆地測試的效能在許多條件下目標服務。從soapUI還允許您同時執行多個LoadTests(見一個例子進一步下降),結合LoadTests可以用來進一步維護服務的行為。選擇所需的戰略LoadTest從策略在LoadTest視窗工具欄:
我們看看可用不同的載入策略,看看他們可以用來做不同型別的負載和效能測試。
1。簡單的策略——基線,負載和浸泡測試
簡單的策略執行指定的執行緒數與指定的各執行模擬之間的延遲對伺服器的“呼吸空間”。例如如果你想執行功能測試與10秒延遲10個執行緒,執行緒設定為10,推遲到10000年,隨機延遲的多少你想隨機化(即設定0.5將導致延誤5至10秒)。當建立一個新的LoadTest這是預設策略和設定在一個相對較低的負載與1000毫秒的延遲(5個執行緒)。
簡單的基準測試的策略是完美的。用它來維護您的服務的基本效能和驗證沒有執行緒或資源鎖定問題。增加執行緒的數量,當你想要做更復雜的負載測試或使用長期浸泡測試策略。
2。固定利率策略——簡單
簡單的策略不做的一件事就是保證在一定時間內執行,例如,如果你想開始你的TestCase 10倍每秒鐘執行不管需要多長時間。使用簡單的策略可以設定10個執行緒和延遲補償的平均差距TestCase的結束和下一秒的開始,但這將是非常不可靠。應該使用固定利率策略相反,根據需要設定率(10)在我們的例子中,你走;策略將自動開始為這個設定所需數量的執行緒試圖維護配置的值。
暗示的標題,這裡有一些曲折:如果我們的TestCase執行時間超過1秒?維護配置的TPS價值,內部戰略將啟動新的執行緒來彌補,一段時間後,你可能會有許多超過10個執行緒執行由於原始的沒有完成組內。而不是令人驚訝的是這可能導致目標服務變得更慢,導致越來越多的執行緒被開始與配置的TPS“跟上”的價值。正如你可能猜到“馬克斯執行緒”設定是她阻止soapUI過載(本身和目標服務)在這種情況下,指定一個值將限制執行緒的最大數量的soapUI將被允許開始維護配置的TPS,如果達到現有的執行緒必須完成之前soapUI將任何新的開始。
“請求水平”設定將試圖維持TPS不是TestCase而是請求的執行水平,例如,如果你有一個數據驅動的LoadTest或者TestCase和許多請求,您希望TPS設定應用而非整個TestCase的執行水平的要求水平。
在任何情況下,固定利率策略用於基線,負載和soak-testing如果你不遇到上述“執行緒擁堵”問題。另一方面,你可能會引起交通擁堵(甚至結合另一個LoadTest)看到你的服務如何處理這個或擁塞處理後如何恢復。3所示。可變負荷策略
有幾個策略,可用於不同負載(執行緒)的數量隨著時間的推移,每個模擬一種不同的行為。他們可以為恢復和壓力測試是有用的,但是,正如對基線測試,結合自己或與其他策略。讓我們來快速瀏覽:
- 方差策略——這不同執行緒的數量隨著時間的“鋸齒”莊園配置;間隔設定為所需的值和方差的執行緒的數量應該減少和增加多少。例如如果我們從20執行緒,設定間隔60和方差0.8,執行緒的數量將從20增加到36在第一15秒,然後減少回20,繼續到4執行緒45秒後,最後返回到初始值後60秒。在統計圖中我們很容易遵循這個方差:
2. 破裂的策略——這種策略是專門為恢復測試和方差推向了極端,它並沒有配置延遲,然後執行的配置數量的執行緒“破裂時間”和回到睡眠。這裡你可以(而且應該)的執行緒數量設定為高價值(20 +)來模擬衝擊的交通在短時間間隔內,然後用一個標準衡量系統的恢復基線LoadTest包含基本績效斷言。讓我們試試這個破裂延遲和60秒10秒的持續時間;
在這裡可以看到的活動圖,也請注意,該決議已經改為250 ms(從預設的“資料”值),否則我們沒有任何圖更新在“睡眠”時期的執行(因為沒有收集資料)。
3.執行緒可以線性策略改變從一個水平到另一個執行緒的數量/ LoadTest的執行。它的主要功能是作為一種手段來確定某些統計資料變化或事件發生時的水平,例如找到ThreadCount的最大的TPSBPS可以實現或發現ThreadCount功能測試的錯誤開始發生。設定開始和結束執行緒值(例如5 - 50)並設定持續時間相對較長時間(我每個執行緒使用至少30秒值,在本例中,將1350秒)獲得準確的測量資料(更多內容見下文)。
4.網格策略——這種策略允許專門配置的相對變化的執行緒數量隨著時間的推移,其主要用途是更高階的場景和恢復測試,你需要看到在不同負載下的服務行為和負載變化。比如讓你想要執行的60秒10,20,10,40歲,10個執行緒。配置您的LoadTest開始10個執行緒然後網格中的輸入以下值
兩個值儲存相對於時間和實際ThreadCount LoadTest;如果你改變這些,相應的網格戰略價值將重新計算。執行測試顯示以下輸出:
5.指令碼戰略——指令碼是終極定製可能性;您所指定的指令碼叫做定期(“間隔”戰略LoadTest選項對話方塊中設定),應該返回所需的當前時間的執行緒數量。返回一個值而不是當前將啟動或停止執行緒調整改變。這允許任何型別的方差的執行緒的數量,例如下面的指令碼隨機排列5和15之間的執行緒的數量
執行這個策略的時間間隔設定為5000執行緒的數量會改變每5秒:
這裡的可能性是無限的。
4所示。統計計算和ThreadCount的變化
這些策略將會改變許多執行緒的數量有重要影響的統計計算,你需要意識到,當執行緒的數量發生變化時,這通常會改變目標服務的響應時間,導致改變avg,tps等等。但自從LoadTest已經執行在以前的結果對於那些執行的執行緒數量將為新ThreadCount傾斜的結果。
比如讓你5執行緒和有平均500 ms。使用執行緒策略你執行緒的數量逐漸增加,當執行6執行緒的平均增加到600 ms但由於收集的“老”值5執行緒仍然存在,這些總共將導致較低的平均水平。有兩種簡單的方法解決,選擇“重置統計ThreadCount變化”的價值LoadTest選項對話方塊,或手動重置統計與相應LoadTest工具欄按鈕;在這兩種情況下舊的資料將被丟棄。看到這個行動讓做一個ThreadCount策略從10到20執行緒測試超過300秒(30秒每個執行緒),下面你將看到的結果都與這個設定未檢查,然後檢查;
在後一種你看到“跳躍”統計每次重啟時執行緒的數量變化,逐漸平一個新值。最後TPS計算在20執行緒不同這兩個之間的約10%,顯示較低的“影響”更高的結果。
5。同時執行多個LoadTests
好,讓我們有一個快速瀏覽,我們將建立一個基線測試簡單的策略和低數量的執行緒,同時執行一個破裂策略如何基線測試效能“復甦”後,破裂;
在這裡你可以看到簡單的策略(底部圖)逐漸恢復後的負載。
6。最後的話
希望你得到一個很好的概述soapUI的不同策略和他們如何可以用來模擬不同場景和型別的負載。正如你可能已經注意到,soapUI更關注於“行為”LoadTesting(瞭解您的服務處理程式不同的載入)而不是具體的數字,這是無論如何難以計算因為有太多的外界因素影響。