『居善地』接口測試 — 1、接口測試的概念
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來說，接口測試的性價比更高。
這就成為了企業內重點測試的對象，我們都知道服務端中保存着用戶數據、業務數據、交易數據等。倘若任何一個接口實現有問題，都會影響所有用戶。
正是由於服務端數據和業務邏輯關係著企業的命脈，所以極少會有企業把接口交於第三方測試。
作為測試人員，我們需要驗證的是接口間數據傳遞的正確性和完整性。
參考：
