小夥伴們大家好，上一次和大家分享了《服務端測試之接口測試初探》，講了一些接口測試的基本概念和理論知識。在上次的分享中，簡單提到了接口測試用例設計包含的幾個方面。本期我將在上次分享的基礎上，和各位小夥伴一起具體看看這幾個方面都是什麽，在實際的項目中應該如何使用。

一、功能性用例設計

之前講過，服務端的接口是和客戶端的功能相對應的，對功能的驗證，可以參照接口說明文檔來進行。概括起來講，就是我們需要驗證接口說明文檔中提到的各種情況，保證這些情況下接口的返回和最初設計的是一樣的，這樣我們就可以認為該接口實現了功能需求。

舉個例子，目前有一個接口A，關於該接口的請求參數列表如下：

可以看到，規定該接口的請求類型是get，同時該接口包含4個請求參數，那麽在功能性的用例設計上，我們可以考慮如下幾個方面：
1.以get方式請求；
2.請求中需要包含這4個參數；
3.各個參數的類型符合要求；
4.key參數的長度需要控制在10個字符以內。

通過這幾個方面寫出來的case就是功能性的測試用例了。其實不難看出，功能性測試用例的目的是為了驗證服務端在正常情況下是否實現了需求，因此構造出的用例都是滿足接口說明文檔的要求，即驗證在正常情況下，客戶端傳入正常的參數後，服務端可以正常響應。

二、業務邏輯用例設計

業務邏輯方面的用例設計與功能性用例設計不同，邏輯用例主要關註接口內的各種判斷對應的邏輯分支是否符合預期，這種用例不是針對某個具體的功能點，而是去驗證接口內部的各種處理邏輯。這類用例，往往需要以業務邏輯流程圖為依據進行設計。
舉個例子，在小編最近測試的項目中，畫出接口流程圖後有這樣的一個邏輯：

可以看到這一塊有兩個判斷，那麽 針對這一塊兒的處理邏輯，我們需要對不同的判斷分支都設計用例，以保證流程圖中涉及到的分支我們都有測試用例覆蓋。圖中涉及到的不同的分支有：
1.abdf；
2.acg;
3.abdeg;
相應的，我們的用例就應該是：
1.userInfo != null && value(userGroup) != 0;
2.userInfo == null;
3.userInfo != null && value(userGroup) == 0;
業務邏輯的用例設計主要是以服務端接口內部的邏輯流程圖為基礎，針對流程圖中的判斷和分支進行用例設計，保證服務端接口的每一種邏輯下都有測試用例覆蓋。

三、異常處理的情況

由於客戶端與服務端接口之間通常是通過HTTP請求來進行交互獲取數據，因此對於請求中攜帶的參數以及數據的容錯處理是必須考慮的一類case。關於異常處理我們可以歸為兩大類：參數異常和數據異常。具體而言常見的異常類型有以下幾種：缺省或增加參數、參數類型不對、參數為空、數據超過限制等等。我們還是用接口A的參數來舉例：

接口A的請求中一共有4個參數；那麽異常情況可以這樣去考慮：
1.多了一個/若幹個參數，比如請求中又攜帶了一個v=1這樣的參數；
2.缺省了某個參數，比如請求中不帶page參數；
3.參數類型不對，比如isMob規定是boolean類型，可以嘗試傳遞一個其他的類型；
4.數據為空，比如我們可以令key=(null)，發送請求後檢查服務端的響應；
5.數據超過限制，比如在接口文檔中規定key的長度不超過10個字符，那麽我們需要設計可以覆蓋到邊界值的用例，比如長度為9、10、11等。
……
值得註意的是，在功能均已實現的時候，對服務端而言容錯非常重要，如果容錯做得不好，往往可能一個格式不正確的參數就會引起服務端的異常甚至崩潰，因此在設計用例的時候，異常用例需要格外註意，需要盡可能多的設計出包含各種異常的用例，至少保證服務端在請求異常的情況下不會出現崩潰等極端狀況。

四、性能和安全性方面

在進行服務端測試的時候，性能和安全性方面的用例是必須要考慮的。服務端的性能測試往往與功能性測試分開執行，一般情況下在服務端的功能測試進行完畢保證功能上沒有問題的情況下，可以進行性能測試。性能測試借助於一些工具開展，比如LoadRunner等，關於性能測試，在後續的分享中我們會為大家詳細介紹。安全性方面，主要需要考慮一些常見的安全策略，舉個例子，在請求中需要攜帶用戶的敏感信息（比如電話號碼、身份證號碼、地址信息等）時，敏感信息一定是需要加密的，需要驗證對這些數據加密的生效性；又比如，在上面的接口A中，我們可以在參數中傳一段JS代碼，看服務端如何處理……

以上向大家介紹了服務端用例設計常見的幾個方面，希望可以給各位測試小夥伴在平時的用例設計中提供一點幫助。大家如果有什麽好的思想和方法，也可以進行留言互動。在以後的文章中，我們會繼續就服務端測試相關的思想、方法、工具使用以及流程規範等和大家共同探討，敬請大家持續關註。

服務端測試之接口測試用例設計