接口測試簡介 本節概要 1 了解測試金字塔（應知） 2 了解接口的定義（應知） 3 掌握接口測試用例設計（應會） 4 接口測試工具的簡介（應知） 1 了解測試金字塔（應知） 1.1在軟件測試界有個金字塔大家需要了解  首先我們來看看這個分層 手動測試： 就是我現在這樣手動的黑盒測試 界面測試： 一般都是 UI 層級的測試， 我所了解到的使用的工具就是 selenium， 通過對 UI的自動化測試， 也能進行功能上的驗收。 服務測試： 就是對產品所提供的服務進行測試 組件測試： 接口測試， 可以通過代碼實現， 也可以借助工具， 當前使用最多的工具應該就是 poster、 postman 和 Jmeter 單元測試： 針對類庫和程序集進行測試 從上面這個金字塔我們基本可以看出以下幾個特點： 1) **測試越往下面測試效率越高，** **測試質量保障程度越高** 單元測試時對軟件中最小可測試單元進行測試， 所以在缺陷的定位上更精確。 而不同的語言都有自己的單元測試框架， 從而也能夠保證單元測試的規范。 和其他測試相比， 單元測試對測試員的要求更高， 但是也能夠更好的保證測試的質量。 2) **測試越往下面測試成本越低** 大家也都知道， Bug 越早發現， 損失就越小， 成本也越低。 這個金字塔， 也是符合這個規則的。 雖然目前敏捷開發盛行， 但是真正的敏捷團隊， 我至今沒有遇到多少， 大部分的團隊仍然是瀑布式模型。 那么按照瀑布模型來看， 單元測試， 是最早開始實施的。 等到界面測試、 手工測試的時候才發現的 Bug， 再進行定位、 解決， 花費的時間會更多。 3) **測試越往下面，** **職業前景越好** 越往金字塔底層， 測試的技術含量要求更高， 測試人員的核心競爭力更大， 薪酬當然要高一些， 如果從技術方向來說， 可以做高級測試工程師、 測試架構師都有可能。 2.1 **接口測試的定義** 接口測試是測試系統組件間接口的一種測試。接口測試主要用于檢測外部系統與系統之間以及內部各個子系統之間的交互點。 測試的重點是要檢查數據的交換， 傳遞和控制管理過程， 以及系統間的相互邏輯依賴關系等。 2 了解接口的定義（應知） 2.2**接口的分類** **外部系統的接口** 其實無論是 C/S 還是 B/S 的產品， 都會存在外部接口的調用。 最經常見到的就是， 接入的第三方登錄（QQ、 微信、 微博等） ， 在產品上， 使用你們在接入的平臺已經注冊過得賬號進行登錄， 然后產品就會調用接入的接口， 交給接入的第三方進行驗證， 驗證通過的話，返回給產品一個登錄成功的信息， 就實現了第三方接入的登錄。 **服務與服務的接口** 服務間的接口， 其實就是不同模塊的互相調用， 實現功能上的交互。 舉個例子來說， 比如我們注冊一個賬號， 這個時候， 就會先去調用數據查詢的服務， 檢查數據是否有重復， 如果無重復數據再允許注冊， 然后還要調用新增數據的接口， 這樣才可以完成一個賬號的創建。 **上層服務對下層服務的調用** 應用層： 系統的功能 服務層： 服務器對數據和邏輯的處理 數據庫： 主要用來存放數據 就像上面的例子， 我們去注冊一個用戶。 首先在應用層， 我們通過輸入框和注冊的按鈕， 輸入我們將要注冊的用戶的信息， 然后通過注冊按鈕， 提交請求至服務層。 這個時候服務層， 在接收到應用層的請求之后， 要先去判斷是否是重復的數據， 所以就要去調用數據庫的查詢接口， 如果發現是重復數據， 那么返回一個是重復數據的狀態碼到服務層， 服務層， 根據狀態碼做出判斷， 返回到應用層， 應用層根據服務層返回的內容， 做出相應的處理。 如果不是重復數據， 那么也會返回一個狀態碼給服務層， 服務層判斷之后作出處理， 返回到應用層。 然后我們在應用層上看到的就是注冊成功了。 上面講述的這個例子， 在各個層級中的數據傳遞， 層級之間的交互都是通過接口的。 **2.3** **神秘的接口測試** 接口， 一個很熟悉的名詞， 經常聽人提起， 卻又是那么神秘。 大家都覺得接口測試很神秘， 其實它并不神秘， 我們大家在 UI 層的測試就做過， 只是不知道而已。 現在無非是提升到另一個層級罷了。 拋開 UI 層， 客戶端我們來看。 所謂的接口充滿著整個項目， 模塊與模塊之間的交互、調用， 端與端的交互、 數據的傳遞， 還有外部接口的調用， 最常見的就是第三方集成的 SDK的調用（比如支付、 登錄、 注冊） 。 這些都要通過一個一個的接口去實現。 通過接口， 將模塊， 端與端銜接起來， 這樣才能使我們的項目正常的進行工作。 最簡單的接口測試應該就是， 拿一個接口， 粘貼到瀏覽器的地址欄然后拼接參數， 檢查返回數據的正確性， 這里這個正確性不僅僅包括數據是否正確還要檢查數據格式。 當然， 我們也能通過工具去完成這項測試。 那么再進一步應該就是通過設置線程、 循環、 啟動時常， 去完成壓力、 并發的測試。 這里也可以算作是性能接口測試。 這些的通過工具可以實現。 用代碼實現起來的話， 監測的數據沒有工具那么全面， 但是代碼比工具更加靈活。 高級接口測試就涉及到了簽名加密的接口，這一類的接口一般都是通過寫腳本去進行測試。 2,4 **接口測試的意義** **保證系統的穩定性** 越接近底層對系統的影響就越大。 服務端的一個缺陷， 可能會引起客戶端的幾個甚至十幾個缺陷， 還有一些會直接導致客戶端的崩潰。這對整個系統造成的損失是不可估量的，因此服務端接口的質量將直接影響到系統的正確和穩定。 正常來講， 一般的開發或者是白盒測試， 都需要進行單元測試， 而相對于單元測試來講，接口測試需要測試的接口或者函數的數量會遠遠小于單元測試， 所以， 接口定義的穩定性會遠遠高于類級別的函數 將缺陷控制在項目前期 對于我們測試來說， 越早介入測試越好。 由測試金字塔中的介紹可以看出， 他的顆粒度比單元測試更粗。 一般是基于子系統或者是子模塊的接口層面的測試， 所以并不需要等到完全集成， 所有功能開發完成才能進行測試。 從這個角度來看， 它確實能夠幫助我們將缺陷控制在項目前期。 節省測試成本 我們上面也說到了， 接口測試是基于子系統或者是子模塊的接口層面的測試。 因此， 接口測試需要測試的接口或者函數的數量會遠遠小于單元測試， 所以， 接口測試用例代碼的改動量也遠遠小于單元測試，代碼維護成本會比單元測試少很多，因而測試的投入量會小很多。 而且將缺陷有效的控制在了項目前期， 避免了很多不必要的麻煩， 所以我認為， 接口測試能夠節省測試成本。 3 掌握接口測試用例設計（應會） 3.1 **接口測試用例的理解** **如何簡單設計接口測試的設計用例** a) 明確出發點——測試的目的是為了讓找出軟件的缺口， 修復并使之更加完善。 在這一基礎點上， 接口測試也不例外。 以找出軟件的誤漏為出發點， 測試用例需緊貼此線， 更容易找出問題所在。 b) 明確測試點——選擇好的測試對象。 系統內部層次繁復復雜， 任何一個接口的變動都將導致用例失效。 （可將這些最外層的接口根據數據的流向分為進入和流出兩類， 進入系統的接口實際上是我們用例的執行調用的接口。 可通過參數對這些接口進行調用， 模擬外部的使用； 而流出的接口則是我們用例真正該驗證的點。 數據從哪里流出， 流出的狀態如何，此時系統的狀態都是作為測試目的所要著重關注的部分） c) 確認完整的測試對象的功能——確認外部接口提供給使用這些接口的外部用戶什么樣的功能， 外部用戶真正需要的時什么樣的功能予以區別。 用例的設計要嚴格按照測試對象功能設計才是正確的用例。 **接口測試用例有哪些要求**： 結構好， 可讀性高， 滲透性強。 接口測試用例包括的內容 a) 接口測試測試的功能點： 如果一個接口功能過于復雜時， 可以對接口用例進行結構劃分（如根據層次， 平臺， 功能點等等） ， 這樣用例具有更好的可讀性（接口劃分原則為： 以接口提供的功能點的不同進行合適粒度的劃分， 同一功能點的用例又可根據測試環境的不同， 數據的不同進行用例的填充） b) 接口測試用例的環境： 程序內部環境和程序所調用的外部接口的環境。 c) 關于接口測試測試數據： 分為兩部分： 接口參數數據和用例執行所需系統數據。 數據的設計、 準備測試用例的數據不可馬虎。 通過好的測試數據查找問題， 能極大的提高工作效率。 接口參數數據需要對每個參數根據測試接口的實際功能進行分析， 在符合業務邏輯的情況下進行邏輯組合排列， 一定要記得邊界值和錯誤點的數據， 這樣用例更容易發現問題。 d) 執行操作： 即對所測接口的調用。 e) 預期結果： 根據需求進行驗證， 是衡量軟件是否達到預期的標準。 應該著重細致，每個用例均需驗證， 應該避免一個用例重復做相同的驗證， 提高測試用例的效率。 **具體測試用例的參考點** a) 參數測試： 針對參數進行的測試， 也可以說是假定接口參數的不正確性進行的測試， 確保接口對任意類型的輸入都做了相應的處理： 輸入參數合法（不合法） ， 輸入參數為空， 為null， 輸入參數超長等等； b) 功能測試： 接口是否滿足了所提供的功能， 相當于正常情況測試， 如果一個接口功能復雜時推薦對接口用例進行結構劃分， 這樣子用例覺有更好的可讀性和可維護性； c) 邏輯測試： 保持內部邏輯的正確性， 從設計文檔中考慮內部邏輯錯誤的分之情況和異常； d) 異常情況測試： 接口實現是否對清楚情況都進行了處理， 接口輸入參數雖然合法， 但是在接口實現中， 也會出現異常， 因為內部的異常不一定是輸入的數據造成的， 而有可能是其他邏輯造成的， 程序需要對任何異常都進行處理。 下面給大家分享一個接口：   3.2 接口測試用例的設計 通過接口測試文檔知道了以下信息。 請求的 URL 請求的方式 用戶中獎之后的返回值。 狀態碼，接口測試用例要覆蓋到每一種情況。 當然，這里提供的處理邏輯并不一定是完整的，比如，這個接口的調用，還有哪些情況是接口沒考慮到的。比 如你傳的參數是空的，結果接口沒有正確處理這種情況，而是返回了一堆報錯。那么說明這個接口有問題，需要開 發修改。當然，這主要是靠你對接口業務的熟悉程度了。和功能測試用例的設計本身沒有區別。 3.3 狀態嗎  4 接口測試工具的簡介（應知） 4.1 關于接口測試工具 1. postman 是google開發的一款功能強大的網頁調試與發送HTTP請求的chrome插件，并能運行測試用例的的Chrome插件. 2. Firefox RESTClient的插件,是一款用于測試各種Web服務的插件,它可以向服務器發送各種HTTP請求(用戶也可以自定義請求方式),并顯示服務器響應. 3. Jmeter：是Apche公司使用Java平臺開發的一款測試工具。想學習更專業接口測試。了解接口測試工具，還有使用方法的話，去傳智播客的論壇去。里面有視頻資料還有課堂筆記資料。足夠自學了。找不到的話去官網對話框直接要也能要到。我就是直接要的。 注意：章節主要學習postman的使用 4.2 postman介紹 Postman有兩個版本：1 .chrom瀏覽器插件版本，2.native本地安裝版他們的區別如下： 1） native版本可以直接操作cookies，而chrome版本需要安裝拓展 2） native版本自帶proxy，可以用來抓包： 3） native版本可以直接操作cookies，而chrome版本需要安裝拓展 4） 有一些headers在chrome上是受限的，比如origin and user-agent 5） don't follow redirect option，只有native版本才有這個選項 6） postman console，native版本自帶 基于以上原因，本課程也主要介紹native版本的使用。（插件版本官方已經停止更新） 至于這個能不能做 APP 的接口測試，我只想說， 接口測試只看協議， 不分架構， 無論你是 C/S 還是 B/S。 無論你是 web 還是 APP，只要你是 http 協議， 它就能夠幫助你完成你的測試。） 為了保持版本一致建議使用教材中的安裝文件