代碼精準分析在閑魚接口測試中的應用

作者：閑魚技術——問衿

一、背景

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

二、方案概述

服務端主要對外提供 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接口：com.idle.test.openService@getInfo~II，如圖6所示可以擷取對應的調用鍊資訊，根據其中 method 字段即可解析出方法鍊路清單，是以建立了方法 getName，getAdress 與RPC接口 com.idle.test.openService@getInfo~II 之間的映射關系。

圖6 方法鍊路擷取

四、流量錄制

在實際使用中我們采用流量錄制平台進行流量錄制，通過接口調用擷取前 N 天的流量，具體規則可配置，由于流量本身是非線性的，部分流量可能很大，是以我們通過排程平台從應用的緯度出發，進行任務排程定時執行，保證流量及時更新，覆寫更多小流量接口，具體流程圖如圖5所示。隻不過此時錄制的流量是線上流量，而不是預發流量，但是整體流程一緻，并且錄制的 HTTP 及 RPC 接口也是一緻的。錄制的流量作為用例儲存在資料庫，比如線上上環境我們錄制了RPC 接口 com.idle.test.openService@getInfo~II 的流量，那麼就可以建立RPC 接口com.idle.test.openService@getInfo~II 與流量之間的映射關系，落庫到資料庫時流量是以流量 id 進行儲存，否則資料量過大不便處理。

五、用例關聯

在代碼差異化分析之後我們已經擷取了變動的方法名，經過調用鍊路的分析，我們建立了變動的方法和HTTP或者RPC接口的映射關系，那麼如何将其與用例進行關聯？我們通過流量錄制平台錄制線上流量，建立HTTP或者RPC接口同流量資料之間的映射關系，繼而建立了變動的方法同流量用例之間的映射關系。具體而言，首先我們會積累各個應用 HTTP 及 RPC 的線上流量資訊，建立HTTP及RPC接口同流量之間的關系，同時将對應接口的方法鍊路資訊解析後儲存在資料庫，此時建立了HTTP或者RPC入口同接口調用過程中的方法之間的關聯；代碼發生變動後，我們可以擷取變動的方法名，從上面的映射關系可以推斷根據方法名可以找到對應的流量用例。

當項目提測時，會根據應用及應用開發分支擷取變動方法，繼而查詢到對應的HTTP及RPC方法，之後自然就獲得了服務端的流量資料，就可以觸發用例回歸。整個過程中可以清晰地看到影響的接口，并且可以執行對應的用例，通過影響的接口可以評估影響範圍，做到心中有數，而不是強依賴開發同學的判斷，進而對接口變更風險有了準确的評估。

六、效果及展望

在未采用精準測試服務之前，服務端接口發生變更之後，我們采用全量回歸方式，按照每個應用每天送出n次，N個核心應用，以一周的時間計算，單次回歸時間是M，M一般是在幾分鐘左右，那麼總體的用例回歸時間是MNn7，并且并不具備精準性；通過代碼精準分析之後不必采用全量回歸的方式，隻要針對性進行回歸即可，單次接口回歸時間假設為K，K一般是小于一分鐘，以一周為次元計算，總體的接口回歸時間：KNn7，那麼相比未采用精準測試服務之前總體耗費的時間大大降低。

精準測試是服務端接口測試的進一步延伸，除了應用于接口測試之外，本身積累的大量資料，比如代碼送出記錄，變動的方法，流量的分布，方法鍊路的變動等可以為後續項目風險評估，整體品質預測，業務服務監控等提供支援，并且可以作為一項基礎服務為其他的測試能力提供支撐。