程式碼精準分析在閒魚介面測試中的應用

作者：閒魚技術——問衿

一、背景

在服務端的質量保障中介面測試一直佔據著重要的作用，從最開始的手工測試到編寫介面測試程式碼，再到後來的基於流量錄製的介面回放，測試效率不斷得到提高，但是風險評估主要還是依賴開發同學以及測試同學對業務的熟悉程度，沒有相應的工具予以支撐，迴歸的時候也沒有重點，通常會全量回歸，避免遺漏。因此開發相應的工具及平臺精準確定程式碼的改動範圍，有效評估影響面，提高迴歸效率。

二、方案概述

服務端主要對外提供 HTTP及RPC 介面，可以將其看作是入口型的介面，流量錄製平臺通常獲取的都是HTTP 及 RPC 級別的流量，因此我們主要的解決思路如下：
step1：通過訂閱 Gitlab 的訊息獲取程式碼的改動資訊，包括改動的程式碼行範圍，修改的類檔案等
step2：分析程式碼的差異，根據改動的程式碼行範圍判斷修改了哪些方法
step3：通過流量錄製平臺本身的能力獲取 HTTP及 RPC 介面的呼叫鏈路，建立方法和入口介面的對映關係，此時根據修改變動的方法就可以查詢到對應的入口介面
step4：通過流量錄製平臺獲取到對應的流量用例。其中錄製的就是HTTP及 RPC 介面流量用例
step5：建立變動方法與流量用例之間的對映關係
下面就通過主要的四個方面展開闡述：程式碼差異化分析，方法呼叫鏈路解析，流量錄製，用例關聯。

圖1 流程概覽

三、程式碼差異化分析

程式碼改動之後，我們希望知道程式碼改動的影響範圍和影響程度。影響範圍包括影響到了哪些介面，影響到了哪些呼叫這個介面的應用；影響程度指的是影響的介面或者應用是否是強依賴或者是核心的，目前我們實現了獲取到影響到哪些介面的能力，其餘的內容我們計劃後續實現。圖2是程式碼差異化分析整體流程圖。

圖2 差異化分析流程圖
對於程式碼的差異化分析目前我們支援 Java，Objc，以及 Flutter。Java解析使用開源的Java解析器，Objc 及Flutter通過各自的語法進行處理，自行實現了簡單的方法解析器；其中在解析時使用了Gitlab傳遞過來的變動程式碼行範圍資料，通過程式碼行來進行檢索判斷。考慮到 Java 解析器有現成的開源工具，Objc 以及 Flutter 需要自行實現，現以 Objc 舉例說明具體的解析過程：
1、根據 Git diff 資訊獲取變動的程式碼檔案路徑及程式碼行範圍，如圖3 所示，變動的程式碼行範圍是[1200,1207]。

圖3 Git diff 資訊
2、在步驟1中我們可以獲取到變動的程式碼檔案路徑，可以下載對應的程式碼檔案作為解析的資料來源
3、按行解析，判斷該行是否是方法宣告，如果是，記錄下程式碼行數作為當前方法的起始行，同時按行向上搜尋判斷是否含有方法結束標誌，如果有那麼記錄下行數作為上一個方法的終止行。最終我們獲取到了程式碼檔案的類似 AST的一個數據結構，其中以方法塊的形式記錄了各個方法名及其起始和終止行數。比如圖4展示了對應的資料結構。

圖4 方法塊資料結構
4、根據 Git diff 中獲取的程式碼行變動範圍在上述的方法塊資料結構中檢索，如果程式碼行範圍是方法塊行範圍的子集，那麼就命中了該方法，就返回該方法名，根據圖3的程式碼變化範圍可以在如圖4 的資料結構中發現匹配的方法名是 getName。

三、方法呼叫鏈路解析

方法呼叫鏈路的獲取我們採用流量錄製平臺提供的能力，但是由於獲取方法呼叫鏈路的模組在載入後對應用的響應時間影響比較大，目前該模組只在預發載入，因此我們需要錄製預發的流量，預發的流量僅用於方法呼叫鏈路的分析。

圖5 流量錄製與方法鏈路獲取
圖5 展示了預發流量的錄製與方法鏈路的獲取流程。獲取到預發流量之後，我們通過流量的唯一標識id呼叫流量錄製平臺的API獲取整個呼叫鏈下的方法，舉個例子，比如RPC介面：[email protected]，如圖6所示可以獲取對應的呼叫鏈資訊，根據其中 method 欄位即可解析出方法鏈路列表，因此建立了方法 getName，getAdress 與RPC介面 [email protected] 之間的對映關係。

圖6 方法鏈路獲取

四、流量錄製

在實際使用中我們採用流量錄製平臺進行流量錄製，通過介面呼叫獲取前 N 天的流量，具體規則可配置，由於流量本身是非線性的，部分流量可能很大，所以我們通過排程平臺從應用的緯度出發，進行任務排程定時執行，保證流量及時更新，覆蓋更多小流量介面，具體流程圖如圖5所示。只不過此時錄製的流量是線上流量，而不是預發流量，但是整體流程一致，並且錄製的 HTTP 及 RPC 介面也是一致的。錄製的流量作為用例儲存在資料庫，比如在線上環境我們錄製了RPC 介面 [email protected] 的流量，那麼就可以建立RPC 介面[email protected] 與流量之間的對映關係，落庫到資料庫時流量是以流量 id 進行儲存，否則資料量過大不便處理。

五、用例關聯

在程式碼差異化分析之後我們已經獲取了變動的方法名，經過呼叫鏈路的分析，我們建立了變動的方法和HTTP或者RPC介面的對映關係，那麼如何將其與用例進行關聯？我們通過流量錄製平臺錄製線上流量，建立HTTP或者RPC介面同流量資料之間的對映關係，繼而建立了變動的方法同流量用例之間的對映關係。具體而言，首先我們會積累各個應用 HTTP 及 RPC 的線上流量資訊，建立HTTP及RPC介面同流量之間的關係，同時將對應介面的方法鏈路資訊解析後儲存在資料庫，此時建立了HTTP或者RPC入口同介面呼叫過程中的方法之間的關聯；程式碼發生變動後，我們可以獲取變動的方法名，從上面的對映關係可以推斷根據方法名可以找到對應的流量用例。
當專案提測時，會根據應用及應用開發分支獲取變動方法，繼而查詢到對應的HTTP及RPC方法，之後自然就獲得了服務端的流量資料，就可以觸發用例迴歸。整個過程中可以清晰地看到影響的介面，並且可以執行對應的用例，通過影響的介面可以評估影響範圍，做到心中有數，而不是強依賴開發同學的判斷，從而對介面變更風險有了準確的評估。

六、效果及展望

在未採用精準測試服務之前，服務端介面發生變更之後，我們採用全量回歸方式，按照每個應用每天提交n次，N個核心應用，以一週的時間計算，單次迴歸時間是M，M一般是在幾分鐘左右，那麼總體的用例迴歸時間是MNn7，並且並不具備精準性；通過程式碼精準分析之後不必採用全量回歸的方式，只要針對性進行迴歸即可，單次介面迴歸時間假設為K，K一般是小於一分鐘，以一週為維度計算，總體的介面迴歸時間：KNn7，那麼相比未採用精準測試服務之前總體耗費的時間大大降低。
精準測試是服務端介面測試的進一步延伸，除了應用於介面測試之外，本身積累的大量資料，比如程式碼提交記錄，變動的方法，流量的分佈，方法鏈路的變動等可以為後續專案風險評估，整體質量預測，業務服務監控等提供支援，並且可以作為一項基礎服務為其他的測試能力提供支撐。