百度深研MMGame項目組每天提測的apk游戲包數(shù)量較大，但由于都是第三方游戲，游戲測試僅包括游戲的簡單功能測試和游戲廣告測試，人工測試較為繁瑣，為了自動化驗證游戲功能和廣告、提高游戲測試效率，測試項目組在測試中引入開源的Appium自動化測試框架進行自動化測試。但在使用過程中，由于游戲的特殊性，發(fā)現(xiàn)很多游戲無法獲取到控件、資源ID等內部資源（非原生android代碼或使用OpenGL、ActiveX），而目前主要的移動端自動化測試工具基本都是基于獲取內部控件元素來進行操作。因此，傳統(tǒng)的測試框架和工具無法滿足項目組游戲自動化測試的需求。

　　這種情況下，只能通過點擊坐標代替控件操作，而如何自動獲取控件坐標就成了能否實現(xiàn)自動化的關鍵。解決的方法是將開源計算機視覺庫OpenCV引入Appium框架，將按鈕或控件的截圖作為參數(shù)輸入，在屏幕中通過圖像特征識別獲取對應控件坐標，調用AppiumAPI實現(xiàn)坐標點擊，然后再次調用OpenCV圖像識別庫，自動判斷操作結果，完成自動化測試。

　　一、Appium與OpenCV簡介

　　Appium 是一個開源、跨平臺的自動化測試工具，可以支持 iOS、Android 和 FirefoxOS 平臺。Appium的核心是一個遵守REST設計風格的web服務器，server監(jiān)聽一個端口，接收由client發(fā)送來的command，將其轉換成移動設備可以理解的形式，發(fā)送給移動設備，移動設備執(zhí)行完command后把執(zhí)行結果返回給appiumserver，appiumserver再把執(zhí)行結果返回給client，其使用Selenium的WebDriver JSON協(xié)議，這種架構提供了很好的開放特性，只要某種語言有http客戶端的api，就可以通過這個語言編寫測試腳本，因此，Appium支持SeleniumWebDriver支持的所有語言，如java、Object-C、JavaScript、Php、Python、Ruby、C#、Clojure、 Perl語言。Appium在iOS部分封裝了UIAutomation，Android 4.2以上使用UiAutomator，Android 2.3～4.1使用Instrumentation，也就說Appium同時封裝了UiAutomator和Instrumentation。

　　Appium在不同平臺中使用了標準的自動化APIs，所以在跨平臺時，不需要重新編譯或者修改自己的應用，Appium實現(xiàn)了真正的跨平臺自動化測試。

　　OpenCV的全稱是：Open Source Computer Vision Library（開源計算機視覺庫），其可以運行在Linux、Windows和Mac OS操作系統(tǒng)上。OpenCV輕量級而且高效的實現(xiàn)了圖像處理和計算機視覺方面的很多通用算法，算法實現(xiàn)由一系列 C 函數(shù)和少量 C++ 類構成，同時提供了Python、Ruby、MATLAB等語言的接口。

　　二、游戲自動化測試框架（Appium與OpenCV結合）

　　MMGame游戲自動化測試整體框架由Appium構成，Appium作為client與被測APP的橋梁，可以實現(xiàn)連接設備、完成被測APP輸入/輸出等，OpenCV則為Appium自動化測試提供場景判斷、控件獲取、結果判斷等功能。在對設備進行自動化操作的過程中，關鍵環(huán)節(jié)之一就是元素的定位，對于普通應用，Appium提供的API基本能滿足測試需求（直接獲取控件或資源ID），但是對于游戲（尤其是大型游戲）來說，很多游戲直接使用OpenGL或ActiveX，傳統(tǒng)的自動化工具無法通過獲取視圖元素或資源ID進行元素定位，只能在外部通過坐標點擊和屏幕讀取進行輸入/輸出，但是坐標點擊適用范圍和場景固定，且需要根據(jù)特定設備和測試案例進行坐標適配，通用性、可移植性和可維護性較差。

　　因此，在Appium測試框架的基礎上，考慮引入OpenCV進行圖像識別與定位，確定控件元素位置，返回坐標，然后由Appium完成對坐標的操作，以此實現(xiàn)游戲的自動化測試與結果驗證。OpenCV開源可定制化，兼容多種平臺，能夠識別經(jīng)過拉伸和扭曲的圖像，適用于測試2D/3D游戲，非常適合引入Appium進行游戲自動化測試，更進一步，可以依此實現(xiàn)游戲云端遠程并行測試，極大的擴展測試規(guī)模和測試服務，減少測試人力，加快測試效率。除此之外，圖像處理功能模塊獨立且通用性極強，與平臺、設備無關，也可以應用到其他任何需要圖像識別的產(chǎn)品進行功能擴展。鑒于此，OpenCV的引入，不僅不會影響Appium的跨平臺通用性，且解決了Appium無法獲取普通應用部分元素和游戲中無法獲取內部資源的問題，極大的擴展了Appium的功能。

　　在具體游戲測試中，OpenCV實現(xiàn)以下3個功能：

　　•   確定當前在游戲的哪個階段；

　　•   根據(jù)提供的按鈕、控件截圖，確定其坐標；

　　•   判斷游戲表現(xiàn)是否符合預期。

　　Appium+OpenCV整體框架如下圖1所示：

圖1 Appium+OpenCV整體框架

　　Appium測試框架的使用網(wǎng)上已經(jīng)很多，在此不再做多說明，本文主要介紹OpenCV在Appium中的使用。

　　三、自動測試整體結構和實現(xiàn)原理

　　Appium中使用OpenCV進行游戲自動化測試的大致流程如下：

　　首先收集相關控件的截圖；

　　然后通過Appium獲取屏幕當前截圖，將提供的截圖和當前截圖作為輸入，使用OpenCV（3.0及以上版本）中集成的Akaze特征識別算法進行特征識別，確定截圖在屏幕中的坐標；

　　再通過Appium API實現(xiàn)坐標操作，并獲取操作后屏幕截圖；

　　再次進行圖像處理，判斷點擊后的效果是否符合預期，給出測試結果，完成測試。

　　完整工程結構如下：

　　圖2 Appium+OpenCV整體結構

　　這其中最為核心的是Akaze特征識別算法。Kaze是 Pablo F. Alcantarilla，Adrien Bartoli和Andrew J. Davison2012年在ECCV2012[ECCV是計算機視覺領域最頂尖的三個會議（CVPR、 ECCV， ICCV）之一，每兩年一次]中提出來的一種比SIFT、SURF（OpenCV 2.4.9版本中實現(xiàn)的圖像特征檢測算法）更穩(wěn)定、性能更好的特征檢測算法。

　　KAZE特征檢測是在圖像域中進行非線性擴散處理的過程。KAZE算法的作者提出采用加性算子分裂算法(Additive Operator Splitting, AOS)來進行非線性擴散濾波，可以采用任意步長來構造穩(wěn)定的非線性尺度空間。

　　KAZE特征的檢測步驟大致如下：

　　1）首先通過AOS算法和可變傳導擴散方法來構造非線性尺度空間。

　　2）檢測感興趣特征點，這些特征點是在非線性尺度空間上經(jīng)過尺度歸一化后的Hessian矩陣行列式中的局部極大值（3×3鄰域）。

　　3)計算特征點的主方向，并且基于一階微分圖像提取具有尺度和旋轉不變性的描述向量。

　　Kaze算法的作者在2013年的BMVC（British Machine Vision Conference）會議上，又對Kaze算法做了改進，引入了一個最新的稱為快速顯示擴散的（Fast Explicit Diffusion，F(xiàn)ED）數(shù)學框架去進行特征發(fā)現(xiàn)和描述，F(xiàn)ED方案構建非線性尺度空間的速度比其他離散化方案的速度都要快，此外，F(xiàn)ED方案非常易于實現(xiàn)，也比AOS方案更為精確，作者提出在椎體框架中嵌入FED可以顯著加快非線性尺度空間的特征發(fā)現(xiàn)，并將這種改進的Kaze算法稱之為 AcceleratedKAZE ，即為Akaze。

　　作者基于OpenCV實現(xiàn)了Akaze算法的代碼，在作者項目主頁（http://www.robesafe.com/personal /pablo.alcantarilla/kaze.html）可以下載到完整的實現(xiàn)源代碼，具體使用中可以下載OpenCV 3.0及以上版本直接調用Akaze算法類，或者將下載的Akaze代碼添加進工程來使用。

　　圖2中的Img文件夾中保存了預先傳入的截圖（queryImg文件夾）和獲取到的屏幕截圖(sceneImg文件夾)，以及使用特征識別算法匹配到的結果圖片（matchImg文件夾），具體如下圖3所示：

圖3 工程圖片目錄結構

　　圖2中imgProcess.py基于OpenCV提供的底層圖像處理接口，封裝了一系列自動化測試中所需要的特征識別、結果圖繪制、獲取坐標等接口，以獲取截圖坐標函數(shù)為例，其大致實現(xiàn)過程如下：

　　•   使用特征檢測算法Akaze分別計算控件截圖和屏幕截圖的特征值和描述向量；

　　•   將兩張圖的特征值進行匹配；

　　•   過濾匹配成功的坐標對；

　　•   根據(jù)過濾后的坐標對計算轉換矩陣；

　　•   獲取控件截圖的4個頂點坐標，使用轉換矩陣運算，映射至屏幕坐標；

　　•   根據(jù)屏幕坐標計算中心點坐標并返回。

　　大致代碼如下圖4所示：

圖4 imgProcess.py代碼結構

　　圖2中Appium_OpenCV_TestCase.py是執(zhí)行具體測試邏輯的測試用例，代碼具有簡單易寫，結構簡單，邏輯清晰的優(yōu)點。Appium測試用例有固定的模板，不同的是，在測試case代碼中，使用OpenCV進行圖像匹配、坐標獲取、結果確認等，取代了傳統(tǒng)的通過獲取視圖元素或資源ID實現(xiàn)操作，大致代碼如下圖5所示：

　　圖5 測試用例Appium_OpenCV_TestCase.py代碼結構

　　四、使用效果

　　1、功能測試

　　為了展示使用效果，以實際工作中的一款被測游戲APP為例，使用以上實現(xiàn)的框架和圖像匹配功能，進行簡單的基于Appium+OpenCV實現(xiàn)的功能自動化測試演示。

　　首先，我們根據(jù)需要測試的功能邏輯，收集相關截圖，如下圖6所示：

圖6 相關控件截圖

　　運行測試腳本中，會自動獲取特定時刻的屏幕截圖，如下圖7所示：

圖7 屏幕截圖

　　然后將屏幕截圖與傳入的按鈕截圖進行圖像匹配，部分匹配結果如下圖8所示：

圖8 圖像識別結果（綠色方框區(qū)域即為識別到的控件區(qū)域）

　　上面綠色方框就是通過圖像匹配，在屏幕截圖中找到的對應控件的位置，可以看出，除了第一張稍有偏差，其他控件基本是100%匹配，而且第一張雖有一定偏差，但是匹配結果的中心坐標點（即綠色方框的中心點）仍在控件的可點擊范圍內，也是可點擊成功的。至于為何Star按鈕會出現(xiàn)匹配誤差，這與傳入的按鈕截圖有關。項目組在實際使用中總結了以下3條經(jīng)驗：

　　•    截取最精確的源圖片（最小化原則），提高匹配精確度

　　將需要匹配的控件圖片拆分成較小的、唯一的元素。

　　缺點：圖片小，獲取到的特征點少，容易匹配失敗，匹配成功率低

　　優(yōu)點：匹配精確度高

　　•   放大源圖片，提高匹配成功率

　　將需要匹配的圖片適當放大，提高匹配成功率，但匹配誤差增大，精確度降低，此時可以根據(jù)實際經(jīng)驗值對閾值進行調整來保證匹配準確度。

　　缺點：特征值增多，容易發(fā)生誤匹配，精確度降低；需要根據(jù)實際情況獲取經(jīng)驗值，修改匹配閾值。

　　優(yōu)點：匹配成功率較高

　　•   圖片截取使用屏幕原生分辨率

　　2、游戲簡單功能測試與廣告自動驗證

　　項目組日常提測的第三方游戲數(shù)量較大，每天有幾十甚至上百款apk包提測，目前，項目組測試團隊已經(jīng)將游戲測試結果上傳Mars（測試支持平臺），但是需要人工去查看圖片確認廣告是否正常、游戲安裝和啟動是否正常，考慮到測試邏輯較為固定且繁瑣，比較合適引入圖像識別，項目組測試團隊引入封裝好的圖像處理模塊，使用圖像識別自動驗證廣告是否彈出成功，自動判斷游戲是否崩潰、黑屏、閃退等，然后自動在Mars平臺標記測試結果，無需再去進行人工檢查，具體步驟如下圖9所示：

圖9 破解游戲自動結果檢測

　　使用圖像匹配進行廣告驗證和游戲場景識別的代碼如下圖10所示：

圖10 游戲場景匹配

　　廣告匹配結果圖如下圖11所示（彈出的廣告與傳入的廣告截圖完全一致）：

圖11 廣告場景匹配

　　如果彈出的廣告與傳入的廣告截圖不一致，由于有其他相同的特征點，也是可以匹配成功的，只是需要調整匹配閾值，確保不同廣告出現(xiàn)時不被判斷為廣告展現(xiàn)失敗，結果如下圖12所示：

圖12 廣告場景匹配

　　但實際測試過程中會出現(xiàn)很多其他情況，例如如果廣告被其他廣告或者窗口覆蓋，則會匹配失?。ㄆヅ涑晒μ卣髦祵?shù)目太小），如下圖13所示：

　　圖13 廣告場景匹配失敗

　　因此，可以使用源圖片截取的最小化原則，對場景進行二次識別，例如這里可以再次對廣告的關閉按鈕進行匹配，如下圖14所示：

圖14 廣告場景二次確認

　　崩潰匹配的結果如下圖15所示：

圖15 崩潰場景匹配

　　但是也會出現(xiàn)一些誤匹配，如下圖16所示：

　　因此，在具體測試過程中，如果出現(xiàn)某些場景圖像識別錯誤率較高，需要對正確匹配和錯誤匹配情況下的特征值匹配對數(shù)目進行統(tǒng)計分析，確定一個經(jīng)驗值，以此作為判斷是否匹配成功的閾值，也可以調整Akaze算法的內部函數(shù)系數(shù)，來保證識別的準確度在可接受范圍內。

　　自動檢驗完畢后，根據(jù)檢驗結果在Mars上自動標記測試結果，測試人員只需在測試腳本運行完畢后去Mars平臺查看測試結果，然后發(fā)送測試報告即可，如下圖17所示。

圖17 自動標記檢測結果

　　為了檢驗引入圖像識別進行自動測試與人工測試結果的出入，測試團隊將游戲100款游戲的自動測試結果和人工測試結果進行了對比，在測試的全部游戲中，人工檢查判斷為不通過，但是自動檢查判斷為通過（這種情況是最為嚴重的）的有4款，占比大概為4%，主要原因是有少量的游戲需要彈框提示下載新版本安裝包或者彈框提示應用未授權，由于這種情況出現(xiàn)較少，測試邏輯中并沒有包含對這些場景的識別，因此判定為通過。

　　引入圖像識別進行自動檢驗后，省去了第三方游戲自動化測試流程中最為關鍵的一個需要人工干預的環(huán)節(jié)，打通了整個自動化測試流程，目前除了自動發(fā)送測試報告郵件外，其他都已經(jīng)實現(xiàn)，自動測試流程如下圖18所示：

圖18 游戲自動化測試流程

　　五、對比與總結

　　以上就是基于Appium框架，在其中引入OpenCV進行游戲自動化測試的實現(xiàn)與應用，其最主要就是解決了游戲APP或其他普通應用在無法獲取其內部資源進行元素定位的情況下，如何不依賴內部資源實現(xiàn)自動化測試的問題，且圖像處理模塊開源、獨立，可以應用于其他平臺和場景，具有較好的可移植性和可擴展性。

　　下面針對Appium+OpenCV與當前主流的測試框架、工具的實現(xiàn)和特點做一個簡要的對比與總結。

　　1、Appium+OpenCV與當前主流測試框架、工具對比

　　目前，Android基于UI層面的自動化測試工具，都可以理解為是基于Android控件層面的，涉及Widgets和WebView兩大類。其主流的測試方法主要有以下兩種：

　　一種是通過Android提供的各種服務，來獲取當前窗口的視圖信息。然后，在當前視圖內查找目標控件，并根據(jù)該控件屬性信息計算出該控件中心點的坐標，進而構造出一個AndroidInput事件來實現(xiàn)對應用的自動化測試。其主要特點是：測試代碼和被測應用各自運行在各自的進程內，相互獨立，其代表有Uiautomator。

　　另一種則是基于Instrumentation，Instrumentation是早期Google提供的Android自動化測試工具類，可以模擬按鍵按下、抬起、屏幕點擊、滾動等事件。Instrumentation是通過將主程序和測試程序運行在同一個進程來實現(xiàn)這些功能，可以把Instrumentation看成一個類似Activity或者Service并且不帶界面的組件，在程序運行期間監(jiān)控主程序。通過把測試代碼和應用代碼，確切地說是測試APK和被測APK，運行在同一個進程中，通過Java反射機制，來獲取當前窗口所有視圖，并根據(jù)該視圖查找到目標控件的屬性信息，并計算出目標控件中心點坐標。然后，利用Instrument內部接口，實現(xiàn)點擊操作，其代表有Robotium。

　　這兩種方法有一個共同的特點，就是其實現(xiàn)自動化測試依賴于被測應用的代碼或者內部資源，如果無法獲取到內部控件或者資源ID，就無法進行元素定位，也就無法實現(xiàn)自動化操作。而基于Appium引入OpenCV，可以實現(xiàn)不依賴于應用內部資源就可以進行自動化功能測試，極大的擴展了傳統(tǒng)測試框架和工具的功能，且具有良好的平臺兼容性、可擴展性和可移植性。

　　且Appium同時封裝了UIAutomation和Instrumentation，所以Appium擁有目前使用以上這兩種方法實現(xiàn)的主流框架的所有優(yōu)點：支持跨App測試，支持Native App、Hybird App、Web App測試，還支持多種語言來編寫你的測試腳本，在跨平臺時，不需要重新編譯或者修改自己的應用等等。

　　目前主流的移動端（Android、IOS）自動化測試框架、工具有以下這些，詳見表1：

表1 移動端主流自動化測試框架、工具

　　下面針對目前業(yè)界主流的一些測試移動端測試框架和工具與Appium+OpenCV的優(yōu)缺點做一個比較，詳見下表2：

表2 Appium+OpenCV與主流移動端測試工具對比

　　2、總結

　　綜合來說，Appium+OpenCV主要的優(yōu)缺點如下：

　　1)優(yōu)點：

　　•   無需獲取游戲內部資源，直接進行黑盒自動化測試；

　　•   Appium、OpenCV均是開源、跨平臺，具有很好的適用性和功能擴展性；

　　•   OpenCV能夠識別經(jīng)過拉伸和扭曲的圖像，滿足大型3D游戲測試需求；

　　•   使用簡單，測試case代碼易寫；

　　•   圖像識別模塊可獨立遷移；

　　2)缺點：

　　•   純黑盒測試方案，僅限于基本功能測試；

　　•   僅限于對邏輯相對固定的操作進行測試；

　　•   對于界面內容及UI變化的游戲，腳本維護成本高；

　　•   圖像識別有一定誤差。

　　總的來說，由于Appium+OpenCV主要基于Appium實現(xiàn)，所以具有Appium本身的優(yōu)點，而Appium本身同時封裝了UIAutomation和Instrumentation，所以Appium擁有以上這幾個框架的所有優(yōu)點，而引入OpenCV，彌補了Appium在無法獲取被測應用內部資源的情況下不能進行自動化測試的缺點，同時提供了在其他情況下需要進行場景自動識別的功能。