開源的Web Service測試工具介紹
來源: javafan
在本文中，我會分析3款聲稱能驗證你的Web services的正確性的工具：soapUI、TestMaker和WebInject。三款都是開源的，能免費下載并整合到你的下一個Web services項目中去。
由于IT界對Web services的持續關注和偏愛，以及越來越多的Web-service構建工具的出現，Web service變得更加容易創建 – 并且，很容易一團糟。
Web service其實是一些暴露給網絡(不管是內網還是外網)的程序的集合。而一個Web service的錯誤可能激怒的不僅僅是監視和維護著服務器的經理和管理員，還有調用了你的Web service的客戶。要么把你的Web service做好，要么等著兩邊的指責。
在本文中，我會分析3款聲稱能驗證你的Web services的正確性的工具：soapUI、TestMaker和WebInject。三款都是開源的，能免費下載并整合到你的下一個Web services項目中去。
需要注意的是：在使用這些工具之前你應該理解SOAP和HTTP協議。有些商業產品提供的是SOAP的“偽代碼”。把那些難于閱讀的XML翻譯成易讀的偽代碼，能幫助新手和有經驗的SOAP用戶明白某個SOAP請求和響應之間發生的事情。這三款開源的Web service測試工具需要額外的工作，我推薦中等級別的開發人員使用，學習曲線會適當地比商業產品的長。
SoapUI1.6 我用的是1.6版本的soapUI，一款從Eviware而來的基于Java的工具。這個版本的soapUI在自己獨立的UI里執行;新的1.7版本包括NetBeans、InterlliJ和Eclipse的插件。
用戶界面遵循普遍的IDE架構設計：左邊是導航面板，右邊是內容面板，額外的屬性面板放在底部。如果你用過類似Visual Studio的IDE的話，你會發現使用soapUI很順手。
soapUI把工作組織成項目。每個項目主要由需要測試的接口來識別。在這里，接口是指另外一端的指向一個暴露了Web service方法的站點的URI(統一資源標識)。你可以很快地創建一個基本的項目結構;soapUI能接受一個文件的WSDL或者一個Web service終點傳輸的WSDL。
項目被有層次結構地組織，并且包含一個或多個TestSuite，TestSuite包含一個或多個TestCase，TestCase包含一個或多個測試步驟。真正的工作 – 發送請求、接受響應、分析結果、改變測試執行流程 – 發生在測試步驟這個層面。TestCase收集和組織需要執行某個對目標的特定操作的步驟。TestSuite匯總那些發生在某個特定區域的Web service的TestCase(例如訂購一本書所需要的操作)。你可以通過右鍵點擊項目樹中的父節點并選擇上下文菜菜單中的“New”菜單，來創建新的TestSuite、TestCase和測試步驟。
soapUI通過檢查附加給測試響應的斷言來判斷測試是通過還是失敗。有大量的斷言可供選擇，從“simple contains”測試 – 如果某個提供的字符串匹配則表示成功 – 到“XPath matching”，對響應信息執行復雜的XPath表達式匹配成功則表示測試通過。 測試步驟與程序代碼很類似。目前，soapUI定義了6個測試步驟類型，普遍的是請求(Request)，發送一個HTTP請求給目標地址，并接收一個響應。可插入條件跳轉測試步驟(Conditonal GoTo)來控制流程。一個或多個檢查近的響應的Xpath表達式是必不可少的。第一個表達式的成功會導致相關測試步驟分支的執行。
soapUI強大的是Groovy測試步驟。Groovy是類Java的輕量級腳本語言。一個Groovy測試步驟可以是任何Groovy代碼，也是說基本上Groovy能做的事情，在測試步驟中也能做。測試步驟中的Groovy代碼可以訪問soapUI框架。例如，一個Groovy測試步驟可以通過JDBC讀取數據庫的信息，與前一個測試步驟的響應信息進行比較，并響應地修改執行的流程 – 甚至執行另外一個TestCase。
除了功能測試外，soapUI還能對Web service進行壓力測試。每個壓力測試包含一個或多個TestCase的執行，并且可以調整用于模擬各種各樣的場景。你可以指定測試執行一定量的時間長度，或者一定量的迭代周期，指定以并發的方式執行還是隨時間線性變化的方式。 當壓力測試完成后，一個壓力測試編輯器會為每個TestCase提供大量的統計數據：執行的次數，大、小、平均執行時間等。還可以在統計圖表頁以圖表的形式查看這些數據。
讓soapUI運行起來很容易;能很快地構建一個基本的項目和基本的測試。我對這個工具不滿的地方是：在系統中沒有上下文幫助，這讓你在某些區域想知道可供選擇的是什么變得困難。不管怎樣，文檔提供的還是挺不錯的，只要持續使用，一些初的理解上的混淆都會慢慢消失。TestMaker TestMaker是PushToTest的一個Web service測試工具。它需要Java1.4或以上。我把TestMaker4.4安裝在Ubuntu Linux6.10，看Web service測試在Linux會是怎樣的。安裝很簡單，一旦設置好JAVA_HOME環境變量后，TestMaker啟動和運行都沒有問題。
TestMaker的測試是用稱為“測試代理”(test agents)的腳本來完成的。TestMaker提供一個“代理向導”(Agent Wizard)來讀入WSDL定義并自動創建一個測試代理的基本結構。
需要指出的是：TestMaker不僅僅能測試Web services;它還能被用于測試Web應用程序。與TestMaker綁定在一起的還有一個網絡監視工具，能監視瀏覽器和目標Web應用之間的HTTP通信，并且從交互過程中產生測試用例。然而，我沒有體驗那些功能，因為那與Web services的關系不大。
TestMaker的測試代理是用Jython(用Java寫的Python)寫的。這是把雙刃劍。一方面，TestMaker的腳本可以變得很強大，擁有編程能力。Jython可以訪問所有Java庫，還有TestMaker提供的類和方法。TestMaker大的庫是TOOL(Test Object Oriented Library)，它包括所有處理各種通訊協議的類：HTTP，HTTPS、SOAP、JDBC等。因此，你可以創建很精細的測試用例來處理任何Web service可能被調用的客戶端應用。 另一方面，你需要掌握Jython來充分利用TestMaker，或者換句話說，你需要知道Python和Java。這未必是件壞事，但是它意味著TestMaker的學習曲線要比其他工具陡峭。
由代理向導(Agent Wizard)創建的基本的測試代理(test agent)是很簡單的：它知道目標服務的Web方法，并且執行不會出現錯誤，但是它沒有真正執行任何請求、響應或者測試結果。我發現我需要檢查一個測試代理例子的源代碼來填寫缺少的內容。
一旦你跨越了陡峭的學習曲線，可以很容易地通過拷貝、粘貼和調整已有的代碼來創建新的測試。另外，用戶界面的用戶體驗很好。開始啟動TestMaker的時候，它會打開一個“QuickStart”窗口，在這里，你可以運行代理向導(Agent Wizard)，直接跳到測試代理提供的例子，或者深入閱讀它的文檔。TestMaker的用戶界面也是標準的多窗口IDE，左邊是導航面板，右邊是編輯區域，結果顯示區域在右下端，類導航視圖界面在左下端。
