做測試時間長了，對於用例的設計慢慢的也會總結出自己的一套方法。
理論上有很多的用例設計方法，如：等價類，邊界值，錯誤推斷法，因果圖法，正交試驗設計等等。
其實我本人設計用例的方法其實很簡單，就從兩個方面考慮，通過性和異常來考慮，無非就是多考慮幾個異常的場景。
例如：登錄業務。
無非就是考慮：1.輸入正確的用戶名密碼 （這是通過性）
2.輸入錯誤的用戶名，正確的密碼 （這是異常場景一）
3，輸入正確的用戶名，錯誤的密碼 （這是異常場景二）
4，輸入錯誤的用戶名，錯誤的密碼 （這是異常場景三）
至於什么字符，數字，英文等，太繁瑣了，實際工作中最多會多考慮一下字符的長度，其他的根本不可能寫全。如果每個場景都考慮到位，時間也不允許。
所以我寫用例的思路就是從正常場景和異常場景兩個方面考慮，涉及到重要模塊的時候，多考慮一些異常場景，結合業務知識。例如：涉及到了支付，金額之類的，就要多測試一些數據了。
這篇隨筆主要是通過功能性的用例，來引入接口用例的設計。
下面接上我網上找來的一個案例：
這個案例是GET請求，單接口。很簡單，主要是通過這個案例來闡述一下接口測試用例的設計思路。
從截圖中可以看出，入參參數有3個必填參數。
先設計一個通過性的用例，檢查返回結果。
再分別設計多個異常的場景，其中某個或多個或全部必填參數出現錯誤的情況下，返回是否會報錯。
這也與上文中我說的功能用例設計思路類似。
同時我們還可以對入參的參數類型進行異常測試。比如:要求參數是string類型，我們輸入數字，漢字等類型，從而驗證開發有沒有對參數的類型進行控制，
從而達到我們測試的目的。
以上是通過正常場景和異常場景的方法設計接口測試用例的。
還有一個思路就是：安全 從安全方面考慮。（可以是業務層面的安全，也可以是數據的安全方面）
總結：
希望大家以后在設計接口測試用例的時候，不要手無足措，利用這個思路，很快就能進入狀態。
當然實際工作中，很多情況下，公司只測試通過性的接口用例，異常考慮的不充分。如果你能做的比別人多一點，那么，你很快就能出人頭地。