Web自動化測試中的接口測試

1、web 自動化測試中的接口測試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）

2、、業(yè)務(wù)規(guī)律層（bll）、數(shù)據(jù)訪問層（dal）。分層的目的在于降低代碼見耦合，提高代碼架構(gòu)的可維護(hù)性?？偟膩碚f，這三層架構(gòu)的意義如下：1. 表現(xiàn)層（ui）：用戶界面，即用戶可見的操作界面或者入口。2. 業(yè)務(wù)規(guī)律層（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 接口

3、懇求方法常用的有 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ù)規(guī)律的正確性。測試的重點(diǎn)是圍繞 web 服務(wù)暴露的接口檢查接口需求分析具體設(shè)計(jì)編碼實(shí)現(xiàn)測試數(shù)據(jù)的正確性，這個過程是將 web 服務(wù)程序當(dāng)做黑盒，通過自動化測試技術(shù)提高測試執(zhí)行效率降低人工回歸的成本。1.2.2 分什么要

4、做接口測試下圖說明白基于 http 接口的 web 應(yīng)用的整體架構(gòu)特征，依據(jù)這種架構(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)目的公布周期自然受到這種串行下來的工作支配影響，是 1+1 的時(shí)間周期。其次、為了提高效率，公司的團(tuán)隊(duì)引入了系統(tǒng)級自動化測試的工具或方案，既然是從用戶角度去測試，固然要寄期望于從模擬用戶行為代替手工操作來進(jìn)行測試。比如從掃瞄器操作的方式去測試，能很直接的掩蓋用戶的一手操作，但是需要

5、思考的是，掃瞄器各個版本如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)品公布效率，提前 qa 測試介入的時(shí)間點(diǎn)， 我們可以想到有幾種方案：1. qa 跟隨 rd 進(jìn)度，加入到各個層級代碼參與單元測試：假設(shè)我們沒有引入 tdd 模式?jīng)]有引入靈敏，那么常規(guī)的解決方式是一批被測函數(shù)代碼由rd 寫完之后提交 svn，然后 qa update 代

6、碼后先花十幾分鐘閱讀代碼再加上對業(yè)務(wù)需求的理解然后再花費(fèi)十幾分鐘寫 xunit case，與 qa 預(yù)期結(jié)果全都則好，不全都則需要再花時(shí)間與rd 溝通緣由等等。其一qa 花費(fèi)更多時(shí)間，要深化到rd 的代碼規(guī)律深處；其二對qa coding 力量要求也很高，這取決于公司 qa 人員的定位，是要求 qa 更生疏測試設(shè)計(jì)而代碼力量次之呢，還是 qa 的整體技術(shù)力量都要很高，一般來講大多數(shù)的 qa 強(qiáng)項(xiàng)在于業(yè)務(wù)需求的生疏和測試設(shè)計(jì)力量，所以這種方式對團(tuán)隊(duì)整體人員素養(yǎng)的要求格外高。2. qa 不參與單測，rd 依據(jù)需求縱向拆分功能點(diǎn)然后迭代提測，qa 能提前肯定時(shí)間介入測試：對比如下的流程示意圖說明這個

7、過程，實(shí)際上是傳統(tǒng)瀑布模型做了拆分，變?yōu)榱硕鄠€短期的“小瀑布模型”，這樣的效果能使得項(xiàng)目周期長的產(chǎn)品，可提前介入測試以提前發(fā)覺問題。需求分析具體設(shè)計(jì)迭代1編程實(shí)現(xiàn)迭代1測試迭代2開發(fā)迭代2測試在這樣的迭代流程中，如何合理利用自動化手段來提高測試效率呢？一般來講迭代周期不會很長，常規(guī)性的為 35 天一個周期，做太簡單的自動化投入成本較高。對于 web 系統(tǒng)來講，為避開過多的自動化投入得不償失，需要慎重的推斷 web 系統(tǒng)的特征適合哪種自動化模式。所以這里特別要關(guān)注的就是分層自動化測試：系統(tǒng)測試：以系統(tǒng)為整體進(jìn)行黑盒測試，手工為主+ui自動化為輔集成測試：脫離ui，對server 的網(wǎng)絡(luò)通信接口進(jìn)

8、行黑盒測試，自動化為主集成測試單元測試：對代碼函數(shù)進(jìn)行白盒測試單元測試單元測試如上圖所述，web 系統(tǒng)可以做幾種功能測試：單元測試，集成測試，系統(tǒng)測試。大多數(shù)的產(chǎn)品 qa 不會太多介入單元測試，集中在集成測試和系統(tǒng)測試。結(jié)合上面提到的迭代排期， 其實(shí)在一般項(xiàng)目中上層 ui 的開發(fā)往往比較滯后，趕工的結(jié)果也是提測質(zhì)量不高。所以可推舉的一種模式是迭代周期內(nèi)依據(jù) ui 接口劃分功能點(diǎn)做排期，ui 的開發(fā)可以放在ui 接口穩(wěn)定之后提測。所以迭代周期內(nèi)，面對 ui 接口的自動化就是一個將測試前置，并且積存自動化 case 以待回歸時(shí)代替手工操作的大好機(jī)會。就著上面這個結(jié)論，再分析一下本節(jié)開頭拋出的其次個

9、問題：“系統(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)規(guī)律比較薄，比如只是查詢 db 一個字段然后顯示在頁面，把重點(diǎn)放在后端規(guī)律檢查上性價(jià)比更高2. 系統(tǒng)級測試和集成測試的關(guān)注點(diǎn)不同：系統(tǒng)級測試關(guān)注的是用戶從 ui 直接操作所能見到的結(jié)果，而集成測試關(guān)注的是 ui 接口數(shù)據(jù)的精確性。比如報(bào)表功能，頁面上看到的就是一個表格，而對 ui

10、 接口來講需要掩蓋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ù)即

11、可完成一次懇求，從自動化測試實(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 junitjunit 作為單元測試框架常被用作白盒測試，框架具備的一些優(yōu)良特征有：1. 供應(yīng)豐富 api 支持多種驗(yàn)證結(jié)果正確性的規(guī)律2. 通過參數(shù)化、before、after 等特性，支持用例代碼可復(fù)用3. suite

12、 的模式支持 case 的批量運(yùn)行4. 有呈現(xiàn)良好的報(bào)表5. 與 eclipse ide 集成，使用便利2.1.2 httpclienthttpclient 是一個功能豐富支持 http 協(xié)議的客戶端編程工具包，具備以下主要功能：1. 封裝實(shí)現(xiàn)了全部 http 的方法，如 get,post,put,head2. 支持 redirect，會話保持3. 支持文件上傳2.1.3 httpunithttpunit 是一個 http 懇求的測試關(guān)心工具，能處理 web 測試的需求。通過模擬掃瞄器的行為，處理 http 懇求、會話保持、重定向以及對 http response 做 dom 解析。相比于 httpclient，不同之處在于：1. httpunit 能對 http 返回的結(jié)果頁進(jìn)行解析，比如 dom 元素定位2. httpunit 能自己啟動一個 servlet 來運(yùn)行被測服務(wù)2.1.4 htmlunithtmlunit 相比 httpunit 功能更加強(qiáng)大，就像一個掃瞄器，htmlunit 是 junit 的擴(kuò)展測試框架之一，該框架模擬掃瞄器的行為，開發(fā)者可以使用其供應(yīng)的 api 對頁面的元素進(jìn)行操作。htmlunit 支持 http，https，cookie，表單的 post 和 get 方法