使用 JMeter 對 SOAP 應用進行壓力或效能測試

阿新 • • 發佈：2019-01-29

Appache JMeter 以及 SOAP 協議簡述

開源測試工具：Appache JMeter

JMeter 是 Apache 基金會 Jakarta 上的一個純 Java 開源專案，起初用於基於 Web 的壓力測試（pressure test），後來其應用範圍逐漸擴充套件到對檔案傳輸 FTP, 大型資料庫（JDBC 方式），指令碼程式（CGI, Perl 等），Web Services，Java 應用系統等方面的測試。JMeter 本身主要用於效能測試，如系統壓力等。除此之外，JMeter 能夠對應用系統做功能測試和迴歸測試，並且能夠通過使用帶有斷言的指令碼程式來驗證系統然後返回使用者期望的結果。為了提高工具的應用靈活性，JMeter 允許使用正則表示式建立斷言。正是由於它的靈活性和可擴充套件性，JMeter 逐漸成為流行的開源測試工具。

訊息傳遞協議：SOAP

SOAP（Simple Object Access Protocol）稱為簡單物件訪問協議，是 W3C 定義的一種標準訊息傳遞協議，而它通常被認為是 Web Services 的事實標準。SOAP 協議使用 XML 語言來描述，SOAP 訊息格式是由 XML Schema 模式定義，因而通過使用 XML 名稱空間使得 SOAP 具有很強的可擴充套件性。

SOAP 是在去中心化（Decentralized）分散式（Distributed）環境中用來資訊交換的一個輕量級協議。SOAP 本身並不定義像程式模型或實施宣告等形式的語法，而只定義了一種簡單機制：通過提供模組化的包裝模型編碼機制來傳輸應用資訊。

SOAP 基本結構：

1) 信封 Envelope Envelope 元素是 SOAP 中的根元素，並且定義為在 SOAP 訊息中必須出現。Envelope 元素中可以包含多可選的 Header 元素，但同時必須要包含一個 Body 元素。

2) 訊息頭 Header Header 可能出現在 SOAP 訊息中，是一個可選元素。如果出現在訊息中，那麼 Header 一定要是 SOAP 中的第一個元素。SOAP Header 在 Web Services 中的應用越來越廣泛，例如在應用程式的安全性事物中使用標準的訊息標頭檔案，因而成為擴充套件 SOAP 協議的一個非常有效的方法。

3）訊息體 Body Body 元素是 SOAP 中必須出現的一個元素，它要包含應用程式中的傳輸資料或者反饋訊息。應用程式中的傳輸資料可以是任意形式的 XML 資料。SOAP 訊息接收者最終來處理 SOAP Body 體。

回頁首

JMeter 呼叫 SOAP 框架機制

SOAP 使用 RPC（遠端過程呼叫）和訊息傳遞來建立通訊服務，SOAP RPC 定義了用於表示遠端過程呼叫和應答的協議。SOAP 協議本身僅僅定義了訊息的交換結構，它可以和許多現存因特網協議結合在一起使用，其中包括超文字傳輸協議（ HTTP），多用途網際郵件擴充協議（MIME），Java 訊息服務（JMS）以及簡單郵件傳輸協議（SMTP）等。目前與 SOAP 應用最為廣泛的是 HTTP 協議和 JMS 協議，而與之相對應的兩種應用就是 SOAP Over HTTP 和 SOAP Over JMS。

根據 JMS 的規範，訊息交換有 2 種方式：訊息釋出 / 訂閱方式和點對點方式。由這兩種交換方式所建立的訊息收發系統都是非同步的，即 JMS 客戶機可以傳送訊息而不必等待迴應。如果應用程式測試者或測試指令碼開發者希望每一條訊息都能夠被處理並且訊息總是能夠被傳送到指定的位置，那麼應該使用點對點訊息模型而不是訊息釋出 / 訂閱模型。

HTTP（超文字傳送協議）是屬於應用層的面向物件的協議，是全球資訊網 (WWW) 的基礎，由於其簡單快速、靈活、無連線、無狀態的方式，適用於分散式網路資訊系統。SOAP Over HTTP 應用就是指的是遵守 SOAP 編碼規則的 HTTP 請求 / 響應，我們可以用簡單的公式來對此作一個描述：HTTP + XML = SOAP。

JMeter 也同樣提供了兩種 Sampler 分別建立對這兩種服務的呼叫：Web Services (SOAP) Request 和 JMS Point-to-Point。前者使用網際網路中最為廣泛的超文字傳輸協議（ HTTP）而後者使用 JMS 協議，JMS 是 Java 平臺面向訊息中介軟體的技術規範，用它來提供建立、傳送、接收、讀取訊息的服務。許多廠商目前都支援 JMS，包括 BEA 的 WebLogic JMS service，IBM 的 MQSeries 和 Progress 的 SonicMQ。

圖 1.JMeter 框架基於上述兩種不同的協議對 SOAP 訊息的一次簡單呼叫機制流程

回頁首

準備測試環境

當精心編寫好測試指令碼滿懷信心的去執行測試計劃時，發現所有的測試指令碼都 failed 掉了，原因可能是你的測試環境中並沒有完全準備好。下面給出了準備測試環境的詳細步驟：

1.環境變數設定：JMeter 執行在 JRE/JDK 之上，在所有開始之前要設定 JMeter 自動檢測的環境變數 JAVA_HOME=#JAVA INSTALL DIRECTORY#.

2.JMeter 安裝：本文下面下載欄提供了 Apache JMeter 下載地址，首先要取得最新版本的 JMeter 測試工具，JMeter 最新版本包含了構建和執行絕大部分測試型別的檔案，包括 Web (HTTP/HTTPS), FTP, JDBC, LDAP, Java, 和 JUnit 等。

3.準備 jar 包：JMeter 雖然提供了對 SOAP Over HTTP 以及 SOAP Over JMS 測試的 Sampler，但是出於對 licence 的考慮它本身並沒有提供 JMS 需要使用的 jar 包。因此，在執行測試之前需要將這些包複製到 JMeter 的 lib 目錄下，下面列表對測試所需 jar 包作了詳細說明。

4.BeanShell 指令碼處理：如果在測試用例中用到了 BeanShell 指令碼，則需要將 BeanShell 包拷貝到 JMeter bin 目錄下。BeanShell 是一種相容 Java 語言的輕量級指令碼語言，JMeter 指令碼中可能會經常用它來做日誌處理，正則表示式後處理（Post- Process）等。如果在測試用例中用到了 Mail Visualiser, Mail Reader 以及 Web Services (SOAP) sampler，則需要將 MAIL 包拷貝到 JMeter bin 目錄下。如果在測試用例中用到了 JMS 相關的 sampler，則需要將 JMS 包拷貝到 JMeter bin 目錄下。

下面的列表列出了不同的測試用例所需要的 jar 包，以及其下載地址：

bsh-2.0b4.jarhttp://www.beanshell.org/
mail.jar http://java.sun.com/products/javamail/index.jsp
jms.jarhttp://java.sun.com/products/jms/docs.html

除錯指令碼中非常有用的資訊日誌：jmeter.log 在指令碼的除錯和執行過程中，所以的日誌資訊都會記錄在 jmeter.log 中，因此你會在這個檔案中找到比較有用的資訊。

注意事項

如果 JMeter 在執行測試指令碼過程中應該修改 jmeter.bat 檔案中的一些引數，引數大小可以根據測試計劃合理確定：

HEAP=-Xms256m – Xmx1024m
NEW=-XX:NewSize=128m -XX:MaxNewSize=128m
TENURING=-XX:MaxTenuringThreshold=2
EVACUATION=-XX:MaxLiveObjectEvacuationRatio=20%
PERM=-XX:PermSize=64m -XX:MaxPermSize=64m
DEBUG=-verbose:gc -XX:+PrintTenuringDistribution

此外，在搭建測試環境時還需要更多注意的地方：

JMeter 使用相容 JKD1.4 或者更高版本
JMeter 無法識別 zip 格式的包檔案，所以需要的包檔案均要求以 .jar 結尾
JMeter 會自動在 JMETER_HOME/lib 和 ext 目錄下尋找需要的類
對於使用 CSVDataSet, 那麼不要勾選 "Memory Cache"否則資料無法迭代

回頁首

使用 JMeter 連線 SOAP Over HTTP 服務

JMeter 提供了 Web Service (SOAP) sampler，用以呼叫基於 HTTP 的 Web 服務。下面詳細說明 SOAP Over HTTP 服務呼叫的各個屬性。

圖 2.SOAP Over HTTP 服務呼叫的各個屬性

SOAP Over HTTP 服務呼叫的各個屬性說明：

WSDL URL:指定 WSDL 檔案的目標地址
Web Methods:選擇本次請求呼叫的方法
Protocol:指定使用的協議，預設為 HTTP
Server Name Or IP:服務的地址（伺服器名或 IP 地址）
Path:呼叫方法所在的位置
Timeout:設定請求超時限制
SOAPAction:存在於 WSDL 檔案中的呼叫方法，預設不必填寫
Soap/XML-RPC Data:請求資料

下面是一次完整的 HTTP 請求與 HTTP 響應 SOAP 資料：

<span style="font-family:Arial,sans-serif;BORDER-TOP-WIDTH: 0px; PADDING-RIGHT: 0px; PADDING-LEFT: 0px; BORDER-LEFT-WIDTH: 0px; BORDER-BOTTOM-WIDTH: 0px; PADDING-BOTTOM: 0px; MARGIN: 0px; VERTICAL-ALIGN: baseline; PADDING-TOP: 0px; BORDER-RIGHT-WIDTH: 0px; outline: 0px">HTTP Request</span>
 <soapenv:Envelope> 
	 <soapenv:Body> 
		 <q0:getEndDate> 
			 <ip_id>12</ip_id> 
		 </q0:getEndDate> 
	 </soapenv:Body> 
 </soapenv:Envelope> 

 <span style="font-family:Arial,sans-serif;BORDER-TOP-WIDTH: 0px; PADDING-RIGHT: 0px; PADDING-LEFT: 0px; BORDER-LEFT-WIDTH: 0px; BORDER-BOTTOM-WIDTH: 0px; PADDING-BOTTOM: 0px; MARGIN: 0px; VERTICAL-ALIGN: baseline; PADDING-TOP: 0px; BORDER-RIGHT-WIDTH: 0px; outline: 0px">HTTP Response</span>
 <soapenv:Envelope> 
	 <soapenv:Header/> 
	 <soapenv:Body> 
	  <p928:getEndDateResponse> 
	   dstSavings=3600000,useDaylight=true,startYear=0,startMode=3,startMonth=2, 
	   startDay=8,startDayOfWeek=1,startTime=7200000,startTimeMode=0,endMode=3, 
	   endMonth=10,endDay=1,endDayOfWeek=1,endTime=7200000,endTimeMode=0]], 
	   firstDayOfWeek=1,minimalDaysInFirstWeek=1,ERA=1,YEAR=2005,MONTH=8, 
	   WEEK_OF_YEAR=37,WEEK_OF_MONTH=2,DAY_OF_MONTH=7,DAY_OF_YEAR=250,DAY_OF_WEEK=4, 
	   DAY_OF_WEEK_IN_MONTH=1,AM_PM=0,HOUR=0,HOUR_OF_DAY=0,MINUTE=0,SECOND=0, 
	   MILLISECOND=0,ZONE_OFFSET=-18000000,DST_OFFSET=3600000] 
	  </p928:getEndDateResponse> 
	 </soapenv:Body> 
 </soapenv:Envelope>

回頁首

使用 JMeter 連線 SOAP Over HTTP 服務

JMeter 提供了 Web Services (SOAP) sampler，用以呼叫基於 HTTP 的 Web 服務。下面詳細說明 SOAP Over HTTP 服務呼叫的各個屬性。

圖 3.SOAP Over HTTP 服務呼叫的各個屬性

SOAP Over JMS 服務呼叫的各個屬性說明：

QueueConnectionFactory:連線工廠的預設 JNDI 實體
JNDI name Request queue:JNDI 請求佇列名字
JNDI name Receive queue:JNDI 接收佇列名字
Timeout:請求超時設定
Communication style:通訊形式（包括僅僅請求和請求應答）
Content:請求信封
JMS Properties:JMS 的一些屬性設定（對於 IBM WAS 必須要有 targetService 屬性）
Initial Context Factory:JNDI 的初始會話工廠
Provider URL:服務提供地址

下面是一次完整的 JMS 請求與 JMS 響應 SOAP 資料：

<span style="font-family:Arial,sans-serif;BORDER-TOP-WIDTH: 0px; PADDING-RIGHT: 0px; PADDING-LEFT: 0px; BORDER-LEFT-WIDTH: 0px; BORDER-BOTTOM-WIDTH: 0px; PADDING-BOTTOM: 0px; MARGIN: 0px; VERTICAL-ALIGN: baseline; PADDING-TOP: 0px; BORDER-RIGHT-WIDTH: 0px; outline: 0px">JMS Request</span>
 <soapenv:Envelope> 
	 <soapenv:Body> 
		 <tns0:getAuEmpPositionId> 
			 <ev_id>6098</ev_id> 
		 </tns0:getAuEmpPositionId> 
	 </soapenv:Body> 
 </soapenv:Envelope> 

 <span style="font-family:Arial,sans-serif;BORDER-TOP-WIDTH: 0px; PADDING-RIGHT: 0px; PADDING-LEFT: 0px; BORDER-LEFT-WIDTH: 0px; BORDER-BOTTOM-WIDTH: 0px; PADDING-BOTTOM: 0px; MARGIN: 0px; VERTICAL-ALIGN: baseline; PADDING-TOP: 0px; BORDER-RIGHT-WIDTH: 0px; outline: 0px">JMS Response</span>
 <soapenv:Envelope> 
	 <soapenv:Header/> 
	 <soapenv:Body> 
		 <p150:getAuEmpPositionIdResponse> 
			 <getAuEmpPositionIdReturn xsi:nil="true"/> 
		 </p150:getAuEmpPositionIdResponse> 
	 </soapenv:Body> 
 </soapenv:Envelope>

回頁首

設計高效的測試用例集

壓力測試或者系統測試不同於功能測試，測試的重點不在系統產品是不是滿足設計需求。它所看重的是系統在大的使用者量和負載情況下的可靠性以及系統響應 , 它目標是測試系統的執行效率，特別是在較短時間內系統負載快速增長時系統的相應速度。在實際的測試過程中，大量使用者同時訪問的系統節點也可能成為產品潛在的效率瓶頸。因此 , 壓力測試和系統測試也往往是在功能測試之後進行。

對於普通的軟體系統 , 產品的瓶頸可能會在資料庫伺服器上，Web 伺服器上，而對於 SOAP 服務系統測試，Web Services 伺服器和 JMS 伺服器是客戶端請求的主要節點 , 同時，主要業務邏輯的處理也都分佈在這些節點上，它們很有可能成為系統訪問的瓶頸，如果這些節點出現問題，那麼對整個系統的效率會有致命的影響，也是壓力測試和系統測試要優先考慮的。

改進測試策略、測試方法、測試過程，使用高效的測試用例集，從而保證產品質量。這個是主要目的，也是最直接的目的。一個高效的測試用例集應包含以及適應如下要素：

在什麼時候確定要執行系統測試
如何去檢測並解決系統性能和負載問題
收集監視伺服器效能資料（I/O,CPU,MEM）
儘量減少因為個人配置和某些測試用例而造成系統出現錯誤和瓶頸
所有測試工作都得到有效協調並目標一致

當已經確定了所需的 JMeter Samplers，並且在此基礎上設計出一個通用的測試計劃，那麼就可以構建我們的測試指令碼了。本文的測試用例以及最終的測試計劃也是建立在這些要素之上。

測試計劃（Test Plan）描述了測試執行過程中 JMeter 的執行順序、過程以及步驟，一個完整的測試計劃包括一個或者多個執行緒組 (Thread Groups)、迴圈控制器（Loop Controllers）、監聽器 (Listener)、邏輯控制器（Logic Controller）、定時器（Timer）、斷言（Assertions）、配置資訊（Config Elements）等。

在測試計劃中新增一個使用者定義變數配置元素（User Defined Variables）, 可以在裡面定義伺服器地址，日誌路徑，超時限制等變數，提供指令碼重用。同時新增兩個使用者組，一個是 SOAP Over HTTP Group，一個是 SOAP Over JMS Group。在每個使用者組下面分別新增一個總的迴圈控制器（Loop Controller），用以控制指令碼迴圈次數。在總迴圈控制器下面新增隨機選擇器（Random Selector）用以隨機選擇執行測試指令碼。下圖是我們整個的 Test Plan。

圖 4. 設計完成之後的 SOAP 測試計劃

回頁首

啟動 SOAP 服務測試

當準備好我們的測試計劃之後就可以啟動執行壓力測試了，為了記錄測試結果和資訊，要增加 Listener 來完成這個任務。JMeter 提供了視覺化的介面以及統計報表來供我們選擇。這裡我們使用表格（Summary Report）的形式來檢視和分析測試結果。

你可以通過下面的步驟來給每個 Group 增加 Summary Report 監視器 :

1. 選中 Test Plan 中要新增 Listener 的 Group 節點，這裡我們選擇 SOAP Over JMS Group。
2. 右擊選擇 Add-->Listener-->Summary Report, 介面右邊會相應的出現我們選擇的 Listener 的設定資訊。

在經過一系列工作之後，已經完成了整個 Test Plan，現在可以選擇 JMeter 選單 run-->start 來啟動我們的壓力測試了。下圖是執行過程中測試統計資料的實時跟新資訊。為了增加請求負載和獲得更有價值的資料，我們可以更改執行緒數、等待時間和迴圈次數。

圖 5. 基於吞吐量的測試結果報表（Summary Report）

回頁首

獲得的經驗

總結：

使用 JMeter 來作為測試工具對 SOAP 協議的服務進行壓力和系統測試是一個很好選擇，選擇 JMeter 來進行 SOAP 測試具有以下顯著的優點：首先 JMeter 提供了強大全面的 SOAP 請求 / 接收以及監視功能，允許你執行、捕獲在客戶端和伺服器端的 SOAP 流量分析。其次，可以使用 JMeter 可以設計出高效、易維護的測試用例甚至測試計劃。最後，我們可以選擇 JMeter 提供的符合我們情況的結果 Listener，並且可以從這些 Listener 中很容易的分析出系統或者是服務存在的問題和瓶頸。總體上講，我們在 JMeter 測試框架中構建的 SOAP 測試計劃很好的完成了對 SOAP 協議的系統測試。下面詳細列出了我們在本次測試過程中獲得的技巧以及經驗。

測試工具的選擇

測試工具在軟體和產品測試中是必不可少的，包括系統測試，壓力測試，效能測試以及功能測試。它也會與要測試的產品，測試的領域以及測試的重點有很大的關係。因此，選擇一款合適的測試工具對高效的完成測試是至關重要的。

設計高效的測試計劃

一個高效的測試用例集可以快速的診斷出系統的效能瓶頸。為此應該全面的分析瞭解要測試系統的架構與應用，儘量避免盲目或者重複的測試用例，最終來構建效率儘可能高的測試用例集。

儘量全面的系統監控

軟體缺陷和系統性能瓶頸的診斷可能會需要各個方面的檢測資料，它們對問題的解決會提供很大的幫助，因此測試過程中應該有全面的系統監控，包括伺服器的各項資料（CPU,I/O,MEM）, 後臺資料庫的各項資料，相應時間以及網路流量等。

關注 SOAP 請求的超時（Timeout）

基於 SOAP 協議的請求，無論是 SOAP Over HTTP 還是 SOAP Over JMS 都會有請求超時（Timeout），引起請求超時的原因可能是多方面的（伺服器的響應速度，效率，網路頻寬等），合理的分析以及設定請求超時能更準確的掌握產品的效能情況。

使用 JMeter 對 SOAP 應用進行壓力或效能測試

Appache JMeter 以及 SOAP 協議簡述

開源測試工具：Appache JMeter

訊息傳遞協議：SOAP

JMeter 呼叫 SOAP 框架機制

圖 1.JMeter 框架基於上述兩種不同的協議對 SOAP 訊息的一次簡單呼叫機制流程

準備測試環境

注意事項

使用 JMeter 連線 SOAP Over HTTP 服務

圖 2.SOAP Over HTTP 服務呼叫的各個屬性

下面是一次完整的 HTTP 請求與 HTTP 響應 SOAP 資料：

使用 JMeter 連線 SOAP Over HTTP 服務

圖 3.SOAP Over HTTP 服務呼叫的各個屬性

下面是一次完整的 JMS 請求與 JMS 響應 SOAP 資料：

設計高效的測試用例集

圖 4. 設計完成之後的 SOAP 測試計劃

啟動 SOAP 服務測試

圖 5. 基於吞吐量的測試結果報表（Summary Report）

獲得的經驗

總結：

測試工具的選擇

設計高效的測試計劃

儘量全面的系統監控

關注 SOAP 請求的超時（Timeout）

相關推薦