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