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

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

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

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

1 引言

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

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

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

本文的組織結構如下:第2節簡要介紹UI自動化測試的研究進展;第3節詳細敘述本文提出的基于控件路徑的跨設備UI自動化測試方法;第4節介紹該方法面向Android和iOS應用程序實現的框架RRF;第5節進行實驗并分析結果;第6節對本文進行總結.

2 相關工作

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

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

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

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

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

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

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

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

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

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

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

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

3.1 控件路徑

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

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

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

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

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

3.2 跨設備腳本錄制方法

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

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

圖2 跨設備腳本錄制流程圖

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

3.3 跨設備UI自適應

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

圖3 錄放設備屏顯示意圖

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

圖4 GUI控件樹簡略圖

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

3.4 斷言機制

斷言用來驗證應用程序執行的正確性, 快速定位錯誤.

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

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

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

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

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

4 測試框架 RRF實現

RRF是基于上述方法針對Android應用、iOS應用實現的自動化測試框架.該框架的設計框架如圖5.

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

圖5 RRF設計框架

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

5 實驗及分析

5.1 實驗環境

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

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

表1 測試用例介紹及實驗結果

5.2 錄制回放成功率實驗

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

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

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

5.3 斷言實驗

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

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

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

表2 斷言測試結果

6 結論

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