余錦潤，楊丹君，李波波

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

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

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

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

1 自動化測試的相關研究

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

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

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

1.2 基于Spectron 框架的UI 自動化測試

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

1.3 基于Sikulix 框架的UI 自動化測試

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

2 Sikulix+Opencv 模型與算法介紹

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

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

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

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

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

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

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

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

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

3 UI 自動化測試設計與應用

3.1 系統(tǒng)結構的整體設計

針對UI 的功能測試，以本公司內部的Electron應用為測試目標，為了覆蓋其完整的功能測試點，本文基于Opencv 的圖片識別匹配算法以及Sikulix的操作庫設計出如圖3 的系統(tǒng)結構圖。

圖3 系統(tǒng)結構圖Fig.3 Systematic structure diagram

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

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

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

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

圖4 測試工程結構圖Fig.4 Testing engineering structure diagram

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

（1）工程建立了測試驅動文件夾，用來管理此應用的各個功能模塊的Python 驅動代碼，比如菜單欄、工具欄等操作代碼；

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

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

整個測試工程搭建了之后，進行以下章節(jié)的對比實驗，并分析了實驗結果。

3.2 實驗及結果分析

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

測試對象Electron 應用

實驗1Opencv 算法的對比分析

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

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

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

實驗2主流的UI 自動化測試軟件對界面的識別效果

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

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

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

實驗3與人工測試進行對比

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

圖6 RF 自動化測試結果Fig.6 RF automation test results

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

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

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

4 結語

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

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