接口測試常見測試點

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

測試的政策：

接口測試也是屬于功能測試，是以跟我們以往的功能測試流程并沒有太大差別，測試流程依舊是：

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
• 唯一識别碼：删除修改唯一識别碼測試
• from  https://www.cnblogs.com/fireporsche/p/9949805.html