貨拉拉服務端質量保障之測試策略篇

作者簡介

• 代麗，來自貨拉拉/技術中心/質量保障部，主要負責貨拉拉交易和履約以及資金領域的質量保障和服務端質量體系建設工作。

一、背景與挑戰

服務端質量保障是確保伺服器端應用程式在開發、部署和執行過程中達到預期效能和可靠性的關鍵步驟。一個全面的服務端測試策略不僅能提高系統的穩定性和安全性，還能提升使用者體驗和滿意度。
貨拉拉服務端整體採用微服務架構，單點服務互動鏈路呈複雜的發散狀：

面對如此複雜的系統架構，質量保障具有如下挑戰：

1. 支撐快速迭代: 業務保障結果需滿足高效&高質量
   • 高效：業務測試人員在固定時間範圍內可支撐更多業務保障。
   • 高質量：線上缺陷率逐步降低，最終實現萬無一失。
2. 高穩定：業務系統效能達標&健壯性高
   • 效能：服務端在不同工作負載下的表現滿足預期。
   • 健壯性：面對各種失敗情況下，系統均可彈性應對，不會引發更嚴重的問題。
3. "0"資損：資金保障需確保系統定價鏈路準確與資金鍊路資料無損
   • 定價：不同型別的訂單估價滿足業務預期。
   • 資金資料：不同業務領域組合成的資金鍊路資料整體相符，無不一致和賬不平的事情發生。 針對以上背景和挑戰，我們需建設一套完善且高效的測試策略！

二、知己知彼-bug 從哪裡來？

讓我們一起進入開發的視角，開發一個業務需求需要怎麼編寫程式碼，變動的程式碼可能會產生哪些 bug 呢？

三、逐一擊破 - 測試策略

整體測試策略分 5 大類，層層包含且存在增量差異，最終環環相扣形成完整保障閉環。

1.程式碼分支測試

保障目標

• 專案任意階段部署到測試/線上環境的服務程式碼均包含 master 分支程式碼。
• master 分支程式碼無論何時均和線上執行程式碼相同。

保障策略
制定程式碼分支管理規範，將規範落地為【程式碼分支檢測】工具自動檢查和接入服務部署與准入準出流水線管控，最終形成可持續且閉環的程式碼分支保障。
程式碼分支規範：

程式碼分支管控：

2.變更測試

保障目標
確保每個服務端功能按照預期工作。
保障策略
整體分 3 塊，分別是功能測試、資損測試和穩定性測試。

2.1 功能測試

整合&介面測試主要由測試人員根據變更業務內容&程式碼 diff 進行測試分析設計用例&保障，其中程式碼 diff 可結合【精準測試】工具輔助測試分析；單元測試<<單元測試在貨拉拉的落地與實踐>>主要由開發人員根據類、函式或模組變化進行測試分析設計用例&保障。

• 單元測試：檢查單一功能是否正確。
• 整合測試：評估多個功能聯動是否正常。
• 介面測試：驗證服務端提供的 API 介面是否符合預期，包括請求引數、返回結果、錯誤處理等。此處會結合測試工具【資料工廠】和【MOCK】協助測試。

2.2 資損測試

• 定價鏈路：採用流量回放<<貨拉拉流量回放體系搭建與應用>>工具錄製線上定價流量，在程式碼/配置變更之後實時回放/歷史錄製回放（灰度環境操作），透過分析回放出的結果差異得出程式碼/配置變更是否符合業務預期，不僅可協助測試發現遺漏的問題，還可以協助產品/業務預設出此次變更之後使用者司機的價格變化，避免輿情發生的可能。
• 資金資料：採用【資料核對】工具，各領域服務端測試人員在此工具上配置好各類資料模型關係（例如：db 與 db，db 與 es，db 與介面等），最終形成全鏈路資料模型關係網。工具動態監測到 binlog 變動之後，基於前置輸入的資料驅動關係模型進行核對，實時攔截資料不一致與帳不平的問題發生。

2.3 穩定性測試

• 效能：使用 jemeter 工具進行壓力和負載測試，確保系統在高負載、高併發等複雜環境下能夠穩定執行。貨拉拉正在逐步擴大自動化壓測<<全鏈路壓測自動化的探索與實踐>>的實踐，使用全新效能方式，將會極大降低效能測試時長&人工誤判情況發生。

• 健壯性：使用故障演練<<故障演練體系建設>>工具，模擬生產環境中介面、服務和中介軟體等維度異常時，系統能夠迅速恢復並繼續提供服務。常見需確保健壯性的場景有：

  • 網路通訊異常處理：
    • 連線中斷：服務端需要能夠處理客戶端突然斷開連線的情況，確保不會因此導致資源洩露或系統崩潰。
    • 超時處理：對於長時間無響應或超時的請求，服務端應有相應的超時處理機制，避免資源被長時間佔用。
    • 資料包損壞：在網路傳輸過程中，資料包可能會損壞。服務端應具備驗證資料包完整性的能力，並在發現損壞時能夠採取適當的恢復措施。
  • 資料一致性與完整性：
    • 事務處理：對於需要保持資料一致性的操作，服務端應支援事務處理機制，確保在異常情況下能夠回滾到操作前的狀態。
    • 資料校驗：對輸入資料進行嚴格的校驗，確保資料的合法性和準確性，避免因為非法資料導致系統異常或資料損壞。
  • 系統穩定性與容錯性：
    • 異常處理：服務端應具備完善的異常處理機制，能夠捕獲並處理各種執行時異常，避免因為未處理的異常導致系統崩潰。
    • 冗餘部署：透過冗餘部署來提高系統的容錯性和可用性。例如，使用多臺伺服器進行負載均衡和故障轉移。
    • 資源監控與告警：對系統資源進行實時監控，並在資源使用異常或達到閾值時發出告警，以便及時採取措施進行處理。
  • 服務降級與限流：
    • 服務降級：在系統資源緊張或出現故障時，透過降低非核心服務的優先順序來保障核心服務的正常執行。
    • 限流：對訪問流量進行限制，避免因為突發流量導致系統過載或崩潰。
  • 依賴管理：
    • 第三方服務依賴：對於依賴的第三方服務，服務端應具備監控和異常處理的能力，以應對第三方服務不可用或異常的情況。
    • 依賴版本管理：合理管理依賴的版本，避免因依賴版本衝突導致的問題。

3.迴歸測試

保障目標
避免增量程式碼變動影響到自身服務領域或其他服務領域的線上邏輯。
保障策略
整體分 2 塊，分別是進行單服務迴歸的回放測試和全鏈路迴歸的端到端測試。

3.1 回放測試

在專案詳細測試階段開啟流量回放全量錄製並結合【程式碼覆蓋率】工具提取出有效流量樣本實時沉澱至用例集，在專案迴歸測試階段直接對變更的單服務進行迴歸保障。

3.2 端到端（E2E）測試

模擬真實使用者的操作流程，透過向直接和客戶端互動的服務發起請求，經過網路傳輸，到達服務端，再到服務端處理完請求後返回結果，判斷結果是否正確。這種測試方式涵蓋了整個服務端系統的工作流程，確保服務端系統在實際使用環境中能夠正常工作。它如果配合流量回放一起使用，一個保鏈路，一個保單服務節點，就可實現在降低人力成本情況下有效替換掉老式的介面自動化保障。

測試方法採用 testng 測試框架進行自動化方式保障，場景 case 根據業務功能模組分類建設，其中 P0 級別業務功能模組可用於線上/線下確保環境可用的定時巡檢使用，其他功能模組場景 case 可透過機器人快速喚醒執行，不僅可應用到專案冒煙與迴歸測試階段使用，還可以用於線上迴歸驗證和快速應急使用。

4.灰度測試

保障目標
避免發生以下 2 種情況

• 新業務能力上線之後由於使用者反饋不佳下線，不僅投入的資源都浪費了，還在系統留下了大量的垃圾程式碼。
• 變更程式碼之後，影響了線上已經在 run 的業務邏輯，全量使用者受到影響，引發故障。

保障策略
灰度測試，也被稱為灰度釋出或灰度部署，是在某項產品或應用正式釋出前，選擇特定人群（使用者或伺服器叢集）試用，並逐步擴大其試用範圍，以便及時發現和糾正其中可能存在的問題。貨拉拉具備多版本灰度環境【小貨拉拉】，可以透過城市、使用者司機人群和 app 版本號等策略進行灰度，最終實現"儘快試錯，聚焦有用功能 ” 、“小步快跑，風險盡在掌握” 的目標。

5.監測與報警

保障目標

• 及時發現並處理故障：透過持續的監測，能夠迅速發現服務端執行中出現的異常或故障，如介面處理錯誤、服務當機等，從而及時採取修復措施，確保服務的持續穩定執行。
• 預防潛在風險：透過監測資料的分析，可以預測潛在的風險點，如資源使用瓶頸、效能下降趨勢等，提前進行最佳化和調整，避免服務中斷或效能下降。

保障策略
在貨拉拉除了 CI 團隊提供給業務的 monitor 監測與報警能力，測試團隊也建設了【日誌哨兵】工具，實時監測業務程式碼異常，並將程式碼異常結合經驗庫決策判斷，最終且實現精準與實時的問題觸達。

四、成果與收益

從第三章闡述的 5 類測試策略在貨拉拉的具體落地可以看出，除了業務變更部分需要人參與的比較多，其他基本都處於工具化的狀態。這不僅讓貨拉拉服務端質量保障具備了將測試從保姆模式轉成教練模式的條件，還為質量&效率帶來了提升。

• 千行程式碼缺陷率降低 40%
  研發可利用測試的效能建設深入參與到質量保障任務中，主要有單測、程式碼分支檢測、日誌哨兵等賦能，讓研發可自我閉環問題，降低缺陷數。

• 線上質量降低至<=1%
  線上缺陷數/(線上缺陷數 + 線下缺陷數），其中分母不包含研發自閉環保障階段發現的問題。

• 測試人效提升 30%
  測試人效提升主要來源於研發可自閉環需求變多、人工測試保障面變少和工具輔助測試提效，這讓測試人員在固定時間範圍內可支撐更多業務保障。不同業務線會存在一些差異，中臺服務領域因每次變動和線上業務邏輯差異較小提升會比較明顯。

下面的餅圖為貨拉拉貨運在 2024 年 02～07 月（H1）期間服務端缺陷暴露渠道佔比：

• 人工測試暴露問題仍然是主力，其次是日誌哨兵>程式碼分支檢測>E2E>流量回放>資料核對>小貨拉拉；
• 在效能攔截的問題中，其中 46% 問題攔截在需求提測前，30% 問題攔截在詳細測試階段，24% 問題攔截在迴歸&灰度測試階段，整體呈遞減趨勢；
• 效能協助研發自閉環問題佔比效能攔截全量問題的 60%，日誌哨兵>程式碼檢測>流量回放。

五、未來規劃與思考

1.未來規劃

1.1 有明確測試方法部分繼續使用工具和流水線去替代人工測試

eg：此文第三章提到的程式碼分支測試部分

1.2 工具無法替代部分結合 AI 給予推薦和決策建議

eg：智慧問題定位，智慧用例推薦等方向

2.思考：

測試會被替代麼？
作者認為不會被替代。不同時代隨著新的技術和業務模式的出現，對測試是持續需要的，但是會帶來新的挑戰和需求，需要測試人員不斷提升自己的技能和知識，以適應行業的變化和發展。其次我認為測試的核心競爭力是測試方法，程式碼/AI 等相關技能都需要有方法論為支架才能發揮出效果，期望大家在豐富新知識的同時，不要忘記持續豐富自我的測試方法論模型。

感謝大家閱讀至此，期望此文能給你帶來啟發和思考，由於篇幅有限，文章中提到的已在貨拉拉應用的相關效能工具（中括號加粗部分）有些未能展開介紹，後續會持續分篇章分享，請大家敬請期待！