接口測試

抓包做用：  網絡，流量分析  數據分析  篡改數據，再次發送

工具：fiddler,wireshark,charles,瀏覽器網絡監控

接口分類：

• 應用層<->service<->DB
• service<->service<->service
• 系統外部,第三方API--公共服務(如系統介入支付寶，微信的公共服務接口)

在這個過程當中各層之間的交互就是經過接口：

•  應用層與service主要經過http接口
•  service層與DB層主要經過DAO(data access object)數據庫訪問接口)

網絡服務接口的分類

　　Restful API(簡單的傳輸方式，傳紙條)

　　　　 表現層狀態轉化

　　　　　　   資源

　　　　　　　　    URI指向它  

　　　　　　　　　HTTP協議裏面，四個表示操做方向的動詞， GET,POST,PUT,DELETE,改變資源的狀態

　　Web Service(完整的流程,能夠封裝各類協議,如http,socket,soap...,郵政系統)

　　　　  用xml來定義一個接口的信息(接口的方法、調用方式、參數說明)用一個文件來描述WSDL

　　　　  SOAP協議

　　　　  　　 請求和響應的數據載體也是xml

　　　　　　   請求和響應要按照必定的規則進行封裝--信封

　　　　　　  底層也要藉助於各類網絡協議傳輸(最多見綁定http協議)  

開放接口項目地址：http://www.webxml.com.cn/zh_cn/index.aspx  

Http協議基礎

應用層協議,無狀態。標準的客戶端服務器模型,由請求和響應構成

URL結構  

　　http://host[":"port][abs_path]

HTTP請求：

　　 請求行：

　　　　  請求地址,協議版本,請求方法名

　　 請求報文頭：以明文字符串格式傳送，以冒號分隔的鍵值對   請求頭部通知服務器有關客戶端請求的信息

　　　　  User-Agent、Accept、Accept-Encoding、Content-Type

　　 請求正文：數據內容

　　   　　四種格式：

　　　　   1.application/x-www-form-urlencoded

　　　　  　　  對數據進行序列化處理，以鍵值對形式

　　　　   　　key1=value1&key2=value2的方式發送到服務器

　　          2.multipart/form-data

　　　　　　   將表單中數據所有上傳，包括文件

　　          3.字符串文本格式：raw

　　　　　　   text/plain:純文本，瀏覽器不解析

　　　　　　   text/html:html,瀏覽器自動解析

　　　　　　   text/xml或application/xml：後者可指定編碼格式

　　　　　　   application/json:消息主體是序列化後的JSON字符串

　　          4.二進制格式：binary

HTTP響應：

 響應行：

　　   HTTP-Version表示服務器http協議的版本

　　   Status-Code表示服務器發回的響應狀態代碼

 響應報文頭：以明文的字符串格式傳送，以冒號分隔的鍵值對

　　   響應頭部通知客戶端有關服務端的應答消息

　　  Server、Content-Type

 響應正文：待測試的數據

  　　html --文本檢索、樣式內容瀏覽器檢查

　　  xml、json -- 解析後獲取關鍵數據

 

GET與POST請求的區別

1. GET請求沒有請求體,POST請求有請求體(請求正文)

2. GET請求的參數(須要傳遞的數據)要放在URL中發送，大小有限制，POST請求的參數能夠放在URL後傳遞，也能夠放在請求體中(大小不受限制)

3. GET安全性相對較差

　　 a. 參數明文

　　 b. 數據會被瀏覽器緩存

4. 重大區別：

　　GET產生一個TCP數據包，POST產生2個數據包；對於GET請求，瀏覽器會把http header和data一併發送出去，服務器響應200；而對於POST，瀏覽器先發送header,服務器響應100 continue,瀏覽器再發送data,服務器響應200

5. 設計用途不一樣

　　  GET用來查詢--不操做數據，參數量小

　　  POST用來插入、更新數據--安全要求高，數據量大

接口測試流程：

 輸入數據->發送請求->輸出結果->獲取響應->檢查響應

特色：端到端的測試，重點經過不一樣的輸入數據組合，檢查數據的傳輸：

 　　測試業務邏輯

　　 測試數據庫讀寫

　　 覆蓋代碼分支

1. 彌補傳統UI測試的不足

　　  -不少系統沒有界面，只提供接口功能，沒法經過界面的方式進行測試

　　  -你只測了前端頁面能夠測試的功能，服務端的功能你又覆蓋了多少？

　　　　  服務端的全部功能接口都正常嗎？

　　　　  每一個接口返回的每一個字段是否正確   繞過前端的校驗，接口是否有必要的異常處理

　　  -當APP的代碼不更新，而服務器端代碼更新時，直接經過接口自動化測試就能快速知道是否影響APP的功能

  2. 安全方面(SQL注入，1'OR'1'='1)  

　　接口返回的字段是否包含多餘信息(好比用戶id,token等敏感字段)

　　用戶密碼，其餘用戶隱私信息傳輸時都須要進行加密後傳輸

　　接口是否存在防刷限制

在手工接口測試或者自動化接口測試的過程當中，上下游接口有數據依賴如何處理？依賴於第三方數據的接口如何進行測試？  在工具中可使用全局變量等方式將須要的數據進行傳送，可使用SoapUI等工具直接調用第三方數據接口的webservice，經過返回值來查看第三方數據的接口是否調用正常。 也能夠利用一些MOCK的工具來模擬第三方的數據返回，最大限度的下降對第三方數據接口的依賴