01 背景

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

02 定義

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

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

如何挑選有限測試集合并充分執(zhí)行

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

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

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

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

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

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

03 實現(xiàn)思路

首先貼一張流程圖：

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

原始代碼靜態(tài)掃描，獲取基礎(chǔ)函數(shù)調(diào)用鏈

原數(shù)據(jù)解析，掃描結(jié)果存儲至Neo4j

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

測試范圍推薦

2.動態(tài)追蹤+推薦測試用例，流程如下：

業(yè)務(wù)代碼插樁

插樁后執(zhí)行業(yè)務(wù)/自動化測試用例

采集“用例-函數(shù)調(diào)用鏈”權(quán)重

代碼diff獲取版本差異

測試用例推薦

04 技術(shù)架構(gòu)

4.1 技術(shù)選型

4.2 測試范圍評估實踐

4.2.1

原始代碼靜態(tài)掃描，獲取基礎(chǔ)函數(shù)調(diào)用鏈

首先會有兩輪掃描： 1. 自研算法獲取函數(shù)的基礎(chǔ)調(diào)用鏈，獲取函數(shù)節(jié)點及調(diào)用關(guān)系

2. AST掃描，獲取函數(shù)節(jié)點補充信息

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

4.2.2

原數(shù)據(jù)解析，掃描結(jié)果存儲至Neo4j

在獲取到調(diào)用鏈的graph數(shù)據(jù)后，遍歷轉(zhuǎn)換成存入Neo4j所需的cypher語句

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

4.2.3

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

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

通過文件路徑與函數(shù)名，我們可以找到對應(yīng)的函數(shù)節(jié)點

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

4.2.4 測試范圍推薦

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

4.3 測試用例推薦實踐

下面主要講解調(diào)用鏈獲取及加權(quán)部分

4.3.1 業(yè)務(wù)代碼插樁

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

4.3.2 用例執(zhí)行

通過代理服務(wù)執(zhí)行測試用例，采集“用例-調(diào)用鏈”的映射關(guān)系

4.3.3 采集“用例-函數(shù)調(diào)用鏈”權(quán)重

對關(guān)聯(lián)關(guān)系進行加權(quán)計算后，存入Neo4j。 下面舉例幾種不同的權(quán)重計算方式：調(diào)用次數(shù)加權(quán)

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

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

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

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

4.3.4 代碼diff獲取版本差異

與步驟4.2.4一樣，通過代碼diff獲取改動的函數(shù)節(jié)點，然后通過權(quán)重計算獲取測試用例。

4.3.5 測試用例推薦

如果是業(yè)務(wù)用例則自動創(chuàng)建測試計劃，并關(guān)聯(lián)測試用例。 如果是自動化測試用例，則自動導(dǎo)入用例所處的文件、函數(shù)信息。

05 落地效果

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

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

版本平均需執(zhí)行自動化用例數(shù)減少80%

回歸測試階段平均需執(zhí)行用例數(shù)減少60%

覆蓋率需統(tǒng)計代碼減少90%

06 未來展望

隨著增量用例的增多，數(shù)據(jù)量提高，進一步提高GCN的計算結(jié)果準確度

打造調(diào)用鏈代碼染色+頁面可視化功能，助力測試環(huán)境問題定位

審核編輯：郭婷