介面測試也是屬於功能測試，所以跟我們以往的功能測試流程並沒有太大區別，測試流程依舊是：
那麼設計測試用例時我們主要考慮如下幾個方面：介面是否按照設計文件中來實現（比如username引數寫為了user，那麼這就不符合，因為介面文件在整個開發中都需要使用，所以介面實際的設計要與介面設計文件中保持一致）
相容性測試：比如說今天介面進行了調整，但是前端沒有進行變更，這時候需要驗證新的介面是否滿足舊的呼叫方式
錯誤碼測試：通用的錯誤碼與業務錯誤碼是否能夠清晰的說明呼叫問題，錯誤碼是否能夠盡可能的全的覆蓋所有的情況
返回值測試：返回值除了內容需要是正確的，還需要型別也是正確的，保證呼叫方拿到這些引數能夠正確的解析
引數邊界值、等價類測試
json格式測試：通常我們的介面一般設計的都是傳遞json串，那麼就需要去測試 如果傳遞非json的情況，這時候程式會不會正確的處理，返回相應的error code
預設值測試：很多情況一些非必填的引數會有預設值，比如說乙個查詢的介面，引數count為返回查詢的結果數量， 預設為10，那麼就應該有一條case來測試，當然前置條件是資料庫裡面必須要存在這樣的資料超過10條。
是否有依賴業務，比如檢視訂單，是需要使用者首先登入的，所以肯定要保證登入了或有相應的cookie
業務邏輯測試：傳遞正確的引數，介面對資料庫進行查詢的操作，需要去驗證資料庫查詢是否正確，介面對資料庫進行 增刪改的操作，也需要看資料庫是否同步進行了這些操作
異常分為兩類，引數異常和資料異常
1. 引數異常：
關鍵字引數：將引數寫為開發語言中的關鍵字 引數為空：比如去掉了username引數多或少引數：多或者少引數的驗證，現在還不確定如果乙個介面多了引數如果沒有報錯是否是合理的，或者是否需要優化，因為就目前開發給予的答案是，一般不對介面多了引數的處理
錯誤引數：比如將username引數寫為了user等看是否能返回相應的error code
關鍵字資料：將引數的值填為開發語言中的關鍵字
資料為空：將引數的額值填為空
長度不一致：因為資料庫中每個欄位都設定有字段長度，填寫不符合的長度進行驗證
錯誤資料：就是將引數的值任意填寫，或填寫不存在的數值
異常型別測試：比如count引數，這個引數的型別一定是可以轉換為int型別的，這時候我們需要測試如果傳的一些不可以 轉換為int型別值來測試**是否加入判斷
吞吐量併發使用者數
占用記憶體，cpu等
敏感資訊是否加密
必要引數是否後端也進行校驗（現在很多系統前後端架構是分離的，從安全層面來說，只依賴前端進行限制已經完全不能滿足系統的安全要求（繞過前端太容易了）， 需要後端同樣進行控制，在這種情況下就需要從介面層面進行驗證）
介面是否防惡意請求（sql注入）
cookie：就是將header中的cookie修改或刪除後看是否能返回相應的error code
header：就是刪除或修改header中部分引數的值，看是否能返回相應的error code
唯一識別碼：刪除修改唯一識別碼測試
效能測試 介面效能測試需要注意的點
介面效能測試需要注意的點 1 是否呼叫外部系統的介面 有些介面的呼叫會觸發對其它系統介面的呼叫，針對這種情況，可能得考慮新增 擋板 中注釋掉對外部系統介面的呼叫，直接返回模擬資料，模擬對外部系統介面的呼叫返回。這樣以減少因外部系統引起的效能干擾問題 2 是否包含列舉型別的引數 看介面是否攜帶了列舉型...
測試用例設計需要注意的幾個點
測試用例需要注意以下幾點 1 單個用例覆蓋最小化原則下面舉個例子來介紹，假如要測試乙個功能 a，它有三個子功能點 a1，a2 和 a3，可以有下面兩種方法來設計測試用例 方法1 用乙個測試用例 確卻的說是用例的邏輯部分 覆蓋三個子功能 test a1 a2 a3，方法2 用三個單獨的用例分別來覆蓋三...
單例模式的基本原理以及需要注意的點
public class singleton 關鍵點0 建構函式是私有的 private static singleton single null 關鍵點1 宣告單例物件是靜態的 private static object obj new object public static singleton...