介面測試用例設計方式方法有：
針對輸入:因為輸入是由客戶端提交的，客戶端是否按協議提交引數介面側是無法控制的，此時針對輸入測試用例需考慮：按照引數型別進行設計、非法傳參的健壯性及穩定性；
針對介面處理邏輯:依據產品業務定義進行用例設計
針對介面輸出:針對輸出結果（資料操作以及介面返回response）進行分析設計。
關於輸入的用例設計：介面文件一般都會標明引數型別及長度，是否必選項等
異常的引數校驗有必要做那麼多嗎？
例如，在購物**中，客戶端和後台的介面，需要要做充分的異常測試。協議通常有加密，但是因為**有利益可圖，總有一些人去攻擊，那麼一旦攻擊成功，就可以繞過客戶端直接訪問後台介面，如果後台邏輯有漏洞，就有利可圖了。
還有，一些提供給外部使用的介面，也需要做好異常測試，因為你不清楚呼叫者會怎麼使用，那麼作為乙個可靠的提供方，保證自己的穩定和健壯是非常有必要的。另外一些情況，可能這些異常是外部無法觸發的，那麼這種情況下，異常問題就沒有那麼高的優先順序去解決。
測試中，通常需要去權衡測試成本和產品質量，找到乙個平衡點。
用例設計-介面邏輯
約束條件分析
操作物件分析
狀態轉換分析
時序分析
操作物件分析：測試點針對合法或不合法的物件進行設操作
如：登入帳號a，檢視帳號b的資料，風險：個人資料隱私或是安全性。
狀態轉換分析：業務狀態規定流轉必須為a>b>c，測試點需關注能否產生a>c，或c>a等情況，避免流程漏洞帶來利益損失。（**訂單較常見）
時序分析（更多地可以理解為業務流轉流程）：主要為某業務涉及多個介面，非順序執行導致資料異常或正常資料無法寫入的情況
用例設計-輸出
針對輸出結果
成功介面response返回欄位的準確性；
客戶端流程是否正常；
資料更新操作的準確性（資料庫、快取等）；
失敗異常錯誤是否有捕獲處理；
異常流程是否有明確的狀態碼返回；如：
1001 = 服務異常
1001 = w4parseresult是null
介面處理時間
超時未返回
未進行超時處理，導致整個流程阻塞；
超時錯誤返回
服務端處理超時，但返回處理成功；
用例設計還需要考慮其他，比如：
介面測試用例設計
介面測試用例設計點主要包括 功能 邏輯業務 異常 安全 功能 1.功能是否正常 2.功能是否按照介面設計文件實現 舉例 有些新增到購物車，需要登入才能新增。也就是業務要求不支援遊客新增購物車功能，如果設計乙個沒有登入的使用者，然後去測試新增購物車介面，結果介面能新增到購物車，說明功能不正常，不符合需...
介面測試用例設計
主要是子模組或者子系統間互動並相互作用的部分。因此，可以分析，系統間的介面包含三部分 輸入 處理邏輯 輸出。在沒有特殊要求的情況下，至少需要考慮以下內容 1 業務功能覆蓋是否完整 2 業務規則覆蓋是否完整 3 引數驗證是否達到要求 邊界 業務規則 4 介面異常場景覆蓋是否完整如果介面需求還包含效能或...
介面測試用例設計
輸入引數測試 引數必填 選填 合法輸入 非法輸入 邊界值 引數為空或null異常處理，基於業務場景的考慮。如 登陸狀態 許可權 依賴等設計到dao層呼叫的，考慮資料增刪改查的準確性。返回結果測試 與需求一直 返回碼及返回字段 每種錯誤要有單獨且明確的錯誤碼 功能測試 邏輯測試 兩個請求有嚴格的先後順...