作者簡介

haibing，攜程研發能效經理和SRE，關注自動化測試，能效提升方向的工具技術。

一、背景

隨著攜程機票BU業務規模的不斷提高，業務系統日趨復雜，各種問題和挑戰也隨之而來。對于研發測試團隊，面臨著各種效能困境，包括業務復雜度高、數據構造工作量大、回歸測試全量回歸、溝通成本高、測試用例數量多且難以復用、測試數據維護量大以及自動化用例管理等問題。每個都會影響測試團隊的效率和質量，給軟件研發過程帶來挑戰。

總結下來主要是兩個核心困難點：成本與復雜度。

成本方面，我們通常需要在成本和質量之間做出取舍，需要在快速迭代的同時保證質量，又需要在限定的投入下保證質量。

復雜度方面，當業務規則積累一段時間后，業務流程、規則、場景和數據處理的復雜度在疊加后呈二次或者指數等形式增加，給測試質量工作帶來很大的挑戰。

二、探索：自動化回歸測試的探索與實踐

為了應對這些挑戰，我們在質量和測試工作中進行了一些持續性探索：

1）AUTO 測試平臺：常規的可編程的用例設計管理和執行平臺。

2）錄制回放測試：引入 TCP Replay 進行回放測試，好處是可以簡化測試設計，缺點是沒有預期測試結果，需要人力去關注分析結果。

3）測試數據構造：通過腳本結合接口訪問生成數據，解決日常數據依賴的問題，但是構造的人力成本很高，而且是持續性的投入維護。

4）數據 MOCK 平臺：針對不同的場景建設多個 MOCK 平臺，解決測試數據問題。

5）各類覆蓋率平臺：度量測試的范圍與工作量。

6）優化測試環境：建設基準測試環境和子環境，保證連調和測試的需要。

除此以外，還有很多其他測試框架、SQL日志分析、單元測試用例生成、Chaos 故障演練平臺等等的嘗試。

探索中遇到的問題

以上的各種探索都達到了一定的效果，但還是存在兩個問題：

1）自動化測試側重于自動化執行，維護工作依舊是“手工”，產出比不是很樂觀。

2） 在需要構造大量測試數據、寫場景、回歸測試范圍大、發布頻繁的場景下，不管是手工測試還是自動化測試，開發測試都還是面臨著巨大的工作量，包括用例和數據的維護工作，測試的痛點并沒有有效解決。

新的建設目標

因此，研發團隊給我們提了新的建設目標：“質量要提升，要保證。費電可以，但不能廢人。”

基于以上種種探索經驗和新的目標，于是就有了“用真實的生產流量和數據進行回歸測試“的實現想法。最終，我們將這個想法轉化為具體的思路，并將其落地，建設了一個結合錄制+回放+比對的自動化測試平臺 AREX，現已開源（開源地址https://github.com/arextest）。

• 錄制：不只是錄制生產的請求，也錄制請求處理過程中涉及到的數據。
• 回放：不只是回放請求， 也把涉及的數據MOCK到應用里邊。
• 比對：用錄制回放的差異比對來代替測試斷言。

三、AREX平臺介紹

3.1 什么是AREX

AREX包含了Java Agent和前端、存儲、調度、報告、數據庫等服務組件 ，整體架構如下圖所示。

AREX回歸測試邏輯

AREX 回歸測試的實現邏輯是通過在生產環境錄制接近全量的業務場景請求和數據，然后在測試環境回放這些真實的請求和數據，對新版本的應用進行全面、快速的回歸測試。

目標場景

• 需要頻繁大量造數據的測試場景；
• 需要大量業務需要回歸測試的場景；
• 測試人力資源欠缺的開發場景；
• 頻繁發布，頻繁回歸測試的場景；

接下來從工作流程的角度，來講解AREX是如何工作的。

下圖是沒有接入AREX的應用的調用鏈。

圖片

當接入AREX后如下圖所示，上方是流量錄制過程，在正常的調用處理流程中，由AREX Java Agent 在調用鏈路上截取到數據并保存到AREX數據庫。

下方是回放流程，在回放請求時并不會真實地訪問第三方依賴，AREX截斷了調用鏈，由 Agent 從數據庫中讀取先前采集到的數據并返回給調用方。

AREX回放測試用例執行結束后，由AREX調用比對SDK進行比對，輸出差異結果，生成測試報告。

四、AREX技術實現與優化

流量錄制回放的概念雖然已經是老生常談，但是真正落地起來并沒有那么容易，里面有諸多難題需要解決。下面將詳細介紹我們團隊在實現AREX平臺時遇到的技術難點以及我們是如何解決這些問題的。

4.1 AREX gent錄制回放原理

以下通過一個簡單的函數，說明AREX Agent的錄制回放原理：

左側是轉換前的函數，右側是轉換后的函數。

在函數入口部分，做了回放判斷。如果需要回放，則使?采集的數據作為返回結果，也就是Mock。

函數出口部分做了錄制判斷，如果需要錄制，則將應用需要保存的中間數據，保存到 AREX 數據庫。

依賴包的注入，原理就是這么簡單。

4.2 AREX技術挑戰

AREX AGENT技術棧

由于性能好、且代碼更容易閱讀、容易理解，我們采用了ByteBuddy 庫實現字節碼修改。

此外還使用了 SPI（Service Provider Interface），這是 Java 提供的一套用來做擴展的 API，它可以用來啟用框架擴展和替換組件。我們的注入組件就是通過這個插件模式實現的。

實現TRACING

AREX的錄制功能需要將請求、應答、以及第三方的請求應答等都記錄下來，并且需要一個唯一的 Key 將這些數據串聯起來，這樣才能完整地作為一個測試用例，這個 Key 就是 AREX 的 Record ID。

以下這些類實現了 AREX 的調用鏈路。簡而言之，就是在調用鏈的入口處，Agent 會生成一個唯一的 Record ID 并將其保存到 Thread Local 變量中。在應用程序的函數頭和尾部注入 Agent 代碼，這段代碼會讀取 Thread Local 變量中的值，并將其與截取到的數據一起存儲。

解決調用鏈丟失

以上是 AREX TRACING 傳遞實現中比較普遍的基礎場景。除此以外，我們的應用中還有大量使用多線程、異步等技術的場景，這種場景下調用鏈會丟失，給數據的串聯帶來很大的困難。

為了解決調用鏈丟失的問題，我們實現了 Runnable，Callable，ForkJoinTask，Async Client 這些類的封裝。

基本原理就是在多線程代碼調用的地方，用我們封裝的類替換原有的代碼，而在封裝類中保留原有的功能，同時實現 AREX 的數據讀寫功能。

小竅門：Wrapper(包裝類) 是個關鍵詞，在代碼庫中搜索 Wrapper 可以看到所有 AREX 封裝類的實現。

實現錄制和回放注入

以下是一個實現錄制回放的代碼實例。

@Override
public List<MethodInstrumentation> methodAdvices() {
    ElementMatcher<MethodDescription> matcher = named("doFilter")
            .and(takesArgument(0, named("javax.servlet.ServletRequest")))
            .and(takesArgument(1, named("javax.servlet.ServletResponse")));

    return Collections.singletonList(new MethodInstrumentation(matcher, FilterAdvice.class.getName()));
}

當我們需要實現一個新依賴庫的注入時，是如何來實現這個插件呢？

首先，我們通過三個要素來定位到被注入的函數：

• 模塊（ModuleInstrumentation: FilterModuleInstrumentationV3）：邏輯管理的概念，是將多個注入類、或者封裝類，放到一個模塊中。
• 類型（TypeInstrumentation: FilterInstrumentationV3）：就是我們要定位到注入對象的類，即被注入的應用類。
• 函數（MethodInstrumentation）：此函數要定位到注入修改的函數。

如上例中，我們要注入的類是 CacheAspectSupport 類，所在的模塊是 CacheModuleInstrumention 模塊，要注入修改的函數是 doFilter 函數。

接下來，通過三個步驟來實現函數注入代碼的功能。以下通過一個Mybatis的 Query() 函數來更直觀地看看AREX Agent如何實現代碼注入：

步驟一：將名為 METHOD_NAME_Query（字符串“Query”）的函數與類 QueryAdvice 關聯起來，QueryAdvice 是實現注入功能的類。

步驟二：QueryAdvice 類實現了函數 OnMethodEnter()，并標注了 ByteBuddy 的 Annotation。

步驟三：QueryAdvice 類會被注入到 Query 函數的頭和尾部。

如果需要回放，則將查詢到的數據存儲在一個本地變量中；如果不需要回放，則繼續執行。

以下是 Query 函數在退出前的注入代碼：

• 如果 MOCK 結果符合條件，則返回 MOCK 數據；
• 如果當前狀態是錄制中，則將查詢 SQL+ 查詢結果原始數據保存到 AREX 的數據庫。

實現版本管理

流行的組件往往存在多個版本同時在不同的系統中使用，不同的版本實現方式差別可能很大，甚至不兼容。

針對這種問題，AREX 做到了多個版本的兼容。在應用啟動的時候，AREX Agent 會捕獲到所有的依賴包的信息，比如 JAR 包的 Manifest.MF 文件，從 Manifest 中獲取類庫的版本信息，然后根據版本信息來啟動對應的 AREX 注入代碼，由此實現實現了多個版本的兼容。

如下圖所示，設置了當前注入腳本適配的版本范圍，這樣 AREX 就可以在這些類加載前識別出應用依賴的組件版本，之后在類加載時進行版本的匹配，保證正確的代碼注入。

實現代碼隔離

由于 AREX 大多數的使用場景是在生產環境進行錄制，在測試環境進行回放，因此穩定性至關重要。為了系統的穩定性，防止 Agent 的代碼影響到被測應用的代碼執行，AREX 實現了代碼隔離互通。

AREX核心JAR是在一個獨立的ClassLoader中加載，和用戶的應用代碼不互通。為了保證注入的代碼可以在運行時被正確訪問，對 ClassLoader進行了簡單的修飾，如下圖所示。

解決時間問題

攜程的很多業務場景是時間敏感的，經常會遇到錄制的時間在回放的時候已經過期了，業務邏輯走不下去，導致回放失敗的情況。

我們用自己實現的 currentTimeMillis() 代理了 Java 原有的 currentTimeMillis() 調用，時間的記錄和回放都將按照錄制當時的場景來執行，從而實現了時間的 Mock。

在AREX Agent #182 針對此場景進行了詳細的描述：

解決緩存問題

實際應用中會使用各式緩存來提升運行時的性能，由于緩存數據的差異導致的執行結果不一致，在錄制回放里邊是一個很大的問題。

AREX 提供了動態類 Mock 的功能，實現方法是將訪問本地緩存的方法配置成動態類，相當于你自定義了這個方法進行 Mock，會在生產環境錄制你配置的這個動態類方法的數據，回放相應的匹配出數據返回。

當然這種方式也存在不足之處：

• 緩存配置容易忽略，對回放通過率有很大影響；
• 每個應用都有自己的緩存實現，無法提前處理，需要人工參與，有配置成本。

4.3 AREX其他優勢

支持寫接口測試

要驗證系統修改后的業務正確性，僅校驗返回結果是遠遠不夠的，通常還需要驗證中間過程數據的正確性，例如業務系統寫數據庫的數據內容是否正確等等。

針對這一點，AREX 在寫接口測試也做了完美支持。

AREX 在錄制和回放的過程中會記錄下新舊版本系統對外的數據庫請求，并將這兩個請求進行比對，如果存在差異則會在回放報告中進行展示

由于 AREX MOCK 了所有對第三方依賴的請求，支持數據庫、消息隊列、Redis 數據的驗證，甚至支持驗證運行時的內存數據，并且在回放的過程中不會真的產生對數據庫的調用，因此不會產生臟數據。

生產問題快速定位

在實際使用過程中，AREX 還可以用來實現生產問題的快速定位。

生產問題出現后因版本差異、數據差異等問題，導致開發人員難以在本地復現，進行 Debug 的成本很高，很費事費力。

利用 AREX，可以強制在生產環境錄制有問題的 Case（應答報文中會生成唯一的 Record ID），隨后啟動本地開發環境，發送請求的報文頭添加此 Record ID，就可以在本地復原錄制到的請求和數據，隨后利用本地代碼直接 Debug 生產問題。

五、AREX自動化測試的實施與展望

5.1 AREX在攜程的推行效果

各BU在接入AREX后，除去前期需要一些熟悉工具、配置的學習成本外，明顯減少了測試開發人員在自動化用例開發、數據 MOCK、構造數據方面的工作量，形成了良性循環，減少了漏測并增加了覆蓋范圍，有效提升了產品的質量。

其中在兩個場景效果最顯著：

• 技術重構項目，特別是請求應答不修改的場景。這種使用場景下，幾乎不需要測試人員參與，開發人員自己就可以通過 AREX 進行快速自測，保證質量。
•  開發人員提升自測質量。

5.2 AREX優化

初期AREX在攜程內部試用階段，大家對工具的評價還是很好的。但是，在擴大使用范圍、特別是在有其他團隊非主動接入時，就出現了各種問題：

• 誤報率高（時間、uuid、序列號等等)，前期比對過濾配置多。
• 代碼變更的預期確認很麻煩，人工干預量大。

目前我們正在對AREX配置和比對能力進行重點優化。

配置增強

現階段要保證高比對通過率需要大量的人工干預（比對忽略配置等），所以首先要做的就是降低用戶配置成本：

• 可視化直觀展示差異點
• 人工標記操作提升易用性
• 配置更新可重算和重新執行

同類聚合

通過聚合的方式將同類的錯誤進行多維度聚合，方便開發人員觀察差異。最終達到大部分情況下，開發只要確認一個差異就可以去掉大部分的比對差異的效果

算法降噪

1）預分析降噪

預分析降噪是將錄制流量的生產版本發布到測試環境，對此版本進行回放并比對其差異，提前識別出類似于 token，序列號等的“噪聲”點。

之后將噪聲標記到規則庫，作為知識庫。

最后識別報文和數據的 Schema 變更，進行主動降噪，減少用戶手工配置的成本。

2）比對知識庫

比對是AREX的核心能力，但目前的比對是比較粗略的，誤報率較高，我們希望可以做到在迭代測試中，增加比對知識的積累（非人工干預），形成比對知識庫，幫助用戶準確識別有效差異。例如將 Schema 的定義轉成有效的比對規則。

精準測試

精準測試是為了縮小測試范圍，后續AREX中也會引入精準測試，主要目的是做到明確比對差異的來源。

我們計劃將代碼變更、代碼執行鏈路與AREX的回放關聯起來，通過代碼變更與差異結果的雙向追溯，讓用戶“可觀察”地確認問題。首先識別差異是否是由代碼更新導致的預期中的差異，進一步主動過濾識別非預期問題的差異點。

經過對比對差異結果的優化處理，可以有效地降低研發配置成本、提升差異結果的精確度，這才是AREX的自動化回歸測試真正可以落地的價值所在。

六、寫在最后

AREX經過不斷優化，逐步達到了用真實流量和數據進行回歸測試的目標，降低了成本，提高了質量，達到了建設初期設定的目標。

當然還有很多需要優化和提升的地方，包括算法、性能、支持范圍等等，需要進一步的優化發展。也希望各位有志之士可以加入到我們AREX開源項目的共建當中。