jmeter（三）SOAP/XML-RPC Request

項目背景：公司的微信端H5界面新開發了會員註冊功能，須要對其進行壓力測試

項目目標：須要承受每分鐘最少6000的壓力

 

1、創建一個測試計劃（test plan）

以前有說過，jmeter打開後會自動生成一個空的test plan，用戶能夠基於該test plan創建本身的test plan

一個性能測試的負載必須有一個線程組完成，而一個測試計劃必須有至少一個線程組。添加線程組操做以下：

在測試計劃處右鍵單擊：添加→Threads（Users）→線程組

每一個測試計劃都必須包含至少一個線程組，固然，也能夠包含多個，多個線程組的運行在jmeter中採用的是並行的方式，即：同時被初始化且同時執行其下的sampler

 

線程組主要包含三個參數：

線程數：虛擬用戶的數量，一個線程指一個線程或者進程

Ramp—Up Period(in seconds)：準備時長。設置的線程數須要多久所有啓動，好比上圖，線程數爲6000，啓動時間爲60，那麼須要60S內啓動6000個線程；

循環次數：每一個線程發送請求的次數。如上圖，6000個線程，每一個線程發送1次，若是勾選了永遠，那麼它將永遠發送下去，直到中止腳本；

設置合理的線程數對可否達到測試目標有決定性影響。好比在本例中，若是線程數太少，則沒法達到設定的要求；

另外，設置合理的循環次數也很重要，除了給定的設置循環次數和永遠，還能夠經過勾選調度器，設置開始和結束時間來控制。

 

2、添加sampler

添加完線程組後，在線程組上右鍵單擊：添加→Sampler→SOAP/XML-RPC Request（SOAP/XML-RPC：都是報文中不一樣的數據格式）

前面說過，取樣器（Sampler）是與服務器進行交互的單元。一個取樣器一般進行三部分的工做：向服務器發送請求，記錄服務器的響應數據和記錄相應時間信息

這裏解釋一下，由於微信H5界面的會員註冊，向微信端發送的是xml文件，因此這裏我選擇的取樣器是SOAP/XML-RPC Request

上面的圖中，選擇SOAP/XML-RPC Request取樣器，而後URL一欄輸入咱們須要進行加壓的URL

而後默認選項，Use KeepAlive的意思是：保持鏈接，這個是http協議報文中的一個首部字段，以前的關於HTTP協議的隨筆寫過

下面的SOAP/XML-RPC Data輸入須要發送的xml格式的文件就行（也能夠導入xml文件的文件夾進行讀取），下面是xml和json的區別：

添加完取樣器和具體的地址參數以後，接下來就是添加監聽器，對測試結果進行獲取

 

3、添加監聽器

在線程組上右鍵單擊，添加你須要的監聽器，通常經常使用的就是結果樹和聚合報告

添加後啓動線程組進行測試，等線程執行完成後，根據結果樹中的請求和響應結果（成功或者失敗）就能夠分析咱們的測試是否成功，以及根據聚合報告結果來確認咱們此次確認是否達成了預期結果。

 

4、聚合報告簡析

Aggregate Report： JMeter 經常使用的一個 Listener，中文被翻譯爲「聚合報告」

Label：每一個 JMeter 的 element（例如 HTTP Request）都有一個 Name 屬性，這裏顯示的就是 Name 屬性的值

#Samples：表示你此次測試中一共發出了多少個請求，若是模擬10個用戶，每一個用戶迭代10次，那麼這裏顯示100

Average：平均響應時間——默認狀況下是單個 Request 的平均響應時間，當使用了 Transaction Controller 時，也能夠以Transaction 爲單位顯示平均響應時間

Median：中位數，也就是 50％ 用戶的響應時間

90% Line：90％ 用戶的響應時間

Note：關於 50％ 和 90％ 併發用戶數的含義，請參考下文

http://www.cnblogs.com/jackei/archive/2006/11/11/557972.html

Min：最小響應時間

Max：最大響應時間

Error%：本次測試中出現錯誤的請求的數量/請求的總數

Throughput：吞吐量——默認狀況下表示每秒完成的請求數（Request per Second），當使用了 Transaction Controller 時，也能夠表示相似 LoadRunner 的 Transaction per Second 數

KB/Sec：每秒從服務器端接收到的數據量，至關於LoadRunner中的Throughput/Sec