1、背景介紹
1.1 接口
web ui接口是服務器與客戶端交互的方式，即瀏覽器或者其他客戶端工具與web服務UI層交互的協議.常見的有兩大類，一是瀏覽器與服務器交互的 HTTP，HTTPS協議的接口，另一類web service接口如soap，rmi，rpc等協議。這些接口的共通特征都是作為Server對外的UI提供通信服務。
1.2 接口測試
web ui接口測試即站在web服務程序UI層之上自動化測試的一種手段，是站在用戶的角度上測試web服務程序業務邏輯的正確性。測試的重點是圍繞web服務 暴露的接口檢查接口數據的正確性，這個過程是將web服務程序當做黑盒，通過自動化測試技術提高測試執行效率降低人工回歸的成本。
1.3 可測性分析
1.3.1 為什么做接口測試
在業務模塊的分層測試中，各種測試方式的比重如下圖所示，實踐中我們從系統級測試發現的bug數目最多，所以系統級測試占比比較大；除此之外，由于現在敏 捷的嘗試以及普遍開展的項目迭代，面向模塊提前介入測試的方式也越來越頻繁，而此時并不具備系統級可測性，因此模塊的接口就成為測試自動化的最好入口。
在業務系統常用測試方案中，有以下說明：
（1）單測在不同的團隊和模塊有不同的作法，如果QA太多的介入，則對QA coding能力要求較高，case的傳承性也受到挑戰
（2）業務模塊接口測試主要關注接口請求參數與返回數據的正確性，以參數覆蓋為測試等價類
（3）系統級case對web業務模塊來說都是基于瀏覽器用戶行為的，目前有selenium自動化，大部分是手工測試。
從分層測試的特征，業務系統的結構出發，我們認為，接口測試的必要性包括：
（1）迭代開發模式中，接口測試可先于系統級測試提前進行，屬于測試前置
（2）相比于基于瀏覽器客戶端的系統級測試，接口測試更專注接口數據正確性，穩定性與可靠性的性價比高
1.3.2 接口可測性
接口在業務模塊中的類型為典型的HTTP接口（Ajax，Dwr，Action…），也有Java類型的一些接口（RPC，RMI，SOAP），在可測性上具有一些共通特征：
（1）可自動化率高：接口總能通過相應的client來發送請求
（2）脫離RD代碼依賴，只針對接口：屬于黑盒測試范疇，難度較白盒低
（3）執行速度介于系統級與單測之間：對于業務模塊來講，脫離瀏覽器后的接口測試穩定性與效率都是大幅提升
（4）容易實現數據分離與數據驅動，容易抽取公共的框架性內容，降低case編寫維護人員對coding的依賴
2、輕量級測試框架itest
itest是interface test接口測試框架的簡稱：支持基于網絡通信的WEB UI接口自動化測試，支持HTTP，SOAP，RPC等幾種常見協議，支持多種驗證結果的模式，支持數據分離，最主要的特征還是通過數據文件驅動測試執行，不需要編碼實現測試用例。
2.1 架構設計
itest功能組成與基本處理流程如下圖，以主要協議HTTP為例：
基本設計思想：
（1）itest框架支持case文件與執行的分離，case并非coding模式，而是通過各類文件描述case信息（請求文件，數據準備清理文件，驗證結果文件…），itest解析case信息后轉化為接口請求
（2）登錄是針對uc，uuap等測試環境下，模擬請求并獲得sessionid，HTTP請求的case需要帶著sessionid
（3）參數化：itest作為執行框架，執行接口的部分邏輯比較薄，是基于數據驅動的方式，把case數據轉為Junit4的參數化數組，循環執行
（4）setup與teardown：以不同文件后綴代表不同的行為，itest內部可擴展實現對不同后綴名文件的操作邏輯，如后綴為.sql，則當做sql語句直接執行
（5）驗證：也是以文件后綴名做有區別的驗證，如后綴.response是直接判斷expected.equals(actual)？而后綴是.csv的則拼裝為sql后查詢db是否結果匹配
基礎結構：
Junit4+HTTPunit+Ant
2.2 數據驅動
為降低自動化過程中case編寫人員的編程成本，采用的模式是itest作為核心的執行與驗證框架，傻瓜式的執行外部case目錄內的各類文件，每一個 case都不需要coding。如下圖所示：case的存在形式為文件目錄，1個case是1個目錄，itest順序讀取case，以相同流程執行每一個case。
2.3 結果驗證
結果驗證按照業務系統的特征，現在支持以下幾種：對接口返回的內容直接做對比驗證；對數據庫update后的內容做驗證；將接口返回的json做處理后做驗證。
2.4 測試數據
對業務系統自動化測試來說，業務測試數據非常關鍵，因為它需要符合一定的業務規則；如何構造數據有幾個爭議的地方：
（1）數據（包括DB，server文件，樁文件）一次性構造好放那不動，無法保證數據不被污染，且移植性受限；
（2）如果能做整個環境的備份還原則不怕污染，但是case與case之間可能會互相干擾數據
（3）自動化case是否嚴格要求數據的隔離，如果要求，則每個case都自己負責生命周期內的數據準備和清理；如果不要求，則需要case設計時刻意避免數據的使用混亂
不同業務系統在設計上各有千秋，哪一種數據準備的方案都是有不同的代價，結合筆者所處產品線的特征，認為自動化case自己負責生命周期內的數據準備與清理，是綜合效果比較好的模式：1個獨立的case，能有自己生命周期內的數據準備和清理，則最大程度上保證了case運行的穩定性和可靠性，避免case之間互相因為數據發生干擾！
2.5 擴展性
itest在擴展性方面，通過“以文件后綴作為識別標簽，新的功能需求，約定一種新的文件后綴”，itest維護人員在框架內開發相應的分支邏輯，而case編寫人員則只需按照文件約定格式設計文件即可。如下為目前支持的不同文件，以及相應的不同邏輯功能：
