機器學習會影響測試工程師的工作嗎?

機器學習以及深度學習技術迅猛發展,很多行業已經從中受益,其中軟件質量工程也從中收益良多。機器學習的很多思想和方法可以被用來解決目前軟件測試領域的多項難題。本文將會從測試設計、測試執行和測試結果分析三個維度來探討目前機器學習在其中的應用與創新。其中會涉及基于機器學習來識別 GUI 控件以提高 GUI 自動化測試的效率與穩定性、基于路徑權重來優化測試設計、基于 kNN 之類的算法對批量失敗測試用例做自動分類處理等多個案例,希望通過本文可以引發你對機器學習在軟件測試領域應用的更多思考。
人工智能應用概述
自從 2016 年 AlphaGo 以 4:1 戰勝了圍棋九段李世乭,人工智能的威力在公眾面前得到了充分的展現。這種基于改進的蒙特卡洛樹搜索、殘差卷積神經網絡的強化學習系統首次向公眾展示了其超越人類智慧的強大的力量,也使 AI 變得更加廣為人知。之后各行各業都出現了大量的基于 AI 的產品與應用,其中以機器學習,自然語言處理,計算機視覺和專家系統為支撐的應用層出不窮,大到金融分控模型,無人駕駛,輿情監控與分析,小到智能美顏,智能音箱,無處不見 AI 的應用。這類應用基本都是通過軟件來實現的,那在軟件研發的過程中,AI 技術是否也有其應用場景,并可以幫助來提高軟件研發的效能呢?那么我們今天就一起來探討一下機器學習在軟件測試領域的應用。
軟件測試技術的局限性
當前普遍采用的傳統軟件測試技術主要有以下三個方面的局限性:
從測試的執行層面來看,GUI 自動化測試的開發效率與維護成本高居不下。這個主要表現在 GUI 控件識別上,當界面發生變化,或者控件屬性發生細微變化的時候,都會引發很多自動化測試用例的維護工作量,這也正是自動化測試無法真正成為“銀彈”的一個主要原因。
從測試的設計層面來看,測試覆蓋率的鴻溝隨著產品功能點的增長而不斷放大。不知道你沒有注意到,做軟件產品研發的企業都有一個普遍特點,就是產品迭代的初期,一般研發的效率都比較高,但是隨著產品規模的不斷擴大,軟件功能的逐漸增多,軟件研發的效率會變得越來越差,有時候很小的改動都會引發大量測試需求。這個主要是由于隨著軟件生命周期的增長,功能點越來越多,因為新的功能與現有的功能進行交互,當功能點的基數很大的時候,就會引發所謂的“蝴蝶效應”,因為這個過程中測試只能線性增長,這中間就會存在大量測試無法覆蓋的盲區。為此,在快速迭代持續交付的今天,即使已經普遍采用自動化測試技術,軟件測試人員依然面臨著前所未有的壓力。下面的圖 1 很好展示了這個現象。

圖 1:測試覆蓋率的鴻溝
從測試結果分析的角度來看,失敗測試用例分析并進行分類的工作量是很大的,而且時間成本也很高。注意這里的”分類”僅限于指將失敗的測試用例分配給某個開發組來后續做進一步處理。由于互聯網產品的自動化測試大規模普及,所以自動化測試用例的數量往往比以往任何時候都多,像 eBay 這樣的大型全球化電商,全回歸自動化測試用例的數量會達到好幾萬的數量級,這個時候,哪怕只有 1% 的測試用例失敗,那么需要分析的失敗測試用例的絕對數量也是好幾百,可想而知這個如果完全基于人工來對失敗用例進行分類分發的工作量是比較大的,很難在分鐘級別完成,這就勢必拉長了整個測試的周期,降低了迭代速度。
針對上述的三個局限性,接下來我們來看看如何利用機器學習技術來優化測試的過程。
機器學習在 GUI 自動化測試執行領域的應用與創新
機器學習在 GUI 自動化測試執行領域的應用有很多種不同的思路。這里我介紹其中最主要也是具有實際落地案例的應用。
第一種是通過控件的統計學特征來識別 GUI 對象,以此來克服 GUI 控件識別的穩定性難題。早期 GUI 的自動化測試中有一種所謂的“低級錄制“和”虛擬對象“功能,是指自動化測試的回放執行是通過頁面對象像素的比較以及相對位置關系來完成的,也就是說是通過控件的像素比較來確定頁面對象的,這種技術雖然簡單直接,但是其穩定性是個大問題,而且也無法應對今天的終端設備分辨率的多樣性。那么基于統計學特征來識別 GUI 對象則是這個方法的升級版本,可以順利解決穩定性以及應對不同分辨率的難題,同時當控件的顯示發生變化的時候,依然可以做到較高的準確識別率。
那基于統計學特征的 GUI 對象識別的原理到底是怎么回事呢?這里舉個簡單的例子你應該就能一下子明白了。比如現在有個”OK“的按鈕,那么這個按鈕的深色像素(OK 的字體部分)和淺色像素(按鈕的背景色部分)所占的百分比我們是可以統計計算得到的,假定是 8:92,那么當這個按鈕的 ID 或者 XPATH 發生變化的時候,或者界面的大小發生變化的時候,再或者界面的配色發生變化的時候,這個深色像素和淺色像素的百分比是不會發生變化的,那么這個時候我們就可以通過這個百分比來唯一確定這個頁面對象了。這個百分比就是統計特征值,當我們綜合應用多個維度的統計特征,尤其是高階統計特征的時候,我們的控件識別率就會非常穩定。
目前網易公司的 AirTest 就是利用了類似的技術來完成基于 AI 的控件識別的,并且能夠很好地應對游戲測試中的對象識別。愛奇藝則更進一步,他們開發的 Aion 更是在控件識別之前利用機器學習和機器視覺對軟件界面做了圖像切割和子元素提取,進一步提高了頁面對象的識別率。
第二種方式更加直觀,即直接通過視覺外觀來查找頁面對象。比如測試代碼中可以直接指定點擊“購物車“而無需事先提供購物車圖標的 ID 和 XPATH 等定位信息。比如下面的代碼(圖 2)就是直接通過”購物車“來完成點擊操作的,其中完全沒有給出傳統的定位器信息(購物車圖標的 ID,XPATH 等)。

圖 2:直接通過“ShoppingCart“來點擊購物車圖標
這個的實現原理就是利用機器學習來訓練模型,我們會收集市面上所有的購物車圖標作為模型訓練的樣本數據來完成模型的訓練(圖 3),然后就可以直接這個模型來實現各種購物車圖標的識別了。目前移動應用測試工具 Appium 的一個 AI 插件 Appium Classifier Plugin 就已經實現了類似的功能,并且這個機器學習模型的訓練數據是開源的,它可以告訴我們,圖標代表什么樣的內容。我們可以使用此插件根據其外觀在屏幕上查找圖標,即通過視覺外觀查找元素。這種方法比傳統的頁面對象定位靈活得多,因為 AI 模型經過訓練后識別圖標時無需任何上下文,并且不要求進行圖像樣式的精確匹配,這意味著使用 AI 模型查找“購物車”圖標可以跨應用程序和跨平臺工作,而無需擔心各個平臺的細微差別。

圖 3:用作訓練樣本集的各種購物車圖標
機器學習在測試設計領域的應用與創新
上面講述的利用機器學習來對 GUI 控件進行智能化識別雖然在自動化測試執行層面帶了很大的幫助,但是此種類型的應用對于機器學習來講,似乎有點“殺雞用牛刀”了。因為如果我們能將機器學習用在測試設計上,或者說用在縮小測試范圍上,那么機器學習將會發揮更強大的作用,此時機器學習就像是變形金剛中的能量塊,能夠發揮舉足輕重的重要作用。可以這樣說“機器學習和測試設計結合將成為交付真正測試自自動化的催化劑”。

圖 4:機器學習在測試設計中將發揮更大的作用
具體來講,這里有兩種完全不同的思路來應用機器學習技術來幫助測試的設計。
第一種思路是通過機器學習來訓練一個機器人,使其成為某個領域的測試專家。比如通過大量的訓練,“登錄”測試機器人可以比人類更好地對登錄功能進行全方位的測試,“訂單“測試機器人可以進行全方位的訂單系統測試,這種類型的機器人有點類似于專家系統的概念,能夠根據訓練時積累的場景來展開測試。并且你會發現這樣一個事實,幾乎所有的應用都是有共性的,比如都有登錄功能,都有搜索功能,都有用戶管理功能等,這也就是說我們可以通過構建有限種類的機器人來支持大多數軟件的測試設計工作,而且構建的測試機器人數量并不會隨著應用數量的增長而增長。相反,當構建了一定數量的測試機器人之后,這些機器人就能應對大量應用的測試了。目前比較知名的 Appdiff 就是利用了這樣的思路來構建 AI 測試工具的,并且通過自動化地比較前后多次的執行結果,比如 GUI 的變化,頁面性能的變化等來自動化地發現潛在問題(圖 5)。

圖 5:通過自動化地比較前后多次的執行結果來發現軟件中的異常
第二種方式是先構建被測系統的模型,這里又可以分為兩種不同的種類的模型。一種是基于被測系統頁面流轉的模型(圖 6),這個模型反映的是被測系統各個頁面之間的跳轉關系,比如 A 頁面可以到 B 頁面,然后 B 頁面可以到 C 頁面,那么這個三個頁面就對應圖論中的三個節點,然后 A 可以到 B,那么 A 到 B 之間就存在一條有向邊,同樣的,B 和 C 之間也有一條有向邊。另一種是基于后端微服務架構的系統架構圖(圖 7),反映的是后端各個微服務之間的相互調用關系網絡。
有了這種基于圖論的模型后,接下來會通過應用的后臺日志系統來分析頁面和頁面之間的跳轉,或者是微服務和微服務之間的調用,這個過程通常需要借助大數據分析系統的能力,通常使用 Hadoop 和 MapReduce 來完成,然后對于頁面模型每檢測到一次頁面跳轉,就將有向邊的權重加一,如果是微服務模型每檢測到一次調用,也將有向邊的權重加一,然后后面測試路徑的選擇就會優先覆蓋哪些高權重的路徑,當測試時間資源有限的時候,就只會覆蓋那些高權重路徑,以此來體現軟件測試中“基于風險驅動“的設計思想。同時,我們還可以考慮利用圖論的算法來合并多個模型來形成一個更大的模型,下面的圖 8 給出了示例。

圖 6:基于頁面流轉的圖

圖 7:基于微服務調用關系的圖

圖 8:利用圖論的算法來合并多個模型來形成一個更大的模型
進一步設想,如果我們將上述的測試設計和測試自動化執行結合起來,這樣就能完成一條龍的測試設計和執行,并且整個過程并沒有人工的干預。可想而知,這樣將可以最大化利用機器的空余時間來完成大量測試用例的設計和執行,以此來填補測試覆蓋率的鴻溝。
機器學習在測試分析領域的應用與創新
最后,我們來看一下機器學習在測試結果分析領域的應用與創新。前文中我們提到失敗測試用例分析的工作量很大的,而且時間成本也很高,那么我們是否可以利用機器學習來對失敗測試用例進行自動化的分類呢?答案是肯定的,而且這種基于特征值的分類問題正是機器學習的強項。
具體的做法是選擇失敗測試用例的多個特征值,然后基于 kNN 之類的算法來完成失敗用例的自動化分類。這里特征值的選擇將直接影響分類的準確性,同時需要事先標注大量的已知失敗用例的分類結果來對 kNN 進行訓練。kNN 算法的基本原理是“近朱者赤,近墨者黑”,由你的鄰居來推斷出你的類別。系統的整體架構設計如圖 9 所示。從圖中可見,我們選擇了 Exception Name,Exception Message,Stack Trace 等作為了我們的特征值。
這里需要要特別注意兩點,一是我們必須確保輸入日志的完整性,只有當日志包含了完整準確的信息,才有可能基于此做出準確的分類,這種對日志完整性的要求其實可以看做可測試性需求,在設計階段,作為資深的測試工程師就應該需要關注這方面的內容。二是在 kNN 算法模塊的前面,我們放置了一個 Hard Rule 模塊,這個模塊和機器學習沒有任何關系,而是基于日志中硬編碼的規則來對失敗測試用例進行分類,比如假定日志中拋出異常的模塊是 A,那么我們就應該將這個失敗用例自動分配給模塊 A 的開發團隊去做進一步的分析,由于這里采用的是確定的硬編碼,所以分類的準確率在前期就會很高。而那些無法通過 Hard Rule 完成分類的用例才會進入到 kNN 的算法模塊,而 kNN 模塊的分類準確性在很大程度上取決于訓練樣本的數量與質量。
eBay 就是通過這樣的系統來完成日常全回歸過程中失敗用例的分類,基本每天會自動完成超過 200 個失敗用例的分類任務,項目前期由于樣本數量的局限性,所以前期的準確率在 70% 左右,后期隨著樣本數量的增加,準確率維持在 90% 左右。

圖 9:基于 kNN 和 Hard Rule 的失敗測試用例分類系統
進一步,我們可以想象,如果將機器學習應用到性能測試報告的分析上又會是什么樣的效果。這個和目前 AI 在醫療診斷領域的應用非常類似,只是醫療診斷領域的輸入是各種化驗報告,而性能測試分析領域的輸入則是各種性能指標,然后基于機器學習的算法來發現這些指標之間的連帶關系,以此來確定系統的性能瓶頸。
總結
本文介紹了機器學習在測試執行,測試設計以及測試結果分析領域的典型應用場景,并希望由此拋磚引玉,激發讀者更多關于人工智能在軟件測試領域應用的落地實踐與方法。
