本文章轉(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ù)端的接口是和客戶(hù)端的功能相對(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)求類(lèi)型是get肋联，同時(shí)該接口包含4個(gè)請(qǐng)求參數(shù)，那么在功能性的用例設(shè)計(jì)上镀脂，我們可以考慮如下幾個(gè)方面：
1.以get方式請(qǐng)求牺蹄；
2.請(qǐng)求中需要包含這4個(gè)參數(shù)；
3.各個(gè)參數(shù)的類(lèi)型符合要求薄翅；
4.key參數(shù)的長(zhǎng)度需要控制在10個(gè)字符以?xún)?nèi)沙兰。
通過(guò)這幾個(gè)方面寫(xiě)出來(lái)的case就是功能性的測(cè)試用例了。其實(shí)不難看出翘魄，功能性測(cè)試用例的目的是為了驗(yàn)證服務(wù)端在正常情況下是否實(shí)現(xiàn)了需求鼎天，因此構(gòu)造出的用例都是滿(mǎn)足接口說(shuō)明文檔的要求，即驗(yàn)證在正常情況下暑竟，客戶(hù)端傳入正常的參數(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)部的各種處理邏輯桑包。這類(lèi)用例，往往需要以業(yè)務(wù)邏輯流程圖為依據(jù)進(jìn)行設(shè)計(jì)纺非。
舉個(gè)例子哑了，在小編最近測(cè)試的項(xiàng)目中赘方，畫(huà)出接口流程圖后有這樣的一個(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è)試用例覆蓋优妙。
三、異常處理的情況
由于客戶(hù)端與服務(wù)端接口之間通常是通過(guò)HTTP請(qǐng)求來(lái)進(jìn)行交互獲取數(shù)據(jù)憎账，因此對(duì)于請(qǐng)求中攜帶的參數(shù)以及數(shù)據(jù)的容錯(cuò)處理是必須考慮的一類(lèi)case套硼。關(guān)于異常處理我們可以歸為兩大類(lèi)：參數(shù)異常和數(shù)據(jù)異常。具體而言常見(jiàn)的異常類(lèi)型有以下幾種：缺省或增加參數(shù)胞皱、參數(shù)類(lèi)型不對(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ù)類(lèi)型不對(duì)酒贬，比如isMob規(guī)定是boolean類(lèi)型又憨，可以嘗試傳遞一個(gè)其他的類(lèi)型；
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è)試分開(kāi)執(zhí)行牡辽，一般情況下在服務(wù)端的功能測(cè)試進(jìn)行完畢保證功能上沒(méi)有問(wèn)題的情況下喳篇，可以進(jìn)行性能測(cè)試。性能測(cè)試借助于一些工具開(kāi)展态辛，比如LoadRunner等麸澜，關(guān)于性能測(cè)試，在后續(xù)的分享中我們會(huì)為大家詳細(xì)介紹奏黑。安全性方面炊邦，主要需要考慮一些常見(jiàn)的安全策略，舉個(gè)例子熟史，在請(qǐng)求中需要攜帶用戶(hù)的敏感信息（比如電話號(hào)碼馁害、身份證號(hào)碼、地址信息等）時(shí)蹂匹，敏感信息一定是需要加密的碘菜，需要驗(yàn)證對(duì)這些數(shù)據(jù)加密的生效性；又比如限寞，在上面的接口A中忍啸，我們可以在參數(shù)中傳一段JS代碼，看服務(wù)端如何處理……
