基于控件路徑的跨設(shè)備UI自動化測試方法①

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

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

2(安徽省計算與通信軟件重點實驗室, 合肥 230027)

1 引言

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

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

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

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

2 相關(guān)工作

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

2.1 基于編寫腳本的自動化方案

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

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

2.2 基于錄制回放的自動化方案

鑒于手動編寫測試腳本需耗費大量人力, 錄制回放的方法被提出.錄制回放的測試方法包含基于圖像匹配、基于坐標、基于控件屬性等方式.

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

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

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

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

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

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

3.1 控件路徑

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

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

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

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

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

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

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

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

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

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

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

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

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

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

圖4 GUI控件樹簡略圖

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

3.4 斷言機制

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

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

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

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

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

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

4 測試框架 RRF實現(xiàn)

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

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

圖5 RRF設(shè)計框架

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

5 實驗及分析

5.1 實驗環(huán)境

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

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

表1 測試用例介紹及實驗結(jié)果

5.2 錄制回放成功率實驗

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

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

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

5.3 斷言實驗

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

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

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

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

6 結(jié)論

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