乾貨 | 攜程微服務架構下的測試淺談

原創： 施賽花 攜程技術中心 8月21日

一、前言

在現在這個網際網路時代，多變的市場環境以及日益增長的客戶需求，加速了產品的迭代和更新。傳統的單體式應用已經因跟不上發展的步伐而逐漸退出歷史的舞臺，取而代之的是SOA的問世。

SOA的出現使系統架構發生了跳躍式的轉變，它提出了面向服務的設計思想。而現今流行的微服務架構，和SOA雖是一脈相承，但不再強調傳統SOA架構裡的ESB（企業服務匯流排）。

使用微服務架構可以將系統劃分成更細粒度的服務，每個微小服務實現單一業務功能，且可以根據自身特點選擇更適用的程式語言和技術。每個微服務可以由不同的團隊獨立完成開發，互不影響，加速了產品的推出和迭代。

誇張一點說，如果將整個軟體系統比作宇宙的話，那每個微服務就好比行星，它可以獨立的執行在自己的程序中。各服務之間通過網路通訊，看似獨立，卻又因業務聯絡關聯在了一起，就像各個行星之間有著引力等物質將它們緊緊關聯。一系列獨立執行的微服務就共同構建起了整個系統。

二、微服務架構下測試的分類

以傳統建築行業為例，專案的完成需要設計院、施工方和監理單位協同合作。類比到軟體系統中，架構師、開發和測試也是缺一不可。微服務架構下，更要求採用的測試策略能夠為服務內部的完整性，以及每個服務之間的互動，提供全面的測試覆蓋。

相比於常見的UI測試層、介面測試層、單元測試層，三層測試金字塔，在微服務架構，這個分類可以被擴充套件為5類。

下面將逐一介紹在微服務架構中主要採用的測試型別：

• 單元測試

單元測試是針對程式碼單元的測試，通常只測試一個函式和方法呼叫，驗證其執行結果是否符合預期，是對程式碼質量最快速的反饋。高覆蓋率、高質量的單元測試是保障程式碼質量的第一道保護傘。在掌握TDD（Test-Driven Design，測試驅動開發）的前提下，單元測試更是對程式碼重構起到了非常關鍵的作用。

• 整合測試

雖然單獨測試模組非常重要，但是測試各個模組之間互動是否正常，同樣也佔據了重要的地位。在微服務架構下，整合測試的目的是把一些子模組組合在一起，測試其作為子系統是否存在缺陷，檢查模組之間的通訊和互動是否通暢且準確，是否以預期的方式協作

• 元件測試（微服務測試）

在微服務架構中，元件實際上就代表著微服務本身，所以元件測試就是檢查服務內部功能實現是否完整，內部邏輯是否正確，異常處理是否正常等。

• 契約測試

契約測試稱之為消費者驅動的契約（Consumer-Driven Contracts，簡稱CDC）測試。契約測試是為了測試服務之間連線的正確性，測試服務能否符合契約預期，即是否能真正滿足服務消費者的需求。

• 端到端測試

端到端測試是從UI層開始執行，目的是檢查整個軟體系統是否符合使用者的預期需求。一個常規頁面功能展示的背後往往涉及多個服務，所以執行端到端測試需要部署多個服務。這樣的測試能夠達到更廣的覆蓋面，但是也面臨測試不穩定，定位問題難等問題。

在微服務架構下，前端及後端各微服務之間都是分開研發及測試。保證每個微服務本身的質量成了測試中至關重要的一環。要想樓房造的高而穩，那基礎必須紮實。微服務就好比那基石，高質量的微服務，是保障軟體系統整體質量的關鍵。

相較於端到端測試在敏捷開發中的維護成本，服務在迭代研發過程中，和UI相比變化相對少，所以自動化更易維護，且能在迭代中不斷複用。而且，服務測試自動化受外界因素的影響較少，不會受瀏覽器、手機型號及系統版本等影響。

三、基於微服務架構的服務測試工具

微服務架構帶來了便利，隨之也給測試工作增加了難度和新的挑戰。測試人員必須跟上時代的步伐，調整自己的測試方法和工具。

怎樣模擬多樣的上層資料以及穩定的下層服務，高效、高覆蓋的完成對服務的測試。此時，攜程基於微服務架構的自動化比對工具就應運而生了。

該比對工具是以生產Log作為測試資料來源，通過Mock、快取等實現生產流量在測試環境的回放，以達到對服務進行全面測試的目的。

1、設計初衷

1）縮減測試資料維護成本、增加測試覆蓋度

因是對服務的測試，首先要做的就是模擬上層應用或系統呼叫被測服務。常規服務測試自動化中，測試資料都是由自動化來完成構建，痛點：資料維護成本高，Case量級偏少。

解決方案：

拉取生產的Log資料作為資料來源，這樣原來5%左右測試資料的維護成本就縮減為了0%。資料每天定時拉取，增加了資料的新鮮度。且拉取的資料量大，這樣就能保障資料的多樣性，豐富的測試場景，以達到增加覆蓋度的目的。

2）測試用例的持續執行成功

因測試環境的不穩定性，以及測試環境資料的缺失，且對於下層服務返回資料的強依賴性，做到Case持續執行成功並不是一件容易的事。

解決方案：

通過實現Mock，擺脫對底層服務的依賴，且能高效還原當前Case在生產環境的測試場景。

3）實現對被測服務所有輸入輸出流的驗證

很多時候被測試的服務內部需要去呼叫其他服務，且有非常複雜的邏輯判斷，對呼叫其他服務這塊中間輸出流的驗證也是非常重要的，所以常規只對服務返回結果的驗證遠遠不夠。

解決方案：

實現對被測試服務所有輸入輸出流的比對驗證。

2、具體實現

比對工具中最關鍵的是實現兩個服務：

• 比對服務：負責測試資料的拉取、被測服務的呼叫以及最後的比對；

• Mock服務：負責被測服務需要的返回結果的高效匹配，以及對呼叫其他服務請求報文的收集及快取。

比對工具工作流圖：

3、工具優勢

• 模擬生產流量

通過實現多執行緒，對生產上高QPS的服務，能夠高效還原生產流量場景，並且通過模擬生產高併發時被測服務的負載量，使原本還有藏身之所的Bug更無所遁形。同時，每次執行Case的時間也有了量級上了縮減。

• 靈活Mock下層服務

以攜程機票一個聚合層服務為例，它需要呼叫超過30個下層服務，常規測試用的打樁服務需要對指定下層服務進行預設返回，在多執行緒的情況下，這種方式匹配效率較低且容易出錯。我們Mock服務中對打樁功能進行了改良，不僅擺脫對指定服務的Mock，並能快速準確的匹配返回結果。

• 多種比對方式

工具除支援兩個測試環境進行比對外，更支援直接與生產資料比對。不同的比對方式，滿足更多的測試需求，且對於被測服務中已知有變化的節點，也支援除外不比較，大大縮減測試結果的分析時間。

四、總結

技術的發展不會停步，學習的腳步不會停止。在微服務架構下，除了對微服務技術本身的研究外，對更適用於微服務架構測試的探究，是每個測試人未來努力發展的方向。

作者簡介：施賽花，攜程機票BU測試工程師，主要負責攜程機票聚合層服務的測試，以及自動化工具的開發。善於研究新技術，並轉用於實踐，提升測試工作效率。