建站
咨詢
售后
建站咨詢
新聞中心
在所有的開(kāi)發(fā)測(cè)試中，接口測(cè)試是必不可少的一項(xiàng)。有效且覆蓋完整的接口測(cè)試，不僅能保障新功能的開(kāi)發(fā)質(zhì)量，還能讓開(kāi)發(fā)在修改功能邏輯的時(shí)候有回歸的能力，同時(shí)也是能優(yōu)雅地進(jìn)行重構(gòu)的前提。編寫(xiě)接口測(cè)試要遵守哪些原則?測(cè)試代碼的結(jié)構(gòu)應(yīng)該是什么樣的?接口測(cè)試有哪些實(shí)踐技巧?本文分享作者在接口測(cè)試上的實(shí)踐總結(jié)。
網(wǎng)站建設(shè)哪家好，找成都創(chuàng)新互聯(lián)公司！專注于網(wǎng)頁(yè)設(shè)計(jì)、網(wǎng)站建設(shè)、微信開(kāi)發(fā)、重慶小程序開(kāi)發(fā)公司、集團(tuán)企業(yè)網(wǎng)站建設(shè)等服務(wù)項(xiàng)目。為回饋新老客戶創(chuàng)新互聯(lián)還提供了銅鼓免費(fèi)建站歡迎大家使用！
一線開(kāi)發(fā)同學(xué)，可能都或多或少地造成過(guò)線上bug甚至故障;也會(huì)遇到這樣的場(chǎng)景，某同學(xué)在開(kāi)發(fā)某功能的時(shí)候重構(gòu)了代碼，造成了線上bug或者故障;在開(kāi)發(fā)某個(gè)功能時(shí)，發(fā)現(xiàn)需要修改公共邏輯，害怕影響到其他功能，非常不雅觀地拷貝代碼，重新寫(xiě)套單獨(dú)邏輯來(lái)支持。
上面這些情況，都包含了一個(gè)關(guān)鍵的問(wèn)題，無(wú)論是功能開(kāi)發(fā)還是邏輯重構(gòu)，如何來(lái)保障代碼開(kāi)發(fā)的質(zhì)量。保障的手段，每個(gè)人都知道，就是測(cè)試。首先是新功能測(cè)試，保障新功能邏輯正確;其次是回歸測(cè)試，保障原有業(yè)務(wù)功能邏輯正確。測(cè)試的方式，一般是兩種，人工測(cè)試和自動(dòng)化測(cè)試。隨著測(cè)試技術(shù)和工具的持續(xù)發(fā)展，人工測(cè)試比例逐步降低，被自動(dòng)化測(cè)試逐步替代。自動(dòng)化測(cè)試是可持續(xù)和可重復(fù)的，甚至是可AI化的。
一 測(cè)試分層
測(cè)試也是分層的，如下圖所示：
在一個(gè)系統(tǒng)內(nèi)，自動(dòng)化測(cè)試一般分單元測(cè)試、模塊測(cè)試和接口測(cè)試。
單元測(cè)試
目前我的應(yīng)用代碼基本都是基于spring框架面向接口這種編程模式，單元測(cè)試已被弱化。單元測(cè)試的要求基本上是單個(gè)類單個(gè)方法的測(cè)試，在我們當(dāng)前模式下，編寫(xiě)成本太高。當(dāng)然，如果是一個(gè)工具或者一段比較內(nèi)聚而又復(fù)雜的邏輯(例如算法邏輯)，還是應(yīng)該使用單元測(cè)試來(lái)保障邏輯的正確性。
模塊測(cè)試
在系統(tǒng)比較大、模塊比較多的情況下，可以建立模塊測(cè)試層，保障各模塊功能的正確性。不過(guò)當(dāng)前的系統(tǒng)發(fā)展趨勢(shì)是微服務(wù)架構(gòu)，因此模塊測(cè)試層并非十分必要，可以通過(guò)接口測(cè)試層來(lái)覆蓋。
接口測(cè)試
個(gè)人覺(jué)得準(zhǔn)確來(lái)說(shuō)應(yīng)該叫入口測(cè)試，這一層，是從系統(tǒng)入口出發(fā)進(jìn)行集成測(cè)試。應(yīng)用入口通常是HSF(一個(gè)分布式RPC服務(wù)框架)服務(wù)，消息，定時(shí)任務(wù)。
作為開(kāi)發(fā)，測(cè)試手段千萬(wàn)條，接口測(cè)試不可少。在我們應(yīng)用的接口測(cè)試有效且覆蓋完整的情況下，不僅能保障我們新功能的開(kāi)發(fā)質(zhì)量，還能讓我們?cè)谛薷墓δ苓壿嫷臅r(shí)候有回歸的能力，同時(shí)這也是我們做代碼重構(gòu)的前提。同時(shí)，易測(cè)性也是代碼結(jié)構(gòu)合理的一個(gè)指標(biāo)，如果發(fā)現(xiàn)一段代碼編寫(xiě)測(cè)試腳本困難或者無(wú)法測(cè)試，那就說(shuō)明當(dāng)前代碼結(jié)構(gòu)不合理需要重構(gòu)。接下來(lái)，我將主要談一談接口測(cè)試的有效性。
二 測(cè)試原則
基礎(chǔ)原則：
- 自動(dòng)化：接口測(cè)試是非交互式的自動(dòng)化執(zhí)行，不需要人參與。
- 獨(dú)立性：接口測(cè)試之間不應(yīng)該相互依賴。
- 可重復(fù)：接口測(cè)試可重復(fù)執(zhí)行，不受環(huán)境影響。
- 接口測(cè)試遵守BCDE原則，保障接口交付質(zhì)量。
- Border：邊界測(cè)試。
- Correct：正確的輸入，正確的預(yù)期輸出。
- Design：按照需求和設(shè)計(jì)文檔編寫(xiě)測(cè)試邏輯。
- Error：錯(cuò)誤輸入，預(yù)期輸出。
- 數(shù)據(jù)準(zhǔn)備：數(shù)據(jù)準(zhǔn)備通過(guò)系統(tǒng)服務(wù)進(jìn)行，不能通過(guò)直接插入db方式。
- 可測(cè)性：對(duì)于不可測(cè)的代碼需要進(jìn)行重構(gòu)成合理的結(jié)構(gòu)。
- 覆蓋性：接口測(cè)試需要覆蓋所有UC，同時(shí)代碼覆蓋率和分支覆蓋率應(yīng)達(dá)到一定標(biāo)準(zhǔn)，新增代碼必須被覆蓋。
- 持續(xù)性：如果代碼修改導(dǎo)致已有接口測(cè)試執(zhí)行失敗，必須修復(fù)代碼問(wèn)題或者測(cè)試代碼邏輯。
- 時(shí)間要求：接口測(cè)試應(yīng)該在項(xiàng)目發(fā)布之前完成，不應(yīng)放到項(xiàng)目發(fā)布之后補(bǔ)充。
以上的基本原則應(yīng)適用于所有層的自動(dòng)化測(cè)試用例，在編寫(xiě)接口測(cè)試時(shí)，除了上面這些原則，還有其他原則需要遵守，先看一張圖：
從系統(tǒng)角度來(lái)分析入口調(diào)用，以HSF服務(wù)為例：
- 外圍系統(tǒng)調(diào)用由我們系統(tǒng)提供的服務(wù)。
- 系統(tǒng)執(zhí)行了一堆代碼邏輯，其中包含有分支邏輯。
- 系統(tǒng)執(zhí)行過(guò)程中依賴外部HSF服務(wù)，進(jìn)行了調(diào)用，并得到了返回值。
- 系統(tǒng)執(zhí)行過(guò)程中依賴DB查詢或者落地了數(shù)據(jù)，依賴緩存查詢或者落地了數(shù)據(jù)。
- 系統(tǒng)執(zhí)行過(guò)程中對(duì)外發(fā)送了消息。
- 給上游系統(tǒng)返回HSF執(zhí)行結(jié)果。
有效接口測(cè)試的關(guān)鍵原則是要覆蓋所有入口，mock所有依賴，校驗(yàn)執(zhí)行過(guò)程中所留下的痕跡，總結(jié)如下：
- 入口覆蓋：接口測(cè)試用例必須覆蓋HSF服務(wù)入口、消息入口、定時(shí)任務(wù)入口。
- 依賴mock：在基本原則中，有可重復(fù)這個(gè)原則，即接口測(cè)試不能受環(huán)境依賴，需要mock掉對(duì)外依賴。但對(duì)于db依賴，不建議完全mock掉，一方面mock成本高，另外可能覆蓋不到sql和表約束邏輯。
- 校驗(yàn)完整：有效的接口測(cè)試，應(yīng)該具備完整的校驗(yàn)，沒(méi)有校驗(yàn)的接口測(cè)試是沒(méi)有意義的。只要執(zhí)行過(guò)程中，留下的痕跡對(duì)業(yè)務(wù)有影響，都要進(jìn)行完整校驗(yàn)，方能保障接口測(cè)試的有效性。
- 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)：通過(guò)mock工具獲得依賴HSF調(diào)用的入?yún)?，進(jìn)行入?yún)⑿ｒ?yàn)。
- 消息校驗(yàn)：通過(guò)mock工具獲得發(fā)送的消息對(duì)象，進(jìn)行消息體校驗(yàn)。
三 測(cè)試代碼結(jié)構(gòu)
在編寫(xiě)測(cè)試代碼的時(shí)候，也應(yīng)跟寫(xiě)業(yè)務(wù)代碼一樣，考慮代碼的可讀、可擴(kuò)展、可復(fù)用性。同時(shí)也可以根據(jù)系統(tǒng)的業(yè)務(wù)特性，在測(cè)試框架的基礎(chǔ)上封裝適合當(dāng)前系統(tǒng)的測(cè)試組件，提高測(cè)試代碼編寫(xiě)效率，規(guī)范測(cè)試代碼結(jié)構(gòu)。
一個(gè)接口的測(cè)試代碼，大概的結(jié)構(gòu)如下：
1 測(cè)試準(zhǔn)備
依賴數(shù)據(jù)準(zhǔn)備
很多時(shí)候，我們的測(cè)試有數(shù)據(jù)依賴，可能是配置數(shù)據(jù)，也有可能是業(yè)務(wù)數(shù)據(jù)(例如退款需要依賴支付數(shù)據(jù))。
- 配置數(shù)據(jù)：可以通過(guò)定義配置文件來(lái)初始化配置。
- 業(yè)務(wù)數(shù)據(jù)：這類數(shù)據(jù)，禁止通過(guò)直接插入數(shù)據(jù)方式產(chǎn)生，而是應(yīng)通過(guò)調(diào)用業(yè)務(wù)服務(wù)產(chǎn)生。
依賴mock
對(duì)于外部依賴，需要對(duì)被依賴的服務(wù)進(jìn)行mock，避免真實(shí)調(diào)用。
接口測(cè)試入?yún)?zhǔn)備
準(zhǔn)備接口方面的入?yún)ⅰ?/p>
2 測(cè)試執(zhí)行
調(diào)用接口方法，執(zhí)行業(yè)務(wù)邏輯。
3 測(cè)試校驗(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)ⅰ?/li>
四 實(shí)踐技巧
1 執(zhí)行效率
對(duì)于接口測(cè)試，執(zhí)行效率是不得不關(guān)注的一個(gè)點(diǎn)，若一個(gè)接口測(cè)試執(zhí)行3分鐘以上才能看到結(jié)果，會(huì)大大降低開(kāi)發(fā)同學(xué)編寫(xiě)接口測(cè)試的熱情。對(duì)于測(cè)試執(zhí)行效率提高，建議的方案為：
- 最小化啟動(dòng)測(cè)試上下文，例如spring boot的應(yīng)用，啟動(dòng)spring就可以了
- 使用內(nèi)存數(shù)據(jù)庫(kù)，例如h2
- 將中間件依賴mock掉
2 測(cè)試框架選擇
對(duì)于測(cè)試框架，建議選擇基于testng，能夠提供通過(guò)配置文件做數(shù)據(jù)準(zhǔn)備的測(cè)試框架。如果找不到合適的，可以自己基于testng進(jìn)行封裝。
3 接口測(cè)試覆蓋度
場(chǎng)景的完整性影響著測(cè)試用例的覆蓋度，一方面需要開(kāi)發(fā)同學(xué)基于業(yè)務(wù)場(chǎng)景的輸入和測(cè)試經(jīng)驗(yàn)枚舉出正常和異常情況，另一方面接口方法也有一些固定需要測(cè)試的點(diǎn)，例如冪等測(cè)試，邊界值測(cè)試，參數(shù)不正確測(cè)試等等。
同時(shí)也要通過(guò)覆蓋率工具查看接口未覆蓋的代碼或分支邏輯，進(jìn)行針對(duì)性的場(chǎng)景覆蓋測(cè)試。根據(jù)我的經(jīng)驗(yàn)，分支完整覆蓋非常重要，特別是異常的分支。
五 總結(jié)
要保障系統(tǒng)線上運(yùn)行穩(wěn)定，質(zhì)量保障手段必不可少。雖然現(xiàn)在有很多自動(dòng)化的保障手段，但接口測(cè)試依然是最基本的和最重要的保障手段之一。如能做到持續(xù)保障接口測(cè)試覆蓋度和有效性，很大程度上會(huì)降低線上bug的產(chǎn)生，開(kāi)發(fā)同學(xué)也會(huì)更有積極性去重構(gòu)代碼。
分享名稱：如何編寫(xiě)有效的接口測(cè)試？
URL標(biāo)題：http://www.5511xx.com/article/djgcjeh.html
