簡(jiǎn)介

接口測(cè)試在需求分析完成之后，即可設(shè)計(jì)對(duì)應(yīng)的接口測(cè)試用例，然后根據(jù)用例進(jìn)行接口測(cè)試。接口測(cè)試用例的設(shè)計(jì)也需要用到黑盒測(cè)試用例設(shè)計(jì)方法，和測(cè)試流程與理論章節(jié)的功能測(cè)試用例設(shè)計(jì)的方法類似，設(shè)計(jì)過程中還需要增加與接口特性相關(guān)的測(cè)試用例。

圖片

接口測(cè)試的質(zhì)量目標(biāo)

• 功能
• 性能
• 安全
• 兼容
• 健壯性
• 高可用性（中間件）

協(xié)議分析方法

• 網(wǎng)絡(luò)監(jiān)聽：

TcpDump

WireShark

• 代理 Proxy
• 推薦工具：手工測(cè)試 Charles [全平臺(tái)]、安全測(cè)試 BurpSuite [全平臺(tái) Java]
• 自動(dòng)化測(cè)試：mitmproxy
• 其他代理：Fiddler [僅 Windows]、AnyProxy [全平臺(tái)]

接口測(cè)試用例的設(shè)計(jì)方法

正式設(shè)計(jì)接口測(cè)試用例之前，需要梳理一下接口測(cè)試的思路：

圖片

基本功能流程測(cè)試

在基本功能流程測(cè)試方面，首先需要先執(zhí)行冒煙測(cè)試，把最基本的功能流程走通。冒煙測(cè)試決定提測(cè)是否成功，如果通過冒煙測(cè)試，才會(huì)進(jìn)入到詳細(xì)的測(cè)試階段。如果冒煙測(cè)試不通過，需要打回給開發(fā)，開發(fā)修改之后重新提測(cè)。冒煙測(cè)試通過之后，進(jìn)行正常流程覆蓋測(cè)試，粒度會(huì)比冒煙測(cè)試更細(xì)一些，覆蓋一些分支業(yè)務(wù)邏輯。

基于輸入域的測(cè)試

因?yàn)榘l(fā)出接口請(qǐng)求需要攜帶請(qǐng)求參數(shù)，所以肯定會(huì)涉及到關(guān)于請(qǐng)求參數(shù)的各種用例的設(shè)計(jì)。

關(guān)于請(qǐng)求參數(shù)的用例設(shè)計(jì)可以考慮下面這些方面

• 邊界值測(cè)試

對(duì)于有范圍要求的參數(shù)，需要綜合等價(jià)類和邊界值的方法設(shè)計(jì)測(cè)試用例。邊界值選擇上點(diǎn)和離點(diǎn)即可，要覆蓋到有效等價(jià)類和無效等價(jià)類。

• 特殊字符校驗(yàn)

對(duì)于很多請(qǐng)求參數(shù)會(huì)要求不能包含特殊字符，對(duì)于有這類要求的字段，需要單獨(dú)設(shè)計(jì)包含特殊字符的測(cè)試用例來做驗(yàn)證。

• 參數(shù)類型校驗(yàn)

有一些參數(shù)還會(huì)對(duì)于傳參值的類型有要求，比如只能包含英文數(shù)字，或者只能包含整數(shù)類型等。對(duì)于這種對(duì)類型有要求的字段，也要單獨(dú)設(shè)計(jì)測(cè)試用例，設(shè)計(jì)一些反向用例來做驗(yàn)證。

• 必選參數(shù)校驗(yàn)

在接口中有必填的參數(shù)，也有選填的參數(shù)。對(duì)于每一個(gè)必填參數(shù)，都要設(shè)計(jì)一條不傳的用例來驗(yàn)證必填性。

• 組合參數(shù)校驗(yàn)

對(duì)于有選填參數(shù)的接口來說，需要對(duì)于各種參數(shù)的不同組合場(chǎng)景進(jìn)行驗(yàn)證。比如只傳必填參數(shù)，或者必填參數(shù)和不同數(shù)量的選填參數(shù)做組合的場(chǎng)景，可以使用判定表的方法進(jìn)行設(shè)計(jì)。

• 排重邏輯

如果有的字段要求不能重復(fù)，那么需要對(duì)它進(jìn)行排重邏輯的覆蓋，看看重復(fù)請(qǐng)求相同的參數(shù)，服務(wù)端的處理邏輯是不是正確。

• 接口冪等性

冪等是指任意多次執(zhí)行所產(chǎn)生的影響均與一次執(zhí)行的影響相同。保證接口的冪等性是非常重要的，尤其是在涉及資金的系統(tǒng)，比如銀行、電商系統(tǒng)等。

例如用戶重復(fù)提交請(qǐng)求，或者網(wǎng)絡(luò)重發(fā)，系統(tǒng)重試等場(chǎng)景，都需要設(shè)計(jì)測(cè)試用例來保證接口的冪等性。接口的冪等測(cè)試，需要多次發(fā)送同一參數(shù)的請(qǐng)求，查看服務(wù)端響應(yīng)是否只有一次是成功的。

線程安全測(cè)試

線程安全測(cè)試包含了并發(fā)測(cè)試、分布式測(cè)試。分布式更多的一個(gè)概念，是為了解決單個(gè)物理服務(wù)器容量和性能瓶頸問題而采用的優(yōu)化手段。

分布式的實(shí)現(xiàn)有兩種形式：

• 水平擴(kuò)展：當(dāng)一臺(tái)機(jī)器扛不住流量時(shí)，就通過添加機(jī)器的方式，將流量平分到所有服務(wù)器上，所有機(jī)器都可以提供相當(dāng)?shù)姆?wù)。
• 垂直拆分：前端有多種查詢需求時(shí)，一臺(tái)機(jī)器扛不住，可以將不同的需求分發(fā)到不同的機(jī)器上。

相對(duì)于分布式來講，高并發(fā)在解決的問題上會(huì)集中一些，它的重點(diǎn)是測(cè)試同時(shí)有多少量，比如在線直播服務(wù)同時(shí)有上萬人觀看。

高并發(fā)可以通過分布式技術(shù)去解決，將并發(fā)流量分到不同的物理服務(wù)器上。但除此之外，還可以有很多其他優(yōu)化手段，比如使用緩存系統(tǒng)，還可以使用多線程技術(shù)將一臺(tái)服務(wù)器的服務(wù)能力最大化。

對(duì)于并發(fā)場(chǎng)景，需要測(cè)試多個(gè)相同參數(shù)的請(qǐng)求，只有一條請(qǐng)求成功，其他請(qǐng)求失敗。

對(duì)于分布式測(cè)試，則需要測(cè)試在分布式環(huán)境中并發(fā)相同參數(shù)的請(qǐng)求，只有一條請(qǐng)求成功，其他請(qǐng)求失敗。

故障注入

故障注入測(cè)試需要測(cè)試人員故意制造故障的場(chǎng)景，來保證系統(tǒng)的健壯性。

如果產(chǎn)品中用到了 Redis，就需要對(duì)于 Redis 做一些故障降級(jí)測(cè)試。Redis 一般會(huì)放在數(shù)據(jù)庫前面，用來做高速緩存。

Redis 故障注入需要開發(fā)配合清空 Redis 數(shù)據(jù)，發(fā)請(qǐng)求，擊穿 Redis，從 DB 中獲取正常的數(shù)據(jù)，并能回寫到 Redis 中。然后開發(fā)配合啟動(dòng) Redis 數(shù)據(jù)恢復(fù)功能，測(cè)試可以從 Redis 中獲取正確的數(shù)據(jù)。還需要開發(fā)配合制造 Redis 崩潰場(chǎng)景，發(fā)請(qǐng)求，測(cè)試是否降級(jí)從 DB 中獲取到正常的數(shù)據(jù)。

除了 Redis 之外，還需要進(jìn)行服務(wù)故障轉(zhuǎn)移測(cè)試。比如數(shù)據(jù)庫故障測(cè)試與接口故障測(cè)試。

• 數(shù)據(jù)庫故障測(cè)試

開發(fā)配合制造數(shù)據(jù)庫數(shù)據(jù)丟失場(chǎng)景，啟動(dòng)數(shù)據(jù)恢復(fù)策略，測(cè)試規(guī)定時(shí)間段內(nèi)數(shù)據(jù)是否可以恢復(fù)；開發(fā)配合制造數(shù)據(jù)庫崩潰場(chǎng)景，測(cè)試數(shù)據(jù)庫多活策略是否啟動(dòng)，保證功能不受影響。

• 接口故障測(cè)試

開發(fā)配合接口服務(wù)重啟，測(cè)試集群負(fù)載是否自動(dòng)重啟實(shí)例，所有請(qǐng)求無異常；開發(fā)配合制造集群崩潰場(chǎng)景，測(cè)試是否返回對(duì)應(yīng)的錯(cuò)誤信息，內(nèi)部服務(wù)是否有重試機(jī)制。

接口測(cè)試用例要素

• 模塊
• 測(cè)試標(biāo)題
• 優(yōu)先級(jí)
• 前置條件
• 請(qǐng)求方法
• 請(qǐng)求參數(shù)
• 預(yù)期結(jié)果
• 實(shí)際結(jié)果

圖片

總結(jié)

• 接口測(cè)試的質(zhì)量目標(biāo)
• 協(xié)議分析方法
• 接口測(cè)試用例設(shè)計(jì)思路
• 接口測(cè)試用例要素