張 娜，蔡樂俊，徐 曼，包梓群，包曉安

（浙江理工大學 信息學院，浙江杭州 310000）

0 引言

隨著移動互聯(lián)網(wǎng)發(fā)展以及智能手機的普及，智能手機應(yīng)用程序得到爆發(fā)式增長。APP 從輕量級逐步向多元化應(yīng)用演化，用戶對APP 要求不斷提高［1］，移動端測試也日益重要。軟件開發(fā)公司會對移動端的同一個功能進行數(shù)次測試，傳統(tǒng)測試方案中，基于DFS 的自動化測試方案即使在數(shù)次測試后遍歷控件數(shù)量仍不會改變，因而會遍歷大量的無效控件，浪費了測試時間；基于錄制回放功能的自動化測試方案無法在數(shù)次測試中全面覆蓋界面控件，耗時長且代碼覆蓋率低。因此，在研究移動端軟件測試算法中，越來越多的學者將人工智能算法引入移動端軟件測試用例生成上，以提高效率、節(jié)省時間［2］。

移動終端平臺種類繁多，主要分為iOS 和Android 兩大平臺，大多數(shù)移動應(yīng)用都需要支持多平臺，因其基礎(chǔ)架構(gòu)不同，所以對移動端自動化測試框架的兼容性提出了更高要求［3］。李昕宇等［4］設(shè)計了一種基于圖像識別的自動化測試方案，該方案可根據(jù)移動端控件圖標識別點擊，容易上手識別率高，但靈活性低，不適合在大型自動化測試中應(yīng)用；朱菊等［5］提出基于數(shù)據(jù)驅(qū)動測試框架的自動化測試方法，該框架在時耗和可維護性上具有一定優(yōu)勢，但要求測試人員對開發(fā)有深入了解，編寫難度大；Azim 等［6］在基于關(guān)鍵字驅(qū)動的測試框架上，通過對用戶和Android 應(yīng)用程序的交互進行模擬來實現(xiàn)控件的遍歷，該方法可以動態(tài)監(jiān)測控件，在界面覆蓋率上有較大優(yōu)勢；曹羽中等［7］提出一種基于錄制/重放的Android 應(yīng)用眾包測試方法，可直接在眾包用戶設(shè)備上進行重放，減少了測試成本。

以上幾種方案是基于數(shù)據(jù)驅(qū)動的測試框架、基于關(guān)鍵字驅(qū)動的測試框架、基于圖像識別的測試框架等，大多對控件識別階段或自動化測試框架進行優(yōu)化，普遍存在靈活性、可維護性、復(fù)用性較差等缺陷。針對以上問題，本文在自動化測試階段引入智能算法。由于移動端在自動化測試時通常會對一個功能模塊測試數(shù)十次，且每當完成一次測試目標后就需要根據(jù)算法優(yōu)化測試路徑，因此在引入智能算法時要考慮是否會增加自動化測試負擔。本文以契合自動化測試流程的蟻群算法為基礎(chǔ)，結(jié)合Airtest 框架和Poco 框架處理APP 控件，提出一種基于DFS 算法和優(yōu)化蟻群算法的全路徑最優(yōu)規(guī)劃算法（All Path Optimum Programming Algorithm，APOPA），并分別在iOS 和Android 平臺上進行測試。該算法在首次遍歷界面時對控件節(jié)點進行處理，獲取信息并根據(jù)測試要求篩選控件節(jié)點，為之后優(yōu)化的蟻群算法生成測試用例進行預(yù)處理。

1 蟻群算法優(yōu)化

蟻群算法模擬了自然界螞蟻種群覓食機制［8］，最早用于旅行商（Traveling Salesman Problem）問題。在移動端上基于蟻群算法求解最優(yōu)測試用例描述如下：

假定現(xiàn)有蟻群須歷經(jīng)n 個控件，種群中存在m 只螞蟻個體，用Qij（i，j=1，2，…，n）表示控件之間的控件個數(shù)，移動端控件與傳統(tǒng)問題中的城市不同，控件之間存在樹形結(jié)構(gòu)。Qij=Qi-Qj，Qi為該節(jié)點到初始點的控件個數(shù)，規(guī)定信息素的濃度大小為τij(t)，螞蟻k（k=1，2，…，m）從控件i到控件j關(guān)鍵因素是狀態(tài)轉(zhuǎn)移概率，狀態(tài)轉(zhuǎn)移概率由以下多方面參數(shù)構(gòu)成，計算公式為：

其中：ωk(k=1,2,…,m)表示螞蟻走訪的控件集合，ηij(t)代表螞蟻由控件i向控件j移動的期望值，計算公式為：

α表示控件間信息因素的重要程度，信息素濃度對螞蟻移動的影響以α的數(shù)值表示，α越大，螞蟻行為受到的影響也越大；β為啟發(fā)函數(shù)的重要程度因子，數(shù)值越大蟻群就越容易選擇局部較短路徑［9］。

為鼓勵螞蟻盡量選擇為遍歷過程貢獻大的節(jié)點，同時盡量避免訪問重復(fù)經(jīng)過的節(jié)點［10］，對蟻群算法進行優(yōu)化，增加了信息素獎懲機制。在螞蟻遍歷完成一次測試后，從該輪解中找到最優(yōu)解，即節(jié)點最少的路徑并且成功達到測試目標的點，與之相反則為最差的解［11］。為了讓算法接近真實蟻群，加入信息素的消散因子ρ(0 <ρ<1)。本實驗將根據(jù)測試是否達到目標點來更新信息素。當完成一次測試更新信息素時，所有有向邊上的信息素都有一定程度揮發(fā)。對最優(yōu)路徑上的信息素和最差路徑上的信息素進行獎勵和懲罰，即增加最優(yōu)路徑上邊的信息素，減少最差路徑上邊的信息素［12］，公式如下：

式（3）中，(1-ρ)代表信息素剩余調(diào)整程度值，代表第k 只螞蟻完成本輪走訪后在控件i和j間分泌出的信息素增量，Δτij表示所有螞蟻完成本輪走訪分泌在控件i和j之間的信息素濃度，τreward和τpunish分別表示對最優(yōu)路徑獎勵的信息素量和對最差路徑懲罰的信息素量。

2 自動化測試方案設(shè)計

2.1 自動化測試預(yù)處理方案

深度優(yōu)先搜索算法在自動化測試中得到廣泛應(yīng)用，文獻［13-14］使用DFS 算法作為測試策略。為了保證測試的覆蓋率以及效率，本文采用DFS 算法進行預(yù)處理，對移動端的UI 控件樹深度遍歷所有節(jié)點，獲取測試路徑上所有控件的節(jié)點信息，并初步根據(jù)控件屬性、測試要求等預(yù)處理控件節(jié)點［15］；同時，針對Android 端和iOS 端APP 大量采用相同圖標的情況，利用Airtest 框架的圖像識別技術(shù)對界面進行監(jiān)控，判斷是否到達測試點，以進一步提高代碼的覆蓋率和腳本的兼容性。

自動化測試需要盡量避免回溯，因為回溯會導(dǎo)致無效的狀態(tài)轉(zhuǎn)移，使測試過程重復(fù)操作效率變低；另一方面是進入一個曾經(jīng)探索過的狀態(tài)，而該狀態(tài)需要進行回溯［16］。

在移動端自動化測試中回溯需將應(yīng)用的狀態(tài)從根節(jié)點執(zhí)行到需要回溯到的目標節(jié)點，該過程十分耗時，所以在測試過程中應(yīng)盡量避免低效的回溯。針對此類問題，采用DFS 算法獲取控件節(jié)點，然后檢測驅(qū)動事件的冗余狀態(tài)。圖1 為微信的控件截圖，其中TextView“新的朋友”和ImageView 圖片在觸發(fā)點擊事件之后，所引發(fā)的測試狀態(tài)變化是相同的，為避免造成回溯需對其進行優(yōu)化，合并造成冗余狀態(tài)的控件。對于此類驅(qū)動事件圖標和文字都是同一個控件節(jié)點的子節(jié)點，如上述兩個控件都屬于TableView-Cell 控件，并且該圖標和文字節(jié)點為葉子節(jié)點，定義當某個控件節(jié)點下方包含一個圖標和文字節(jié)點為葉子節(jié)點時，選擇該控件節(jié)點為測試點節(jié)點，不再分開點擊。

Table 1 Test results of three tested programs表1 3 個被測程序?qū)嶒灲Y(jié)果

Fig.1 WeChat TableViewCell control圖1 微信TableViewCell 控件

2.2 自動化測試平臺

隨著智能手機的普及，出現(xiàn)了一批優(yōu)秀的開源自動化測試工具［17］，如Android 集成測試框架Robotium，支持Andriod 系統(tǒng)下的移動端和網(wǎng)頁；Uiautomator 是谷歌推出的一款由Java 編寫的UI 測試框架，同樣僅支持Andriod 系統(tǒng)，在Web 端測試時受限于位置坐標的點擊；AirtestIDE 是一個跨平臺的UI 自動化測試編輯器，支持Andirod、iOS、Web，運行在Windows 和MacOS 上，支持自動化腳本錄制、一鍵回放、報告查看等功能。

通過對比，在綜合考慮平臺兼容性、腳本語言適應(yīng)性后，可知Airtest 平臺是相對綜合性較好的一款自動化測試軟件。Airtest 平臺主要涉及的框架有Poco、Airtest 等框架。Poco 是一個基于UI 控件搜索的跨引擎自動化測試框架，支持主流游戲引擎如Cocos2d-x、Unity3d、安卓原生應(yīng)用。Poco 可以準確定位到當前游戲畫面上的元素位置，還能獲取該按鈕名稱、坐標等詳細信息。Airtest 是一個基于圖像搜索的自動化測試框架，可通過圖像識別對界面上的UI 控件進行定位操作［18］。

2.3 移動端連接測試平臺

Airtest 平臺連接IOS 設(shè)備，需要在移動端創(chuàng)建一個WebDirver 服務(wù)器［19］，如圖2 所示。

Fig.2 IOS operation program圖2 IOS 操作程序

WebDirver 用于遠程操控IOS 設(shè)備，定位UI 元素，移動設(shè)備端通過注入bootstrap.sh 進行監(jiān)聽，bootstrap.sh 將執(zhí)行結(jié)果返回給AirtestIDE Server，AirtestIDE Server 再將結(jié)果返回給AirtestIDE Client。

連接安卓設(shè)備，如圖3 所示。

AirtestIDE 還可直接使用USB 通過ADB（）對手機進行控制。Android 端測試流程：AirtestIDE 把收到的請求轉(zhuǎn)發(fā)給手機上的Bootstrap jar，Bootstrap 負責監(jiān)聽AirtestIDE 命令并在手機上實現(xiàn)操作，最后Bootstrap 將執(zhí)行結(jié)果返回給AirtestIDE。

Fig.3 Andriod operation program圖3 Andriod 操作流程

3 自動化測試方案實現(xiàn)

基于全路徑的最優(yōu)規(guī)劃算法分為兩個階段：①采用DFS 算法為蟻群算法進行預(yù)處理；②優(yōu)化蟻群算法生成測試用例。

3.1 自動化測試預(yù)處理

（1）通過DFS 算法遍歷界面圖層獲取所有控件信息，保存在txt 文檔中。圖4 為DFS 算法獲取的某功能界面UI 列表，每個控件都包含相應(yīng)的信息。

Fig.4 List of interfaces obtained through DFS圖4 通過DFS 獲取的界面列表

（2）根據(jù)方案優(yōu)化合并冗余控件。

（3）測試者根據(jù)測試要求判斷節(jié)點重要性，對測試節(jié)點進行篩選，刪除無效節(jié)點，標記有效控件。在生成測試用例前，在節(jié)點間留下信息素，解決蟻群算法在前期沒有足夠信息素收斂過慢的問題。

（4）將預(yù)處理后的控件信息保存到txt 文檔中。

3.2 測試用例步驟生成

圖5 為蟻群算法生成測試用例流程。

生成測試用例流程如下：①設(shè)置起始點并開始遍歷；②獲取保存在txt 文檔中的控件信息，對無效的節(jié)點標記；獲取標記的主要控件，為其添加信息素，解決遍歷初期信息素不足問題；③更新信息素表；④計算轉(zhuǎn)移概率并遍歷，當遍歷到無效控件時跳過該控件；普通控件按照公式計算概率并選擇遍歷；⑤判斷是否到達測試點，若到達測試點則執(zhí)行步驟⑥；若沒有到達測試點則執(zhí)行步驟③；⑥保存當前路徑并篩選，對最優(yōu)路徑獎勵一部分信息素，對最差路徑懲罰一部分信息素；⑦判斷是否迭代完成，若迭代完成則執(zhí)行步驟⑧，反之跳轉(zhuǎn)至步驟③繼續(xù)迭代；⑧結(jié)束并輸出測試用例。

Fig.5 Process of generating test cases圖5 生成測試用例流程

4 實驗結(jié)果與分析

為檢驗本文所提的APOP 算法在自動化測試中的效果，從兩個方面進行驗證實驗：①采用平均測試時耗驗證算法在實際應(yīng)用中的可行性；②通過最優(yōu)路徑控件曲線驗證改進后的算法性能。

實驗環(huán)境：2018 Macbook Pro，macOS Big Sur，2.2 GHz六核Intel Core i7，內(nèi)存16 GB 2400 MHz DDR4，AirtestIDE 1.2.6。

手機端實驗環(huán)境：三星S10 Andiord10.0，iPhone12 IOS14.2.1。

本自動化測試實驗采用MacOS 操作系統(tǒng)，對iOS 以及Andiord 兩個主流移動端平臺的3 款A(yù)PP 主要功能進行自動化測試?；緟?shù)設(shè)置如下：迭代次數(shù)K=20，每代的螞蟻數(shù)量為10 只，為避免隨機性影響，每組測試50 次。實驗開始運行前將被測移動端通過WebDirver 與電腦連接，實時投影在AirtestIDE 上，設(shè)置日志路徑和格式，在電腦上運行自動化測試，根據(jù)輸出的日志來搜集UI 控件信息。

某組登錄模塊的最優(yōu)控件數(shù)量收斂曲線如圖6 所示，設(shè)置成功登錄之后的界面為測試目標，最優(yōu)控件數(shù)量為達到測試目的最少控件數(shù)量，分別使用普通蟻群算法和APOP 算法。

從圖6 可以看出，傳統(tǒng)蟻群算法所需遍歷的控件太多且迭代慢，測試結(jié)果大部分在迭代20 次之后也沒有得出最優(yōu)測試路線，而APOP 算法在保證不減少測試控件覆蓋率的情況下經(jīng)過預(yù)處理后，控件數(shù)量大幅減少，且算法可以在前期快速收斂并獲得最優(yōu)路徑。

Fig.6 The log-in module automatically tests the optimal control quantity curve圖6 登錄模塊自動化測試最優(yōu)控件數(shù)量曲線

實驗結(jié)果如表1 所示。

上述測試時耗、控件覆蓋率、腳本重復(fù)率等都是十分重要的指標。定義腳本重復(fù)率如下：

其中，Irepeat為測試iOS 版本的測試腳本和Andiord 版本的代碼重復(fù)數(shù)量，Atestcount為安卓版本的自動化測試代碼總數(shù)，Rcover越大表示在測試iOS 和Android 同一款A(yù)PP 時腳本改動越小。

上述測試用例均在相同的網(wǎng)絡(luò)環(huán)境下進行。將3 組不同的APP 進行實驗，每組別之間界面功能都有差異，根據(jù)實驗結(jié)果可知自動化測試點擊一個控件并不像人為手動點擊那樣迅速，整個測試流程有識別控件、點擊和回溯等，且整個生成測試路徑過程是一個樹狀形式，在測試過程中需要消耗的資源并不是幾個控件的入口那么簡單。在實驗中僅進行一次登錄模塊測試，點擊路徑控件最少的框架平均測試時間都需要20s，可見，為了保證測試時間和測試控件數(shù)量，在移動端自動化測試引入智能算法優(yōu)化測試路徑是必不可少的。

使用基于APOP 算法對3 款A(yù)PP 進行測試，從數(shù)據(jù)結(jié)果可知，平均測試時耗略大于錄制回放功能，在個別組內(nèi)耗時相近。但該方案在控件覆蓋率上遠大于基于錄制回放的自動化測試，平均是其3 倍左右。腳本重復(fù)率接近100%，意味著在Android 平臺和iOS 平臺，測試腳本基本無需改動，多平臺均可用。

5 結(jié)語

本文研究了Airtest 平臺下的自動化測試，綜合考慮設(shè)計了基于APOP 算法的自動化測試方案，并對這種方案進行了驗證，實驗結(jié)果表明在測試控件覆蓋率和兼容度上均有很大提高。但在擁有更多獨立控件的界面時，如何進一步優(yōu)化算法以提高系統(tǒng)兼容性和減小空間、時間復(fù)雜度，是后續(xù)要開展的另一個重要研究課題。