http://mp.weixin.qq.com/s?__biz=MjM5OTI2MTQ3OA==&mid=2652177907&idx=4&sn=31e36ba744bb9683b1bbe49039247909&scene=0#wechat_redirect

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編寫人員則只需按照檔案約定格式設計檔案即可。如下為目前支援的不同檔案，以及相應的不同邏輯功能：