HTTP介面功能自動化測試入門

雲智慧 Vivi Sun

無論是瀏覽器上運行的Web應用還是移動端的H5應用,都離不開HTTP介面。Web應用通常是分為前後台開發的,後台提供介面調用返回Json對象,前台使用JS框架去載入後台返回的Json。而H5頁面動態獲取內容的方式則是採用ajax非同步請求後台數據實時刷新,用GET/POST的HTTP請求後台介面,再將返回的數據(一般是json或xml格式)渲染在頁面上。因此,HTTP介面功能測試是確保Web應用和H5應用頁面內容數據正確的關鍵。

簡而言之,HTTP介面功能測試是對服務後台一系列HTTP介面功能測試:

輸入:根據介面描述構造不同的參數輸入值;

輸出:json。

HTTP介面功能測試的相關知識

t1、http相關知識

1)、HTTP協議的URL

HTTP(超文本傳輸協議)是一個基於請求與響應模式的、無狀態的、應用層的協議,常基於TCP的連接方式,HTTP1.1版本中給出一種持續連接的機制,絕大多數的Web開發,都是構建在HTTP協議之上的Web應用。

HTTP URL (URL是一種特殊類型的URI,包含了用於查找某個資源的足夠的信息)的格式如下:host[:port][abs_path],其中http表示要通過HTTP協議來定位網路資源;host表示合法的Internet主機域名或者IP地址;port指定一個埠號,為空則使用預設埠80;abs_path指定請求資源的URI;如果URL中沒有給出abs_path,那麼當它作為請求URI時,必須以「/」的形式給出,通常這個工作瀏覽器自動幫我們完成。

eg.: a、輸入:www.guet.edu.cnt瀏覽器自動轉換成:桂林電子科技大學

ttb、192.168.0.116:8080/inde

2)、HTTP協議的請求

http請求由三部分組成,分別是:請求行、消息報頭、請求正文.

請求行以一個方法符號開頭,以空格分開,後面跟著請求的URI和協議的版本,格式如下:Method Request-URI HTTP-Version CRLF,其中 Method表示請求方法;Request-URI是一個統一資源標識符;HTTP-Version表示請求的HTTP協議版本;CRLF表示回車和換行(除了作為結尾的CRLF外,不允許出現單獨的CR或LF字元)。請求方法(所有方法全為大寫)有多種,各個方法的解釋如下:

GET:請求獲取Request-URI所標識的資源;

POST:在Request-URI所標識的資源後附加新的數據;

HEAD:請求獲取由Request-URI所標識的資源的響應消息報頭;

PUT:請求伺服器存儲一個資源,並用Request-URI作為其標識;

DELETE:請求伺服器刪除Request-URI所標識的資源;

TRACE:請求伺服器回送收到的請求信息,主要用於測試或診斷;

OPTIONS:請求查詢伺服器的性能,或者查詢與資源相關的選項和需求應用;

PATCH:實體中包含一個表,表中說明與該URI所表示的原內容的區別;

MOVE:請求伺服器將指定的頁面移至另一個網路地址;

COPY:請求伺服器將指定的頁面拷貝至另一個網路地址;

LINK:請求伺服器建立鏈接關係;

UNLINK:斷開鏈接關係;

WRAPPED:允許客戶端發送經過封裝的請求;

Extension-mothed:在不改動協議的前提下,可增加另外的方法。

3)、HTTP協議的響應

t在接收和解釋請求消息後,伺服器返回一個HTTP響應消息,HTTP響應也是由三個部分組成,分別是:狀態行、消息報頭、響應正文。

a、狀態行格式如下:HTTP-Version Status-Code Reason-Phrase CRLF其中,HTTP-Version表示伺服器HTTP協議的版本;Status-Code表示伺服器發回的響應狀態代碼;Reason-Phrase表示狀態代碼的文本描述。狀態代碼有三位數字組成,第一個數字定義了響應的類別,且有五種可能取值:

1xx:指示信息–表示請求已接收,繼續處理;

2xx:成功–表示請求已被成功接收、理解、接受;

3xx:重定向–要完成請求必須進行更進一步的操作;

4xx:客戶端錯誤–請求有語法錯誤或請求無法實現;

5xx:伺服器端錯誤–伺服器未能實現合法的請求;

b、響應正文就是伺服器返回的資源的內容。

2、JSON

  JSON(JavascriptObjectNotation)是一種輕量級的數據交換語言,以文字為基礎,且易於讓人閱讀。JSON建構有兩種結構:

1)、」名稱/值」對的集合(A collection of name/value pairs)。不同的語言中,它被理解為對象(object),記錄(record),結構(struct),字典(dictionary),哈希表(hash table),有鍵列表(keyed list),或者關聯數組(associative array)。

2)、值的有序列表(An ordered list of values)。在大部分語言中,它被理解為數組(array)。

eg.:

a、表示名稱 / 值對

t{ "firstName": "Brett" }

tb、表示數組

{ "people": [

{ "firstName": "Brett", "lastName":"McLaughlin", "email": "aaaa" },

{ "firstName": "Jason", "lastName":"Hunter", "email": "bbbb"},

{ "firstName": "Elliotte", "lastName":"Harold", "email": "cccc" }

]}

3、實現方法

1、使用Python語言驅動測試;

2、調用http介面採用pycurl模塊;

3、設置斷言,對比實際返回結果和預期結果的正確性;

4、首次執行測試採用半自動化的方式,即人工檢查輸出的json文件是否正確,一旦正確將封存json文件,為後續回歸測試的預期結果,如果發現錯誤手工修正為預期文件。(注意不是每次測試都人工檢查該文件,只首次測試的時候才檢查)

5、增加測試套件,按照邏輯,或者說按照測試組的理解把測試用例劃分成不同的部分,每個部分就是一個test suite。

6、使用HTMLTestRunner模塊生成測試報告

4、舉例說明

以監控寶的2個介面為例

1、 查看介面文檔

t1)、用戶管理相關-列出所有用戶介面

2)、網站監控相關-創建網站監控任務

2、 編寫測試用例

1)、列出所有用戶

封裝的get請求

2)、創建網站監控任務

封裝的post請求

3、執行測試用例

1)、執行單個測試用例(列出所有用戶)

2)、執行測試集(用戶管理相關介面)

3)、創建網站監控任務同上

4、增加測試套件

5、運行測試套件生成報告

介面自動化後,重複工作(請求介面是否有效、參數校驗、返回數據校驗)都可以用自動化的方式解決,並且研發人員在提測之前可以先進行一輪冒煙測試,根據自動化測試用例檢查結果,提升提測之前的功能質量;提測之後,測試人員再一輪冒煙測試,注重點落到返回結果對比上,這樣測試的效率會得到很大的提升。

或許有人要問,到底提升多少呢?由於每個團隊不同,研發、測試人員磨合程度不同,不能一概而論,大膽邁出一步去嘗試,就會發現價值。


推薦閱讀:

如何看待谷歌 Google 打算用 QUIC 協議替代 TCP/UDP?
談談 HTTP 緩存
關於ajax請求的安全,如何避免csrf類似的攻擊?
認識HTTP----Cookie和Session篇

TAG:HTTP | 自动化测试 |