根據以往的工作經驗，介面用例設計主要從以下三個方面來進行設計：
1 輸入
輸入引數主要從以下幾各方面設計：
b 引數長度校驗：參考介面文件即可。
c 引數值的有效性校驗：如：身份證號的校驗 ，設計的資料雖然符合身份證號的規則，但是並不是真實有效的身份證號；這種情況就要看身份證號的校驗規則是什麼樣了，一般都是用的現成的身份證號校驗器，但是有些是自己寫的校驗演算法，這個本人就遇到過這種問題---校驗演算法寫的不正確；所以引數有效性的校驗就需要結合實際業務場景，判斷哪些資料是真實有效的資料，一定要確保所有真實有效的資料是可以驗證通過的。
d 引數組合校驗：不同的引數組合可能會存在不同的業務場景；
e 如果引數是列舉值，一定要各種列舉值都要測試，因為可能不同的列舉走的不同的業務流程；
f 引數值的預設值的校驗：參考介面文件。
g 某些引數具有特定的生成規則，要單獨針對生成規則設計用例，一定要保證真實有效的資料是可以驗證通過的。如身份證號中間幾位 ******19860701****，本人就遇到過輸入******19861001****這種值校驗不正確；
2 介面邏輯
介面邏輯我用的設計方法是分支覆蓋--->路徑覆蓋--->場景覆蓋,同樣也是要結合實際業務場景，根本不發生的業務場景就是無效的測試用例。
a 第一步先把業務流程圖畫出來；
b 依據路程圖中的分支分別設計，不同分支不同的場景，這裡就要把異常的場景考慮進去；如介面超時，介面異常，介面請求成功或失敗，成功後怎麼處理，失敗後流程是否繼續執行，失敗後的資料怎麼處理；
以打款介面為例：打款結果有打款成功或打款失敗，成功後怎麼處理，需要回寫打款成功狀態，失敗後怎麼處理，也需要回寫失敗狀態，失敗後的資料可以操作退回，也可以操作重新出款等等；
c 測試邏輯設計完成後要想一想不同的業務場景怎麼去測試，需要哪些人員協助，如介面超時怎麼去測試，請求重複怎麼去測試，請求併發怎麼去測試
3 輸出
輸入結果：正常輸出和異常輸出，常用的方法有錯誤推斷法（列舉出程式中可能存在的錯誤或者異常，根據他們選擇測試用例）
4 以上都完成後，要結合實際的業務場景去掉冗餘的用例（即實際業務場景不存在的流程或者輸入資料）；
5 如果業務流程涉及到狀態轉換，要單獨設計使用者---方法：狀態轉換圖；
6 涉及到多個不同金額或者手續費的計算，可能還會用到正交實驗法去設計用例；
7 另外，用例設計中還應當包含異常流程中產生的異常資料的處理流程；---通常所說的補償機制，這塊流程能大大的減輕人工運營的工作量，當然，這需要在做系統設計的時候就需要把這部分考慮進去；
介面測試用例設計
介面測試用例設計點主要包括 功能 邏輯業務 異常 安全 功能 1.功能是否正常 2.功能是否按照介面設計文件實現 舉例 有些新增到購物車，需要登入才能新增。也就是業務要求不支援遊客新增購物車功能，如果設計乙個沒有登入的使用者，然後去測試新增購物車介面，結果介面能新增到購物車，說明功能不正常，不符合需...
介面測試用例設計
主要是子模組或者子系統間互動並相互作用的部分。因此，可以分析，系統間的介面包含三部分 輸入 處理邏輯 輸出。在沒有特殊要求的情況下，至少需要考慮以下內容 1 業務功能覆蓋是否完整 2 業務規則覆蓋是否完整 3 引數驗證是否達到要求 邊界 業務規則 4 介面異常場景覆蓋是否完整如果介面需求還包含效能或...
介面測試用例設計
輸入引數測試 引數必填 選填 合法輸入 非法輸入 邊界值 引數為空或null異常處理，基於業務場景的考慮。如 登陸狀態 許可權 依賴等設計到dao層呼叫的，考慮資料增刪改查的準確性。返回結果測試 與需求一直 返回碼及返回字段 每種錯誤要有單獨且明確的錯誤碼 功能測試 邏輯測試 兩個請求有嚴格的先後順...