接口測試的原理，什麼是接口測試？爲何要作接口測試？如何開展接口測試？

最近幾年接口測試被炒得火熱了，愈來愈多的測試同行意識到了接口測試的重要性。主要是日常的功能點點點，你們水平都同樣，然而要拿到更高的薪資，對事業更有成就感。更深刻的思考頁面上看不到的功能，也就是接口測試了。

接口測試主要用於外部系統與系統之間以及內部各個子系統之間的交互點，定義特定的交互點，而後經過這些交互點來，經過一些特殊的規則也就是協議，來進行數據之間的交互。

 

接口通常分爲兩種：1.程序內部的接口 2.系統對外的接口

 

提及接口測試，網上有不少例子，可是當初作爲新手的我來講，看了不不知道他們說的什麼，以爲接口測試，好高大上。認爲學會了接口測試就能屌絲逆襲，走上人生巔峯，迎娶白富美。所以學了點開發知識後，發現接口測試其實都是人們玩的名詞罷了。接口測試，真心很簡單。它只不過是數據傳遞是一種表現而已。

 

嗶哩嗶哩，免費學習好去處。正好我前幾天剪了一個關於接口自動化測試技術的合集。

 

阿里面試官：你說一下Python接口測試，這樣回答讓他豎起大拇指！

 

 

若是對你有幫助，別忘了回來點個贊同。

 

什麼是接口？

業內常說的接口通常指兩種：

1.API：應用程序編程接口，程序間的接口
2.GUI：圖形用戶界面，人與程序的接口

 

• 軟件接口測試中的接口特指API接口
• 接口測試又稱API測試

 

接口實例：系統與系統間的接口調用，做用：實現了兩個或多個獨立系統或模塊間的通訊和數據交換能力。

 

常見的Web接口類型

REST接口——經過HTTP的get和post方式獲得數據，返回報文json格式
SOAP接口——經過soap協議獲得數據，相比Httpservice能處理更加複雜的數據類型，請求報文和返回報文xml格式

Http接口的組成

eg：http://127.0.0.1:80/user.php?act=register

請求協議：http://
IP：127.0.0.1
端口號：80
接口地址：user.php
接口參數：act
參數值：register

SOAP接口

SOAP實際上就是HTTP+XML
不管哪一種語言開發的平臺，只要是網頁開發均可以經過http協議來進行通訊，而且返回的數據想要通用的話，可使用XML格式來編寫

面試題：什麼是RESTful？

RESTful是REST的全程。
提供了一組客戶端和服務器交互的規則。
當用「GET」方式時，只用來獲取數據，成功了返回http狀態碼200。
當用「POST」方式時，只用來建立數據，成功了返回http狀態碼201
當用「PUT」方式時，只用來修改更新數據，成功了返回http狀態碼203
當用「DELETE」方式時，只用來刪除數據，成功了返回http狀態碼204
    ps：GET(SELECT)：從服務器取出資源（一項或多項）。

           POST(CREATE)：在服務器新建一個資源。

           PUT（UPDATE）：在服務器更新資源（客戶端提供改變後的完整資源）。

           PATCH（UPDATE）：在服務器更新資源（客戶端提供改變的屬性）。

           DELETE（DELETE）：從服務器刪除資源。

 

爲何要作接口測試？

儘早進行系統集成測試，暴露BUG
解決系統測試複雜度
屏蔽UI層的不穩定性
檢查系統安全性，穩定性
接口通過測試穩定了，前端頁面隨便改，減小BUG的產生

接口測試的原理

原理：模擬客戶端向服務器發送請求報文，服務器接受請求報文後對相應的報文作處理並向客戶端返回應答，客戶端再接受應答的一個過程。
接口測試是黑盒測試。做爲黑盒測試，基本的測試思路是經過輸入和輸出判斷被測系統或者對象的邏輯。

接口測試關注點

關注在系統架構的業務邏輯層，不注重UI操做或者用戶感觀
檢查數據的交換，傳遞和控制管理過程
注重系統間的相互邏輯關係調用

接口測試的範圍

按測試類型分：功能、性能、安全性

按數據的輸入輸出分：

一、進入系統的接口（調用外部系統的參數爲本系統使用）

二、數據流出系統接口（驗證系統處理後的數據是否正常）

 

接口測試和UI測試的異同點

UI的操做實際上就是用另外一種方式調用接口，那麼接口有多少種參數組合就要求UI用例要構造多少種操做進行調用
UI操做所須要的數據能夠用接口來生成
接口測試能夠保證數據和邏輯的準確性，UI測試須要考慮交互和界面展現的邏輯正確性
UI測試須要重視接口調用不成功或者接口異常狀況下UI的呈現方式和用戶體驗
UI中可能會有一些狀態的緩存信息（這樣就不須要每次頻繁調用接口去獲取了），好比鑑權信息等，須要重點關注這些緩存的更新策略

接口測試的三種形式

手動測試：輔助工具、Fiddler、Postman、HttpWath。。。

自動化測試：本身開發的工具、SoapUI、RobotFramework。。。

性能測試：本身開發的工具、Jmeter、LoadRunner。。。

 

如何開展接口測試

找開發或者開發主管索要接口說明文檔（API文檔）。做用：是開發測試腳本的依據
熟悉業務，設計測試用例，準備測試數據
根據接口說明文檔開發接口測試腳本，執行腳本
API文檔
測試文檔接口說明，參數，返回值，是否齊全
熟悉業務
設計測試用例，準備測試數據
開發接口測試腳本
執行腳本，調入數據
提交BUG
寫報告

一份好的接口說明文檔是什麼樣的？

在項目中，一份完整的接口文檔應該包含如下的內容：

接口說明
請求方式（get\post）
請求地址
請求參數、參數類型、請求參數說明
返回參數說明
返回示例

 

 

 

HTTP協議——Http請求

請求：Request，由客戶端發送給服務器端
請求分類：GET和POST請求（有什麼區別？）
GET請求主要是數據的獲取
POST請求主要是數據的提交

HTTP協議——Http響應

響應：Response，由服務器端返回給客戶端
響應包含正常的響應和異常的響應。
HTTP協議經過響應的狀態碼來進行定義：1xx，2xx，3xx（正常），4xx，5xx（異常）

接口功能測試點

接口文檔規範性
接口可用性
接口實現功能驗證
輸入輸出參數個數及命名
輸入參數的必填項
輸入參數的合法性
輸出參數內容的正確性
接口傳遞參數的安全性

——接口可用性

主要測試接口是否可用、接口是否存在、接口的協議類型
測試用例中應包括：
依據接口文檔中給定的接口地址和協議方法可以訪問到該接口。
使用錯誤的協議方法沒法按照接口地址進行訪問。
使用正確的協議方法沒法按照錯誤的接口地址進行訪問。

——輸入輸出參數個數及命名

主要測試接口包含的輸入輸出參數的個數以及各個參數的命名是否正確。
測試用例中應包括：
依據接口文檔檢查輸入參數的個數以及命名是否和文檔一致。
依據接口文檔檢查輸出參數的個數以及命名是否和文檔一致（注意檢查輸出的正常參數和異常參數）。
輸入錯誤的參數名，接口會報錯，並有錯誤信息返回。

——輸出參數內容的正確性

主要對輸出參數的內容是否和後臺真實數據一致進行檢查。
測試用例中應包括：
考慮多種輸入參數的組合狀況，依次測試在這些組合狀況下接口返回的數據的各字段內容是否正確，要具體檢查每一個字段的內容。通常經過與後臺數據庫數據比較來進行檢查。
考慮多種輸入參數的組合狀況，依次測試在這些組合狀況下接口返回的數據中涉及輸入參數的項，是否和最初輸入的值一致。

——接口實現功能驗證

主要對接口操做的具體功能是否正常運轉進行檢查。
測試用例中應包括：
輸入正確的參數，檢查接口對應的要實現的後臺功能是否正確運轉。例如：對一個啓動接口發送啓動的命令，接口對應的後臺系統可以正確啓動並返回正確的參數。
輸入錯誤的參數，檢查接口對應的要實現的後臺功能是否沒有運轉。

——接口文檔規範性

主要對開發提供的接口文檔是否規範準確進行檢查。
測試用例中應包括：
接口文檔中對於輸入輸出參數都有準確的命名，不存在模糊的狀況。
接口文檔對於每個參數都有明確的類型說明，是否可選仍是必輸，是否有默認值。
接口文檔對於每個輸入參數都有明確好基本的錄入條件，好比長度最長多少、只能爲數字仍是字母、不能含有特殊字符等。
針對一個接口若是有多種類型的輸出參數組合且參數的命名或者個數有不一樣，這種狀況，要在接口文檔中羅列清晰，並明確指出出現這種類型的輸出參數的條件。

——接口傳遞參數的安全性

接口傳遞參數的加密顯示
防止SQL注入攻擊

——SQL注入的原理

定義：利用現有應用程序，將（惡意）的SQL命令注入到後臺數據庫引擎執行的能力。
用於沒有對用戶的輸入數據進行必要的合法性判斷，致使了攻擊者可用提交一段數據庫查詢代碼，根據程序返回的結果，得到一些他想要獲得的數據。
舉例：
在用戶名輸入框中輸入：’or 1=1 #，密碼隨便輸入，這時候的合成後的SQL查詢語句爲：
select * from users where username = '' or 1=1 #' and password = md5('')
等價於：select * from users where username = '' or 1=1

接口測試用例怎麼寫

三個步驟：

初始化測試數據調用接口，傳入輸入數據對輸出斷言