postman接口案例

接口測試

　　什麼是接口（API）

　　API全稱Application Programming Interface，這裏面咱們其實不用去關注AP，只須要I上就能夠。一個API就是一個Interface。咱們無時不刻不在使用interfaces。咱們乘坐電梯裏面的按鈕是一個interface。咱們開車一個踩油門它也是一個interface。咱們計算機 操做系統也是有不少的接口。(這是目前我的找到比較好理解的一段解釋)

　　接口就是一個位於複雜系統之上而且能簡化你的任務，它就像一箇中間人讓你不須要了解詳細的全部細節。那咱們今天要講的 Web  API就是這麼一類東西。像谷歌搜索系統，它提供了搜索接口，簡化了你的搜索任務。再像用戶登陸頁面，咱們只須要調用咱們的登陸接口，咱們就能夠達到登陸系統的目的。

　　如今市面上有很是多種風格的Web API，目前最流行的是也容易訪問的一種風格是REST或者叫RESTful 風格的API。從如今開始，如下我提到的全部API都是指RESTful風格的API。

　 　什麼是接口測試和爲何要作接口測試

　　接口測試是測試系統組件間接口的一種測試。接口測試主要用於檢測外部系統與系統之間以及內部各個子系統之間的交互點。測試的重點是要檢查數據的交換，傳遞和控制管理過程，以及系統間的相互邏輯依賴關係等。

　　如今不少系統先後端架構是分離的，從安全層面來講，只依賴前端進行限制已經徹底不能知足系統的安全要求（繞過前端太容易了）， 須要後端一樣進行控制，在這種狀況下就須要從接口層面進行驗證。

　　現在系統愈來愈複雜，傳統的靠前端測試已經大大下降了效率，並且如今咱們都推崇測試前移，但願測試能更早的介入測試，那接口測試就是一種及早介入的方式。例如傳統測試，你是否是得等先後端都完成你才能進行測試，才能進行自動化代碼編寫。 而若是是接口測試，只須要先後端定義好接口，那這時自動化就能夠介入編寫接口 自動化測試代碼，手工測試只須要後端代碼完成就能夠介入測試後端邏輯而不用等待前端工做完成。

　 　接口測試的策略

　　接口測試也是屬於 功能測試，因此跟咱們以往的功能測試流程並無太大區別，測試流程依舊是：1.測試接口文檔（需求文檔） 2.根據接口文檔編寫 測試用例（用例編寫徹底能夠按照以往規則來編寫，例如等價類劃分，邊界值等設計方法） 3. 執行測試，查看不一樣的參數請求，接口的返回的數據是否達到預期。

　　接口測試點

 

來個實例

　　假如咱們如今拿到了以下的一個接口文檔（豆瓣圖書開源API：https://developers.douban.com/wiki/?title=book_v2）

　　image.png

　　從文檔中咱們能夠大致知道這個接口的一些信息，例如接口是GET請求，請求協議是https，請求的接口服務器地址是api.douban.com，接口的路徑是/v2/book/search，接口能夠帶有四個參數q（查詢的關鍵字），tag（查詢的tag），start（取結果的offset），count（取結果的條數），若是接口請求正常返回狀態200，返回大致以下結果：

{ 　　      "start": 0, 　　      "count": 10, 　　      "total": 30, 　　      "books" : [Book, ] 　　    }

　　假設這個文檔是完善的（我的認爲開發文檔還能夠把參數類型寫上）這時咱們根據這個文檔，咱們設計了以下一個測試用例：

　　用q=自動化測試，start=0，count=1做爲參數請求搜索圖書接口，那麼接口請求的狀態碼應該是200，reponse應該返回count=1,start=0等等。

　　最後咱們去執行測試用例，假設我如今沒有別的接口測試用例工具，咱們就經過 瀏覽器來測試這個GET請求的接口，那麼我就能夠在瀏覽器低質欄輸入：https://api.douban.com/v2/book/search?q=自動化測試&start=0&count=1，並判斷返回信息是否有誤。

　　image.png

　　 JSONView 引入

　　咱們發現直接從Chrome打開咱們的查詢圖書的接口請求，返回的 數據爲JSON格式，可是瀏覽器顯示排版難以閱讀，這時咱們能夠考慮安裝一些插件來便於咱們閱讀，例如JSONView插件：

　　https://chrome.google.com/webstore/detail/jsonview/chklaanhfefbnpoihckbnefhakgolnmc 。插件安裝完後咱們再次請求搜索圖書接口，咱們看到格式化後的排版：

　　image.png

　　固然相似的格式化JSON的插件工具很是多，能夠本身找個喜歡方便的即可。

　 　Postman 引入

　　咱們剛剛經過瀏覽器來測試咱們的一個GET請求的接口的一個測試用例，可是平時咱們的接口請求方法除了GET還有POST，PUT，DELETE等等，那麼瀏覽器畢竟不是專業的接口測試軟件，並且它也沒法測試POST這類型的的接口，那麼咱們就須要找一個專業的接口測試軟件：Postman。

　 　Postman 的安裝

　　之前的Postman 除了mac版本都須要在Chrome的插件安裝，但如今也推出Win和liunx的PC版，因此咱們如今只須要到官方網站：https://www.getpostman.com/ 去根據本身的操做系統下載對應的版本即可。

　　image.png

　 　首次使用

　　建議去註冊個帳號，登陸使用，能夠不一樣電腦上方便數據同步。

　 　GET請求

　　image.png

　 　POST 請求

　　POST 請求例子，經過Postman 配置好請求方法，地址，參數後發起請求，最後以下：

　　Post Demo

　　也許你也有疑問，若是開發沒有完備的接口文檔，我如何知道他API的信息？

　　這時咱們就得經過一些抓包工具抓取這些API信息。

　 　常見抓包工具

　　HTTP抓包工具：Fiddler、Charles、Firebug、開發者工具等等。。。

　　 Chrome開發者工具簡單演示

　　1.打開Chrome 瀏覽器，按下F12快捷打開Chrome開發者工具

　　2.點擊Network 標籤

　　3.勾選 Preserve log選項，確保頁面刷新不會把已抓到的請求清空

　　image.png

　　4.打開網站首頁，輸入登陸名和密碼，點擊登陸

　　5.查看開發者工具，能夠找到以下圖Login的請求接口

　　image.png

　　6.查看Login 請求的詳細信息

　　請求方法：POST

　　請求的URL：http://test.logwing.com/Home/Login

　　請求參數格式：Content-Type: application/x-www-form-urlencoded

　　請求參數：UserName=XXX&Password=XXXX&CheckCode=&Remember=false&LoginCheckCode=7119

　　請求結果類型：Content-Type: application/json; charset=utf-8

　　請求結果：

 

　　response

　　更多關於Chrome開發者工具幫助中文幫助文檔能夠參考：https://github.com/CN-Chrome-DevTools/CN-Chrome-DevTools

　 　Fiddler

　　Chrome開發者工具依賴於Chrome瀏覽器，也只能抓取Chrome瀏覽器發起的請求，若是咱們想獲取全部程序發起的請求，咱們就能夠經過Fiddler來抓取。

　 　簡介

　　Fiddler（中文名稱：小提琴）是一個HTTP的調試代理，以代理服務器的方式，監聽系統的Http網絡數據流動，Fiddler能夠也可讓你檢查全部的HTTP通信，設置斷點，以及Fiddle全部的「進出」的數據（我通常用來抓包）,Fiddler還包含一個簡單卻功能強大的基於JScript .NET事件腳本子系統，它能夠支持衆多的HTTP調試任務。

　 　工做原理

　　Fiddler是以代理WEB服務器的形式工做的,瀏覽器與服務器之間經過創建TCP鏈接以HTTP協議進行通訊，瀏覽器默認經過本身發送HTTP請求到服務器，它使用代理地址:127.0.0.1, 端口:8888. 當Fiddler開啓會自動設置代理， 退出的時候它會自動註銷代理，這樣就不會影響別的程序。不過若是Fiddler非正常退出，這時候由於Fiddler沒有自動註銷，會形成網頁沒法訪問。解決的辦法是從新啓動下Fiddler。

　　工做原理.png

　 　簡單演示

　　抓取http請求

　　1.啓動Fiddler。

　　2.點擊Fiddler主界面右下角的監聽程序，選擇ie瀏覽器則該系統上全部的瀏覽器發起的http請求都將被抓取。

　　image.png

　　3.打開chrome瀏覽器 ，打開官網首頁，輸入用戶名密碼登陸。

　　4.查看Fiddler主面板，能夠查看到Login請求。

　　5.查看Login請求的信息

　　能夠查看到跟Chrome插件查看到相似的信息。

　　request\response

　　請求參數