共計(jì) 2503 個(gè)字符，預(yù)計(jì)需要花費(fèi) 7 分鐘才能閱讀完成。

本文丸趣 TV 小編為大家詳細(xì)介紹“spring 怎么編寫有效的接口測試”，內(nèi)容詳細(xì)，步驟清晰，細(xì)節(jié)處理妥當(dāng)，希望這篇“spring 怎么編寫有效的接口測試”文章能幫助大家解決疑惑，下面跟著丸趣 TV 小編的思路慢慢深入，一起來學(xué)習(xí)新知識(shí)吧。

一 測試分層

測試也是分層的，如下圖所示：

在一個(gè)系統(tǒng)內(nèi)，自動(dòng)化測試一般分單元測試、模塊測試和接口測試。

單元測試

目前我的應(yīng)用代碼基本都是基于 spring 框架面向接口這種編程模式，單元測試已被弱化。單元測試的要求基本上是單個(gè)類單個(gè)方法的測試，在我們當(dāng)前模式下，編寫成本太高。當(dāng)然，如果是一個(gè)工具或者一段比較內(nèi)聚而又復(fù)雜的邏輯 (例如算法邏輯)，還是應(yīng)該使用單元測試來保障邏輯的正確性。

模塊測試

在系統(tǒng)比較大、模塊比較多的情況下，可以建立模塊測試層，保障各模塊功能的正確性。不過當(dāng)前的系統(tǒng)發(fā)展趨勢是微服務(wù)架構(gòu)，因此模塊測試層并非十分必要，可以通過接口測試層來覆蓋。

接口測試

個(gè)人覺得準(zhǔn)確來說應(yīng)該叫入口測試，這一層，是從系統(tǒng)入口出發(fā)進(jìn)行集成測試。應(yīng)用入口通常是 HSF（一個(gè)分布式 RPC 服務(wù)框架）服務(wù)，消息，定時(shí)任務(wù)。

作為開發(fā)，測試手段千萬條，接口測試不可少。在我們應(yīng)用的接口測試有效且覆蓋完整的情況下，不僅能保障我們新功能的開發(fā)質(zhì)量，還能讓我們在修改功能邏輯的時(shí)候有回歸的能力，同時(shí)這也是我們做代碼重構(gòu)的前提。同時(shí)，易測性也是代碼結(jié)構(gòu)合理的一個(gè)指標(biāo)，如果發(fā)現(xiàn)一段代碼編寫測試腳本困難或者無法測試，那就說明當(dāng)前代碼結(jié)構(gòu)不合理需要重構(gòu)。接下來，我將主要談一談接口測試的有效性。

二 測試原則

基礎(chǔ)原則：

自動(dòng)化：接口測試是非交互式的自動(dòng)化執(zhí)行，不需要人參與。

獨(dú)立性：接口測試之間不應(yīng)該相互依賴。

可重復(fù)：接口測試可重復(fù)執(zhí)行，不受環(huán)境影響。

接口測試遵守 BCDE 原則，保障接口交付質(zhì)量。Border：邊界測試。Correct：正確的輸入，正確的預(yù)期輸出。Design：按照需求和設(shè)計(jì)文檔編寫測試邏輯。Error：錯(cuò)誤輸入，預(yù)期輸出。

數(shù)據(jù)準(zhǔn)備：數(shù)據(jù)準(zhǔn)備通過系統(tǒng)服務(wù)進(jìn)行，不能通過直接插入 db 方式。

可測性：對(duì)于不可測的代碼需要進(jìn)行重構(gòu)成合理的結(jié)構(gòu)。

覆蓋性：接口測試需要覆蓋所有 UC，同時(shí)代碼覆蓋率和分支覆蓋率應(yīng)達(dá)到一定標(biāo)準(zhǔn)，新增代碼必須被覆蓋。

持續(xù)性：如果代碼修改導(dǎo)致已有接口測試執(zhí)行失敗，必須修復(fù)代碼問題或者測試代碼邏輯。

時(shí)間要求：接口測試應(yīng)該在項(xiàng)目發(fā)布之前完成，不應(yīng)放到項(xiàng)目發(fā)布之后補(bǔ)充。

以上的基本原則應(yīng)適用于所有層的自動(dòng)化測試用例，在編寫接口測試時(shí)，除了上面這些原則，還有其他原則需要遵守，先看一張圖：

從系統(tǒng)角度來分析入口調(diào)用，以 HSF 服務(wù)為例：

外圍系統(tǒng)調(diào)用由我們系統(tǒng)提供的服務(wù)。

系統(tǒng)執(zhí)行了一堆代碼邏輯，其中包含有分支邏輯。

系統(tǒng)執(zhí)行過程中依賴外部 HSF 服務(wù)，進(jìn)行了調(diào)用，并得到了返回值。

系統(tǒng)執(zhí)行過程中依賴 DB 查詢或者落地了數(shù)據(jù)，依賴緩存查詢或者落地了數(shù)據(jù)。

系統(tǒng)執(zhí)行過程中對(duì)外發(fā)送了消息。

給上游系統(tǒng)返回 HSF 執(zhí)行結(jié)果。

有效接口測試的關(guān)鍵原則是要覆蓋所有入口，mock 所有依賴，校驗(yàn)執(zhí)行過程中所留下的痕跡，總結(jié)如下：

入口覆蓋：接口測試用例必須覆蓋 HSF 服務(wù)入口、消息入口、定時(shí)任務(wù)入口。

依賴 mock：在基本原則中，有可重復(fù)這個(gè)原則，即接口測試不能受環(huán)境依賴，需要 mock 掉對(duì)外依賴。但對(duì)于 db 依賴，不建議完全 mock 掉，一方面 mock 成本高，另外可能覆蓋不到 sql 和表約束邏輯。

校驗(yàn)完整：有效的接口測試，應(yīng)該具備完整的校驗(yàn)，沒有校驗(yàn)的接口測試是沒有意義的。只要執(zhí)行過程中，留下的痕跡對(duì)業(yè)務(wù)有影響，都要進(jìn)行完整校驗(yàn)，方能保障接口測試的有效性。HSF 接口返回值校驗(yàn)：按照?qǐng)鼍昂徒涌诩s定進(jìn)行 HSF 返回參數(shù)校驗(yàn)。DB 校驗(yàn)：校驗(yàn)落地?cái)?shù)據(jù)的正確性。緩存校驗(yàn)：校驗(yàn)存入緩存中數(shù)據(jù)的正確性。HSF 依賴入?yún)⑿ｒ?yàn)：通過 mock 工具獲得依賴 HSF 調(diào)用的入?yún)ⅲM(jìn)行入?yún)⑿ｒ?yàn)。消息校驗(yàn)：通過 mock 工具獲得發(fā)送的消息對(duì)象，進(jìn)行消息體校驗(yàn)。

三 測試代碼結(jié)構(gòu)

在編寫測試代碼的時(shí)候，也應(yīng)跟寫業(yè)務(wù)代碼一樣，考慮代碼的可讀、可擴(kuò)展、可復(fù)用性。同時(shí)也可以根據(jù)系統(tǒng)的業(yè)務(wù)特性，在測試框架的基礎(chǔ)上封裝適合當(dāng)前系統(tǒng)的測試組件，提高測試代碼編寫效率，規(guī)范測試代碼結(jié)構(gòu)。

一個(gè)接口的測試代碼，大概的結(jié)構(gòu)如下：

1 測試準(zhǔn)備

依賴數(shù)據(jù)準(zhǔn)備

很多時(shí)候，我們的測試有數(shù)據(jù)依賴，可能是配置數(shù)據(jù)，也有可能是業(yè)務(wù)數(shù)據(jù) (例如退款需要依賴支付數(shù)據(jù))。

配置數(shù)據(jù)：可以通過定義配置文件來初始化配置。

業(yè)務(wù)數(shù)據(jù)：這類數(shù)據(jù)，禁止通過直接插入數(shù)據(jù)方式產(chǎn)生，而是應(yīng)通過調(diào)用業(yè)務(wù)服務(wù)產(chǎn)生。

依賴 mock

對(duì)于外部依賴，需要對(duì)被依賴的服務(wù)進(jìn)行 mock，避免真實(shí)調(diào)用。

接口測試入?yún)?zhǔn)備

準(zhǔn)備接口方面的入?yún)ⅰ?/p>

2 測試執(zhí)行

調(diào)用接口方法，執(zhí)行業(yè)務(wù)邏輯。

3 測試校驗(yàn)

返回參數(shù)校驗(yàn)：校驗(yàn)接口的返回參數(shù)。

DB：校驗(yàn) DB 落地?cái)?shù)據(jù)。

緩存數(shù)據(jù)校驗(yàn)：校驗(yàn)落地到緩存中的數(shù)據(jù)。

消息校驗(yàn)：校驗(yàn)對(duì)外發(fā)送的消息對(duì)象。

對(duì)外 HSF 調(diào)用校驗(yàn)：校驗(yàn)對(duì)外 HSF 調(diào)用的入?yún)ⅰ?/p>

四 實(shí)踐技巧

1 執(zhí)行效率

對(duì)于接口測試，執(zhí)行效率是不得不關(guān)注的一個(gè)點(diǎn)，若一個(gè)接口測試執(zhí)行 3 分鐘以上才能看到結(jié)果，會(huì)大大降低開發(fā)同學(xué)編寫接口測試的熱情。對(duì)于測試執(zhí)行效率提高，建議的方案為：

最小化啟動(dòng)測試上下文，例如 spring boot 的應(yīng)用，啟動(dòng) spring 就可以了

使用內(nèi)存數(shù)據(jù)庫，例如 h3

將中間件依賴 mock 掉

2 測試框架選擇

對(duì)于測試框架，建議選擇基于 testng，能夠提供通過配置文件做數(shù)據(jù)準(zhǔn)備的測試框架。如果找不到合適的，可以自己基于 testng 進(jìn)行封裝。

3 接口測試覆蓋度

場景的完整性影響著測試用例的覆蓋度，一方面需要開發(fā)同學(xué)基于業(yè)務(wù)場景的輸入和測試經(jīng)驗(yàn)枚舉出正常和異常情況，另一方面接口方法也有一些固定需要測試的點(diǎn)，例如冪等測試，邊界值測試，參數(shù)不正確測試等等。

同時(shí)也要通過覆蓋率工具查看接口未覆蓋的代碼或分支邏輯，進(jìn)行針對(duì)性的場景覆蓋測試。根據(jù)我的經(jīng)驗(yàn)，分支完整覆蓋非常重要，特別是異常的分支。

讀到這里，這篇“spring 怎么編寫有效的接口測試”文章已經(jīng)介紹完畢，想要掌握這篇文章的知識(shí)點(diǎn)還需要大家自己動(dòng)手實(shí)踐使用過才能領(lǐng)會(huì)，如果想了解更多相關(guān)內(nèi)容的文章，歡迎關(guān)注丸趣 TV 行業(yè)資訊頻道。