json格式測試：
通常我們的介面一般設計的都是傳遞json串，那麼就需要去測試
如果傳遞非json的情況，這時候程式會不會正確的處理，返回相應的 error code
預設值測試：
很多情況一些非必填的引數會有預設值，比如說乙個查詢的介面，引數count為返回查詢的結果數量，
預設為10，那麼就應該有一條case來測試，當然前置條件是資料庫裡面必須要存在這樣的資料超過10條。
異常型別測試：
比如上面的count引數，這個引數的型別一定是可以轉換為int型別的，這時候我們需要測試如果傳的一些不可以
轉換為int型別值來測試**是否加入判斷
必傳項測試：
如果介面的引數有必傳項，那麼需要測試在不傳這個引數的時候介面返回情況，測試是否會提示
相應的error code
非必傳項測試：
如果介面有非必填項，當我不傳遞這些引數的時候會不會正常的返回相應的結果
6.非空測試：
無論是必傳的和非必傳的引數，傳遞的key是正確的，但是value=null，這時候返回結果是否正確
7.業務邏輯測試：
傳遞正確的引數，介面對資料庫進行查詢的操作，需要去驗證資料庫查詢是否正確，介面對資料庫進行
增刪改的操作，也需要看資料庫是否同步進行了這些操作
8.相容性測試：
比如說今天介面進行了調整，但是前端沒有進行變更，這時候需要驗證新的介面是否滿足舊的呼叫方式
9.錯誤碼測試：
通用的錯誤碼與業務錯誤碼是否能夠清晰的說明呼叫問題，錯誤碼是否能夠盡可能的全的覆蓋所有的情況
10.資料異常測試：
假如資料庫設計為32位varchar型別，那麼如果傳33位會是什麼情況，會不會丟擲相應的錯誤碼，而不會丟擲資料庫異常
11.返回值測試：
返回值除了內容需要是正確的，還需要型別也是正確的，保證呼叫方拿到這些引數能夠正確的解析
12.加密測試：
組合介面測試（場景測試）
單個的介面測試通過後，需要將單個的介面組成連續的場景，比如說投資介面需要用到乙個類似token的 引數，而這個引數是登陸介面獲取到的，所以就需要先呼叫登陸介面，然後再去呼叫投資介面。還有就是 像資料許可權與操作許可權這些，都會依賴一些其他的介面，那麼把這些依賴的介面組成乙個場景來測試資料的 正確性。還有一部分介面是內部呼叫的，比如說註冊介面，在註冊的時候通常需要獲取乙個驗證碼，然後輸入 驗證碼再進行提交註冊的操作，在這過程中，驗證驗證碼的操作是在註冊的內部完成的，那麼其實在組合場景 的時候就不需要再去中間加入驗證驗證碼的介面。
計畫測試場景
目標 1 測試終端使用者響應時間 多長時間完成業務處理 2 定義最優硬體配置 哪種硬體配製提供最優的效能 3 檢查穩定性 系統可以執行多長時間不會發生出錯或失敗 4 檢查硬體或軟體公升級 公升級如何影響效能和穩定性 5 評價新產品 選擇哪種伺服器硬體或軟體 6 測量系統能力 在不降低效能下系統能夠處...
效能測試場景
執行緒數 需要設定的併發使用者數 併發使用者數 受cpu的主頻 分配的記憶體大小 作業系統 允許開啟檔案數量 開放的埠數量 的影響，一台電腦，大概能支援 1500併發使用者數以內 http協議 ramp up時間 在多長時間內啟動所有的執行緒。注意 只是說明，在第n秒結束時，會產生m個併發使用者數，...
效能測試場景設計之容量測試場景設計
目前僅限於容量測試場景設計。場景模型的設計過程其實就是根據預期目標tps和測試模型計算出每乙隻交易的併發使用者數和迭代間隔時間。選擇固定間隔時間方式，詳細方法請看7.3節中的pacing選項的說明，不同的預期目標tps將會得到不同的併發使用者數和間隔時間。首先，假定乙個總的目標tps，然後通過測試模...