01 背景

傳統軟件測試技術主要基于測試人員對業務的理解，但由于經驗的局限性、被測系統的復雜性以及與真實業務數據的差距，肯定存在測試不充分的情況，所以，雖然整個測試流程很規范，但最終軟件質量還是不盡如人意。而隨著分布式、微服務架構、大數據技術的出現，軟件越來越復雜，迭代越來越快，測試的挑戰性越來越大。測試人員急切的需要一套更加精確、高效的測試技術和方法。精準化測試技術就在這種背景下應運而生并快速發展。 精準化測試技術是一種可追溯的軟件測試技術，通過構建一套計算機測試輔助分析系統，對測試過程的活動進行監控，將采集到的監控數據進行分析，得到精準的量化數據，使用這些量化數據進行質量評價，利用這些分析數據可以促進測試過程的不斷完善，形成度量及分析閉環，實現軟件測試從經驗型方法向技術型方法的轉型。

02 定義

在對精準測試下定義之前我們先看幾個精準測試需要解決的問題：

如何刻畫和度量有限測試集合的充分性

如何挑選有限測試集合并充分執行

如何讓上述過程更加自動化、更加精準

那我們可以得到精準測試需要包含的幾個特性：

全不全：通過代碼覆蓋率度量測試充分性

準不準：通過精準推薦代替人工進行變更影響范圍評估指導用例回歸

快不快：精準推薦自動化&用例執行失敗快速定位等

然后我們可以將其定義為：精準測試是基于代碼和用例關聯關系的測試充分性度量和提升手段之一。

03 實現思路

首先貼一張流程圖：

整體使用有兩條鏈路： 1.靜態掃描+推薦測試范圍，流程如下：

原始代碼靜態掃描，獲取基礎函數調用鏈

原數據解析，掃描結果存儲至Neo4j

代碼diff獲取版本差異，圖譜查詢影響接口范圍

測試范圍推薦

2.動態追蹤+推薦測試用例，流程如下：

業務代碼插樁

插樁后執行業務/自動化測試用例

采集“用例-函數調用鏈”權重

代碼diff獲取版本差異

測試用例推薦

04 技術架構

4.1 技術選型

4.2 測試范圍評估實踐

4.2.1

原始代碼靜態掃描，獲取基礎函數調用鏈

首先會有兩輪掃描： 1. 自研算法獲取函數的基礎調用鏈，獲取函數節點及調用關系

2. AST掃描，獲取函數節點補充信息

AST是抽象語法樹(Abstract Syntax Tree)的簡稱，AST以樹狀形式表現編程語言的語法結構，樹上每個節點都表示源代碼中的一種結構。

4.2.2

原數據解析，掃描結果存儲至Neo4j

在獲取到調用鏈的graph數據后，遍歷轉換成存入Neo4j所需的cypher語句

如上圖所示，圖譜最基本的組成單位，存在(代碼所屬包)-[包含]->(文件)-[包含]->(函數)-[調用]->(函數)的結構 在獲取項目調用鏈原數據后，再深度遍歷每一條調用鏈路采集每個包、文件、函數的對應關系，以及路徑、所處位置、出參入參、注釋、代碼行等信息，寫入Neo4j。

4.2.3

代碼diff獲取版本差異，圖譜查詢影響接口范圍

通過git開放api，我們可以在git diff內獲取兩次commit對比

通過文件路徑與函數名，我們可以找到對應的函數節點

然后通過圖譜向上追蹤查詢完整的調用鏈路，最終獲取到影響的接口

4.2.4 測試范圍推薦

可視化頁面展示版本代碼對比，與影響的接口(服務端)、頁面/組件(客戶端)

4.3 測試用例推薦實踐

下面主要講解調用鏈獲取及加權部分

4.3.1 業務代碼插樁

修改編譯邏輯，在開始編譯前通過AST解析插入覆蓋率和Trace的采集器

4.3.2 用例執行

通過代理服務執行測試用例，采集“用例-調用鏈”的映射關系

4.3.3 采集“用例-函數調用鏈”權重

對關聯關系進行加權計算后，存入Neo4j。 下面舉例幾種不同的權重計算方式：調用次數加權

假如有一條測試用例，執行時經過了Api_1和Api_2兩個接口 然后Api_1執行時經過了函數FuncA、FuncC、FuncE Api_2執行時經過了函數FuncB、FuncD、FuncE 我們可以理解為該條測試用例，對于函數A、B、C、D、E的調用次數加權分別為1、1、1、1、2業務模塊加權這是半手工的方式，如果在用例管理系統中，有一條case屬于“書架”模塊，那我們可以將不同層級的代碼，處于bookshelf目錄下的函數，都與該case綁定一個“同模塊(module_weight)”的關系(relationship)

文本相似度加權通過對測試用例庫內的所有用例，進行分詞、建立詞庫，使用tf-idf的方式計算用例與用例間的文本相似度，來計算用例的相似性

此方案對測試人員編寫用例時的要求較高，如果會有不同的測試人員去測試相同模塊，因為書寫習慣不一樣，可能會導致case計算結果不準確，所以我們引入GCN計算case的相似性GCN(圖卷積神經網絡)計算用例相似性實際使用中，我們會采取不同的特征來訓練GCN，用于計算不同場景的結果 在這里我們舉一個簡單的例子，用于計算case的相似性：

1. 我們通過采集不同case對函數的調用層級，構成一個C × N的稀疏矩陣 （C：測試用例個數，N：函數節點數） 2. 將調用層級數取反，然后歸一化，得到訓練模型用的矩陣 3. 根據GCN的定義X'=σ(L ?symXW)來定義GCN層，然后堆疊兩層GCN構建圖卷積網絡 4. 訓練完后，通過TSNE將輸出層的score嵌入進行二維化處理，計算每個節點與節點的歐式距離，再存入Neo4j

4.3.4 代碼diff獲取版本差異

與步驟4.2.4一樣，通過代碼diff獲取改動的函數節點，然后通過權重計算獲取測試用例。

4.3.5 測試用例推薦

如果是業務用例則自動創建測試計劃，并關聯測試用例。 如果是自動化測試用例，則自動導入用例所處的文件、函數信息。

05 落地效果

目前平臺在MR、冒煙、提測、回歸、上線等不同階段，采取了8種不同的質量保障措施：

迭代時間由3周縮短至2周

版本平均需執行自動化用例數減少80%

回歸測試階段平均需執行用例數減少60%

覆蓋率需統計代碼減少90%

06 未來展望

隨著增量用例的增多，數據量提高，進一步提高GCN的計算結果準確度

打造調用鏈代碼染色+頁面可視化功能，助力測試環境問題定位

審核編輯：郭婷