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