移動應用GUI 測試技術綜述

張光蘭，萬瑩

（四川大學計算機學院，成都 610065）

0 引言

據統計，全球智能手機用戶的數量預計將從2016年的21 億增加到2019 年的25 億左右[1]。這導致了對運行在這些設備（應用程序）上的新軟件應用程序的持續需求，而目前針對移動應用的測試方法和傳統的桌面端軟件的測試方法一致，可分為手工測試和自動化測試。手工GUI 測試方法，顧名思義，就是一種比較傳統也比較常見的方法，其存在的問題是：人工成本高、工作進度無法評估、工作成果依賴于測試工程師的經驗[2]。并且隨著時間的發展，GUI 軟件會變得大型化、復雜化和多元化[3]。此外，帶有GUI 移動應用程序的自動化技術比帶有GUI 桌面應用程序自動化測試技術要更加復雜，例如：平臺多樣性、移動應用更新速度快、市場壓力都給移動應用的測試帶了新的挑戰。

1 GUI測試的定義

GUI（Graphical User Interface，圖形用戶界面）是底層程序代碼的前端表示形式，對諸如選擇下拉列表框、菜單、導航欄、按鈕控件等用戶操作會作出相對應的前端反映[4]。因為帶有圖形界面的軟件相對與傳統的軟件而言，其美觀的圖形用戶界面帶給了用戶們最直觀的體驗，使得用戶可以快速上手而逐漸受到用戶的青睞。所以在目前市場上的軟件大多都帶圖形用戶界面。所以，針對GUI 進行的軟件測試也應該成為整個GUI 軟件測試中非常重要的一部分[4]。

而GUI 測試指對帶有GUI 的軟件進行軟件測試，如文獻[5～8]中說提及的GUI 測試是通過測試應用程序的GUI，從而達到測試被測系統的功能、GUI 的結構及實現GUI 的代碼。而移動端的GUI 測試用例指的是一個完成的用戶行為的一系列相關的事件/動作，即移動應用程序的GUI 測試用例是由一系列的事件/動作組成。由此可見，移動應用的GUI 測試的輸入一般都是事件/動作，而輸出一般是狀態的變化。狀態變化可能體現為頁面的變化，也可能是頁面中某些元素的狀態變化等。針對移動應用的GUI 測試用例中，事件/動作之間的依賴關系也是一項非常重要的活動[9]。

2 GUI測試方法

2.1 GGUUII測試框架

目前存在常用的GUI 測試框架如表1 所示，由于篇幅的原因，我們只是列舉了比較常見的框架，其中Uiautomator 框架中提供的API 可以對移動應用程序進行頁面截圖及頁面的元素的結構信息文件。

表1 常見的GUI 測試框架

●Instrumentation 是Android 主推的白盒測試框架。在單元測試的基礎上進行功能擴展，達到對Android系統的高度控制，Robotium[10]、Selendroid[11]、Athrun[12]都是基于Instrumentation 的二次封裝框架，其缺點是不能跨應用使用。

●Calabash[13]是一個適用于iOS 和Android 開發者的跨平臺App 測試框架，可用來測試屏幕截圖、手勢和實際功能代碼。缺點：測試步驟失敗后，將跳過所有的后續步驟，需要Calabash 框架安裝在iOS 的ipa 文件中，因此測試人員必須要有iOS 的App 源碼。除了Ruby，對其他語言不友好。

●Monkey[14]是谷歌提出的，它可以生成一些偽隨機用戶事件流發送到被測試系統中，然后模擬用戶的點擊等手勢，以及一些系統級的事件。它應該是目前流行移動端自動化框架或者工具的一個鼻祖。Monkeyrunner 同樣是Android SDK 自帶的測試工具，它可以用于做功能測試，回歸測試并且可以自己定義測試擴展，靈活性較大。Monkeyrunner 工具提供了一些API，可以通過該 API 來控制 Android 設備或者模擬器。

●Uiautomator 是通過以控件的方式來定位，當然也是支持坐標軸的方式來定位。缺點：Uiautomator 是Android 4.1 后加入的，所以僅支持Android 4.1 和以上的版本，但是不支持Webview。

●Appium[15]：同時支持 Android、iOS、FirefoxOS。并且Appium 可以用任何你熟悉的開發語言來進行編寫測試用例。例如 Java、Python、Ruby、PHP、JavaScript、Object-C、C#。采用的控件的定位方式對不懂Java 而熟悉其他語言的來說還是相當不錯的選擇。缺點是穩定性相對較差。

2.2 GGUUII測試技術

在移動應用程序的測試中，現有很多的測試手段：云測、眾測、自測、外包測試等不同的方式；目前提供云測試的平臺服務很多，最出名的是Testin 云測（Android&iOS）、百度 MT（Android&iOS）、阿里 MQC（Android&iOS）、貫眾云測試（Android&iOS）、騰訊優測（Android）。其中括號內表示云測試平臺可以支持的測試類型。此外，這幾個測試平臺都是用到Monkey 工具做兼容性，穩定性測試。這幾個云測試平臺的測試場景如表2 所示。但是云測試在測試過程中真正使用真機來測試的很少，據我們所知，在測試過程中使用真機和模擬機是有很大的不同的，模擬機消耗的資源太大，使用它作為測試平臺的話，測試出來的很多問題其實在真機中是不存在或者說是反應是不一樣的。另外，眾測、自測、外包測試其實是屬于同一種測試方法的不同形式，即可分為手工測試和自動化測試。目前國內外已經存在很多關于移動應用GUI 測試方法。這些有關移動應用GUI 測試方法的研究方向可分為模糊技術、錄制/回放，基于模型，且在這些技術中，基于模型生成測試用例的方法被認為是最具有希望的研究方向之一[14]。

表3 列出了自動化GUI 測試方法的優缺點，可供測試工程師選擇GUI 的測試方法作為一個依據。

2.3 GGUUII測試工具

表4 中列舉出針對現有的GUI 測試方法對應的工具，其排名不分先后順序。這些工具來源于論文的整理得到，由于工具比較多，這里列出論文中出現較多次數的工具，包括隨機探測工具、基于模型探索、系統化探測工具及針對移動應用的錄制回放工具，另外我們還列出每個工作是否需要源代碼。

表2 云測試平臺對比表

表3 測試方法的優缺點

表4 GUI 測試工具

2.4 GGUUII測試的評估方法

Amalfitano 等人在文獻[25]中提出GUI 測試的主要是以覆蓋率作為評價標準。其覆蓋率包括缺陷覆蓋率、活動覆蓋率、事件覆蓋率。如公式（1）所示，缺陷覆蓋率是規定的測試時間內或者執行相同數目的測試用例時覆蓋的缺陷數目與缺陷總數的比值，是衡量測試工具或者測試用例有效性的主要指標之一。活動覆蓋率如公式（2）所示是在規定的測試時間內或者執行相同數目的測試用例時已經覆蓋的活動數量與活動總數的比值。事件覆蓋率如公式（3）所示是在規定的測試時間內或者執行相同數目的測試用例時已覆蓋事件數量與事件總數的比值。另外，現今軟件開發人員通常采用更多的代碼來實現應用軟件的GUI，幾乎能占到整個應用軟件程序代碼量的60%[26]，現在也有代碼覆蓋率來評估工具的效率之一，例如文獻[20]、[28]中就使用代碼覆蓋率來評估。

2.5 GGUUII測試技術的挑戰

Ozlem Muslu 提出了基于模型的GUI 測試用例生成的三大挑戰，狀態相等的判斷，狀態搜索，輸入之間的等待時間[29]。在Choudhary S Rdeng 等人[24]對目前研究存在有關移動應用的自動化工具進行對比研究，目的是為了驗證當前的自動化工具是否實現自動輸入技術，最后發現，我們的自動化輸入可以實現，但是輸入的值并不能模擬用戶的真實輸入，只能是簡單的隨機輸入而已。正如因為面臨這些挑戰，使得自動化測試在實際工程中使用甚少。這一結果和Vasquez M L 等人[27]通過向移動應用測試工作者發送問卷調查的方式來統計實際工業中的測試工程師依然采用測試手段，最后發現實際測試工程中測試工程師偏向于手工測試。在表4 的工具只有Monkey、MobiGUITAR 在實際中也得到一些測試工程師的青睞。

3 結語

本文從GUI 測試的定義，自動化的測試框架、工具特別多，但是在實際工作中并沒有得到真正意義上的應用，存在這一現象的原因是很多方面的，最突出的原因如下：

（1）測試工程師缺少自動化相關的測試知識；

（2）當前的自動化工具缺乏相應的使用文檔；

（3）工具的安裝環境比較復雜，安裝過程比較耗時。

為了滿足實際測試工作者的需求，我們需要研究出可行度極高的移動應用GUI 自動化測試方法，使得測試工作者從測試工作中的某些階段逐漸解脫出來，把更多的精力放在更重要的測試階段中。

4 未來展望

按照目前的發展趨勢，未來的移動應用會呈現爆炸式增大，而我們的移動應用的GUI 測試實現自動化是必然的趨勢，我們當前使用到的隨機測試、基于模型的測試、錄制回放測試中，基于模型的測試被認為是最具有研究價值的測試，而基于模型的測試難點在于模型的構建上。現有的MobiGUITAR[5]工具主要應用于在模擬器上，構建出的模型是映射到被測系統的控件上，其控件的有效性沒有進行驗證，另外，通過控件模型轉化為事件模型，最后再轉化為有限狀態機模型。接下來，通過遍歷模型得到的測試用例并沒有進行測試用例約簡和優先級的排序。導致在有限的時間內，測試用例的執行力不高。這樣子就沒有滿足盡快盡早暴露被測系統的缺陷。而Stoat[20]工具構建出的模型是隨機模型，然后根據隨機模型進行遍歷，從一開始的模型就不能真正映射到系統，所以Stoat 構建出來的模型不能完全代表被測系統。因此，在未來的研究中，對于模型的自動化構建以及如何構建出可以映射被測系統的模型是未來研究方向之一。