侯津, 顧乃杰, 丁世舉, 杜云開

1(中國科學(xué)技術(shù)大學(xué) 計(jì)算機(jī)科學(xué)與技術(shù)學(xué)院, 合肥 230027)

2(安徽省計(jì)算與通信軟件重點(diǎn)實(shí)驗(yàn)室, 合肥 230027)

1 引言

近年來, 智能手機(jī)和平板的普及程度日益提高, 其上的應(yīng)用程序數(shù)量也急劇增加, 應(yīng)用程序頻繁的版本迭代導(dǎo)致大量測(cè)試資源消耗在回歸測(cè)試中.UI (User Interface)測(cè)試作為回歸測(cè)試的重點(diǎn), 其效率的提升將會(huì)直接影響測(cè)試成本.因此, UI測(cè)試的自動(dòng)化已經(jīng)成為移動(dòng)應(yīng)用測(cè)試中一個(gè)重要的研究課題.

按照自動(dòng)化程度的不同, 目前UI自動(dòng)化測(cè)試方法可分為手動(dòng)編寫測(cè)試腳本和錄制回放法兩大類.前者要求測(cè)試人員編寫測(cè)試腳本, 測(cè)試成本較高.后者錄制腳本后進(jìn)行回放, 又可細(xì)分為基于控件屬性、基于坐標(biāo)、基于圖像匹配等方式, 但這些方式普遍存在跨設(shè)備能力較弱的問題, 并且只能進(jìn)行簡單的文本斷言.現(xiàn)有的UI自動(dòng)化測(cè)試方法在面對(duì)錄放設(shè)備屏幕分辨率差異較大、或控件縮放規(guī)則不同、或開發(fā)人員未賦予控件唯一屬性時(shí), 自動(dòng)化回放成功率不高, 導(dǎo)致這種現(xiàn)象的主要原因在于這些自動(dòng)化測(cè)試方法缺少唯一定位控件的有效方式, 從而同一控件在錄放時(shí)定位至不同控件, 導(dǎo)致回放失敗.

針對(duì)缺少唯一定位控件的有效方式而導(dǎo)致的跨設(shè)備能力不足及UI語義描述過于簡單的問題, 本文提出一種基于控件路徑的跨設(shè)備UI自動(dòng)化測(cè)試方法, 在此基礎(chǔ)上實(shí)現(xiàn)了針對(duì)Android應(yīng)用和iOS應(yīng)用的UI自動(dòng)化測(cè)試框架 RRF (Record Replay Framework).該方法使用了控件路徑以唯一準(zhǔn)確地定位控件, 以此實(shí)現(xiàn)跨設(shè)備腳本錄制和回放, 并提出兩種新的斷言機(jī)制以支持與數(shù)字排序和圖片相關(guān)的UI語義.具體實(shí)現(xiàn)上,該方法一方面通過用戶操作坐標(biāo)和GUI (Graphical User Interface)控件樹生成控件路徑并寫入文件, 從而錄制跨設(shè)備測(cè)試腳本;另一方面進(jìn)行文本、排序、圖片斷言處理或使用一般搜索算法結(jié)合跨設(shè)備UI自適應(yīng)方法, 將控件路徑信息轉(zhuǎn)化成操作坐標(biāo)和操作類型,以生成手機(jī)事件進(jìn)行回放.

本文的組織結(jié)構(gòu)如下:第2節(jié)簡要介紹UI自動(dòng)化測(cè)試的研究進(jìn)展;第3節(jié)詳細(xì)敘述本文提出的基于控件路徑的跨設(shè)備UI自動(dòng)化測(cè)試方法;第4節(jié)介紹該方法面向Android和iOS應(yīng)用程序?qū)崿F(xiàn)的框架RRF;第5節(jié)進(jìn)行實(shí)驗(yàn)并分析結(jié)果;第6節(jié)對(duì)本文進(jìn)行總結(jié).

2 相關(guān)工作

近年來, UI自動(dòng)化測(cè)試的自動(dòng)化程度正逐漸提高,測(cè)試方案由自動(dòng)化程度較低的手動(dòng)編寫腳本, 發(fā)展到自動(dòng)化程度較高的錄制回放方式.

2.1 基于編寫腳本的自動(dòng)化方案

Robotium[1]是一套用于Android系統(tǒng)的自動(dòng)化測(cè)試框架.它通過重簽名被測(cè)應(yīng)用, 將測(cè)試腳本和被測(cè)應(yīng)用運(yùn)行在同一進(jìn)程中, 進(jìn)而抓取被測(cè)應(yīng)用的GUI控件信息和驅(qū)動(dòng)被測(cè)應(yīng)用的運(yùn)行.它提供基于控件文本屬性、控件唯一標(biāo)識(shí)符等的控件定位方式, 并且支持原生控件、Web控件等所有控件類型.其缺點(diǎn)在于無法進(jìn)行跨應(yīng)用的測(cè)試.為了支持跨應(yīng)用測(cè)試, Android Software Development Kit (SDK)提供了測(cè)試框架UIAutomator[2], 它將測(cè)試腳本安裝至設(shè)備中直接單獨(dú)運(yùn)行, 即可控制待測(cè)應(yīng)用.它支持跨應(yīng)用測(cè)試, 但無法支持Web控件的測(cè)試.Appium[3]的出現(xiàn)克服了上述方法功能的不完整性, 它是一款集成的自動(dòng)化測(cè)試框架,提供Android和iOS客戶端, 其中iOS客戶端可以簡單錄制并且提供GUI控件樹查看功能.Appium通過在手機(jī)服務(wù)端集成UIAutomator和其他框架以支持跨應(yīng)用和Web控件操作.

Robotium、UIAutomator、Appium等自動(dòng)化測(cè)試框架提供自動(dòng)執(zhí)行測(cè)試腳本的方法, 并且提供多種控件定位方式.但它們都需要測(cè)試人員手動(dòng)編寫測(cè)試腳本, 并且測(cè)試人員需依靠其他工具查看控件屬性等信息以編寫腳本.

2.2 基于錄制回放的自動(dòng)化方案

鑒于手動(dòng)編寫測(cè)試腳本需耗費(fèi)大量人力, 錄制回放的方法被提出.錄制回放的測(cè)試方法包含基于圖像匹配、基于坐標(biāo)、基于控件屬性等方式.

李昕宇等提出了一種基于圖像匹配的移動(dòng)應(yīng)用自動(dòng)化測(cè)試方法[4], 其工作主要針對(duì)手機(jī)軟件中比較常見的文字、圖片、控件、列表及網(wǎng)格等不同類型的區(qū)域,建立基準(zhǔn)圖像庫, 通過基于特征點(diǎn)匹配的圖像匹配方法, 實(shí)現(xiàn)對(duì)手機(jī)界面顯示結(jié)果的正確性評(píng)估.這種方法雖然不需要用戶編寫測(cè)試腳本, 但只能進(jìn)行界面測(cè)試,無法進(jìn)行功能測(cè)試.

隨后出現(xiàn)基于坐標(biāo)的錄制回放工具, 例如Jacareto[5]、MonkeyRunner[6]、Monkey[7]及 Pounder[8],可以支持UI功能測(cè)試.它們記錄鼠標(biāo)點(diǎn)擊坐標(biāo)和鍵盤事件, 在回放中, 使用捕獲的信息創(chuàng)建新的觸屏和鍵盤事件.這些基于坐標(biāo)的錄制回放方法, 簡單快速且很少需要測(cè)試人員干預(yù).但錄放設(shè)備不同時(shí), 同一個(gè)錄制坐標(biāo)在回放中可能定位到不同的控件, 從而導(dǎo)致回放操作和錄制操作不一致.因此這種方法跨設(shè)備能力不足,并且不支持UI組件層次的斷言.RERAN是一種Android平臺(tái)下的錄制回放方法[9], 在該方法中, 用戶對(duì)設(shè)備的操作直接通過底層的事件流捕獲, 然后通過在設(shè)備的事件流中注入捕獲的事件來實(shí)現(xiàn)回放過程.這種方法類似于基于坐標(biāo)的方法, 但它不僅可以捕獲觸摸事件, 還可以捕獲其它由傳感器產(chǎn)生的事件.然而,由于它不能提供測(cè)試腳本和斷言操作, 測(cè)試人員很難理解和編輯測(cè)試用例, 或檢驗(yàn)UI組件的輸出.

針對(duì)基于坐標(biāo)的錄制回放無法提供腳本修改及UI層次的斷言等問題, Chien-Hung Liu 等提出一種Android平臺(tái)下基于GUI控件樹插樁的錄制回放方法[10].該方法在視圖層次結(jié)構(gòu)樹的根結(jié)點(diǎn)下面引入一個(gè)稱為interceptlayout的模擬布局[11].其可以攔截從根視圖分發(fā)的所有鍵和觸摸事件, 然后生成基于Robotium的錄制腳本, 直接使用Robotium即可進(jìn)行回放.但該方法需提供待測(cè)應(yīng)用程序的源碼, 且不能進(jìn)行跨應(yīng)用測(cè)試.另外當(dāng)錄放設(shè)備屏幕分辨率差別較大而導(dǎo)致回放設(shè)備中的部分控件被屏幕遮擋的情況, 該方法也無法適用.因此該方法仍存在跨設(shè)備能力有限的不足之處.

Kaasila等提供了一個(gè)名為Testdroid的在線Android應(yīng)用程序測(cè)試平臺(tái)[12], 支持UI組件層次的斷言且不需提供源碼.該平臺(tái)通過跟蹤與之交互的UI組件記錄用戶操作, 記錄的操作被翻譯成Robotium測(cè)試腳本, 可以與被測(cè)試應(yīng)用程序一起上傳到平臺(tái).測(cè)試腳本被自動(dòng)調(diào)度且并行地在一組可用的物理設(shè)備上執(zhí)行,然后通過平臺(tái)可以訪問跨多個(gè)設(shè)備的測(cè)試結(jié)果, 然而它不支持跨應(yīng)用測(cè)試, 跨設(shè)備能力不足且只支持文本相關(guān)的UI語義.

3 基于控件路徑的跨設(shè)備GUI測(cè)試方法

基于坐標(biāo)、基于控件屬性等錄制回放測(cè)試方法,由于在應(yīng)對(duì)不同分辨率場(chǎng)景時(shí)精確定位控件的能力有限, 導(dǎo)致了測(cè)試腳本無法完全適用于其他設(shè)備, 因此跨設(shè)備能力差.另外上述方法也存在斷言機(jī)制簡單的弊端.在此背景下, 本節(jié)提出了基于控件路徑的自動(dòng)化測(cè)試方法以精確定位控件錄制跨設(shè)備腳本, 以及提出了UI自適應(yīng)方法以應(yīng)對(duì)錄放設(shè)備分辨率差距較大的場(chǎng)景;另外還將介紹排序、圖片兩種斷言機(jī)制.

3.1 控件路徑

定義1.移動(dòng)應(yīng)用程序的GUI由圖形用戶界面對(duì)象(控件)組成, 一個(gè)或多個(gè)頁面的控件形成的樹形結(jié)構(gòu)被定義為GUI控件樹.

定義2.描述一個(gè)控件從GUI控件樹根結(jié)點(diǎn)到該控件結(jié)點(diǎn)的絕對(duì)路徑被定義為控件路徑.

GUI控件樹包含了控件的一組固定的屬性.在GUI執(zhí)行期間, 這些控件包含控件相應(yīng)的信息, 如控件的rect屬性, 它構(gòu)成了一個(gè)矩形框用以描述控件在頁面的位置和大小.利用GUI控件樹結(jié)合控件操作坐標(biāo)信息即可生成控件路徑.XPath (XML Path Language)是XML路徑語言, 它是一種用來表示XML文檔中某部分位置的語言.控件路徑是XPath的一種表達(dá)形式用以精確描述該控件在GUI界面中的位置.圖1為部分控件樹屬性示意圖.在此部分控件樹中, 結(jié)點(diǎn)d的控件路徑一種表示方式為/table[1]/cell[1]/text[1], 其中每個(gè)結(jié)點(diǎn)是一個(gè)控件, table、cell、text表示控件type即類型, 1表示該結(jié)點(diǎn)是父結(jié)點(diǎn)子樹中第一個(gè)此類型的結(jié)點(diǎn), 即該結(jié)點(diǎn)的index(索引值), 也可通過name屬性和index結(jié)合表示.

圖1 GUI控件樹及屬性示意圖

由圖1可見, 控件的屬性如id或text等不唯一確定.它們可空可相同, 這些由開發(fā)人員設(shè)定.因此采用控件屬性定位控件的方法普遍存在找不到控件或定位多個(gè)控件的情況, 即使通過聯(lián)合使用控件屬性也仍然不能完全覆蓋所有GUI場(chǎng)景.而控件路徑可以有效解決控件定位的問題以達(dá)到唯一準(zhǔn)確定位控件的目的.圖1中, 每個(gè)控件都有唯一確定的控件路徑與之對(duì)應(yīng).并且當(dāng)待測(cè)應(yīng)用的版本穩(wěn)定, 整個(gè)頁面的架構(gòu)和控件結(jié)構(gòu)是確定的, 這是由開發(fā)代碼控制的, 即同一應(yīng)用的同一版本在某系統(tǒng)中的某狀態(tài)下GUI控件樹是確定的, 所以控件路徑在搭載同一系統(tǒng)中的不同設(shè)備中也可唯一準(zhǔn)確定位控件.因此基于控件路徑的方法具有良好的跨設(shè)備能力.理論情況下移動(dòng)設(shè)備上的應(yīng)用只要顯示為相同的頁面布局且具有相同的GUI控件樹,此方法都適用.如該方法適用于搭載同一版本Android系統(tǒng)的不同型號(hào)手機(jī)、平板或者搭載同一版本iOS系統(tǒng)的不同型號(hào)手機(jī)、平板.

3.2 跨設(shè)備腳本錄制方法

由于基于控件路徑的方法具有良好的跨設(shè)備能力,因此跨設(shè)備腳本錄制使用了控件路徑作為控件定位的依據(jù).本節(jié)將介紹如何獲取相關(guān)信息, 并將其轉(zhuǎn)化成控件路徑以錄制成腳本.

跨設(shè)備腳本錄制方法流程圖見圖2.首先通過事件處理算法處理監(jiān)聽信息, 以獲取用戶操作類型和坐標(biāo)信息;其中操作坐標(biāo)信息用于生成控件路徑, 操作類型用于回放的事件重構(gòu).然后通過系統(tǒng)框架抓取手機(jī)當(dāng)前狀態(tài)的GUI控件樹, 這里不會(huì)對(duì)應(yīng)用進(jìn)行任何修改;由于不同狀態(tài)下控件的屬性會(huì)發(fā)生變化, GUI控件樹需要實(shí)時(shí)渲染以提供最新GUI控件樹信息.接著通過操坐標(biāo)信息和GUI控件樹進(jìn)行控件定位并生成控件路徑, 即使用坐標(biāo)在GUI控件樹中深度搜索包含該坐標(biāo)的最小控件, 該控件即為用戶操作控件;記錄該控件的控件路徑和操作坐標(biāo)在其的比例來更精確定位操作位置.最后將所有信息寫入文件, 即可生成跨設(shè)備測(cè)試腳本.

圖2 跨設(shè)備腳本錄制流程圖

控件路徑具體生成步驟見算法1, 該算法使用操作坐標(biāo)p在GUI控件樹深度搜索, 查找符合條件的最小控件(2–4行).待找到最小控件結(jié)點(diǎn)后將路徑上所有結(jié)點(diǎn)的 type、index 入棧 (第 6行).深度遍歷完成后, 出棧所有的結(jié)點(diǎn)type和index組合即可生成控件路徑.

3.3 跨設(shè)備UI自適應(yīng)

基于控件路徑的測(cè)試方法支持大部分情況的跨設(shè)備回放.但當(dāng)設(shè)備間屏幕尺寸和分辨率差別較大, 待操作控件在錄放設(shè)備中顯示不同時(shí), 仍可能存在回放失敗的情況.如圖3在一個(gè)長屏手機(jī)A錄制點(diǎn)擊控件b3的腳本, 在短屏手機(jī)B中回放.由于屏幕外的控件無法被操作, 而控件b3在短屏手機(jī)中未顯示.因此即使通過控件路徑定位到該控件, 也無法回放該控件的操作.此時(shí)跨設(shè)備UI自適應(yīng)方法通過滑動(dòng)屏幕, 重新渲染GUI界面來顯示待操作控件至當(dāng)前界面以解決這個(gè)問題.

圖3 錄放設(shè)備屏顯示意圖

跨設(shè)備UI自適應(yīng)方法首先確定滑動(dòng)的方向.某狀態(tài)GUI控件樹見圖4, 控件anc、a、b、c是控件樹的一部分.anc是 a、b、c的上層結(jié)點(diǎn)即父親結(jié)點(diǎn), 控件b顯示在手機(jī)屏幕中而控件a、c在屏幕外.下面結(jié)合圖4來介紹鑒定滑動(dòng)方向的方法.假設(shè)c為待查找控件.首先在屏幕內(nèi)任意找到一個(gè)控件b, 然后遍歷b和c的祖先結(jié)點(diǎn)并找到最近公共祖先結(jié)點(diǎn)anc.由anc分別沿著控件b、c的子樹向下遍歷, 并比較兩子樹同層結(jié)點(diǎn)的index, 若c結(jié)點(diǎn)的 index較大, 則c在 b的下方, 向上滑動(dòng), 否則向下滑動(dòng).圖中所示 a、b、c在控件樹的同層且控件c的index較大, 故c在b的下方,此時(shí)通過上滑操作即可將c滑入屏幕內(nèi).確定滑動(dòng)方向后, 下一步需要確定滑動(dòng)距離.由于控件或自適應(yīng)設(shè)備或保持不變, 單個(gè)滑動(dòng)的最大距離不超過s.最大距離s根據(jù)公式(1)得出.

圖4 GUI控件樹簡略圖

h和h′分別是設(shè)備A錄制和設(shè)備B回放中控件的高度, 當(dāng)h′/h<1時(shí), 令h′/h=1, 此時(shí)認(rèn)為控件保持不變即h′/h=1所得的s值為該控件可滑動(dòng)也就是縮放的最大距離.H和H′分別是錄放設(shè)備屏幕的高度, 單位均為像素.其中h′/h在Android平臺(tái)下可由單位轉(zhuǎn)換公式(2)轉(zhuǎn)化為dpi′/dpi, 即回放與錄制設(shè)備屏幕密度比.計(jì)算出跨設(shè)備自適應(yīng)的最大距離后, 每次滑動(dòng)s/4距離,并重新渲染GUI界面, 直到屏幕內(nèi)顯示出待查找控件.

3.4 斷言機(jī)制

斷言用來驗(yàn)證應(yīng)用程序執(zhí)行的正確性, 快速定位錯(cuò)誤.

定義3.在UI自動(dòng)化測(cè)試中, 基于UI語義的斷言算法可以表示為一個(gè)三元組＜C,P,R＞, 其 中C={c1,c2,···,cn}是錄制時(shí)UI屬性數(shù)據(jù)集,c1,c2,···,cn分別是錄制時(shí)各UI控件的屬性數(shù)據(jù);R={r1,r2,···,rn}是回放時(shí)UI屬性數(shù)據(jù)集,r1,r2,···,rn分別是回放時(shí)各UI控件的屬性數(shù)據(jù).P={p1,p2,···,pn}是有窮的斷言規(guī)則的集合.

定義4.對(duì)于?pi∈P, 由Assert(ci,ri)表示控件i是否符合斷言規(guī)則pi.若符合規(guī)則pi, 則Assert(ci,ri)=1, 否則Assert(ci,ri)=0.

其中P包括文本斷言、排序斷言、圖片斷言.在UI自動(dòng)化測(cè)試中,?pi∈P, 都有Assert(ci,ri)=1, 則未檢出錯(cuò)誤(前提是加入的斷言符合程序正確運(yùn)行的規(guī)律).

文本斷言首先對(duì)控件進(jìn)行定位, 然后將控件的屬性信息和錄制信息比較以驗(yàn)證程序執(zhí)行正確性.在許多應(yīng)用中網(wǎng)格或者表格控件提供一列或者一行數(shù)據(jù)的排序, 如股價(jià)排序、QQ訪問量排名等.排序斷言自動(dòng)判斷UI界面某行或某列數(shù)據(jù)是否有序, 以應(yīng)對(duì)該測(cè)試場(chǎng)景.排序斷言主要在于解決如何獲取應(yīng)用程序一行或一列數(shù)據(jù)的問題, 然后判斷該序列有序即可.針對(duì)這個(gè)問題, 首先根據(jù)一行或一列的兩個(gè)控件路徑定位具體控件, 然后查找這兩個(gè)控件的最近公共祖先結(jié)點(diǎn), 沿著祖先結(jié)點(diǎn)往下搜索本行或本列的所有控件, 加入待排序集合.同一行的結(jié)點(diǎn)控件路徑的最后一層index不同, 由公共祖先結(jié)點(diǎn)到倒數(shù)第二層的所有結(jié)點(diǎn)皆具有相同的index, 類似于相同的行號(hào);相對(duì)的同一列結(jié)點(diǎn)則是中間某層祖先結(jié)點(diǎn)的index不同, 其后的所有層結(jié)點(diǎn)index均相同.獲取排序集合具體算法見算法2, 首先進(jìn)行初始化, 由XPathToNode()定位到XPath1、XPath2所在控件結(jié)點(diǎn), 并由getAncestor()返回兩個(gè)結(jié)點(diǎn)的最近公共祖先結(jié)點(diǎn)ancestor(1–3行);然后將ancestor入隊(duì)列nodes, 將XPath1、XPath2分割成單個(gè)結(jié)點(diǎn)信息, 將ancestor結(jié)點(diǎn)及后代結(jié)點(diǎn)入隊(duì)列(4–6行);結(jié)點(diǎn)總數(shù)不同時(shí)說明選中的兩個(gè)結(jié)點(diǎn)是非同行或同列結(jié)點(diǎn), 此時(shí)直接返回(7–8行).兩個(gè)結(jié)點(diǎn)從祖先結(jié)點(diǎn)的下一個(gè)結(jié)點(diǎn)開始分別往下遍歷, 當(dāng)兩者當(dāng)前結(jié)點(diǎn)的index不同, 若已經(jīng)遍歷到最后一層則是這兩個(gè)結(jié)點(diǎn)屬于同行結(jié)點(diǎn), 直接將這層所有結(jié)點(diǎn)即curNode的所有孩子結(jié)點(diǎn)入隊(duì)列nodes并返回結(jié)果;若非最后一層說明兩個(gè)結(jié)點(diǎn)屬于同一列, 此時(shí)將這一層(假設(shè)第k層)的所有結(jié)點(diǎn)即curNode的所有孩子結(jié)點(diǎn)入隊(duì)列nodes, 其后兩個(gè)結(jié)點(diǎn)每層(第k+n層)祖先結(jié)點(diǎn)的index均相同, 出隊(duì)列所有結(jié)點(diǎn)curNode, 并將每一個(gè)curNode孩子結(jié)點(diǎn)中index與nodes1當(dāng)前結(jié)點(diǎn)index相同的結(jié)點(diǎn)入隊(duì)列nodes;最后隊(duì)列nodes中所有結(jié)點(diǎn)即為待排序集合(9–18行).

由于控件的某些屬性由開發(fā)人員設(shè)定, 所以文本控件屬性值存在為空的情況, 或者界面某部分不是一個(gè)控件如只是一個(gè)文本控件的部分, 而文本斷言或排序斷言需識(shí)別出控件, 然后對(duì)控件中的文本屬性值進(jìn)行校驗(yàn).所以在面對(duì)上述兩種斷言場(chǎng)景時(shí), 上述斷言無法使用.針對(duì)上述情況, 基于圖像匹配的圖片斷言被提出, 其提供用戶截取一部分區(qū)域然后與回放時(shí)頁面截圖進(jìn)行比較以提供自動(dòng)校驗(yàn)UI界面顯示結(jié)果的能力,例如校驗(yàn)?zāi)硞€(gè)搜索按鈕是否顯示在界面上或某部分文字排列是否和錄制時(shí)相同等.由于該方法基于圖片對(duì)比所以不要求截取區(qū)域是一個(gè)控件或必須有控件屬性值.具體方法是準(zhǔn)備錄制時(shí)截取的圖片和回放當(dāng)前頁面截圖.然后使用 O p e n C V的模板匹配算法matchTemplate返回圖片匹配結(jié)果.由于在不同分辨率場(chǎng)景錄放設(shè)備相同位置截取的區(qū)域可能存在偏差, 若使用相應(yīng)坐標(biāo)位置在回放頁面中進(jìn)行截圖對(duì)比, 可能匹配失敗.而本方法用錄制截圖在整個(gè)回放頁面截圖中進(jìn)行查找, 只要回放頁面中顯示出相同的布局則會(huì)查找成功, 所以可以應(yīng)對(duì)不同分辨率場(chǎng)景.對(duì)于圖片中有多個(gè)匹配點(diǎn)的情況, 匹配成功個(gè)數(shù)作為結(jié)果返回.通過上述圖片斷言方法來判斷回放中UI界面顯示的正確性.

4 測(cè)試框架 RRF實(shí)現(xiàn)

RRF是基于上述方法針對(duì)Android應(yīng)用、iOS應(yīng)用實(shí)現(xiàn)的自動(dòng)化測(cè)試框架.該框架的設(shè)計(jì)框架如圖5.

圖5中實(shí)線箭頭經(jīng)過路徑代表跨設(shè)備腳本的錄制.錄制由捕獲手機(jī)事件開始, 這里RRF采用手機(jī)端捕獲和電腦端捕獲兩種方法.為了支持Android手機(jī)端錄制的事件捕獲,RRF使用了Android SDK 提供的getevent工具.getevent用來讀取/dev/input/event*設(shè)備文件.當(dāng)用戶與Android應(yīng)用程序交互時(shí), 用戶事件通過Android設(shè)備的傳感器生成/dev/input/event *設(shè)備文件并發(fā)送至內(nèi)核, 事件格式為(時(shí)間戳 設(shè)備 類型 編號(hào)值), 觸屏手勢(shì)被編碼為上述格式的觸摸屏事件流.例如, 1494674903/dev/input/event1 0003 0035 0000013c表示一個(gè)點(diǎn)觸事件.其中前三項(xiàng)分別對(duì)應(yīng)時(shí)間戳、設(shè)備和觸摸事件類型,0035對(duì)應(yīng)于事件的x位置, 0000013c(十六進(jìn)制)對(duì)應(yīng)于屏幕的坐標(biāo)316(十進(jìn)制).高級(jí)手勢(shì)操作通常涉及多個(gè)觸摸屏事件.RRF通過觸摸屏事件處理算法對(duì)這些底層數(shù)據(jù)進(jìn)行處理, 抽象出用戶的各種高級(jí)手勢(shì)操作和坐標(biāo).對(duì)于電腦端錄制的事件獲取,RRF則通過不斷截取手機(jī)屏幕圖片, 映射至電腦后在電腦端操作手機(jī)屏幕;然后監(jiān)聽鼠鍵事件, 并生成手機(jī)操作事件信息.下一步通過不斷重新渲染GUI界面, 由Android或iOS系統(tǒng)框架實(shí)時(shí)獲取GUI控件樹.由上述步驟獲取兩個(gè)輸入后, 利用第3節(jié)的控件路徑生成算法進(jìn)行控件定位并生成控件路徑,然后將控件路徑及其他描述信息, 包括斷言、錄制截圖等寫入文件, 生成XML測(cè)試腳本, 到此跨設(shè)備腳本的錄制過程結(jié)束.此外RRF將測(cè)試用例中的數(shù)據(jù)信息和邏輯操作分存儲(chǔ)成數(shù)據(jù)文件、邏輯文件.當(dāng)邏輯操作相同時(shí), 只需要改動(dòng)數(shù)據(jù)文件即可生成新的測(cè)試腳本, 以減少了錄制的重復(fù)工作.

圖5 RRF設(shè)計(jì)框架

圖5中虛線箭頭經(jīng)過路徑表示跨設(shè)備腳本的回放過程.回放的核心模塊是使用控件路徑進(jìn)行控件定位或斷言.這里的控件定位是將錄制腳本翻譯成待操作控件, 精確至坐標(biāo).該模塊有兩個(gè)輸入, 分別是當(dāng)前GUI控件樹和錄制腳本信息.RRF通過控件路徑在GUI控件樹查找控件, 面對(duì)3.3節(jié)所述場(chǎng)景通過UI適應(yīng)方法調(diào)整UI顯示, 然后獲取控件坐標(biāo)信息.隨后通過Android平臺(tái)的UIAutomator框架、iOS平臺(tái)的WebDriverAgent[13]框架等執(zhí)行手機(jī)指令.根據(jù)3.4節(jié)實(shí)現(xiàn)斷言, 即控件定位后直接驗(yàn)證字符串、數(shù)字?jǐn)嘌?或利用算法2獲取待排序集合, 實(shí)現(xiàn)排序斷言;或利用圖片比對(duì)算法返回錄制截取圖片在當(dāng)前頁面匹配個(gè)數(shù),實(shí)現(xiàn)圖片斷言;另外為了提高效率,RRF支持同一腳本安裝至多個(gè)設(shè)備同時(shí)回放, 以提高RRF測(cè)試效率.

5 實(shí)驗(yàn)及分析

5.1 實(shí)驗(yàn)環(huán)境

待測(cè)設(shè)備包括一臺(tái)紅米A2搭載Android 4.2.4系統(tǒng), 辨率為720*1280;一臺(tái)華為榮耀6搭載Android 4.4.2系統(tǒng), 分辨率為 720*1184;一臺(tái)小米 4搭載Android 4.0.4系統(tǒng), 分辨率為 1920*1080.待測(cè)軟件為國泰君安君宏8.8.5, QQv7.5.5.

由于iOS平臺(tái)下錄制回放工具較少, 且iOS平臺(tái)下的RRF與Android平臺(tái)的基本一致.本實(shí)驗(yàn)只針對(duì)兩款A(yù)ndroid平臺(tái)的錄制回放工具和Android平臺(tái)下的RRF進(jìn)行對(duì)比實(shí)驗(yàn), 這兩款工具分別是基于坐標(biāo)的MonkeyRunner和基于控件屬性的iTestin[14].在回放成功率實(shí)驗(yàn)中, 回放步驟和錄制完全一致則為成功, 每個(gè)測(cè)試用例各錄制回放50次以統(tǒng)計(jì)回放成功率.在斷言實(shí)驗(yàn)中, 程序斷言結(jié)果和預(yù)期結(jié)果一致則為成功, 每個(gè)測(cè)試用例同樣各錄制回放50次來記錄正確率.

表1 測(cè)試用例介紹及實(shí)驗(yàn)結(jié)果

5.2 錄制回放成功率實(shí)驗(yàn)

本實(shí)驗(yàn)3個(gè)測(cè)試用例.每個(gè)測(cè)試用例錄制多個(gè)腳本進(jìn)行回放.登錄和股票搜索測(cè)試僅對(duì)待測(cè)軟件進(jìn)行操作, 操作手勢(shì)包括點(diǎn)擊、滑動(dòng)等, 操作控件的類型包含原生、混合、WebView所有的控件類型;注冊(cè)測(cè)試為跨應(yīng)用測(cè)試, 涉及待測(cè)軟件和信息兩個(gè)應(yīng)用, 操作手勢(shì)僅包含點(diǎn)擊操作.實(shí)驗(yàn)首先根據(jù)測(cè)試用例的操作序列, 在選定錄制設(shè)備上進(jìn)行腳本錄制;然后在回放設(shè)備中回放錄制腳本;最后統(tǒng)計(jì)錄制回放成功率.

針對(duì)MonkeyRunner、iTestin失敗的現(xiàn)象, 經(jīng)過分析錄制腳本、相關(guān)日志等記錄, 基于坐標(biāo)的Monkey Runner在錄放時(shí)相同坐標(biāo)會(huì)定位到不同的控件從而回放失敗率較高, 而控件路徑則可以在具有相同控件樹的不同設(shè)備中唯一定位控件, 因此基于控件路徑的方法具有比基于坐標(biāo)的測(cè)試方法具有更好的跨設(shè)備能力.另外由于基于坐標(biāo)的方式不能識(shí)別出控件, 所以也不支持上文所述的UI組件層次上的斷言.而iTestin使用基于組件屬性組合的方式進(jìn)行錄制, 由于控件屬性組合存在不能唯一定位控件的情況, 從而其在錄放設(shè)備中控件定位不精確, 所以跨設(shè)備能力相對(duì)較弱, 而RRF使用基于控件路徑的方法可以唯一精確定位控件且在回放時(shí)未顯出待查找控件的情況下通過UI自適應(yīng)方法進(jìn)行控件查找以操作控件, 所以具有較好的跨設(shè)備能力.另外由于iTestin基于Robotium框架, 所以它不具有跨應(yīng)用測(cè)試的能力.對(duì)于RRF失敗的測(cè)試結(jié)果, 分析其原因是由于測(cè)試用例受網(wǎng)絡(luò)的影響數(shù)據(jù)加載時(shí)長不定, 影響滑動(dòng)的執(zhí)行結(jié)果的準(zhǔn)確性, 進(jìn)而影響測(cè)試腳本的后續(xù)執(zhí)行, 最終導(dǎo)致回放失敗.總體而言,RRF提供了一種可以跨設(shè)備的黑盒自動(dòng)化測(cè)試方法以進(jìn)行UI功能測(cè)試或回歸測(cè)試, 其相較于基于圖片的方式具有較廣的應(yīng)用場(chǎng)景, 較于基于坐標(biāo)或組件屬性的方式具有較好的跨設(shè)備能力, 其在跨設(shè)備支持上達(dá)到了很好的效果, 錄制回放成功率也高于傳統(tǒng)的框架.

實(shí)驗(yàn)結(jié)果見表1.從中可以看出在實(shí)驗(yàn)的測(cè)試用例中RRF完全支持跨應(yīng)用測(cè)試, 且跨設(shè)備測(cè)試成功率達(dá)90%以上.作為對(duì)比, MonkeyRunner不具有跨設(shè)備能力, iTestin跨設(shè)備能力較弱且不能跨應(yīng)用.

5.3 斷言實(shí)驗(yàn)

由于現(xiàn)有的自動(dòng)化測(cè)試框架不具有自動(dòng)排序和圖片斷言能力, 第二節(jié)所述基于組件的方式只具有文本斷言能力.本實(shí)驗(yàn)僅對(duì)RRF的斷言成功率進(jìn)行測(cè)試.

本實(shí)驗(yàn)首先在錄制過程中對(duì)漲幅和最新價(jià)加入排序斷言或截取圖片片段加入圖片斷言, 然后回放并統(tǒng)計(jì)回放結(jié)果, 最后根據(jù)待測(cè)軟件內(nèi)容人工設(shè)置斷言的預(yù)期結(jié)果, 并計(jì)算斷言成功率.其中圖片斷言預(yù)期結(jié)果為成功匹配圖片個(gè)數(shù).

由表2可見, 本框架支持排序、圖片斷言, 且正確率高于90%.對(duì)于圖片斷言失敗的測(cè)試結(jié)果, 分析原因有以下兩點(diǎn).其一是因?yàn)榻厝D片為動(dòng)態(tài)變化圖片, 導(dǎo)致回放時(shí)錄制截圖恰好不在當(dāng)前頁面內(nèi)而無法成功匹配錄制截圖.其二是網(wǎng)絡(luò)加載延時(shí)而導(dǎo)致當(dāng)前界面未完全加載就執(zhí)行圖片匹配算法, 進(jìn)而導(dǎo)致匹配失敗.針對(duì)第一點(diǎn)由于App情況不可控導(dǎo)致的斷言失敗情況,可通過測(cè)試人員人工排查.針對(duì)第二點(diǎn)失敗情況,RRF提供用戶添加延時(shí)以等待圖片加載完成.

表2 斷言測(cè)試結(jié)果

6 結(jié)論

本文提出了一種基于控件路徑的跨設(shè)備UI自動(dòng)化測(cè)試方法, 并實(shí)現(xiàn)了針對(duì)Android和iOS應(yīng)用程序的框架RRF.這種測(cè)試方法解決了編寫和管理測(cè)試腳本困難的問題, 同時(shí)也解決了現(xiàn)有工具普遍跨設(shè)備能力差和斷言簡單的問題.RRF實(shí)現(xiàn)跨設(shè)備、跨應(yīng)用的錄制回放, 支持多種斷言場(chǎng)景, 并且不需對(duì)被測(cè)應(yīng)用程序有任何修改, 另外還支持多設(shè)備同時(shí)回放, 可以很大程度上提供測(cè)試人員的工作效率.在未來的工作中, 將添加測(cè)試工具對(duì)手機(jī)上各種傳感器(例如加速度計(jì)、指南針、GPS等)的支持, 以達(dá)到支持更多App自動(dòng)化測(cè)試的目的.