對於測試人員來說，掌握接口測試基本上已經成爲一個標配的能力了，但是對於初學者來說，看着網上一大堆高大上的名詞解釋，總會認爲接口測試是一個很高深的東西（包括我剛開始也這麼認爲），所以今天我就儘量用簡單通俗的表達告訴你，接口測試其實很簡單！
一、什麼是接口？
我扒遍了各種相關名詞解釋和百科詞條，發現關於接口的解釋還真是多種多樣，這裏我只列出一個相對更客觀更通用的定義，雖然聽起來也很彆扭。
接口，泛指實體把自己提供給外界的一種抽象化物（可以爲另一實體），用以由內部操作分離出外部溝通方法，使其能被內部修改而不影響外界其他實體與其交互的方式。
通俗點說，能夠把某個硬件或軟件模塊封裝起來供外部使用，都可以稱之爲接口，可以存在於所有的軟硬件設備之間。
我們在生活中無時不刻不在使用各種接口，比如我們乘坐電梯裏面的按鈕就是一個接口，我們開車一個踩油門它也是一個接口，我們計算機操作系統中也有很多接口。
在 IT 行業中，我們通常所說的接口指的都是 API 軟件接口，即 Application Programming Interface，應用程序接口，簡稱 API。本文中後面的部分中提到的接口都是指 API 接口。
對於 API 接口來說，使用者只需要關心輸入和輸出，不需要了解接口內部的具體實現邏輯。
我們工作中常見的接口可以分爲兩類：
- 系統內部的接口：
- 同一個系統內部不同模塊、不同服務之間的調用
- 如系統內部註冊、登錄接口的調用，查詢訂單、JDBC接口調用等。
- 系統外部的接口：
- 不同系統甚至不同公司之間的接口調用
- 如同一公司的系統 A 和 系統 B 之間的調用，第三方登錄時調用外部公司的微博登錄、微信登錄接口等。
二、軟件測試模型
我們看一下針對接口的測試位於軟件測試模型中的位置。
關於測試模型，最出名的就是測試金字塔模型。
測試金字塔的概念是由敏捷開發大師 Mike Cohn 首先提出的，主要包含以下幾點：
- 把軟件測試分爲 UI 界面測試、接口測試、單元測試三層結構
- 應該進行更多的單元測試，而不僅僅是通過用戶界面運行的測試
- 單元測試穩定性更高、更高效
但是在實際工作中，單元測試對技術專業性要求更高，很多情況下都是由開發來實施。雖然單元測試能夠儘早的發現問題，減小修覆成本，但對測試人員的高要求也意味着更高的人力成本，所以對接口測試層的投入顯得更加高效、成本更低。
結合實際現狀，對接口測試和 UI 層測試以及單元測試進行了比較，最終認定接口（API）測試可以獲得更高的投資回報，所以有了金字塔模型的改進版–橄欖模型（不倒翁模型）：
三、接口測試的意義
1. 更早的發現問題
隨着敏捷測試的盛行，我們都知道測試工作要儘早的介入到項目開發週期中，因爲越早的發現 bug，修復的成本就越低。
然而功能測試一般都要等到系統提供可測試的 UI 界面後才能進行，單元測試又要求較高的專業性和人力成本，所以選擇接口測試來更早的介入測試。
接口測試可以在功能界面未開發出來之前對系統的接口進行測試，從而更早的發現總是並以更低的成本修復問題。
2. 縮短產品週期
接口測試更早的介入，可以更早的發現並解決 bug，從而使得留到後期功能測試階段的 bug 數量減少，最終縮短整個項目的上線時間，有助於實現敏捷測試。
3. 發現更底層的問題
系統中的有些 bug 如果想通過 UI 層功能測試會比較困難，或者構造測試數據和測試條件非常複雜，而通過接口測試可以更簡單、更全面的覆蓋到底層的代碼邏輯，從而發現一些隱藏 bug。
尤其是一些異常的、極端的情況，可以用接口測試很容易的驗證。
四、接口測試策略
接口測試主要用於檢測外部系統與系統之間以及內部各個子系統之間的交互點。
測試的重點是檢查數據的交換、傳遞和控制管理過程，以及系統間的相互邏輯依賴關係等。
具體來說，就是根據測試文檔編寫測試用例，執行測試，查看不再的參數請求接口時返回的數據是否符合預期，跟普通的測試沒太大區別。
接口測試策略包括接口功能測試、接口性能測試和接口安全測試三方面，具體測試點包含但不侷限於如下內容：
最後，關於接口測試工具也有很多，常用的有 postman、soapUI、jmeter 等，具體使用方法都不復雜，後面有時間 再一一詳述。
這篇文章測重於對接口理論知識的理解，給出的只是方向性的指導，沒有詳細的具體實踐，所以肯定還有同學不知道該怎麼辦，不過沒關係呀，這都是正常的，關於接口測試的內容非常多，也不是一兩篇文章能夠全部講完，最重要的是先知道大概的方向，然後就去大膽實踐，在做的過程中成長最快。