SoapUI測試WS接口實戰

引文：

本文討論以下問題：

視頻播放功能如何進行壓力測試？

進行webservices接口測試時，用LR和soapui哪個工具更好？

1 測試需求

前幾天接到一項壓力測試的任務：視頻播放功能的並發壓力測試，也就是客戶想知道我們系統的視頻播放功能能支撐多少並發。

視頻播放的大概流程是客戶端發起請求，系統對請求進行權限驗證，權限驗證通過以后進行配置下載，最后視頻流返回客戶端。——由於視頻流回傳是受網絡影響較大的，所以針對客戶的這個需求我分成兩個工作，一是計算客戶當前寬帶能支撐多少路視頻播放；二是對鑒權和配置下載接口進行測試，驗證其瓶頸。

以下以配置下載接口為例說明本次測試過程：

讓開發提供鑒權接口的信息，如下圖所示。

接口名	getData
接口地址	http://IP:PORT /PeiZhi/services/IPzService?wsdl
輸入參數名	xtlb	jkid	queryXml
輸入參數值	1010	0002	<?xml version="1.0" encoding="utf-8" ?> <root> <QueryCondition> <szUser>wangchengyi</szUser> <szPass>wangcyadmin</szPass> <szUserType>0</szUserType> </QueryCondition> </root> （szUserType：0表示視頻監控普通用戶，1表示數字矩陣，2表示高清調度，3表示DVR調度，5表示車載調度）

 

好了，有了接口信息以后，就該選擇測試工具了。對於WS接口的測試，特別是入參為XML格式的，我比較鍾情於用SoapUI進行測試（下文也有原因說明）。下面介紹一下詳細測試過程，為了方便第一次接觸SoapUI的童鞋理解，下文描述較詳細，如已了解可以跳過。

2 SoapUI 下載地址

鏈接：http://pan.baidu.com/s/1dFkJVLR 密碼：z1jo

3 SoapUI介紹

開源的 Web  服務測試工具，可以測試基於 SOAP 的 Web  服務，以及REST 風格的 Web 服務。支持多樣的測試，例如功能測試，性能測試，回歸測試等。

4 SoapUI使用過程

4.1 創建/導入工程

1）  安裝並運行SoapUI之后，你就可以創建第一個SoapUI工程了。程序第一次打開時，左側導航面板上，自動有一個空的 Projects 工程。

2）  右擊左側導航面板中的工作空間節點“Projects”，選擇 “New  SoapProject”。

 

3）  頁面彈出“NewSoapUI Project”，填入Project Name，Initial WSDL/WADL 可填入URL 地址或直接導入WSDL 導文入件文，件后，如下圖所示：

 

 

默認選上：

• Create sample requests for all operations?（為每個接口創建一個請求的例子）
• Creates a TestSuite for the imported WSDL or WADL （為WSDL或者WADL創建一個測試包）
• 點擊 OK 按鈕后，頁面彈出保存工程的提示，以 project 名稱+“- soapui-project.xml”的形式進行命名，因此上述工程在保存時頁面給出默認命名為PeiZhiTest-soapui-project.xml，直接點擊保存即可。

4）  保存成功后，頁面繼續彈出“GenerateTestSuite”TAB頁：

選擇：

• Single TestCase with one Request for each Operation（為每個接口的請求都創建一個測試用例）
• Create new empty requests創（建一個空的請求）
• Operations 中選擇要測試的 WS 接口方法，如果一個 WS 有多個方法， Operations 中會列出所有方法，只須選擇要測試的方法即可。
• 最后勾選上 Generates a default LoadTest for each created TestCase（為每個創建好的測試用例生成一個默認的負載測試）

5）  選擇完畢后，點擊 OK 按鈕，進入測試用例命名頁面，命名完畢后，確定。

 

6）  在測試用例編寫完畢后，可使用 ctrl+s 鍵，保存當前的工程。

7）  如果要導入其他的工程，可通過選擇“Import Project”，找到XXX- soapui-project.xml，選中后即可導入工程。

 

4.2 創建測試用例

1）  上面操作已經增加了 PeiZhiTest的 Web 服務，接下來可以執行請求了。在上面增加接口的時候，已經根據 WSDL 的 Schema 定義為每一個操作創建了默認請求。

 

 

2）  現在將以測試getData方法為例，來介紹用例的創建過程。按照下圖所示，打下測試包下的“getData  TestCase”，在展開的“Test Steps”下選擇“getData”，雙擊打開。

雙擊“getData”后，在 SoapUI 的右側會出現請求編輯器：

請求編輯器分為三部分：

• 頂部的工具欄，包含一組請求相關的動作、操作
• 左邊是請求區域
• 右邊是響應區域

SoapUI 默認生成的請求中，“？”表示需要被替換的內容。根據開發提供的參數信息替換這些值。

 

3）  通過按下工具欄最左邊的按鈕（綠色箭頭）來發送本次請求，請求會在后台執行，響應內容會出現在編輯器的右邊。

 

4）  根據上述返回的結果報文后，可看到接口已被正確的調用，為在測試中不用人為地進行接口功能是否正確的判斷，因此加入斷言 Assertions，可由程序直接對返回結果進行判斷。點擊下圖左上角的增加斷言按鈕：

 

會彈出“Add Assertion”對話框，選擇“Contains”的斷言，確定后彈出如下對話框，在Content 中填入內容，此處是表示返回的結果報文里應該包含的字段，根據我們 PeiZhiTest 接口的返回值，填寫如下，點擊“OK”，插入斷言完畢，程序會在運行用例時，自動幫我們校驗返回的結果報文是否包含斷言內容。

  

說明：

“Test Steps”中可創建多個測試用例，組成一個測試用例集，在運行該test steps時，會根據用例的順序從上到下依次測試，將上一用例的輸出作為下一用例的輸入再組織相應的用例，此處待進一步研究。

 

4.3 創建負載測試

1）  在創建完測試用例后，本工程的負載腳本也由在最初創建好工程時，已經默認創建完畢，在此可直接打開使用，如下，可直接點開 Load Tests 節點下名稱為“LoadPeiZhiTest”的負載腳本，雙擊打開。

  

2）  雙擊打開后，頁面如下顯示，設置過程參考如下，場景為 100 用戶並發，持續運行 10分鍾，沒有思考時間。相應的SoapUI 可設置 Threads=100， Test Delay=0，Limit=600，后面的下拉框選擇 Seconds，表示 600 秒。設置完畢后，點擊左上方的綠色箭頭，程序開始進行負載測試。

參數說明：

limit：表示我們負載測試要持續執行的時間，單位為秒。

Threads：配置負載測試所用的線程數，即一般性能測試中所說的並發數。

Test Delay:設置測試時線程的休眠時間，即在完成一次完整的用例執行后，開始下一次執行時，線程的休眠時間，單位為毫秒。

Random:該值的設置是與“Test Delay”的設置結合在一起的，如下圖，它表示休眠的時間會在（1-0.5）*1000=500 和（1+0.5）*1000=1500秒之間波動。如果設置為0，則表示test delay不會隨意變化，直接是初始設置的毫秒數。

3）  負載測試過程中，右上方會有進度條顯示測試的進度情況，SoapUI提供了2 個圖表和一個簡要列表的形式列出了測試過程中相關數據的監控，如下圖，下圖為簡要列表形式提供的數據：

   

4）  點擊上方紅色方框框住的按鈕，會彈出下方的監控圖表，圖中只有曲線，沒有任何數據說明，只能看到變化的情況，由於無相應的刻度，而無法直觀地看出數據大小：

 

SoapUI 還提供了另一個圖表，此圖表與上圖類似，不過僅能顯示線程數與另一統計內容的曲線變化情況，另一統計內容可通過下圖紅色方框里的“select statistic”進行選擇，如下：

 

5 與 LoadRunner的比較

本章主要探討用兩個工具測試相同接口時的不同。

使用LoadRunner提供的Webservice協議進行相同接口的測試。

1）  不加校驗的腳本（腳本名稱：LR_1 ）如下：

lr_start_transaction("PeiZhi");

    web_service_call( "StepName=getData_101",

        "SOAPMethod=IPzService|IPzServiceHttpPort|getData",

        "ResponseParam=response",

        "Service=IPzService",

        "ExpectedResponse=SoapResult",

        "Snapshot=t1474862040.inf",

        BEGIN_ARGUMENTS,

        "in0=1010",

        "in1=0002",

        "in2=<?xml version=\"1.0\" encoding=\"utf-8\" ?><root><QueryCondition><szUser>wangchengyi</szUser><szPass>wangcyadmin</szPass><szUserType>0</szUserType></QueryCondition></root>",

        END_ARGUMENTS,

        BEGIN_RESULT,

        "out=Param_out",

        END_RESULT,

        LAST);

    lr_end_transaction("PeiZhi", LR_AUTO);

2）  加了檢查點的腳本（腳本名稱：LR_2  ）： 

lr_start_transaction("PeiZhi");

 web_reg_find("Text=jqz",

 

        LAST );

    web_service_call( "StepName=getData_101",

        "SOAPMethod=IPzService|IPzServiceHttpPort|getData",

        "ResponseParam=response",

        "Service=IPzService",

        "ExpectedResponse=SoapResult",

        "Snapshot=t1474862040.inf",

        BEGIN_ARGUMENTS,

        "in0=1010",

        "in1=0002",

        "in2=<?xml version=\"1.0\" encoding=\"utf-8\" ?><root><QueryCondition><szUser>wangchengyi</szUser><szPass>wangcyadmin</szPass><szUserType>0</szUserType></QueryCondition></root>",

        END_ARGUMENTS,

        BEGIN_RESULT,

        "out=Param_out",

        END_RESULT,

        LAST);

    lr_end_transaction("PeiZhi", LR_AUTO);

3）  場景與SoapUI的場景一致：100 用戶並發，持續運行 10 分鍾，沒有思考時間。對 LR_2 腳本進行性能測試后，發現響應時間比使用 SoapUI 進行測試的響應時間來的大，因此把校驗過程注釋掉，使用 LR_1，又進行了一次負載測試。  

 

根據測試結果分析得出以下結論： 

1. SoapUI是專門針對WS接口的測試工具，在對相同接口測試時，SoapUI表現出來的性能更優越。
2. SoapUI在發送請求時，是直接以組裝好的soap報文進行發送，而LR是使用web_service_call方法，從方法傳入相應的參數，再由LR組裝為 soap報發后，再發往接口進行調用，因此LR在組裝報文時，會有相應時間的耗費。LR腳本中創建的事務，就包含了這段組裝報文的時間，因此響應時間會比SoapUI的響應時間更大。LR與SoapUI的差別應該還有更多，在此我尚未研究的更深入。
3. 對於LR，在測試中若增加對返回結果的校驗，也會耗費一定的時間，從上面的數據可以看出，時間差大約 0.12s左右，這也與校驗中使用的方法有關系，如果方法高效的話，這個時間差也將更少。
4. SoapUI提供的結果數據的分析不如LR那么詳細與全面，但對於接口級的測試已足夠，且速度更優。

目前 WS 接口有多種語言可以實現，除了 JAVA、C++，當前還有遇到 WCF， 生成的 WSDL文件無法直接讀到接口的入參與出參，此種接口生成的WSDL，LoadRunner讀取時直接失敗，暫找不到解決方法。而使用SoapUI，本人已測試過，可支持JAVA、C++，且 WCF 這種形式的接口也可支持。