2、請求方式：post、get等等
3、請求引數說明
名稱 型別 必填 說明
key string 是/否 填寫什麼資料
4、返回引數說明
名稱 型別 說明
error int/string 返回碼
5、介面文件分析
1、介面名稱
2、介面位址
3、支援格式
4、請求方式
5、請求引數（引數名、型別、是否必填、引數說明等）
6、返回引數（返回碼、返回值資訊、返回json資訊或xml資訊等）
6、http響應碼
1xx：資訊響應類
2xx：成功響應類
3xx：重定向響應類
4xx：客戶端錯誤
5xx：伺服器錯誤
7、具體用例設計
1、必填引數（1、引數都正確，2、型別錯誤，3、引數數值範圍）
2、必填引數不傳參（1、必填引數全部為空，2、必填引數部分為空）
3、正常場景（功能是否按照介面文件要求的功能實現）
4、異常場景
1、引數為空
2、引數多填
3、引數少填
4、引數型別錯誤
5、引數數值範圍錯誤
6、異常場景下是否有正確的處理邏輯和響應提示
8、通用介面測試用例
1、覆蓋所有引數，正向用例
2、覆蓋所有必填引數，正向用例
3、某一必填引數為空，逆向用例
4、必填引數基礎上，多傳乙個引數，少傳乙個引數，逆向用例
5、必填引數資料型別錯誤，資料值錯誤，逆向用例（例如整型變字串）
6、任意組合可選引數，正向用例
7、與業務邏輯相關的，使用者身份證為空或者錯誤，逆向用例
8、欄位的唯一性校驗，如插入資料字段不能重複，傳送兩次請求，檢視第二次返回結果，逆向用例
介面測試用例設計
介面測試用例設計點主要包括 功能 邏輯業務 異常 安全 功能 1.功能是否正常 2.功能是否按照介面設計文件實現 舉例 有些新增到購物車，需要登入才能新增。也就是業務要求不支援遊客新增購物車功能，如果設計乙個沒有登入的使用者，然後去測試新增購物車介面，結果介面能新增到購物車，說明功能不正常，不符合需...
介面測試用例設計
主要是子模組或者子系統間互動並相互作用的部分。因此，可以分析，系統間的介面包含三部分 輸入 處理邏輯 輸出。在沒有特殊要求的情況下，至少需要考慮以下內容 1 業務功能覆蓋是否完整 2 業務規則覆蓋是否完整 3 引數驗證是否達到要求 邊界 業務規則 4 介面異常場景覆蓋是否完整如果介面需求還包含效能或...
介面測試用例設計
輸入引數測試 引數必填 選填 合法輸入 非法輸入 邊界值 引數為空或null異常處理，基於業務場景的考慮。如 登陸狀態 許可權 依賴等設計到dao層呼叫的，考慮資料增刪改查的準確性。返回結果測試 與需求一直 返回碼及返回字段 每種錯誤要有單獨且明確的錯誤碼 功能測試 邏輯測試 兩個請求有嚴格的先後順...