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