1、背景
1.1 Web程序中的接口
1.1.1 典型的Web設計架構
web是實現了基于網絡通信的瀏覽器客戶端與遠程服務器進行交互的應用，通常包括兩部分：web服務器和web客戶端。web客戶端的應用有html，JavaScript，ajax，flash等；服務器端的應用非常豐富，比如java的servlet，jsp，ssh框架，.net的aspx，還包括其他腳本如php，python。
web服務器端的設計架構近年來一直比較流行的是三層架構（3-tier application），通常意義上的三層架構就將業務應用劃分為：表現層（UI）、業務邏輯層（BLL）、數據訪問層（DAL）。分層的目的在于降低代碼見耦合，提高代碼架構的可維護性。
總的來說，這三層架構的意義如下：
1）表現層（UI）：用戶界面，即用戶可見的操作界面或者入口。
2）業務邏輯層（BLL）：封裝具有業務含義的操作函數。
3）數據訪問層（DAL）：封裝對數據庫或者其他存儲介質的原子性操作。
1.1.2 Web接口的概念
web接口是服務器與客戶端交互的方式，即瀏覽器或者其他客戶端工具與web服務UI層交互的協議.常見的有兩大類，一是瀏覽器與服務器交互的HTTP協議的接口，另一類web？service接口如soap，rmi，rpc等協議。
HTTP接口請求方法常用的有GET、POST兩種請求類型。具有無連接無狀態的特征。HTTP請求例如GET？/images/logo.gif？HTTP/1.1，表示從/images目錄下請求logo.gif這個文件。
1.2 WEB接口自動化
1.2.1 Web接口測試
web接口測試即站在web服務程序UI層之上自動化測試的一種手段，是站在用戶的角度上測試web服務程序業務邏輯的正確性。測試的重點是圍繞web服務暴露的接口檢查接口數據的正確性，這個過程是將web服務程序當做黑盒，通過自動化測試技術提高測試執行效率降低人工回歸的成本。
1.2.2 什么要做接口測試
下圖說明了基于HTTP接口的web應用的整體架構特征，按照這種架構設計開發項目，引發兩個問題：
第一、系統級測試一定要等到web服務器程序和瀏覽器端的程序都開發完畢后才能進行嗎？參考以下傳統的RD與QA合作進行的項目流程，可以看到，QA在RD提測程序后才能真正進入到測試階段，那么項目的發布周期自然受到這種串行下來的工作安排影響，是1+1的時間周期。
第二、為了提高效率，公司的團隊引入了系統級自動化測試的工具或方案，既然是從用戶角度去測試，當然要寄希望于從模擬用戶行為代替手工操作來進行測試。比如從瀏覽器操作的方式去測試，能很直接的覆蓋用戶的一手操作，但是需要思考的是，瀏覽器各個版本如ie6，7，8，chrome，firefox等，各自有各自特性，JavaScript在瀏覽器內表現效果又不盡相同，瀏覽器在不同windows環境下、不同網絡條件下運行的狀況又不一樣，給QA帶來一個難題：如何保證瀏覽器上的自動化case穩定、高效執行？
我們先分析第一個問題，項目團隊需要提高產品發布效率，提前QA測試介入的時間點，我們可以想到有幾種方案：
1）QA跟隨RD進度，加入到各個層級代碼參與單元測試：
假設我們沒有引入TDD模式沒有引入敏捷，那么常規的解決方式是一批被測函數代碼由RD寫完之后提交svn，然后QA update代碼后先花十幾分鐘閱讀代碼再加上對業務需求的理解然后再花費十幾分鐘寫Xunit case，與QA預期結果一致則好，不一致則需要再花時間與RD溝通原因等等。其一QA花費更多時間，要深入到RD的代碼邏輯深處；其二對QA？coding能力要求也很高，這取決于公司QA人員的定位，是要求QA更熟悉測試設計而代碼能力次之呢，還是QA的整體技術能力都要很高，一般來講大多數的QA強項在于業務需求的熟悉和測試設計能力，所以這種方式對團隊整體人員素質的要求非常高。
2）QA不參與單測，RD依據需求縱向拆分功能點然后迭代提測，QA能提前一定時間介入測試：
對照如下的流程示意圖說明這個過程，實際上是傳統瀑布模型做了拆分，變為了多個短期的“小瀑布模型”，這樣的效果能使得項目周期長的產品，可提前介入測試以提前發現問題。
在這樣的迭代流程中，如何合理利用自動化手段來提高測試效率呢？一般來講迭代周期不會很長，常規性的為3~5天一個周期，做太復雜的自動化投入成本較高。對于web系統來講，為避免過多的自動化投入得不償失，需要謹慎的判斷web系統的特征適合哪種自動化模式。所以這里特別要關注的就是分層自動化測試：
如上圖所述，web系統可以做幾種功能測試：單元測試，集成測試，系統測試。大多數的產品QA不會太多介入單元測試，集中在集成測試和系統測試。結合上面提到的迭代排期，其實在一般項目中上層UI的開發往往比較滯后，趕工的結果也是提測質量不高。所以可推薦的一種模式是迭代周期內按照UI接口劃分功能點做排期，UI的開發可以放在UI接口穩定之后提測。所以迭代周期內，面向UI接口的自動化就是一個將測試前置，并且積累自動化case以待回歸時代替手工操作的大好機會。
就著上面這個結論，再分析一下本節開頭拋出的第二個問題：“系統級自動化測試的穩定性與可靠性”，先提出幾個觀點如下：
1）有一些測試點，從系統級角度做自動化的性價比不高：
第一：目前技術手段上還不具備低成本的實現手段的，比如flash、js實現的一些效果、不規范HTML標簽、對瀏覽器運行版本環境考慮不周等引發的問題。導致開發成本高，運行的穩定性較低。
第二：UI實現邏輯比較薄，比如只是查詢DB一個字段然后顯示在頁面，把重點放在后端邏輯檢查上性價比更高。
2）系統級測試和集成測試的關注點不同：系統級測試關注的是用戶從UI直接操作所能見到的結果，而集成測試關注的是UI接口數據的準確性。比如報表功能，頁面上看到的就是一個表格，而對UI接口來講需要覆蓋N種參數組合。
上面兩點說的是系統級測試和集成測試的區別之處，在自動化實施過程中，推薦分層的測試思路，既能夠細化測試也能綜合衡量自動化的投入成本，總的來講就是以下幾點：
1）傳統瀑布項目，持續周期長，通過迭代模式可提前介入測試，而迭代周期內系統級功能可能不具備可測性，但是接口可以具備可測性。
2）基于UI的自動化有利有弊，需要結合系統特征綜合考慮分層測試的必要，分層后各有測試的側重點，比如UI自動化重點關注UI的操作流程和顯示，集成測試更關注UI接口的參數等價類覆蓋和數據正確性。
1.2.3 接口可測性分析
接口顯而易見要比UI簡單的都，只需要知道協議和參數即可完成一次請求，從自動化測試實施難易程度來看，有以下幾個特征：
1）驅動執行接口的自動化成本不高：HTTP，RPC，SOAP，RMI等各類都可以依據相應的協議封裝一個client作為接口請求的執行器。
2）整個自動化測試中綜合性價比高：接口測試還是屬于黑盒范疇，所以比單元測試難度要低；而相比UI自動化穩定性可靠性更高。
2、接口測試工具選型
2.1 常見測試工具
2.1.1 JUnit
JUnit作為單元測試框架常被用作白盒測試，框架具備的一些優良特征有：
1）提供豐富API支持多種驗證結果正確性的邏輯
2）通過參數化、@before、@after等特性，支持用例代碼可復用
3）suite的模式支持case的批量運行
4）有展現良好的報表
5）與eclipse ide集成，使用方便
2.1.2 HttpClient
HttpClient是一個功能豐富支持HTTP協議的客戶端編程工具包，具備以下主要功能：
1）封裝實現了所有HTTP的方法，如GET，POST，PUT，HEAD
2）支持redirect，會話保持
3）支持文件上傳
2.1.3 HttpUnit
HttpUnit是一個HTTP請求的測試輔助工具，能處理web測試的需求。通過模擬瀏覽器的行為，處理HTTP請求、會話保持、重定向以及對HTTP？response做DOM解析。
相比于HttpClient，不同之處在于：
1）HttpUnit能對HTTP返回的結果頁進行解析，比如DOM元素定位
2）HttpUnit能自己啟動一個servlet來運行被測服務
2.1.4 HtmlUnit
HtmlUnit相比HttpUnit功能更加強大，就像一個瀏覽器，HtmlUnit是Junit的擴展測試框架之一，該框架模擬瀏覽器的行為，開發者可以使用其提供的API對頁面的元素進行操作。HtmlUnit支持HTTP，HTTPS，COOKIE，表單的POST和GET方法，能夠對HTML文檔進行包裝，頁面的各種元素都可以被當作對象進行調用，對JavaScript的支持也比較好。
2.1.5 JWebUnit
JWebUnit以HttpUnit和JUnit為基礎的一個web測試工具?？梢杂脕眚炞C鏈接跳轉、表單輸入和提交、表格內容以及其他？Web？應用程序特性的正確性。相比于HtmlUnit，JWebUnit封裝的更友好，編寫case也會更加簡單。