接口測試是測試系統組件間接口的一種測試。接口測試主要用於檢測外部系統與系統之間以及內部各個子系統之間的交互點。測試的重點是要檢查數據的交換，傳遞和控制管理過程，以及系統間的相互邏輯依賴關系等。
測試的策略：
接口測試也是屬於功能測試，所以跟我們以往的功能測試流程並沒有太大區別，測試流程依舊是：
-
評審測試接口文檔（需求文檔）
-
根據接口文檔編寫測試用例（用例編寫完全可以按照以往規則來編寫，例如等價類划分，邊界值等設計方法）
-
執行測試，查看不同的參數請求，接口的返回的數據是否達到預期
那么設計測試用例時我們主要考慮如下幾個方面：
功能測試：
-
接口的功能是否正確實現了
-
接口是否按照設計文檔中來實現（比如username參數寫為了user，那么這就不符合，因為接口文檔在整個開發中都需要使用，所以接口實際的設計要與接口設計文檔中保持一致）
-
兼容性測試： 比如說今天接口進行了調整，但是前端沒有進行變更，這時候需要驗證新的接口是否滿足舊的調用方式
-
錯誤碼測試： 通用的錯誤碼與業務錯誤碼是否能夠清晰的說明調用問題，錯誤碼是否能夠盡可能的全的覆蓋所有的情況
-
返回值測試： 返回值除了內容需要是正確的，還需要類型也是正確的，保證調用方拿到這些參數能夠正確的解析
-
參數邊界值、等價類測試
-
json格式測試： 通常我們的接口一般設計的都是傳遞json串，那么就需要去測試 如果傳遞非json的情況，這時候程序會不會正確的處理，返回相應的 error code
-
默認值測試： 很多情況一些非必填的參數會有默認值，比如說一個查詢的接口，參數count為返回查詢的結果數量， 默認為10，那么就應該有一條case來測試，當然前置條件是數據庫里面必須要存在這樣的數據超過10條。
邏輯業務：
-
是否有依賴業務，比如查看訂單，是需要用戶首先登錄的，所以肯定要保證登錄了或有相應的cookie
-
業務邏輯測試： 傳遞正確的參數，接口對數據庫進行查詢的操作，需要去驗證數據庫查詢是否正確，接口對數據庫進行 增刪改的操作，也需要看數據庫是否同步進行了這些操作
異常測試：
異常分為兩類，參數異常和數據異常
參數異常：
-
關鍵字參數：將參數寫為開發語言中的關鍵字
-
參數為空：比如去掉了username參數
-
多或少參數：多或者少參數的驗證，現在還不確定如果一個接口多了參數如果沒有報錯是否是合理的，或者是否需要優化，因為就目前開發給予的答案是，一般不對接口多了參數的處理
-
錯誤參數：比如將username參數寫為了user等看是否能返回相應的error code
數據異常：
-
關鍵字數據：將參數的值填為開發語言中的關鍵字
-
數據為空：將參數的額值填為空
-
長度不一致：因為數據庫中每個字段都設置有字段長度，填寫不符合的長度進行驗證
-
錯誤數據：就是將參數的值任意填寫，或填寫不存在的數值
- 異常類型測試： 比如count參數，這個參數的類型一定是可以轉換為int類型的，這時候我們需要測試如果傳的一些不可以 轉換為int類型值來測試代碼是否加入判斷
性能測試：
-
響應時間
-
吞吐量
-
並發用戶數
- 占用內存，CPU等
安全性測試：
-
敏感信息是否加密
-
必要參數是否后端也進行校驗（現在很多系統前后端架構是分離的，從安全層面來說，只依賴前端進行限制已經完全不能滿足系統的安全要求（繞過前端太容易了）， 需要后端同樣進行控制，在這種情況下就需要從接口層面進行驗證）
-
接口是否防惡意請求（SQL注入）
-
cookie：就是將header中的cookie修改或刪除后看是否能返回相應的error code
-
header：就是刪除或修改header中部分參數的值，看是否能返回相應的error code
-
唯一識別碼：刪除修改唯一識別碼測試
轉載：https://www.cnblogs.com/fireporsche/p/9949805.html