本文章轉(zhuǎn)載于搜狗測(cè)試
小伙伴們大家好，上一次和大家分享了《服務(wù)端測(cè)試之接口測(cè)試初探》，講了一些接口測(cè)試的基本概念和理論知識(shí)。在上次的分享中，簡(jiǎn)單提到了接口測(cè)試用例設(shè)計(jì)包含的幾個(gè)方面。本期我將在上次分享的基礎(chǔ)上，和各位小伙伴一起具體看看這幾個(gè)方面都是什么，在實(shí)際的項(xiàng)目中應(yīng)該如何使用。
一、功能性用例設(shè)計(jì)
之前講過(guò)，服務(wù)端的接口是和客戶端的功能相對(duì)應(yīng)的，對(duì)功能的驗(yàn)證，可以參照接口說(shuō)明文檔來(lái)進(jìn)行。概括起來(lái)講，就是我們需要驗(yàn)證接口說(shuō)明文檔中提到的各種情況，保證這些情況下接口的返回和最初設(shè)計(jì)的是一樣的，這樣我們就可以認(rèn)為該接口實(shí)現(xiàn)了功能需求。
舉個(gè)例子，目前有一個(gè)接口A，關(guān)于該接口的請(qǐng)求參數(shù)列表如下：
可以看到，規(guī)定該接口的請(qǐng)求類型是get，同時(shí)該接口包含4個(gè)請(qǐng)求參數(shù)，那么在功能性的用例設(shè)計(jì)上，我們可以考慮如下幾個(gè)方面：
1.以get方式請(qǐng)求；
2.請(qǐng)求中需要包含這4個(gè)參數(shù)；
3.各個(gè)參數(shù)的類型符合要求；
4.key參數(shù)的長(zhǎng)度需要控制在10個(gè)字符以內(nèi)。
通過(guò)這幾個(gè)方面寫出來(lái)的case就是功能性的測(cè)試用例了。其實(shí)不難看出，功能性測(cè)試用例的目的是為了驗(yàn)證服務(wù)端在正常情況下是否實(shí)現(xiàn)了需求，因此構(gòu)造出的用例都是滿足接口說(shuō)明文檔的要求，即驗(yàn)證在正常情況下，客戶端傳入正常的參數(shù)后，服務(wù)端可以正常響應(yīng)。
二、業(yè)務(wù)邏輯用例設(shè)計(jì)
業(yè)務(wù)邏輯方面的用例設(shè)計(jì)與功能性用例設(shè)計(jì)不同，邏輯用例主要關(guān)注接口內(nèi)的各種判斷對(duì)應(yīng)的邏輯分支是否符合預(yù)期，這種用例不是針對(duì)某個(gè)具體的功能點(diǎn)，而是去驗(yàn)證接口內(nèi)部的各種處理邏輯。這類用例，往往需要以業(yè)務(wù)邏輯流程圖為依據(jù)進(jìn)行設(shè)計(jì)。
舉個(gè)例子，在小編最近測(cè)試的項(xiàng)目中，畫出接口流程圖后有這樣的一個(gè)邏輯：
可以看到這一塊有兩個(gè)判斷，那么 針對(duì)這一塊兒的處理邏輯，我們需要對(duì)不同的判斷分支都設(shè)計(jì)用例，以保證流程圖中涉及到的分支我們都有測(cè)試用例覆蓋。圖中涉及到的不同的分支有：
1.abdf；
2.acg;
3.abdeg;
相應(yīng)的，我們的用例就應(yīng)該是：
1.userInfo != null && value(userGroup) != 0;
2.userInfo == null;
3.userInfo != null && value(userGroup) == 0;
業(yè)務(wù)邏輯的用例設(shè)計(jì)主要是以服務(wù)端接口內(nèi)部的邏輯流程圖為基礎(chǔ)，針對(duì)流程圖中的判斷和分支進(jìn)行用例設(shè)計(jì)，保證服務(wù)端接口的每一種邏輯下都有測(cè)試用例覆蓋。
三、異常處理的情況
由于客戶端與服務(wù)端接口之間通常是通過(guò)HTTP請(qǐng)求來(lái)進(jìn)行交互獲取數(shù)據(jù)，因此對(duì)于請(qǐng)求中攜帶的參數(shù)以及數(shù)據(jù)的容錯(cuò)處理是必須考慮的一類case。關(guān)于異常處理我們可以歸為兩大類：參數(shù)異常和數(shù)據(jù)異常。具體而言常見(jiàn)的異常類型有以下幾種：缺省或增加參數(shù)、參數(shù)類型不對(duì)、參數(shù)為空、數(shù)據(jù)超過(guò)限制等等。我們還是用接口A的參數(shù)來(lái)舉例：
接口A的請(qǐng)求中一共有4個(gè)參數(shù)；那么異常情況可以這樣去考慮：
1.多了一個(gè)/若干個(gè)參數(shù)，比如請(qǐng)求中又?jǐn)y帶了一個(gè)v=1這樣的參數(shù)；
2.缺省了某個(gè)參數(shù)，比如請(qǐng)求中不帶page參數(shù)；
3.參數(shù)類型不對(duì)，比如isMob規(guī)定是boolean類型，可以嘗試傳遞一個(gè)其他的類型；
4.數(shù)據(jù)為空，比如我們可以令key=(null)，發(fā)送請(qǐng)求后檢查服務(wù)端的響應(yīng)；
5.數(shù)據(jù)超過(guò)限制，比如在接口文檔中規(guī)定key的長(zhǎng)度不超過(guò)10個(gè)字符，那么我們需要設(shè)計(jì)可以覆蓋到邊界值的用例，比如長(zhǎng)度為9、10、11等。
……
值得注意的是，在功能均已實(shí)現(xiàn)的時(shí)候，對(duì)服務(wù)端而言容錯(cuò)非常重要，如果容錯(cuò)做得不好，往往可能一個(gè)格式不正確的參數(shù)就會(huì)引起服務(wù)端的異常甚至崩潰，因此在設(shè)計(jì)用例的時(shí)候，異常用例需要格外注意，需要盡可能多的設(shè)計(jì)出包含各種異常的用例，至少保證服務(wù)端在請(qǐng)求異常的情況下不會(huì)出現(xiàn)崩潰等極端狀況。
四、性能和安全性方面
在進(jìn)行服務(wù)端測(cè)試的時(shí)候，性能和安全性方面的用例是必須要考慮的。服務(wù)端的性能測(cè)試往往與功能性測(cè)試分開執(zhí)行，一般情況下在服務(wù)端的功能測(cè)試進(jìn)行完畢保證功能上沒(méi)有問(wèn)題的情況下，可以進(jìn)行性能測(cè)試。性能測(cè)試借助于一些工具開展，比如LoadRunner等，關(guān)于性能測(cè)試，在后續(xù)的分享中我們會(huì)為大家詳細(xì)介紹。安全性方面，主要需要考慮一些常見(jiàn)的安全策略，舉個(gè)例子，在請(qǐng)求中需要攜帶用戶的敏感信息（比如電話號(hào)碼、身份證號(hào)碼、地址信息等）時(shí)，敏感信息一定是需要加密的，需要驗(yàn)證對(duì)這些數(shù)據(jù)加密的生效性；又比如，在上面的接口A中，我們可以在參數(shù)中傳一段JS代碼，看服務(wù)端如何處理……
