測試開發技能：JMeter高階教程——效能測試與自動化雲監控

效能測試在當今企業系統中起到的作用越來越重要，但在執行效能測試的過程中往往會遇到一些問題：加我VX：atstudy-js 回覆“測試”，進入軟體測試學習交流裙~~

一、專案緊急，不具備獨立的效能測試環境，功能測試和效能測試在一套環境同時執行測試時，其測試過程和測試結果會相互影響，導致結果不夠客觀。如果我們能在白天完成錄製效能測試指令碼，晚上自動執行指令碼，這樣便能規避它們之間的影響。雖然Jmeter可以利用自身定時器實現指令碼的定時執行，但效能測試的執行過程中一般要同步監控應用伺服器和資料庫伺服器的資源消耗情況，但在連續執行多支效能測試交易，無法做到每支交易的執行過程和資源監控過程一一對應。我們本次研究的第一個目標是想透過在批次執行多支交易的每支交易時自動調起雲下伺服器監控程式，自動生產監控結果。

二、現在很多企業應用採用了雲部署的方式，對雲資源消耗的獲取一般透過雲監控平臺去獲取，但開發人員經常會對應用程式進行重新部署，這樣帶來的一個問題就是無法再檢視歷史資料，導致之前執行指令碼過程時的應用伺服器的資源消耗無法獲取到。如果我們能在交易執行完之後立即透過HTTP請求去採集到這些資料並把它寫入到本地檔案中，便可以避免這個問題，所以我們本次研究的第二個目標是自動獲取“雲上”伺服器的資源消耗。

那麼我們該如何實現呢?共分為以下六步。

1.測試計劃設定

依託Jmeter自身功能實現在測試計劃中設定執行緒組的執行方式為依次執行每個執行緒組。

如下圖：勾選獨立執行每個執行緒組選項，當我們批次執行多支交易時，這種方式便會依次去執行每個執行緒組。

2.puttyScript.sh設定

新增BeanShell預處理程式編寫java程式碼對puttyScript.sh進行初始化，puttyScript.sh件主要是完成對putty實現伺服器的登入並完成NMON命令的寫入，從而生成NMON檔案。

3.Jmeter呼叫puttyScript.sh

puttyScript.sh初始化完成之後，需要在指令碼中新增BeanShell後置處理程式，調起puttyScript.sh，使其得到執行，在執行測試指令碼的同時監控雲下伺服器資源，生成對應的NMON檔案。

4.引數記錄

每個測試指令碼執行後，把每個指令碼的執行開始時間作為一個java變數儲存下來。因為後續去獲取雲平臺的資源引數時，需要知道每支交易執行的開始時間、結束時間才能對應獲取到相應的資料，所以需要把這個時間儲存下來以備後續使用，結束時間只要透過開始時間加上執行時間便可以獲得。

5.Jmeter登入雲監控平臺

透過F12獲取到的雲監控平臺的登入請求引數，在Jmeter中新增HTTP請求輸入以上的請求登入引數，在Jmeter中實現雲監控平臺登入，想要在雲監控平臺獲取相關資料，必須依託於在雲監控平臺實現登入。

6.獲取雲監控平臺資源情況

將步驟4當中獲取到的開始時間，結束時間和間隔時間作為請求引數新增HTTP請求去獲取每個交易在雲監控平臺中不同間隔點的資源消耗、進而對這些取到的資料透過beanshell後置處理程式編寫java程式碼進行資料處理，最終將結果寫入到我們本地的檔案當中，以便我們更直觀的分析資料。同時我們將各個取樣點的值寫入到了一個NMON檔案當中，這樣便可以透過圖形化的方式觀察到雲應用的資源變化趨勢。

透過本次創新研究，我們實現了以下成果：

1.實現定時批次排程執行多個效能測試指令碼同時生成對應的測試結果，可透過將執行時間設定在晚上的方式，一方面充分利用晚上的空餘時間極大地提高測試效率，同時降低統一環境下功能測試和效能測試相互帶來的影響。

2.實現效能測試“雲上”監控的圖形化展示及資料展示，一方面生成雲伺服器在指令碼執行期間的平均CPU和記憶體的消耗情況的日誌，同時將此資料寫入到一個新的.nmon檔案中，按30S一次取樣的方式生成雲伺服器的CPU和記憶體在執行指令碼期間的變化趨勢。

3.實現了雲下伺服器的自動監控。

透過在執行指令碼的同時調起nmon監控程式，在監控的伺服器端生成每個指令碼執行期間的.nmon檔案。

4.高通用性，適用於開放平臺所有系統(“雲上+雲下”)，當然應用伺服器和資料庫服務如果都在雲下的情況，本次研究的成果也是支援的。

後續我們將進一步將監控程式進行封裝，以JAR包的方式進行引入到Jmeter當中，使其更加簡潔，增強其易用性，相信在未來效能測試的過程中，本次研究成果能夠很好的應用於其它專案中，減少人工參與，提高測試效率，為測試工作提供一些借鑑意義。