1.簡介
在這篇文章里，我們來學習一下接口測試用例設計，主要是來學習一些用例設計要點。其實說白了，接口用例設計和功能用例設計差不多，照貓畫虎即可。不要把它想象的多么高大上，多么的難，其實一樣，以前怎么設計，現在就怎么設計，和黑盒測試設計測試用例半斤八兩。這里不再贅述，想詳細了解的可以看一下Python的接口自動化用例設計。宏哥在這里，換一個角度來說接口測試的用例設計，首先我們看一下接口測試的范圍。
2.接口測試范圍
2.1功能測試：驗證產品邏輯是否正確
功能測試是我們接口測試時候相當重要的一部分，接口的功能都沒實現，后邊的異常、性能就更加談不上了。其實接口測試和在web頁面、或者移動端操作那些按鈕、輸入框是一樣的。按鈕將綁定的參數通過接口傳過去，而輸入框是將你輸入的參數通過接口傳過去。接口測試是在產品還沒有開發好按鈕和輸入框，你手動寫參數通過工具或者其他方法傳過去，驗證是否可以得到期望的。
下邊的這八種接口功能測試的8種方法和web頁面的測試用例的設計方法一模一樣的，這個都是測試的基礎知識，不知道的自己可以單獨查詢一下各種方法的概念及其的用法。
2.2異常測試
null : 是開發過程中特定指的一個對象為空的端符，就是一個空對象，不指向任何內存地址
" " : 指一個空字符串，代表該對象有值，指向一個空地址
數據類型：例如我們有個年齡的字段要求傳的是ini類型的值，我們給它傳的是字符串。這就是數據類型異常。8中基本數據類型，我們傳一個不符合規定的數據類型。
負載均衡架構：測試某一個后台(Tomcat 4)掛了，掛了之后 Tomcat4的請求會直接返回一個錯誤（前台1個nginx ,后台多個 Tomcat），測試是否會返回這個錯誤，能否會使用戶訪問失敗；一段時間后，想讓 Tomcat4 重新加入，判斷能否重新加入集群中並正確處理所有請求。
冷熱備份：冷備份不常見，熱備份：前面有4個Tomca，后面有4個Tomca備份，如果Tomca4掛了，判斷Tomca4的備份能否頂替之前的，仍然保持4個服務器存活；當Tomca4 正常后，判斷能夠成為Tomca4的備份。
1.3性能測試（狹義）
負載測試：我發了好多請求，看看能不能正常發出去，再看看服務器端能不能正常處理這些發過來的請求。
穩定性測試：比如我跑服務跑了好長時間，比如24h、一周等，看看能不能將程序壓垮等等。
3.自動化接口測試范圍
為什么在這里沒有涉及到前邊接口測試的環境異常和功能測試。在這里宏哥做了細分，這部分主要是有其他的測試負責的，比如：環境異常測試，一般需要我們協調和運維配合。需要他們把環境部署成和線上一樣的架構，以及硬件、內存等等。由於各個公司的資源和重視不一樣，但是最差了也得是等比例縮小的一個初始化的模型。這樣做的接口測試才有意義。性能測試也可以自動化測試，這個也有專門的測試，當然了，你也可以進行一些簡單的測試，如果你是全棧測試，那么這三部分你都精通那最好了。這里宏哥主要介紹的圍繞的功能測試和數據異常測試。
4.自動化接口測試用例設計
這里宏哥通過具體實例說明一下。自動化接口測試原則：你能夠把你設計的接口測試用例映射成一張表。因為映射成一張表你才可以更好的方便的操作，並且可以自動加載它。
4.1接口自動化用例設計示例：登錄
環境異常測試時需要運維小伙伴配合測試的，此暫時不做描述
以常見的登錄界面為例
輸入：用戶名：郵箱或者手機號碼
輸入：密碼：6-16位的長度，區分大小寫，不能用空格
首先，我們先要知道接口測試用例的規則，與功能測試用例不同，不需要描述測試步驟。我們需要描述id（序號）、目標URL、username、password、協議狀態碼（可寫可不寫）、程序狀態碼（開發返回成功的狀態碼）、返回內容（例如success）、實際結果、執行狀態（自定義，例如0：失敗。1：成功）。根據如上內容，可以把這個整理成一個表中，如上字段作為表頭。按照正常數據和異常數據維護成Excel就可以。
數據異常：null、“”、特殊符號（&、*）
PS:紅色框圈住的針對執行SQL時數據截斷的情況。
select username，password from user where username = """ 中間的單引號將會截斷，拋出異常。
設計用例表頭時，將中文轉換成英文，方便程序做映射時處理,同時也方便寫入代碼中。
5.環境異常測試
前邊雖然說需要協調運維的小伙伴配合測試環境異常，但是在這里你可以提前考慮一下，什么事情都要向到前邊，未雨綢繆。不要等出事了臨時抱佛腳。
5.1簡單web架構集群
上圖是一個簡單的web部署架構。接口測試主要是前台傳遞參數，后台接口參數並處理返回期望的結果。簡單的描述一下上邊的架構：用戶通過web頁面發送請求到nginx，nginx接收到請求不作任何處理，將請求分發到后台的tomcat1、tomcat2、tomcat3服務器上。服務器處理請求后，將結果返回到web頁面，用戶看到結果。
這里分發是有規律的，不是一同亂分發，那樣還不得有的服務器先得沒事干，有的服務器累死了，分發原則：根據userid來進行區分。
例如：取余，當余數為0時，分發到1，當余數為1時，分發到2，到余數為2時，分發到3。
環境異常條件：tomcat2服務器掛掉了，專業點就是宕機了。假如此時有9個用戶，他們的userid分別是：1，2，3，4，5，6，7，8，9。此時恰好是1用戶把tomcat2給玩掛了。
5.2環境異常測試示例：
結合上圖：宏哥來描述一下，這個環境異常的場景，根據這個場景設計的測試用例。用戶1將服務器tomcat2玩掛機了，恰好此時用戶1又發出請求，所以此時用戶1的請求期望結果只能發送到tomcat1或者tomcat3上。服務器掛機以后運維團隊收到告警，快速修復tomcat2服務器（例如重啟），當下一次用戶4發送請求的時候，由於tomcat2正常所以預期結果還是正常環境了分發到tomcat2上。這里我們主要是觀察一下tomcat2是否可以正常加入到集群中。這些策略可以提前和運維的小伙伴定好了進行測試。
5.3如何確定分發到那台服務器
方法：通過日志查看有沒有分發到，例如：用戶1分發2上，即使訪問成功但是沒有日志，那么這就是一個bug，和我們之前定好的均衡策略有沖突。其他的都類似。
6.小結
好了，以上就是今天分享的知識，宏哥這里只是做了簡單的講解。希望大家喜歡。
您的肯定就是我進步的動力。如果你感覺還不錯，就請鼓勵一下吧！記得隨手點波 推薦 不要忘記哦！！！
別忘了點 推薦 留下您來過的痕跡
