接口測試經常使用測試點

接口測試是測試系統組件間接口的一種測試。接口測試主要用於檢測外部系統與系統之間以及內部各個子系統之間的交互點。測試的重點是要檢查數據的交換，傳遞和控制管理過程，以及系統間的相互邏輯依賴關係等。

測試的策略：

接口測試也是屬於功能測試，因此跟咱們以往的功能測試流程並無太大區別，測試流程依舊是：

1. 評審測試接口文檔（需求文檔）

2. 根據接口文檔編寫測試用例（用例編寫徹底能夠按照以往規則來編寫，例如等價類劃分，邊界值等設計方法）

3. 執行測試，查看不一樣的參數請求，接口的返回的數據是否達到預期

那麼設計測試用例時咱們主要考慮以下幾個方面：

功能測試：

• 接口的功能是否正確實現了

• 接口是否按照設計文檔中來實現（好比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

• 惟一識別碼：刪除修改惟一識別碼測試