1 測試需求

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

視頻播放的大概流程是客戶端發起請求，系統對請求進行權限驗證，權限驗證經過之後進行配置下載，最後視頻流返回客戶端。——因爲視頻流回傳是受網絡影響較大的，因此針對客戶的這個需求我分紅兩個工做，一是計算客戶當前寬帶能支撐多少路視頻播放；二是對鑑權和配置下載接口進行測試，驗證其瓶頸。微信

如下以配置下載接口爲例說明本次測試過程：網絡

讓開發提供鑑權接口的信息，以下圖所示。併發

接口名編輯器	getData工具
接口地址性能	http://IP:PORT /PeiZhi/services/IPzService?wsdl測試
輸入參數名ui	xtlbspa	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 秒。設置完畢後，點擊左上方的綠色箭頭，程序開始進行負載測試。

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，又進行了一次負載測試。

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

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

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

本文分享自微信公衆號 - 軟件測試經驗與教訓（udatest）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。

SoapUI測試WS接口實戰