1、介面測試概念
介面測試是測試系統元件間介面的一種測試，它界於單元測試與系統測試中間。
介面測試主要用於檢測外部系統與系統之間以及內部各個子系統之間的互動點。
測試的重點是要檢查資料的交換，傳遞和控制管理過程，以及系統間的相互邏輯依賴關係等。
換句話說，介面測試就是開發人員把這個介面實現了，我們需要去驗證這個介面的實現是否正確。但這是一個後臺的功能，不想讓前端人員介入，因為讓前端人員介入的話會比較麻煩。
總結概括：介面測試就是代替前端驗證服務端程式是否正確。
2、介面測試原理
- 測試人員藉助工具模擬客戶端向伺服器端傳送請求。
- 伺服器端接受請求後，對請求進行相應的處理並向客戶端響應結果。
- 客戶端接收響應資料後，測試人員對結果進行判斷的一個過程。
介面測試是黑盒測試。作為黑盒測試，基本的測試思路是通過輸入和輸出判斷被測系統或者物件的邏輯是否正確。
3、做介面測試的依據是什麼
- 需求。熟悉實際的業務需求可以更好的幫我們設計測試用例，準備測試資料。
- 介面文件。根據介面說明文件開發介面測試指令碼，執行指令碼。
- 原型圖。可以根據原型圖更好的判斷實際測試資料，是否符合介面之間的邏輯關係。
4、介面測試分類
- Web介面測試：
- 伺服器介面測試：測試自己公司實現的介面（工作中的重點）
同一個系統內部不同模組、不同服務之間的呼叫。
比如：目前主流的系統架構為應用層、服務層和資料層。應用層：負責展示資料和發起資料請求。服務層：為應用層提供資料處理。資料層：用來儲存資料，有關係型資料庫等，各層之間的互動就是通過伺服器介面。 - 第三方介面測試：測試別人公司實現的介面（不同系統甚至不同公司之間的介面呼叫）
在專案中會用到很多第三方介面，比如要做一個系統來展示每天的天氣，那天氣資料是怎麼得到的呢？不可能自己去預測天氣，有免費的第三方介面可使用，只需按照介面協議呼叫想要的天氣資料即可。當然這是呼叫系統外部的資料。
還比如第三方登入時呼叫外部公司的微博登入、微信登入介面等。
- 伺服器介面測試：測試自己公司實現的介面（工作中的重點）
- 模組介面測試：就是測試一個類中的方法，或者說模組中的一個介面。
一個程式內部介面的測試，模組介面測試是單元測試的基礎，它主要測試模組的呼叫與返回。
5、介面測試的特點
- 無UI介面：在做介面測試的時候是無法看到應用介面的。
- 無UI互動操作：既然無UI頁面，也就不可能在UI上進行點點點操作了。
- 不同於手工測試：介面自動化測試可用於持續整合，介面覆蓋率也比較高。
- 基於協議：介面測試是帶訪問協議的測試，需要測試協議和協議中的內容是否正確。
- 資料驗證：檢查資料的交換，傳遞和控制管理過程，還包括處理的次數，業務邏輯是否正確。
- 格式校驗：請求引數和返回值的資料格式校驗，包括引數的預設，返回的資料是否完全等。
6、介面測試的意義（優勢）
（1）更早的發現問題
不少的測試資料中強調，測試應該更早的介入到專案開發中，因為越早的發現bug，修復的成本越低。
然而功能測試必須要等到系統提供可測試的介面才能對系統進行測試。
而介面測試可以在功能介面開發出來之前對系統進行測試。
系統介面是上層功能的基礎，介面測試可以更早更低成本的發現和解決問題。
然而，在實際的開發過程中，開發人員並沒有充足的時間去編寫單元測試，並且他們往往對自己編寫的程式碼有足夠的信心，不願意將“浪費”時間在編寫單元測試上面。
這個時候介面測試的作用就會變得更加重要。
（2）縮短產品研發週期
對於產品研發週期來說，如果將所有測試工作都集中在功能測試階段，那麼測試的問題和修復週期就會變長。
因為測試可以更早的介入產品開發中，所以可以有效的控制功能測試階段bug的數量，從而有效的縮短產品開發週期。
（3）發現更底層的問題
系統的有些底層邏輯是在UI功能測試中不太容易觸發的，那麼這些邏輯可能會存在問題。介面測試可以更容易更全面的測試到這些底層的邏輯。
（4）檢查伺服器的異常處理能力
我們通常把前端的驗證稱為弱驗證，因為它很容易被繞過，這個時候如果只站在功能的層面進行測試，就很難發現一些安全的問題。
而不以功能為入口的介面測試就會很容易的驗證這些異常情況。
- 比如訂單介面是不允許重複提交的。
- 有些介面還要考慮效能問題。
- 比如購物車裡有多個商品，全部勾選後去支付, 會判斷商品庫存，這時候能提交成功嗎，處理邏輯又是什麼?
- 安全性測試：
服務端提供API， 介面呼叫方在客戶端，之間的通訊暴露在公網上，如果有不善意的使用者抓包獲取了支付介面，用1元價格購買到了100元商品，這是非常危險的，這就是安全性測試的一個方面。
SQL隱碼攻擊等也屬於這類。
7、UI測試與介面測試對比
（1）UI測試特點
一般網際網路公司，最大的特點就是快，產品需要不停的迭代，迭代時間基本在15天左右。
UI自動化測試的優點是，能夠實際模擬真實使用者的行為，直接驗證軟體的商業價值，缺點是用例的維護和執行代價很大。
另外，UI自動化測試的穩定性問題，是長期以來阻礙UI測試發展的重要原因。
在快速迭代的情況下（如不停的更新活動介面），頁面的改動可能會很頻繁，而UI自動化測試本身基於頁面元素，前端小小的改動可能需要測試的非常大的改動。
所以總結如下：
- web應用和APP迭代速度非常快。
- 頁面更新頻繁。
- 測試成本高於效益。
- 可交付於第三方進行測試(雲測、眾測)。
（2）介面測試
針對服務端後臺測試，介面規則一旦確定，後期的變化非常的小。
相對於變化頻繁的UI來說，介面測試的價效比更高。
這就成為了企業內重點測試的物件，我們都知道服務端中儲存著使用者資料、業務資料、交易資料等。倘若任何一個介面實現有問題，都會影響所有使用者。
正是由於服務端資料和業務邏輯關係著企業的命脈，所以極少會有企業把介面交於第三方測試。
作為測試人員，我們需要驗證的是介面間資料傳遞的正確性和完整性。
參考：