單介面測試：

1. json格式測試：  
  通常我們的介面一般設計的都是傳遞json串，那麼就需要去測試
  如果傳遞非json的情況，這時候程式會不會正確的處理，返回相應的        error code

2. 預設值測試：
  很多情況一些非必填的引數會有預設值，比如說一個查詢的介面，引數count為返回查詢的結果數量，
  預設為10，那麼就應該有一條case來測試，當然前置條件是資料庫裡面必須要存在這樣的資料超過10條。

3. 異常型別測試：
  比如上面的count引數，這個引數的型別一定是可以轉換為int型別的，這時候我們需要測試如果傳的一些不可以
  轉換為int型別值來測試程式碼是否加入判斷

4.
 
 必傳項測試：
  如果介面的引數有必傳項，那麼需要測試在不傳這個引數的時候介面返回情況，測試是否會提示
  相應的error code

5. 非必傳項測試：
  如果介面有非必填項，當我不傳遞這些引數的時候會不會正常的返回相應的結果

6.非空測試：
  無論是必傳的和非必傳的引數，傳遞的key是正確的，但是value=null，這時候返回結果是否正確

7.業務邏輯測試：
  傳遞正確的引數，介面對資料庫進行查詢的操作，需要去驗證資料庫查詢是否正確，介面對資料庫進行
  增刪改的操作，也需要看資料庫是否同步進行了這些操作

8.相容性測試：
  比如說今天介面進行了調整，但是前端沒有進行變更，這時候需要驗證新的介面是否滿足舊的呼叫方式

9.
 
錯誤碼測試：
  通用的錯誤碼與業務錯誤碼是否能夠清晰的說明呼叫問題，錯誤碼是否能夠儘可能的全的覆蓋所有的情況

10.資料異常測試：
  假如資料庫設計為32位varchar型別，那麼如果傳33位會是什麼情況，會不會丟擲相應的錯誤碼，而不會丟擲資料庫異常

11.返回值測試：
  返回值除了內容需要是正確的，還需要型別也是正確的，保證呼叫方拿到這些引數能夠正確的解析

12.加密測試：
    測試引數的加密與解密，使前後端能夠減少浪費這方面的時間

組合介面測試（場景測試）

 單個的介面測試通過後，需要將單個的介面組成連續的場景，比如說投資介面需要用到一個類似token的
引數，而這個引數是登陸介面獲取到的，所以就需要先呼叫登陸介面，然後再去呼叫投資介面。還有就是
像資料許可權與操作許可權這些，都會依賴一些其他的介面，那麼把這些依賴的介面組成一個場景來測試資料的
正確性。還有一部分介面是內部呼叫的，比如說註冊介面，在註冊的時候通常需要獲取一個驗證碼，然後輸入
驗證碼再進行提交註冊的操作，在這過程中，驗證驗證碼的操作是在註冊的內部完成的，那麼其實在組合場景
的時候就不需要再去中間加入驗證驗證碼的介面。