作者 | 阿里文娛測試開發專家 正辰
出品 | CSDN（ID：CSDNnews）
對比測試的原理和現狀
引流對比測試是目前阿里內部常用的一種迴歸測試手段，它基於線上真實流量做採集、回放、對比，通過對比結果評估代碼變更是否影響了線上鏈路和功能。通過這種方案，極大地降低了手工構造測試數據的成本：
1）基於用戶真實請求，對於複雜業務的接口，降低了模擬用戶場景的成本；
2）採集流量足夠多的時候，可以對業務場景做全覆蓋測試，減少測試遺漏；
3）測試環境穩定，結果明確可靠，並且不需要手工測試執行。目前線上請求採集策略主要是按比例隨機採集，從使用情況來看，存在一些問題：
1）從測試的角度，我們並不清楚採集到的流量是否覆蓋了核心場景。用測試的話來說：這些流量到底覆蓋了哪些用例？無法有效度量；
2）線上持續採集的情況下，回放請求要及時手工維護，排除失效或者重複請求；
3）採集配置多個接口時，由於大流量接口占比很高，導致小流量接口採集不到有效流量， 需要手動調整採集配置。
基於以上這些問題，不難發現，採集請求的有效性和覆蓋度是對比測試能持續發揮作用的關鍵問題。如何破解？優酷在對比測試中引入熱度鏈路覆蓋率，實現了一套基於線上熱度鏈路覆蓋的精準對比測試方案。
如何有效度量測試覆蓋率？
1．代碼覆蓋率
傳統的測試覆蓋率統計方法，測試之前先對代碼文件進行插樁，生成插過樁的 class 文件或 者 jar 包，測試執行後，會自動收集走到的代碼路徑，生成覆蓋率信息到文件，最後統一對覆蓋 率信息進行處理，生成覆蓋率報告。度量覆蓋率的主要指標有：代碼行覆蓋、代碼分支覆蓋、 方法覆蓋等等。
1）代碼覆蓋率的優點：
a）原理和方案比較成熟，有很多現成的工具，實現成本比較低；
b）度量維度比較多，能結合多個指標全面評估代碼覆蓋率。
2）代碼覆蓋率的問題：
a）無法有效評估業務場景的覆蓋率。代碼覆蓋率高只能說明代碼被執行到了，並不能說明 業務場景被覆蓋了，業務場景的覆蓋率還需要手工評估；
b）覆蓋率分析成本比較高。由於代碼質量問題（無效代碼或者冗餘代碼），很多代碼不會 被真實的業務場景調用到，這部分代碼很難做到測試覆蓋，覆蓋的價值也不高，並不一定需要 覆蓋。
2．子調用鏈路覆蓋率
通過在中間件代碼中插樁，統一實現對外部子調用的代碼路徑採集，從而聚合出代碼走過 的子調用鏈路，然後通過聚合鏈路請求得出每條子調用鏈路的熱度，從而獲得線上真實用戶場 景的鏈路分佈情況。子調用鏈路精準反饋了業務場景的鏈路和熱度，這種基於線上真實請求得
出的覆蓋率評估方案，目前在阿里內部被廣泛使用。度量覆蓋率的主要指標是：子調用鏈路覆 蓋率。
1）相比傳統的代碼覆蓋率：
a）基於線上真實用戶請求分析代碼執行路徑，通過子調用鏈路代表用戶場景，能準確評估業務場景的覆蓋情況；
b）統一在中間件代碼中插樁，業務代碼無需改動，接入成本比較低。基於子調用鏈路覆蓋率評估，是否可以解決對比測試提出的覆蓋率評估難題呢？是否也能適合優酷的業務場景？在試運行一段時間後，我們發現優酷一些業務採集到的子調用鏈路特別少，和業務的體量、複雜度不一致。帶著這個疑問，我們看看下面兩個請求的代碼運行鏈路：
2）基於以上代碼運行鏈路分析：
a）部分業務外部依賴比較少，主要邏輯在應用內部，導致代碼運行的外部子調用完全一樣，但內部方法鏈路不一樣；
b）評估業務內部邏輯覆蓋的話，內部方法鏈路覆蓋要比子調用鏈路覆蓋更有效。如果能聚合出內部方法鏈路，對優酷業務場景的覆蓋率評估會更有指導意義。於是優酷和集團 JVM-SANDBOX 團隊深入合作，提出了一套內部方法鏈路覆蓋率的評估方案：熱度鏈路覆蓋率。
基於熱度鏈路推薦的對比測試
通過收集一段時間內的線上真實請求，並記錄下請求執行過的方法路徑，即為鏈路。線上不同的真實請求很多都是走的同一個鏈路，這樣不同的鏈路就有不同的熱度，根據鏈路熱度可 以自動評估出需要優先覆蓋的鏈路，即為熱度鏈路。
1．方法鏈路感知
要採集方法路徑，首先需要感知到每個方法的執行。利用 JVM-SANDBOX 底層模塊的能 力，能統一在每個內部方法做代碼增強，感知到每個方法“運行前”、“返回前”、“異常後”三 個事件，從而收集到代碼執行到的方法數據，聚合成方法鏈路。
1）BEFORE 事件：感知和改變入參；直接返回；
2）RETURN 事件：感知和改變返回值；重新構造返回結果；拋異常；
3）THROWS 事件：重新構造異常；模擬正常返回。
2．採集模塊部署
在模塊部署環節，最大的挑戰是配置需要增強的代碼邏輯類。最開始由各個業務方自己配 置，但由於配置範圍沒有統一標準，導致採集的鏈路不完成，很難獲取比較。根據優酷的業務 特性，我們統一提供了一套代碼邏輯類掃描服務，支持優酷各個業務的代碼解析和邏輯類掃描， 為每個業務方提供統一的代碼增強配置標準。接入過程如下：
1）TraceModule：採集運行鏈路；2）Repeater：採集請求和返回結果，錄製回放；3）MockModule：服務端動態 Mock。
3．鏈路採集和熱度計算
線上模塊激活後，就可以根據配置的採樣比率，持續採集線上流量，並聚合方法鏈路。
有了應用鏈路數據做參考後，通過採集線上請求，並識別出請求的鏈路，就可以按照熱度 鏈路或者全部鏈路推薦對比請求，通過擴大請求採集週期（推薦採集週期為 7 天），最後推薦的 請求可以覆蓋線上全部業務鏈路，不僅提升了對比測試的有效覆蓋率，而且推薦過程高效且全自動化，全程不需要人工干預，可以快速推廣到服務端所有應用的對比測試。
回顧&展望
基於熱度鏈路分析，可以輔助測試更具體地理解真實的業務場景，除了用於推薦對比測試請求，在優酷服務端迴歸體系中，也用於評估迴歸測試的覆蓋率，相比傳統的代碼覆蓋率評估，業務指導意義更明確。
當然，對於高熱度的鏈路，可能包含了大量的用戶請求，也包含了不同的業務含義，如果只覆蓋其中一條請求，雖然鏈路覆蓋了，但會造成業務覆蓋損失，後期我們可以通過機器學習，智能聚類，讓機器來篩選出覆蓋更完整、更精確的測試集，深度挖掘線上請求數據的價值，輔助測試建設更有意義的質量保障體系。
閱讀更多 CSDN 的文章
