[[378723]]

在所有的開發(fā)測試中，接口測試是必不可少的一項。有效且覆蓋完整的接口測試，不僅能保障新功能的開發(fā)質量，還能讓開發(fā)在修改功能邏輯的時候有回歸的能力，同時也是能優(yōu)雅地進行重構的前提。編寫接口測試要遵守哪些原則?測試代碼的結構應該是什么樣的?接口測試有哪些實踐技巧?本文分享作者在接口測試上的實踐總結。

一線開發(fā)同學，可能都或多或少地造成過線上bug甚至故障;也會遇到這樣的場景，某同學在開發(fā)某功能的時候重構了代碼，造成了線上bug或者故障;在開發(fā)某個功能時，發(fā)現(xiàn)需要修改公共邏輯，害怕影響到其他功能，非常不雅觀地拷貝代碼，重新寫套單獨邏輯來支持。

上面這些情況，都包含了一個關鍵的問題，無論是功能開發(fā)還是邏輯重構，如何來保障代碼開發(fā)的質量。保障的手段，每個人都知道，就是測試。首先是新功能測試，保障新功能邏輯正確;其次是回歸測試，保障原有業(yè)務功能邏輯正確。測試的方式，一般是兩種，人工測試和自動化測試。隨著測試技術和工具的持續(xù)發(fā)展，人工測試比例逐步降低，被自動化測試逐步替代。自動化測試是可持續(xù)和可重復的，甚至是可AI化的。

一 測試分層

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

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

單元測試

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

模塊測試

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

接口測試

個人覺得準確來說應該叫入口測試，這一層，是從系統(tǒng)入口出發(fā)進行集成測試。應用入口通常是HSF(一個分布式RPC服務框架)服務，消息，定時任務。

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

二 測試原則

基礎原則：

• 自動化：接口測試是非交互式的自動化執(zhí)行，不需要人參與。
• 獨立性：接口測試之間不應該相互依賴。
• 可重復：接口測試可重復執(zhí)行，不受環(huán)境影響。
• 接口測試遵守BCDE原則，保障接口交付質量。
  • Border：邊界測試。
  • Correct：正確的輸入，正確的預期輸出。
  • Design：按照需求和設計文檔編寫測試邏輯。
  • Error：錯誤輸入，預期輸出。
• 數(shù)據(jù)準備：數(shù)據(jù)準備通過系統(tǒng)服務進行，不能通過直接插入db方式。
• 可測性：對于不可測的代碼需要進行重構成合理的結構。
• 覆蓋性：接口測試需要覆蓋所有UC，同時代碼覆蓋率和分支覆蓋率應達到一定標準，新增代碼必須被覆蓋。
• 持續(xù)性：如果代碼修改導致已有接口測試執(zhí)行失敗，必須修復代碼問題或者測試代碼邏輯。
• 時間要求：接口測試應該在項目發(fā)布之前完成，不應放到項目發(fā)布之后補充。

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

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

• 外圍系統(tǒng)調用由我們系統(tǒng)提供的服務。
• 系統(tǒng)執(zhí)行了一堆代碼邏輯，其中包含有分支邏輯。
• 系統(tǒng)執(zhí)行過程中依賴外部HSF服務，進行了調用，并得到了返回值。
• 系統(tǒng)執(zhí)行過程中依賴DB查詢或者落地了數(shù)據(jù)，依賴緩存查詢或者落地了數(shù)據(jù)。
• 系統(tǒng)執(zhí)行過程中對外發(fā)送了消息。
• 給上游系統(tǒng)返回HSF執(zhí)行結果。

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

• 入口覆蓋：接口測試用例必須覆蓋HSF服務入口、消息入口、定時任務入口。
• 依賴mock：在基本原則中，有可重復這個原則，即接口測試不能受環(huán)境依賴，需要mock掉對外依賴。但對于db依賴，不建議完全mock掉，一方面mock成本高，另外可能覆蓋不到sql和表約束邏輯。
• 校驗完整：有效的接口測試，應該具備完整的校驗，沒有校驗的接口測試是沒有意義的。只要執(zhí)行過程中，留下的痕跡對業(yè)務有影響，都要進行完整校驗，方能保障接口測試的有效性。
  • HSF接口返回值校驗：按照場景和接口約定進行HSF返回參數(shù)校驗。
  • DB校驗：校驗落地數(shù)據(jù)的正確性。
  • 緩存校驗：校驗存入緩存中數(shù)據(jù)的正確性。
  • HSF依賴入?yún)⑿ｒ灒和ㄟ^mock工具獲得依賴HSF調用的入?yún)ⅲM行入?yún)⑿ｒ灐?/li>
  • 消息校驗：通過mock工具獲得發(fā)送的消息對象，進行消息體校驗。

三 測試代碼結構

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

一個接口的測試代碼，大概的結構如下：

1 測試準備

依賴數(shù)據(jù)準備

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

• 配置數(shù)據(jù)：可以通過定義配置文件來初始化配置。
• 業(yè)務數(shù)據(jù)：這類數(shù)據(jù)，禁止通過直接插入數(shù)據(jù)方式產(chǎn)生，而是應通過調用業(yè)務服務產(chǎn)生。

依賴mock

對于外部依賴，需要對被依賴的服務進行mock，避免真實調用。

接口測試入?yún)蕚?/strong>