接口自動化測試實踐

背景

溫馨提示：下文中大量提到的內容使用了美團的實踐和生哥分享的實踐！

業務系統上線迭代、重構，如何保證被修改後系統原有業務的正確性非常重要。簡單業務手工測試即可，但對於業務十分複雜龐大的系統，迴歸測試將變成一項浩大的工程，但是至關重要！

舉個例子：某電商公司，離職了一批又一批人，進來了一波波新人，幾乎沒有人能梳理清楚其中的業務和代碼。譬如增刪或修改字段和方法、修改條件語句及算術邏輯等，各種條件分支場景尤爲複雜，手工測試覆蓋不全，耗時長，這時自動化測試勢在必行。

單元測試規範

單元測試規範基於阿里規範，自動化測試主要是離不開集成測試，集成測試細分又是一個個單元測試組合而成。我們先粗略的過一下單元測試的一些規範事項。

三、單元測試 
1. 【強制】好的單元測試必須遵守 AIR原則。 說明：單元測試在線上運行時，感覺像空氣（AIR）一樣並不存在，但在測試質量的保障上，卻是非常關 鍵的。好的單元測試宏觀上來說，具有自動化、獨立性、可重複執行的特點。 
⚫ A：Automatic（自動化） 
⚫ I：Independent（獨立性） 
⚫ R：Repeatable（可重複） 
2. 【強制】單元測試應該是全自動執行的，並且非交互式的。測試用例通常是被定期執行的， 執行過程必須完全自動化纔有意義。輸出結果需要人工檢查的測試不是一個好的單元測試。 單元測試中不準使用 System.out來進行人肉驗證，必須使用 assert來驗證。 
3. 【強制】保持單元測試的獨立性。爲了保證單元測試穩定可靠且便於維護，單元測試用例之 間決不能互相調用，也不能依賴執行的先後次序。 反例：method2 需要依賴method1 的執行，將執行結果作爲method2 的輸入。 
4. 【強制】單元測試是可以重複執行的，不能受到外界環境的影響。 說明：單元測試通常會被放到持續集成中，每次有代碼 check in 時單元測試都會被執行。如果單測對外部 環境（網絡、服務、中間件等）有依賴，容易導致持續集成機制的不可用。 正例：爲了不受外界環境影響，要求設計代碼時就把 SUT 的依賴改成注入，在測試時用 spring 這樣的DI 框架注入一個本地（內存）實現或者 Mock 實現。 
5. 【強制】對於單元測試，要保證測試粒度足夠小，有助於精確定位問題。單測粒度至多是類 級別，一般是方法級別。 說明：只有測試粒度小才能在出錯時儘快定位到出錯位置。單測不負責檢查跨類或者跨系統的交互邏輯， 那是集成測試的領域。 
6. 【強制】核心業務、核心應用、核心模塊的增量代碼確保單元測試通過。 說明：新增代碼及時補充單元測試，如果新增代碼影響了原有單元測試，請及時修正。 
7. 【強制】單元測試代碼必須寫在如下工程目錄：src/test/java，不允許寫在業務代碼目錄下。 說明：源碼編譯時會跳過此目錄，而單元測試框架默認是掃描此目錄。 
8. 【推薦】單元測試的基本目標：語句覆蓋率達到 70%；核心模塊的語句覆蓋率和分支覆蓋率 都要達到 100% 說明：在工程規約的應用分層中提到的 DAO層，Manager 層，可重用度高的 Service，都應該進行單元 測試。 
9. 【推薦】編寫單元測試代碼遵守 BCDE原則，以保證被測試模塊的交付質量。 
⚫ B：Border，邊界值測試，包括循環邊界、特殊取值、特殊時間點、數據順序等。 
⚫ C：Correct，正確的輸入，並得到預期的結果。 
⚫ D：Design，與設計文檔相結合，來編寫單元測試。 
⚫ E：Error，強制錯誤信息輸入（如：非法數據、異常流程、業務允許外等），並得到預期的結果。 10. 【推薦】對於數據庫相關的查詢，更新，刪除等操作，不能假設數據庫裏的數據是存在的， 或者直接操作數據庫把數據插入進去，請使用程序插入或者導入數據的方式來準備數據。 反例：刪除某一行數據的單元測試，在數據庫中，先直接手動增加一行作爲刪除目標，但是這一行新增數 據並不符合業務插入規則，導致測試結果異常。 
11. 【推薦】和數據庫相關的單元測試，可以設定自動回滾機制，不給數據庫造成髒數據。或者 對單元測試產生的數據有明確的前後綴標識。 正例：在企業智能事業部的內部單元測試中，使用 ENTERPRISE_INTELLIGENCE _ UNIT_ TEST_ 的前綴來 標識單元測試相關代碼。 
12. 【推薦】對於不可測的代碼在適當的時機做必要的重構，使代碼變得可測，避免爲了達到測 試要求而書寫不規範測試代碼。 
13. 【推薦】在設計評審階段，開發人員需要和測試人員一起確定單元測試範圍，單元測試最好 覆蓋所有測試用例。 
14. 【推薦】單元測試作爲一種質量保障手段，在項目提測前完成單元測試，不建議項目發佈後 補充單元測試用例。 
15. 【參考】爲了更方便地進行單元測試，業務代碼應避免以下情況： 
⚫ 構造方法中做的事情過多。 
⚫ 存在過多的全局變量和靜態方法。 
⚫ 存在過多的外部依賴。 
⚫ 存在過多的條件語句。 說明：多層條件語句建議使用衛語句、策略模式、狀態模式等方式重構。 
16. 【參考】不要對單元測試存在如下誤解： 
⚫ 那是測試同學乾的事情。本文是開發手冊，凡是本文內容都是與開發同學強相關的。 
⚫ 單元測試代碼是多餘的。系統的整體功能與各單元部件的測試正常與否是強相關的。 
⚫ 單元測試代碼不需要維護。一年半載後，那麼單元測試幾乎處於廢棄狀態。 
⚫ 單元測試與線上故障沒有辯證關係。好的單元測試能夠最大限度地規避線上故障。 

我們看一個簡單的SpringBoot單元測試代碼

願景

自動化測試任重道遠，現實是殘酷的，願望是美好的，我期望的功能和目標有如下一些要求和特點：

• 用例統一管理及可視化。流水線（代碼掃描、單元測試、打包與鏡像、環境部署、自動化測試）平臺化統一管理

• 減少用例錄入成本，支持從生產引流複製用例。簡化測試用例錄入的成本，儘可能多的提示，如果可以，開發一些批量生成測試用例的工具；將生產的部分流量複製，將錄製的流量作爲用例管理起來進行日常自動化歸回

• 減少工具開發的成本。儘可能的減少開發工具的時間、工具維護的時間，儘可能使用公司已有的，或是業界成熟的工具或組件。

• 減少用例維護成本，可複用。減少用例維護成本，儘量只用在頁面上做簡單的輸入即可完成維護動作，而不是進行大量的代碼操作。

• 減少界面交互複雜性，頁面操作簡單。

• 豐富的用例分析和統計。

• 消息通知方式多樣，通知相關人員。

自動化測試實踐

下面的實戰篇主要講解的實戰主要基於Jenkins+Ant/maven/TestNG/+ReportNG/Jacoco技術方案
主要以自身實踐、美團、雲集三個結合來簡述：
美團自動化測試
雲集持續集成解決方案

開發流程圖

研發流程工作方式對比

Dcoker/Jenkins+Ant+Junit實踐

流程圖和技術方案如下，在一些未開發完或者不方便調用的接口可以使用Mock去代替，該方案用例腳本均爲Java或者Scala等語言去編寫->調用RPC接口或者其他接口。最終自動化執行之後產生報告，可以比較快的運用到團隊自動化測試方案中。


單元測試項目的涉及到的比較關鍵的文件及部分目錄介紹：

• 數據庫連接地址設置文件：DBConfig
• 清除數據庫操作文件：DBUtil
• 數據集com.biz.set.*
• 數據庫變更文件com.biz.data.*
• 業務用例和數據集相關 com.biz.case.*
• 基於Ant的配置文件build.xml
  /docker/build.xml（doker容器使用)
  /build.xml(本地cmd裏執行ant操作使用)
• build.xml文件內包含郵件羣發、單元測試運行包含的用例範圍、郵件報告的生成
• 單元測試項目依賴RPC基礎調用服務包

腳本樣例

腳本使用Scala編寫，順便提一下，Scala是將面向對象和麪向函數式整合在一起,基於JVM的編程語言。
Scala相對Java語法更豐富，更簡潔，豐富的函數操作，寫起來更像腳本，能夠提高開發效率。不過新版的Java也越來越簡潔的語法

後置檢查，期望值查詢對比

build.xml配置用例範圍、生成分析報告、郵件發送

執行過程

基於docker-compose的執行過程，在sanbox測試服務器的沙箱環境中執行的方法步驟

• docker-compose stop （停止所有服務）
• 切換到單元測試的變量export nodeName=unittest ，使所有業務系統啓動時候連接單元測試庫/緩存/MQ，(如果代碼做了影子隔離，則無需重新啓動所有服務)
  檢查env |grep nodeName 是否切換成功
• docker-compose up -d（啓動單元測試需要的服務，所有服務連接單元測試的庫、緩存、MQ）
• docker ps 查看是否有項目啓動異常
• docker-compose -d unittest yml文件會去讀取執行Docker、build.xml的Ant配置，使用Ant進行自動化測試。
  同理，普通非容器的後臺應用，也可以編寫觸發器監聽分支代碼提交狀況，然後更新代碼，打包構建部署，接着切換節點重啓，執行Ant等一些列操作，結合Jenkins工作流的方式也非常方便。

郵件報告生成樣例

Jenkins+TestNG的實踐

上述方式直接寫在代碼中，在複用性和可維護性上非常不好管理。下面介紹的方式更利於維護拓展和管理。
如下圖所示， 將自動化測試用例存儲至MySQL數據庫中。做成比較常見的“數據驅動”做法。很多團隊也是使用這樣的結構來進行接口自動化，沿用的話，那在以後的“推廣”中，學習和遷移成本低都會比較低

自動用例執行順序大概是如下圖這樣：
簡單區分一下各個部分，可以看到：

上面的傳統方式其實已經做到了簡單維護、界面統計分析交互、分析消息通知等。那麼在此基礎上，再加上引流複製生產數據的功能，那就更加強大了。

阿里Doom自動化測試框架

Doom功能同樣非常強大，未開源。部署架構圖如下，複製生產流量數據到測試用例的思路可以借鑑，減少了大量造數據成本

上述美團和阿里的更詳細的全文如下鏈接進入
雲集-互聯網持續集成解決方案
Lego-美團接口自動化測試實踐
阿里創新自動化測試工具平臺–Doom

下面是其他的一些主流互聯網公司的做法，目標基本一致，實現方案各有千秋。

京東自動化測試最佳實踐
去哪兒持續集成
阿里巴巴自動化測試發展思路
美團自動化測試1
美團自動化測試2
餓了麼自動化測試
羚瓏項目自動化測試方案實踐

全鏈路壓測系統

有了自動化測試同樣隨着系統的發展，發展到需要全鏈路壓測
直接對生產進行壓測有利於快速找到生產的問題和瓶頸，比自動化測試更加直接有效。

提一提：影子區域概念——全鏈路壓測的所有數據都在生產環境做了數據隔離，包含存儲、緩存、消息、日誌等一系列的狀態數據。在壓測請求上會打上特殊的標記，這個標記會隨着請求的依賴調用一直傳遞下去，任何需要對外寫數據的地方都會根據這個標記的判斷寫到隔離的區域，我們把這個區域叫做影子區域
揭開雲集全鏈路壓測的神祕面紗 感謝生哥分享親身實戰
全鏈路壓測集合
阿里全鏈路壓測
京東全鏈路壓測
餓了麼全鏈路壓測
滴滴全鏈路壓測解決之道
美團全鏈路壓測自動化實踐
邏輯思維在全鏈路壓測方面的實踐
餓了麼全鏈路壓測平臺的實現與原理
接口自動化測試實踐的記錄

以上是自己或者身邊的人經驗所得，也有很多互聯網公司的親身實踐，結合以上經驗分享，針對自己的團隊，擇優而從，打造適合的自動化測試、全鏈路測試平臺。