(轉)Web自動化測試中的接口測試

一、背景

　　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應用的總體架構特徵，按照這種架構設計開發項目，引起兩個問題：

　　第1、系統級測試必定要等到web服務器程序和瀏覽器端的程序都開發完畢後才能進行嗎？參考如下傳統的RD與QA合做進行的項目流程，能夠看到，QA在RD提測程序後才能真正進入到測試階段，那麼項目的發佈週期天然受到這種串行下來的工做安排影響，是1+1的時間週期。

　 　第2、爲了提升效率，公司的團隊引入了系統級自動化測試的工具或方案，既然是從用戶角度去測試，固然要寄但願於從模擬用戶行爲代替手工操做來進行測試。 好比從瀏覽器操做的方式去測試，能很直接的覆蓋用戶的一手操做，可是須要思考的是，瀏覽器各個版本如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.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測試工具。能夠用來驗證連接跳轉、表單輸入和提交、表格內容以及其餘？Web？應用程序特性的正確性。相比於HtmlUnit，JWebUnit封裝的更友好，編寫case也會更加簡單。

 

轉載地址：http://www.blogjava.net/qileilove/archive/2013/06/20/400768.html