接口測試總結

• 2019 年 10 月 6 日
• 筆記

在用python進行自動化測試之前，我們今天先講一下接口測試，如何進行接口測試，使用什麼工具進行接口測試，如何使用fiddler進行抓包等等。

說到測試，我們有個金字塔模型可以了解一下。

金字塔模型

金字塔模型

　　通過之前對金字塔結構的學習，大概了解到了金字塔模型想告訴我們的幾個道理：

　　1.越底層，越穩定。

　　金字塔主要觀點認為單元測試的穩定性高，需要多投入。

　　2.越底層，越高效。

　　程序的問題，最終還得落在具體的代碼上，所以底層的測試更容易發現問題。

　　3.越底層，越低成本。

　　越底層測試能越早發現問題，越早發現問題，修復的成本自然越低。

　　4.越底層，越難實施。

　　越底層的實現對技術專業性要求越高，這點跟第三點有點矛盾，往往越專業的人才也意味着人力成本越高。

　　綜合下金字塔模型，我們提出了橄欖模型（不倒翁模型），拿接口測試和UI層測試以及單元測試做了比較，最終認定接口（API）測試可以獲得較高的投資回報。

接口測試

　　什麼是接口（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）

測試URL

https://api.douban.com/v2/book/search

參數

使用q來測試查詢關鍵字接口：

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

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

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

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

JSONView 引入

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

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

當然類似的格式化JSON的插件工具非常多，可以自己找個喜歡方便的便可。

　Postman 引入

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

　Postman 的安裝

　　以前的Postman 除了mac版本都需要在Chrome的插件安裝，但現在也推出Win和liunx的PC版，所以我們現在只需要到官方網站：https://www.getpostman.com/ 去根據自己的操作系統下載對應的版本便可。

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

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

　常見抓包工具

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

Chrome開發者工具簡單演示

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

　　2.點擊Network 標籤

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

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

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

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

　　請求結果：

更多關於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。

　簡單演示

　　抓取http請求

　　1.啟動Fiddler。

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

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

　　4.查看Fiddler主面板，可以查看到Login請求。

　　5.查看Login請求的信息

　　可以查看到跟Chrome插件查看到類似的信息。

今天的內容就到這裡啦！