接口測試總結

在用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，返回大體如下結果：

{

"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，并判斷返回信息是否有誤。

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插件查看到類似的信息。

今天的內容就到這里啦！

聽說有氣質的人都會關注這個公眾號！

HTTP 自動化測試

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。