基于位圖識別的UI自動(dòng)化測試研究和應(yīng)用

余錦潤，楊丹君，李波波

（浙江中控技術(shù)股份有限公司，杭州310053）

自動(dòng)化測試是軟件測試的一個(gè)重要分支，相對于手動(dòng)測試而言，自動(dòng)化測試是將人的測試行為通過代碼框架轉(zhuǎn)化成機(jī)器的測試行為，可用于各種測試范疇，主要強(qiáng)調(diào)的是通過工具結(jié)合自己的測試策略來輔助測試，可以全自動(dòng)，也可以半自動(dòng)，節(jié)省了大量的人力、時(shí)間和硬件資源，也同時(shí)提高了測試效率。一般來說，滿足3 個(gè)條件就可以對項(xiàng)目采取自動(dòng)化測試[1]：軟件需求變動(dòng)周期長、項(xiàng)目周期長、自動(dòng)化腳本可以重復(fù)利用。

在自動(dòng)化測試概念上，敏捷大師Mike Cohn 提出測試金字塔模式[2]，并衍生出分層自動(dòng)化測試概念，區(qū)別于傳統(tǒng)的自動(dòng)化測試概念（基于產(chǎn)品UI 層面的自動(dòng)化測試，黑盒測試），分層自動(dòng)化測試倡導(dǎo)從黑盒單層到黑白盒多層的體系。

UI 層是用戶使用產(chǎn)品的入口，在傳統(tǒng)的測試模型中，大多數(shù)研發(fā)團(tuán)隊(duì)執(zhí)著于通過UI 進(jìn)行全面的測試，甚至投入大量的人力成本進(jìn)行手工測試，而自動(dòng)化實(shí)現(xiàn)難度也極大。進(jìn)行分層后，自動(dòng)化測試的設(shè)計(jì)就有了針對性，也因此誕生了許多針對UI的測試工具和框架。本文主要研究了UI 自動(dòng)化測試的相關(guān)方法，結(jié)合Electron 應(yīng)用的測試難點(diǎn)分析了位圖識別技術(shù)Sikulix 以及Opencv 算法的優(yōu)勢，并進(jìn)行自動(dòng)化模塊的設(shè)計(jì)和工程項(xiàng)目的實(shí)際應(yīng)用，證明了其實(shí)用價(jià)值。

1 自動(dòng)化測試的相關(guān)研究

在常規(guī)桌面客戶端測試中，市面上流行很多測試工具，比如惠普公司開發(fā)的UFT 工具，商業(yè)軟件Ranorex 等，均提供了強(qiáng)大的錄制回放功能，能完成大部分測試需要。在Web 界面測試中，離不開兩大神器——ChromeDriver 和WebDriverIO 的支持，正因?yàn)檫@兩個(gè)驅(qū)動(dòng)，Web 的自動(dòng)化測試進(jìn)行起來游刃有余，并且和很多框架相結(jié)合進(jìn)行高級別的測試需求定制，比如Selenium 等。由于Web 的流行，Electron 應(yīng)用程序也開始興起，Electron 是由Github 開發(fā)，用HTML，CSS 和JavaScript 來構(gòu)建跨平臺桌面應(yīng)用程序的一個(gè)開源庫。Electron 通過將Chromium和Node.js 合并到同一個(gè)運(yùn)行時(shí)環(huán)境中，并將其打包為Mac，Windows 和Linux 系統(tǒng)下的應(yīng)用，節(jié)省了重復(fù)開發(fā)的資源[3]。針對于以上桌面端的UI 自動(dòng)化測試，目前主流的方法分為基于傳統(tǒng)框架的UI 自動(dòng)化測試和基于Spectron 框架的UI 自動(dòng)化測試。

1.1 基于傳統(tǒng)框架的UI 自動(dòng)化測試

傳統(tǒng)框架主要分為基于代碼API 層面的對象獲取法和基于圖片像素識別的對象獲取法2 種?；诖aAPI 層面的對象獲取法得益于開發(fā)人員給出了獲取方式，測試時(shí)操作精準(zhǔn)，但從另一個(gè)角度來說，消耗大量的人力開發(fā)和處理API；基于圖片像素識別方式主要通過對整個(gè)軟件界面進(jìn)行二進(jìn)制比對，類似于大多數(shù)測試工具中的錄制-回放功能，但是這樣的缺陷更加明顯，在不同分辨率，不同瀏覽器渲染方式下，坐標(biāo)點(diǎn)引起的偏移和失真，會導(dǎo)致識別出錯(cuò)，降低了其可移植性。在一些高級的錄制-回放功能中，增加了元素id 識別，但很多非常規(guī)應(yīng)用，比如Electron 加殼應(yīng)用，或者開發(fā)修改過代碼的定制應(yīng)用，其元素id 是無法識別的。

1.2 基于Spectron 框架的UI 自動(dòng)化測試

上文提到Electron 應(yīng)用是Web 加殼的桌面客戶端形式的一種應(yīng)用，會導(dǎo)致其Web 元素id 被隱藏，常規(guī)的測試工具無法識別其元素id，官方給出了一個(gè)開源框架Spectron，通過JS 語言進(jìn)行測試代碼的編寫，可以調(diào)用WebDriverIO 的API，但版本有限制。另一方面，Spectron 專門針對Electron，無法作為常規(guī)的測試工具，擴(kuò)展性弱，且使用JS 語言，對于以Python 為基礎(chǔ)語言的測試人員而言，學(xué)習(xí)成本也比較高。

1.3 基于Sikulix 框架的UI 自動(dòng)化測試

Sikulix 是麻省理工學(xué)院的一個(gè)開源項(xiàng)目，是一種全新的UI 自動(dòng)化測試模式，俗稱“上帝之眼”，完全模擬人的操作模式[4]，可以利用Opencv 提供的圖像識別算法進(jìn)行可視化檢索和操作，相對于以上兩種框架，Sikulix 的優(yōu)勢在于：①Sikulix 由于其jar 包的獨(dú)立性，完全可以作為API 跨平臺操作，用Python調(diào)用可以靈活構(gòu)建大型的測試方案；②Sikulix 的圖像識別可以解決常規(guī)的錄制-回放工具元素id 無法識別問題，對不同分辨率以及不同瀏覽器的渲染方式，Sikulix 不需去操作其坐標(biāo)點(diǎn)，且圖片識別精度可以按照需求設(shè)定，默認(rèn)0.7，解決這種場景的問題；③對于UI 自動(dòng)化測試，這種方式帶來的可擴(kuò)展性以及編寫腳本的直觀性，大大降低了測試人員的上手難度，使測試人員投入更多的資源去探索性測試領(lǐng)域。

2 Sikulix+Opencv 模型與算法介紹

Sikulix 是以Java 為運(yùn)行環(huán)境，本身提供了一個(gè)簡易的IDE，并提供了一個(gè)完整的方法庫模擬測試人員的操作行為，為了實(shí)現(xiàn)更復(fù)雜的測試需求，我們不使用其IDE，而應(yīng)用Jython 集成Python 環(huán)境編寫驅(qū)動(dòng)模塊，Sikulix 的工作原理如圖1所示。

圖1 Sikulix 系統(tǒng)框架Fig.1 System framework of Sikulix

可以看到，除了常規(guī)的Java 和Jython 支持外，最重要的一個(gè)底層驅(qū)動(dòng)Opencv 用于圖像對比和圖片匹配，Opencv 是目前最流行的計(jì)算機(jī)視覺開源庫，在人工智能領(lǐng)域應(yīng)用完善。Opencv 的圖片對比指標(biāo)主要有：①均方差MSE 對比：將兩張尺寸一樣的圖片的所有RGB 三種顏色的像素點(diǎn)進(jìn)行一一對比；②峰值信噪比PSNR 對比：將一張?jiān)瓐D和一張壓縮過的圖片進(jìn)行對比，用PSNR 值表示其失真程度；③結(jié)構(gòu)相似性SSIM 對比： 不同于前兩種指標(biāo)只是機(jī)械地通過線性變換分解圖片信息，SSIM 考慮了人眼的生物特征，基于感知模型（自然圖像具備高度結(jié)構(gòu)化，像素點(diǎn)之間存在相關(guān)性），可檢測結(jié)構(gòu)信息的差異。SSIM 主要由3 個(gè)模塊組成：結(jié)構(gòu)、對比度和亮度，在本文中使用SSIM 對比，其算法流程如圖2所示[5]。

圖2 SSIM 測量系統(tǒng)Fig.2 SSIM measurement system

將以上3 個(gè)模塊的函數(shù)整合之后，得到SSIM的表達(dá)式：

式中：μx表示x 的均值；μy表示y 的均值；表示x的方差；表示y 的方差；σxy表示x 和y 的協(xié)方差；常數(shù)c1=（k1L）2，c2=（k2L）2是為了避免分母接近0 時(shí)引起系統(tǒng)不穩(wěn)定，其中，L 為圖像灰度級數(shù)（L=2bit數(shù)-1），k?1，默認(rèn)為k1=0.01，k2=0.03。

Opencv 的圖片匹配原理是在原圖片中找到一塊與模板圖片匹配的區(qū)域，通過全范圍滑動(dòng)覆蓋原圖像進(jìn)行比較，并將滑動(dòng)時(shí)的度量值存入結(jié)果圖片矩陣中，矩陣的值表示匹配度，矩陣的位置就是匹配位置。Opencv 通過MatchTemplate 函數(shù)提供了6種匹配算法，如表1所示。

本文使用的是相關(guān)系數(shù)匹配-歸一化版本：采用模板與目標(biāo)圖片像素與每個(gè)圖片的平均值計(jì)算數(shù)量積，正值越大匹配度越高，范圍為［-1，1］，如果圖片沒有明顯的特征，則為0，表示無法進(jìn)行匹配。

表1 Opencv 匹配算法Tab.1 Matching algorithms of Opencv

3 UI 自動(dòng)化測試設(shè)計(jì)與應(yīng)用

3.1 系統(tǒng)結(jié)構(gòu)的整體設(shè)計(jì)

針對UI 的功能測試，以本公司內(nèi)部的Electron應(yīng)用為測試目標(biāo)，為了覆蓋其完整的功能測試點(diǎn)，本文基于Opencv 的圖片識別匹配算法以及Sikulix的操作庫設(shè)計(jì)出如圖3 的系統(tǒng)結(jié)構(gòu)圖。

圖3 系統(tǒng)結(jié)構(gòu)圖Fig.3 Systematic structure diagram

前端UI 事件 在圖片素材給定的基礎(chǔ)上，通過鼠標(biāo)的點(diǎn)擊操作，鍵盤的輸入以及快捷鍵操作，界面狀態(tài)的檢測，截圖保存等操作，完成一套UI 自動(dòng)化測試的流程事件。

優(yōu)化層 在整體流程無重大邏輯錯(cuò)誤的基礎(chǔ)上，對于素材圖片，過程圖片，結(jié)果圖片的匹配度有一個(gè)預(yù)先設(shè)定的閾值，因?yàn)椴煌愋偷慕貓D，不同類型的區(qū)域，匹配度不盡相同，不能一個(gè)匹配度用于所有情況，必須靈活設(shè)定。本文每輪至少經(jīng)過3次測試以確定閾值。只有當(dāng)匹配度大于這個(gè)閾值時(shí)，才能進(jìn)行下一步操作。對于軟件界面，有2 種情況，一種是軟件界面被遮擋，導(dǎo)致識別不到相應(yīng)圖片，解決方式是采用區(qū)域遍歷的方式，搜索出遮擋區(qū)域，確認(rèn)存在遮擋后，將軟件前置或者強(qiáng)制重啟（極端情況）；第二種是軟件崩潰情況，會彈出error指示框，識別出指示框界面后，標(biāo)記未通過測試，并強(qiáng)制重啟后進(jìn)行下一個(gè)用例測試。

界面層與功能模塊層 這兩層同屬于測試核心驅(qū)動(dòng)項(xiàng)，針對整個(gè)界面，結(jié)合各個(gè)功能模塊的操作，完成了UI 自動(dòng)化驅(qū)動(dòng)框架的編寫。其中過程圖片和更新圖片模塊是動(dòng)態(tài)自動(dòng)更新，對比點(diǎn)擊功能點(diǎn)的前后截圖，如果相似度小于設(shè)定的閾值，則判斷此處UI 發(fā)生變化，當(dāng)UI 發(fā)生變化時(shí)（核心圖片素材未變），會以自動(dòng)截圖的形式保存至相應(yīng)的路徑中。

管理組件和運(yùn)行環(huán)境 本文使用RobotFrame work 來管理整個(gè)測試工程以及用例的編寫[6]，主要的三大核心部分如圖4所示。其運(yùn)行環(huán)境調(diào)用Java虛擬機(jī)，Sikulix 的函數(shù)庫，Python 的第三方庫。

圖4 測試工程結(jié)構(gòu)圖Fig.4 Testing engineering structure diagram

根據(jù)以上方法，本文的具體實(shí)施測試對象是公司內(nèi)部的AppDev 前端程序，是一款使用Electron加殼的應(yīng)用，從圖4所示的測試工程可以看出：

（1）工程建立了測試驅(qū)動(dòng)文件夾，用來管理此應(yīng)用的各個(gè)功能模塊的Python 驅(qū)動(dòng)代碼，比如菜單欄、工具欄等操作代碼；

（2）工程建立了測試用例文件夾，使用RF 統(tǒng)一管理測試用例的代碼，可以符合測試一體化平臺的運(yùn)行要求；

（3）工程建立了資源庫文件夾，用來管理測試過程中使用的圖片素材，更新過程文件等，這也是自動(dòng)化測試必不可少的判斷要素。

整個(gè)測試工程搭建了之后，進(jìn)行以下章節(jié)的對比實(shí)驗(yàn)，并分析了實(shí)驗(yàn)結(jié)果。

3.2 實(shí)驗(yàn)及結(jié)果分析

實(shí)驗(yàn)環(huán)境DELL 5820 工作站，CPU Inter Xeon 3.20 GHz，內(nèi)存8 G，Windows10 64 位中文版操作系統(tǒng)，分辨率1920*1080 以及1280*1024

測試對象Electron 應(yīng)用

實(shí)驗(yàn)1Opencv 算法的對比分析

上文提到，本文使用Sikulix+Opencv 圖片識別和匹配算法進(jìn)行自動(dòng)化框架的集成。我們基于Opencv 的SSIM 圖片對比算法基礎(chǔ)上，通過6 種匹配算法遍歷匹配此應(yīng)用的126 個(gè)圖片元素（未優(yōu)化匹配度），結(jié)果如表2所示。

表2 匹配算法對比Tab.2 Comparison of matching algorithms

從表中可以看出相關(guān)系數(shù)匹配法成功率最高，但是耗時(shí)最多。而圖片識別率是保證自動(dòng)化進(jìn)行的前提條件，因此使用其歸一化版本，在降低一定耗時(shí)量的同時(shí)，識別率不變。

實(shí)驗(yàn)2主流的UI 自動(dòng)化測試軟件對界面的識別效果

本文的Electron 應(yīng)用界面一共擁有126 個(gè)可點(diǎn)擊以及鍵盤編輯元素，UI 自動(dòng)化測試的前提是能在不同分辨率下識別這126 個(gè)元素，將本文設(shè)計(jì)的系統(tǒng)方案和主流的UI 自動(dòng)化工具進(jìn)行對比實(shí)驗(yàn)，并增加了不同分辨率以及匹配度優(yōu)化的實(shí)驗(yàn)數(shù)據(jù)。

圖5 工具的元素識別數(shù)對比Fig.5 Element recongnition number comparison of tools

從圖5 可以看出，Ranorex 和UFT 由于無法識別到元素id，而自帶的位圖識別功能效果不佳，導(dǎo)致識別率很低。Spectron 由于是官方提供的框架，能準(zhǔn)確識別元素id，因此均能完整識別。而本文Sikulix 方案，由于基于圖片識別匹配，在匹配度沒有進(jìn)行調(diào)整的狀態(tài)下，會出現(xiàn)少量的錯(cuò)誤，在匹配度優(yōu)化后，能完全識別，進(jìn)而可以滿足UI 自動(dòng)化的功能測試要求，且擴(kuò)展性，代碼易讀性方面均優(yōu)于Spectron。

實(shí)驗(yàn)3與人工測試進(jìn)行對比

自動(dòng)化和人工測試的一個(gè)差異就是，自動(dòng)化可以無差別的進(jìn)行測試，杜絕了某些情況下人工的疏忽。我們在RF 框架下運(yùn)行編寫好的148 條冒煙測試用例，運(yùn)行結(jié)果如圖6所示，同時(shí)參照文字版測試用例進(jìn)行人工測試，對比兩者的時(shí)間，通過數(shù)，fail率等，結(jié)果如表3所示。

圖6 RF 自動(dòng)化測試結(jié)果Fig.6 RF automation test results

表3 人工與自動(dòng)化測試的效果比對Tab.3 Comparison of the effects of manual and automated testing

從表3 中分析可知，就冒煙測試而言，自動(dòng)化測試發(fā)現(xiàn)bug 效率明顯高于人工，證明本文方案符合自動(dòng)化測試的效率要求。

綜合以上實(shí)驗(yàn)結(jié)果，我們可以看出，本文結(jié)合Sikulix+Opencv 的作為底層驅(qū)動(dòng)，整個(gè)系統(tǒng)設(shè)計(jì)是可以滿足測試要求的，對比了其他工具在electron應(yīng)用的表現(xiàn)，通過低成本的方法可以解決id 元素識別，分辨率更改，UI 發(fā)生某種改變等一些突出問題。在UI 自動(dòng)化測試領(lǐng)域，本方案擁有上手難度低，擴(kuò)展性強(qiáng)等優(yōu)勢，測試人員能很快設(shè)計(jì)出對應(yīng)的測試框架，是一種實(shí)用性很強(qiáng)的方法。

4 結(jié)語

本文從UI 自動(dòng)化測試出發(fā)，從Electron 應(yīng)用的角度思考，提出一種簡潔易上手，擴(kuò)展性高的測試設(shè)計(jì)方案。通過研究Opencv 圖片識別和匹配算法，Sikulix 的庫函數(shù)，得出相應(yīng)的底層設(shè)計(jì)思路，并完成了整個(gè)測試系統(tǒng)框架的設(shè)計(jì)搭建。通過將本方案和常規(guī)工具進(jìn)行對比，從不同的角度進(jìn)行冒煙測試，實(shí)驗(yàn)結(jié)果表明本方案優(yōu)于傳統(tǒng)的測試工具。

由于本文主要針對桌面應(yīng)用，且目前只實(shí)現(xiàn)了冒煙用例的編寫，后期復(fù)雜測試需求提出，可能面臨各種如下的改進(jìn)：①過度依賴截圖，某些功能組合數(shù)很多，單一的圖片識別方式會導(dǎo)致圖片數(shù)巨大，此時(shí)需要考慮以圖片識別輔助接口測試的方案；②由于是界面展示型測試，和后臺數(shù)據(jù)型測試相比，未知干擾多，包括輸入法兼容，桌面變化等因素，后期需要思考其規(guī)避方案；③目前可以解決UI重排的圖片更新問題，但是無法解決UI 文字，圖形變化問題，需要重新手動(dòng)進(jìn)行素材的提取，后期可能要從人工智能的角度出發(fā)，探索新的無人值更新方法。