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

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 數據：

HTTP Request <soapenv:Envelope> <soapenv:Body> <q0:getEndDate> <ip_id>12</ip_id> </q0:getEndDate> </soapenv:Body> </soapenv:Envelope> HTTP Response <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 數據：

JMS Request 　　<soapenv:Envelope> 　　<soapenv:Body> 　　<tns0:getAuEmpPositionId> 　　<ev_id>6098</ev_id> 　　</tns0:getAuEmpPositionId> 　　</soapenv:Body> 　　</soapenv:Envelope> 　　JMS Response 　　<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），引起請求超時的原因可能是多方面的（服務器的響應速度，效率，網絡帶寬等），合理的分析以及設置請求超時能更準確的掌握產品的性能情況。

最新內容請見作者的GitHub頁：http://qaseven.github.io/