【乾貨分享】研效最佳化實踐：AI演算法助力深層BUG挖掘

導語

隨著產品線上上的持續運營，產品線上上的規模越來越大，功能也越來越複雜。產品體量的增長對質量要求越來越高。為了達到更高的質量要求，必然需要想辦法增加測試的強度，但用傳統的手工寫用例自動化迴歸的方式成本過高。近年來，AI技術在越來越多的領域發揮了越來越重要的作用。在騰訊內部，我們也一直保持著對新技術的好奇心，積極學習並應用於日常工作中。本文作者是騰訊安全部系統測試高階工程師林軍克，他擁有16年的軟體測試經驗，對AI技術在測試領域的落地頗有研究。

 

本文 以安全防護產品舉例子，但此方法論適用於涉及多因素組合導致的BUG的深度挖掘。 下面所示的圖為典型的流量攻擊的防護流程：駭客在網際網路上對業務伺服器發起攻擊，我們有檢測流量的裝置檢測攻擊，檢測到攻擊後自動啟動防護，將被攻擊IP的流量導流到防禦設 備，在防禦裝置上對流量進行清洗後將正常流量重新轉發到業務伺服器。

 

 

01

安全產品測試的痛點分析

 

安全防護產品特點：

1，黑產攻擊手法多樣且快速翻新，需要產品能快速響應現網的新攻擊手法，但絕不能誤殺正常使用者，所以產品防護策略非常多。下面的表格顯示主要策略檔案中配置項的數量，加起來達到兩三百個，且數量還在快速增長中。每迭代一個版本又會增加大量新配置項，處理邏輯非常複雜。

主要的策略配置檔案	策略項置項數量
anti_*******.conf	50
anti_*******.conf	147
********.conf	11
********.conf	11
********.conf	10

即便開發非常小心，實際上仍無法確保每個功能都是高內聚低耦合的，有時候仍難免會出現原本不相關的配置項間相互影響的情況。如果本不相互影響的開關間存在不應有的影響，可能導致切換策略後防護不可控。我們內部曾經出現過一個非預期的影響導致故障的例子，當時的故障是：一個防護UDP流量的配置項影響了HTTPS流量的防護功能，然而這兩個配置原本沒有任何關係。因此我們需要測試在各種組合的策略下，產品功能都能夠穩定可靠。

 

2，對於特定的流量，最終絕大部份流量會被某個特定的防護模組防保護。利用這個特點可以簡化模型，我們可以抓住主要特徵進行建模，其它的防護細節可以暫時不關注。

 

業界解決這種引數組合導致的問題主要利用全對偶演算法來對引數進行兩兩組合。生成的測試集可以用最少的組合數覆蓋任意兩個變數的所有取值組合。在理論上，該用例集能夠暴露所有由兩個變數共同作用而引發的缺陷。雖然這種演算法生成的組合數最少，但如果新增了新的引數重新生成組合，新的組合跟之前的組合完全沒有關聯。所以當引數較少時，我們經常用它來縮減用例數，同時保持較好的測試覆蓋。但是一旦引數量較多時，每次都生成全新的組合，每次都要根據組合重新計算預期結果，整個過程就將變得十分複雜。難以解決“數百個開關在不同的配置下對於特定流量的防護手法”的問題。

 

我們專案組內目前都是用手工增加用例，自動化執行用例。在這種方式下，每次新增配置項都要保持全對偶其實很難。例如，假設目前己有的用例都是全對偶的，現在新增一個配置項，這個配置項只能取0和1兩個值。為了保徵所有引數都組合一遍，那麼必須在原來所有用例的基礎上新增配置項取0時測一遍，取1時再測一遍。每增加一個配置項用例數翻一翻，用例數非常龐大。如果每次都全新生成組合的話，150個配置開關在全新生成全對偶組合的情況下只有約130種組合。而增量方式可達2^150種組合。

 

02

業界是如何自動化生成用例的

 

那業界有沒有既能夠全新生成組合數少又不需要重新人工計算預期結果的方案呢？答案是有的。 UML建模技術 就是隨被測版本更新維護模型，每次測試均重新整體統籌生成全新用例進行測試。這項技術最核心價值在於： 自動化生成用例 ，用最少的用例數達到最大化功能覆蓋，最終更快更全地測試版本。這項技術的劣勢是：模型維護複雜，對於設計缺陷難以發現（用例只是機械地遍歷），沒有從使用者的角度設計用例。

 

 

03

AI在前端頁面測試領域的應用

 

近年來，AI技術的發展非常地快，AI技術也有跟UML同樣的特點： 喜歡建模型 。所以能否透過AI技術繞過複雜的建模？整體統籌用例，用最少的用例數達到最大的覆蓋。同時避免人工計算預期結果。

 

為了探索新技術應用於測試領域，我快速掃了一下AI的盲，再進行更深入的學習時發現，其實AI應用於測試領域的未來已至。業界己經有不少工具在利用AI做自動化測試了，連用例都是自動化設計的。對於前端的頁面，甚至有工具號稱只要給定URL連結，測試人員只需坐等測試結果。類似的軟體有：eggplant、appvance IQ、Sauce Labs等等。

 

透過分析發現這些技術主要利用AI的計算機視覺技術在頁面上識別所有的按紐，根據每一頁上的按紐生成遍歷樹，再根據遍歷樹自動遍歷可能經歷的路徑（user journey）。從而達到自動化設計用例，自動化測試的目的。

   

騰訊的同事之前出版過一本《AI自動化測試》的書，裡面詳細介紹了AI在影像類遊戲和資料類遊戲上的測試。

 

業界已有的這些技術都很優秀，但主要應用於前端頁面的測試，後臺的測試還沒有相應的技術。所以我們開始研究如何將AI技術應用於後臺測試，經過多種嘗試，並結合AI的特點，我們產生了一個大膽的想法：沒有人工的參與，機器不可能理解人工設計的業務邏輯，而像UML那樣構建模型又太過於重型，但AI是非常擅長處理做資料分類的，既然算不出來預期結果能否不計算？測試套只記錄流量如何處理的，記錄後由AI根據流量及防護結果分類。分完類後再按各類分析出此類的典型配置？然後人工審查典型配置下的流量處置方式是否合理。

 

04

探索AI在後臺測試中的應用

 

根據這些想法，我們很快就制定了實施方案。我們的目標：用最小的代價提升多種因素組合的覆蓋，深度挖掘深層次的BUG。方案實施成功的理論基礎是： 基於測試理論，用最少的用例數來覆蓋最多的場景。利用AI對各種場景下的響應進行歸類、洞察。 這兩塊串起來是可行的。 

計劃實施步驟如下：

Step1： 每次新增了新配置項都重新基於全對偶演算法生成配置。

Step2： 對每種配置用典型的攻擊手法並記錄被測端的防護方式。

Setp3： 透過AI分析各種防護跟配置間的關聯。找出各種防護方式最主要的配置項。

Step4： 檢查各種防護方式最相關的N種配置是否符合預期設計？

 

第一部份基於測試理論生成全對偶的組合非常簡單。我花了半天時間就實施了。為了對多個配置檔案中的配置項做組合，我設計了用配置項名@檔名的方式對配置項命名。使用pairwise工具生成。組合之後再用指令碼轉成配置檔案。

 

基於全對偶演算法一共生成了250種組合。選取27種典型特徵的流量分別發起 'GET','POST','PUT','DELETE','HEAD','OPTIONS','TRACE','CONNECT' 請求。流量種數有27*8=216種，在250種配置下分別過這216種流量並記錄下防護手法，得到250*216=54000種場景的防護記錄。記錄下來的結果是這樣的：一共分3部份，第一部份為配置項組合資料，第二部份是所發流量的名字，最後一列是被測端所用的防護手法。

 

資料有了，可以交給AI了。但是團隊只有測試專家，沒有AI專家。我們就在騰訊內部找AI專家請教，AI專家瞭解我們的需求後認為可行，但具體的落地仍然讓我們十分困擾。因為AI領域的知識跟測試領域的知識差異太大了，從頭開始學習這些知識彷彿閱讀天書一般。

 

不過只要肯動腦多學習，方法總比困難多。我找到了一個AI小白也很容易上手的data mining工具，經過反覆學習和實踐，我認為這幾個構件在我們的方案中可以應用。我建立的模型如下：

 

PCA全稱叫主成因分析構件，可以幫我們找出對結果影響很大的N個配置項，配置項對結果影響大小排序，輸出是一個一維的列表。開發設計的配置開關處理順序肯定是個網狀的，這個結果參考一下就好。分類樹對配置項影響定量分析。個人認為這個構件輸出的資訊比較有價值。

 

PCA的分析結果是這樣的。在我們的案例中，這條曲線挺平滑的，說明沒有影響特別大的配置項。

 

AI使用RANK構件分析出來的配置項對結果影響大小，跟開發的設計流程圖對了下順序，大致是可以對得上。初步印證了方案還是有點靠譜的。

 

下圖是透過分類樹對執行結果分類後的展示：

 

我們以一個典型的例子說明一下，如何根據AI的提引找到問題：AI對資料處理後得到了一張很大的分類樹圖，對資料中每一種結果都會用一種顏色標記，如圖中所示黃、紫、白綠分別是4種結果相關的資料展示。其中黃色區域的根節點上表示防護手法為dropos_***********的資料共74條。

該結果最相關配置項：

drop_***********@anti_*********.conf。

左邊葉子節點表示：

當drop_***********@anti_*********.conf配置為android、ios、linux時。

防護手法為：dropos_***********。

右邊葉子節點表示：

當drop_***********@anti_*********.con+f配置為0時。

防護手法為：************************_trans。

 

經合被測系統的防護邏輯，我看到這個地方是確實存在問題。這個功能是一個對特定OS指紋作丟棄的功能，因為我跑用例時只用linux系統發了流量，功能正常的情況下應只有linux下會丟棄。AI卻分析到當drop_***********@anti_*********.conf配置為android、ios、win、linux會丟棄，也就是說在配置為android、ios、win時有OS識別不準確的問題。我們先下記下這個點。

 

方框最下方的配置項是跟結果相關的次相關的配置項，繼續觀察其葉子結點，我們特別關注各葉子結點的比例，這個例子中這個配置項配置為不同值時，比例接近，結果傾向性也很明顯，這是耦合性低的訊號。

 

按照分類樹展示的資訊開啟原始表格，隱藏掉不相關的列並把相關聯的配置項放在一起，這個時候就可以看出問題所在。

 

按有問題場景對應的行號找出相應配置在環境上重現問題，重現問題如圖。重現問題後配置如下：

 

預期：流量在linux下發的，不應匹配上策略，預期應被轉發。實測發現流量因為os_**********被drop了：

 

這個例子說明在AI的指引下成功發現特定場景下OS指紋功能確實存在誤識別的可能，也證明了用AI分析資料的方法是可靠的。我認為AI對於測試的核心價值在於把複雜的資料以視覺化的方式呈現，使分析變得更加容易。

 

綜上所述，本方法可以解決“目前多個引數相互耦合導致的深層次BUG有但不多，但要解決這些問題需要做引數組合測試，解決的代價很大”的痛點。 用較小的代價驗證多個因素間的耦合性 。自動化生成了54000個場景的測試用例，耗時3.5天跑完，AI分析跑出的結果後，己跟開發確認了其中2個BUG。這54000個場景如果人工寫用例，按目前每人天30個用例算，節假日無休也需要4.9年才能完成。使用此方法後，生成組合只需幾分鐘，3.5天跑完，目前摸索階段預計10天也可以分析完，大大提高了測試效率。

 

關於騰訊WeTest

騰訊WeTest是由騰訊官方推出的一站式品質開放平臺。十餘年品質管理經驗，致力於質量標準建設、產品質量提升。騰訊WeTest為移動開發者提供相容性測試、雲真機、效能測試、安全防護等優秀研發工具，為百餘行業提供解決方案，覆蓋產品在研發、運營各階段的測試需求，歷經千款產品磨礪。金牌專家團隊，透過5大維度，41項指標，360度保障您的產品質量。

 

關注騰訊WeTest，瞭解更多測試乾貨知識

WeTest騰訊質量開放平臺 -專注遊戲 提升品質