基于Android平臺的黑盒測試生成工具的研究對比

燕季薇 黃曉偉 嚴 俊,4 張 健 楊紅麗

1(中國科學院軟件研究所計算機科學國家重點實驗室 北京 100190) 2(中國科學院大學計算機與控制學院 北京 100049) 3(北京工業大學計算機學院 北京 100124) 4(中國科學院軟件研究所軟件工程技術研究開發中心 北京 100190)

?

基于Android平臺的黑盒測試生成工具的研究對比

燕季薇1,2黃曉偉3嚴 俊1,2,4張 健1,2楊紅麗3

1(中國科學院軟件研究所計算機科學國家重點實驗室 北京 100190)2(中國科學院大學計算機與控制學院 北京 100049)3(北京工業大學計算機學院 北京 100124)4(中國科學院軟件研究所軟件工程技術研究開發中心 北京 100190)

隨著移動互聯網技術迅速發展，移動設備成為人們生活中必不可少的部分，其中Android手機占有了智能手機的主要市場。相對于傳統軟件，Android應用易于發布、開發周期短，但其質量常常難以保證。軟件測試是用于保證軟件質量的最常用方法，其中關鍵的步驟是如何生成合適的測試用例，而對于事件驅動型Android應用程序，關鍵在于如何生成合理的事件序列輔助測試過程。目前，已有一些研究者開發了面向Android應用的測試事件生成工具。針對三種典型的測試生成工具，分析了其工作原理與特性；并選取覆蓋多種類別的40個應用程序作為基準測試集，設計了統一的測試框架，對工具的兼容性、易用性、測試時間和程序覆蓋能力等特點進行了分析與對比，并根據相關測試工具的缺陷提出一定的創新性的解決方案。

Android應用 黑盒測試 測試生成 比較評估

0 引 言

近年來，移動應用市場發展迅速，豐富多彩的應用程序逐漸融入人們的日常生活中。隨著大量的移動應用被發布，其正確性和安全性也成為開發者們越來越關注的問題。軟件測試作為保證軟件質量和軟件可靠性的重要手段，在軟件工程中占據著非常重要的地位。但由于手工測試成本的昂貴和測試工作的枯燥性，近些年來，研究人員已經開始研究面向應用程序的自動化測試方法。移動應用是典型的事件驅動型程序，在運行過程中會根據當前狀態下不同的事件輸入而執行不同的響應方法，因此針對移動應用的測試更關注于合理測試事件序列的生成。

關于Android應用測試生成的方法已有大量研究，其中部分研究提供了相應的自動化測試工具，然而，這些工具功能特性各有不同，它們的有效性和實用價值成為了一個值得關注的問題。目前，研究人員已經提出了多種測試生成工具，包括Monkey[1]、Dynodroid[2]、GUIRipper[3]、EvoDroid[4]、A3E[5]、AppTag[6]等。這些工具在開放性、兼容性、適用性、探索策略和特性處理等方面各有不同。

由于應用市場上的商業應用種類數量繁多，但源代碼不開放，因此本文選取了具有代表性的黑盒測試生成工具并進行比較，包括應用范圍最廣的Monkey、支持系統事件并優化事件選擇策略的Dynodroid和基于精確遷移模型構造并具有目標導向功能的AppTag進行了對比測試實驗。實驗中使用了Google Play[7]、F-droid[8]和豌豆莢[9]的共40個應用程序作為基準測試集。本文分析了這些工具的工作原理，對它們的功能特點，生成的事件類型等進行了理論分析，并選取來自多個下載平臺的40個應用作為基準測試集。設計了統一的測試框架，對工具的兼容性、易用性、測試時間和程序覆蓋能力等特點進行了分析與對比，并根據相關測試工具的缺陷提出一定的創新性的解決方案。

1 Android應用組件及應用的測試

本節將對Android應用程序組件、Android應用測試和程序插樁技術等相關背景知識進行介紹。

1.1 Android應用程序組件

Android應用程序由四種基本的程序組件聯系在一起，它們將在Manifest文件中被聲明，這四種類型的組件，分別是Activity、Service、Broadcast Receiver 和Content Provider[10]，下面詳細介紹這四種基本組件。

ActivityActivity是管理Android應用程序用戶界面并負責用戶交互的組件。每個Activity包含一組UI控件(如按鈕和文本框)，它們能夠響應點擊、滑動等用戶的輸入事件。

ServiceService是應用程序中能夠在后臺執行長期運行的組件，不同于Activity，它沒有用戶界面。Service用來提供后臺服務，例如，可以在用戶與其他Activity交互的同時下載文件、播放背景音樂等。通常Service并不是Android測試工具的直接測試目標，但可以通過對Activity的測試被間接地測試到。

BroadcastReceiverBroadcast Receiver不主動執行任務，僅僅是接受并響應廣播通知的一種組件。大部分廣播通知都是系統事件廣播，如電池電量低，時區改變或電話呼入等；應用程序同樣也可以發送廣播通知，例如通知其他應用數據下載已經完成。

ContentProviderContent Provider是存儲共享數據(如聯系人和短消息)的一個結構化的接口，它統一了數據的訪問方式，是應用程序間共享數據的首選方式。

1.2 Android應用程序的測試

Android應用的測試過程主要分為三部分：測試輸入，測試中的探索策略，以及測試后的結果評估指標。

1.2.1 測試輸入

Android應用是事件驅動型程序，它通過Android框架借助一系列的事件與環境進行交互，其輸入事件主要有兩種類型，UI事件和系統事件。

UI事件UI是User Interface縮寫，即用戶界面。UI事件是當用戶手指觸擊屏幕或在屏幕上移動時，系統不斷發送給應用程序的對象，包括點擊屏幕、滑動屏幕、文本輸入等操作事件；此外，回退、菜單、電源等物理按鍵對應的操作事件也被包括在內，這些操作都是由用戶產生的。

系統事件系統事件是指應用程序的輸入中與UI無關的事件，分為應用程序廣播和系統服務廣播兩種。常見的系統事件包括短消息通知、電池電量過低提示，或應用的數據下載完成通知等。

1.2.2 測試探索策略

探索策略即在當前狀態下選定下一事件的策略方法， 目前國內外關于Android應用測試生成的方法主要基于以下幾種策略[11]：

隨機探索策略隨機策略是一種通過隨機生成事件序列對應用程序進行測試的方法，優點是可以快速產生大量的可執行事件，需要維護的信息少，測試速度快，簡單易用，缺點是測試序列長，測試針對性弱，很難完成面向特定目標的測試。

模型構造的探索策略一些Android測試工具通過構造應用的GUI模型的方法來生成測試序列。Android應用的運行過程可以被看作應用狀態的遷移過程，輸入事件的執行將導致應用狀態改變，從而引發模型中的狀態遷移。

系統探索策略一些待測的程序行為條件限制性較強，常規的操作難以觸發，可通過符號執行、進化算法等技術對未覆蓋的程序代碼進行探索。

1.2.3 覆蓋率

覆蓋率是一種較常用的測試結果評估指標，可以衡量測試用例的全面性。測試應用程序的最重要的目的就是通過輸入實現對程序代碼的覆蓋，通過對代碼的覆蓋可以找出應用程序的缺陷部分，從而達到對應用程序改善的目的。代碼覆蓋主要包括源代碼和中間代碼覆蓋。對于源代碼開放的應用程序，可根據源碼統計代碼覆蓋率；而對源代碼不開放的大量應用，其中間代碼大多可通過反編譯技術獲得，因此基于中間代碼做覆蓋率統計的適用性更強。

1.3 反編譯與插樁

由于Android應用程序的源代碼難以獲得，研究者可以通過反編譯技術間接的查看應用的內在邏輯。通過反編譯Android應用程序包，可以得到存儲Dalvik字節碼信息的smali格式反匯編文件、資源文件和Manifest等文件，它們涵蓋了程序邏輯、組件配置、界面布局等信息。

我們還可以通過插樁技術獲取程序運行時動態信息。程序插樁技術將在保持源程序邏輯完整性的前提下在程序特定位置植入探針代碼。探針代碼在程序中執行并拋出運行時的程序特征數據，通過對這些運行時數據進行分析可以獲取程序的動態信息。這些動態信息包括基本塊覆蓋信息、路徑覆蓋信息、函數調用信息等[12]。針對Android應用的插樁分為對虛擬機的插樁和對應用程序的插樁，虛擬機插樁方法的特點是只需插樁一次，但受到系統版本限制，虛擬機更新時插樁代碼也需要較大改動。而對應用程序插樁的方法則更加輕量級，不受控于系統版本，但不能用于部分經過混淆無法被成功反編譯的程序。對應用程序的插樁技術又可以分為源碼插樁和字節碼插樁，字節碼插樁可應用于無源碼的應用程序分析。

2 測試生成工具原理分析

為了分析現有的黑盒測試生成工具的不同特性并進行比較，本文選擇了具有代表性的Monkey、Dynodroid和AppTag進行了對比分析，本節將從原理特點、功能特性方面具體介紹它們。

2.1 Monkey

Monkey是Android自帶的命令行測試工具，它可以模擬用戶點擊滑動屏幕、輸入文本、按鍵等操作，快速有效地在Android平臺下進行自動化測試。Monkey的測試對象是應用程序包，適用性廣泛，且它能夠短時間內生成并執行大量的事件，適合壓力測試，但是Monkey生成的事件流隨機性強，無法執行自定義的特定事件序列。

Monkey工具可對安裝在模擬器或者手機設備上的應用進行測試，通過判斷觸發固定數量的隨機事件是否引發程序崩潰來檢測該軟件的穩定性和健壯性。在運行過程中，Monkey將生成的事件序列發送給系統，如果用戶設置了包約束，即要求只能在一個或多個指定的包中運行，Monkey會阻止嘗試在其他包中完成的操作。如果運行時程序崩潰，產生無法響應的錯誤或者無法處理的異常，Monkey都會立即停止并報告錯誤。

2.2 Dynodroid

如圖1所示，Dynodroid 是提供了一種更加高效的隨機測試方法，通過界面控件檢測，得到當前有效事件集并選擇待執行事件。它不僅支持常見的UI事件，同時也提供對多種系統事件(廣播接收和系統服務)的支持。

圖1 Dynodroid架構

Dynodroid的基本原理是一個“觀察-選擇-執行”的循環。如圖1所示，它通過Hierarchy Viewer捕獲應用程序當前Activity對應的控件列表，并映射產生一組UI事件。同時Dynodroid對Android框架插樁，監聽系統事件的注冊和注銷，所有被注冊的系統事件均被加入可執行系統事件集合，直到該事件被注銷時則從集合中刪除。圖 1中的事件集合中包含了當前可被執行的所有UI事件和系統事件，Dynodroid將選擇其中一個事件執行并探測應用程序的新狀態，這個循環過程將在達到用戶指定事件數時停止。在上述過程中，如何選擇當前執行的測試事件是測試的關鍵步驟， Dynodroid提供了按頻率選擇，隨機選擇和基于偏好的隨機三種選擇策略。其中頻率選擇方法將選擇到目前為止執行頻率最小的事件；隨機選擇方法將從集合中隨機選擇事件；基于偏好的隨機選擇將在上下文敏感的狀態下基于頻率選擇，它是默認的選擇策略。

教學方法的多樣性可以激發學生的學習興趣和啟發學生的學習思維.可以組織學生學習國內外的一些數學大家做專題演講，介紹自己在搜集學習的過程中受到了哪些啟發，從大師身上學到了什么，自己將來要如何做等內容.

2.3 AppTag

AppTag是一個基于模型構造的測試序列生成工具，同樣使用了“觀察-選擇-執行”的循環過程。它的特點是能夠動態構建應用的狀態遷移模型，建模時考慮了控件的動態信息(是否選中，是否可操作等)，并維護了每個狀態的回退棧信息，使得狀態的劃分更加精細。同時，為了避免狀態爆炸問題，AppTag引進“狀態相似度”的概念，用來平衡模型的精確度，以及分析的成本。此外，AppTag的另一特點是實現了目標導向的測試序列生成。用戶可以自定義標簽作為測試需求的目標，針對目標信息在字節碼上完成插樁，在動態運行過程中將目標代碼與UI控件相關聯，得到帶有特征標注的GUI模型并生成目標導向的測試序列。

如圖2所示，AppTag的工作流程包括應用插樁、模型構造和測試生成幾個階段。

圖2 AppTag的架構

在應用插樁階段，AppTag對用戶關心的標簽集進行插樁，得到插樁后的應用文件。在模型構造階段，待測應用將在控制腳本的驅動下探索應用，根據當前狀態更新模型并利用已知模型信息選擇合理的待執行事件，直至模型被完全探索。插樁后的應用在運行時會打印標簽集相關的日志信息，通過日志分析可以獲得代碼標簽與UI控件的關聯，從而將標簽信息標注在程序模型上。最后，在測試生成階段，依據已知遷移模型可以得到覆蓋應用的測試序列集和與標簽相關的目標導向測試序列集。

3 實驗準備與設計

這里我們選取來自多個下載平臺的應用作為基準測試集，設計了統一的測試平臺對三種待測工具進行對比實驗。

3.1 基準測試集

基準測試集是用于實驗測試評估的基本對象。由于自動化測試工具難以處理流程較復雜或實時性較強的應用(如12306、跑酷游戲等)，這類應用將被過濾。本文實驗研究所選擇的基準測試集來自Google play、F-Droid，以及豌豆莢三個應用下載平臺，共選取了40個下載量較大的應用程序，涵蓋了工具、游戲、影音等多個類別。

3.2 覆蓋率測試實驗設計

為了保證對不同工具測試結果比較的一致性，我們設計了統一的測試框架。整個過程分為程序插樁、運行控制、測試執行和分析報告四個部分，其架構如圖 3所示。

圖3 統一的測試框架

3.2.1 程序插樁模塊

為了計算待測工具運行時的方法覆蓋率，我們需要收集應用在執行過程中與方法相關的運行信息。而由于Android程序源碼難以獲得，我們選擇基于Dalvik字節碼的插樁方式，在Android應用對應的字節碼中插入樁代碼記錄運行時信息。

3.2.2 運行控制模塊

在運行控制模塊，通過編寫控制腳本自動化驅動測試工具的執行。控制腳本將適配不同的測試生成工具，讀取用戶配置文件中的運行參數，完成測試工具初始化；使待測應用安裝到目標設備(或模擬器)，并實時監控測試工具的運行過程。

3.2.3 測試執行模塊

測試執行模塊負責調用測試生成工具，由指定的的測試生成工具驅動待測應用的測試過程。本實驗分別調用Monkey、Dynodroid和AppTag對應用進行測試。三種工具的輸入及配置文件已在運行控制模塊進行了適配，而輸出將在分析報告模塊適配。通過適配，該框架可也用于其他黑盒測試生成工具的評估測試。

3.2.4 分析報告模塊

測試工具運行結束后，插樁代碼生成的運行時日志和測試工具提供的結果信息將被收集并分析，得到覆蓋結果、運行時間、崩潰信息等多種用戶報告。其中覆蓋結果報告提供了程序運行期間觸發的方法序列；運行時間報告記錄了成功執行測試的運行時長；如果程序運行崩潰，相關信息會以崩潰信息報告的形式反饋給用戶。

4 測試執行及實驗結果分析

本節將針對三種工具的實驗測試結果進行分析。

4.1 測試參數確定

為了使用這些測試工具，需要確定實驗中的測試參數。根據Dynodroid和Monkey的對比實驗[2]，Monkey和Dynodroid分別在事件數達到10 000和2 000時覆蓋率趨于穩定，AppTag不需要配置事件數，我們保持模型狀態相似度閾值為默認的0.7，同時配置Dynodroid默認使用基于偏好的隨機策略。

4.2 實驗結果分析

接下來將對三種工具在實驗過程中的特征特性和測試結果進行分析。

4.2.1 使用環境及輸入輸出

三種工具中，Monkey和AppTag均可運行于模擬器或真機，Dynodroid由于對系統事件的模擬支持，只限于模擬器運行。Monkey和AppTag需要應用Apk作為測試輸入，Dynodroid同時支持對Apk和源碼測試，這里選用Apk測試。運行結束后，Monkey會提供運行成功或崩潰信息，并在控制臺顯示事件序列與執行時間。Dynodroid將提供多種運行報告用于動態運行分析，而AppTag將生成應用的狀態遷移模型，可用于生成可執行的測試序列腳本及目標導向測試腳本。

4.2.2 版本兼容性

Monkey和AppTag均與Android底層無關，僅與應用相關，Monkey適合于各個版本的各種應用，AppTag適應于可以反編譯的任意應用。Dynodroid只支持低版本(2.3)的Android SDK，但目前已有大量應用需要更高的運行版本。針對這一問題，Dynodroid開發者提出了替代的解決方案，修改Android框架中的UIAutomator來適配高版本Android應用。該方案運行速度更優且適用于4.3及以上版本，但對系統事件的支持和對結果日志的實現尚不完善，測試情況不理想，因此我們依然選擇原版本的Dynodroid進行測試。

4.2.3 易用性

在三種測試工具中，Monkey的部署過程最簡單，也最易于使用。Dynodroid的運行方法也較為簡單，實現了自動化的測試過程，需用戶完成策略事件數等參數配置。AppTag也實現了自動化的測試過程，在使用前也需要用戶了解參數含義并合理的設置。

4.2.4 測試時間

根據測試過程統計結果，在默認的參數配置下，Dynodroid測試時間最長，平均每個應用測試時間為20 245秒(約5.6小時)，其中一個應用最大測試時間達到了25 640秒(約7小時)；AppTag其次，平均每個應用測試時間為2 031秒(約0.6小時)，Monkey測試時間最短，平均測試時間僅為46秒，且測試的30個應用中有27個測試時間在一分鐘以內。

從測試時間結果來看，Monkey的測試時間最短，而Dynodroid測試時間最長。Dynodroid測試時間長的原因之一是它運行在模擬器上，更重要的是它使用了Hierarchy Viewer，該方法捕獲一次窗口控件用時約10秒，導致2 000個事件執行用時高達20 000秒。Monkey的測試時間較短，因為它隨機生成的UI事件，測試中不進行狀態監控和窗口控件的捕獲。AppTag的運行時間介于二者之間，它也會捕獲每一次窗口的狀態，但由于維護了待測應用的模型信息，極大地減少了重復事件的執行，同時，使用Robotium獲取當前窗口控件的時間也遠遠小于Hierarchy Viewer使用的時間。

4.2.5 覆蓋率

我們使用3.2節設計的實驗方案對三個工具進行測試。測試框架提供的覆蓋結果給出了程序運行時觸發的方法序列，通過與smali文件中所有方法集合對比計算，可以得到測試過程中應用的方法覆蓋率。

測試結果如表1，在40個測試應用中，Monkey成功測試所有應用，Dynodroid因兼容性等問題在8個應用測試中崩潰或無輸出，6個應用反編譯或插樁失敗導致AppTag無法測試，這些應用將不計入對應的覆蓋率計算過程。其中Monkey、Dynodroid和AppTag的平均方法覆蓋率分別為34.1%，38.9%和40.0%。

表1 測試生成工具覆蓋率比較

同時，如表2所示，我們可以分析得到測試生成工具程序覆蓋能力在不同類別的應用上的表現?？梢钥吹?，它們對于生活工具、瀏覽器/商城等類別應用的測試表現差異較大。對于生活工具等功能簡單明確的應用，Monkey對每個應用的測試結果隨機性較大，Dynodroid表現較為優異，AppTag的模型構建過程易被實際測試中誤差(如廣告、應用更新彈窗)影響。而對于復雜應用(如瀏覽器/商城)的測試中，基于隨機方法的Monkey和Dynodroid易陷入局部循環測試導致覆蓋不全，此外，Monkey還容易滯留在輸入法交互界面不停輸入無法退出。AppTag基于模型構造，在處理復雜應用時不存在局部循環的問題，適用于界面控件變化不大，可以被完整遍歷的應用，若界面變化較大(如文件管理器)則不適合使用遍歷測試。

表2 應用類別與測試生成覆蓋率

4.3 工具對比與分析

通過對工具的原理分析和大量的實驗對比，總結出了三種測試工具在測試過程中的特點特性，其對比分析見表3。

表3 基于實驗的對比分析

續表3

5 工具評估與改進

Monkey、Dynodroid和Apptag是三種具有代表性的Android測試生成工具，它們關注于應用程序的界面的遍歷并實現了程序的基本功能探索。然而現階段的測試生成還面臨著事件序列過長、代碼覆蓋率低等問題，排除程序死代碼、復雜觸發條件等不可控因素，針對Android應用的測試生成研究仍有較大提升空間。

Monkey作為最簡單易用的測試生成工具，可在短時間內生成大量測試事件，但同時也造成了測試事件的冗余。針對這一問題，可設計相應的測試序列的精簡方法，在運行時對序列中事件進行有效性分析，方便測試序列的重用與結果分析。

Dynodroid能夠有效地支持系統事件模擬測試，并根據啟發式策略擇優選擇下一事件。由于它在事件執行過程中可以獲取應用窗口的結果反饋，因此可增加局部循環檢測功能，及時跳出局部循環，從而減少程序覆蓋需要的事件數，縮短執行時間，增加執行效率。

AppTag探索并構造了待測應用的遷移模型，其生成的測試序列較為精簡，且達到了較優的程序覆蓋能力。但它的模型構建過程易被實際測試中誤差影響，可通過重復遷移探測及對比消除模型誤差，增強模型準確性。同時目前AppTag僅關注單個應用測試，可通過支持應用間交互測試使模型，以及對應的測試序列更為完善。

6 結 語

本文對Android應用的三個測試生成工具Monkey、Dynodroid和AppTag的工作原理進行分析，比較了它們在探索策略、支持的事件類型、終止條件和事件選擇策略等方面的差異，并設計了統一的測試框架，對工具的兼容性、易用性、測試時間和程序覆蓋能力等特點進行了對比分析。實驗中使用的基準測試集包含40個Android應用，覆蓋了多種應用類別，這些應用程序來自多個Android移動應用下載平臺，確保了測試集的正確性及可靠性。 最后，根據三種測試工具的缺陷，本文提出了具有創新性的解決方案。

在已完成工作的基礎上，我們將進一步增加測試工具的種類，如增加對GUIRipper、A3E等工具的測試，以及提供對測試工具更多方面(如檢錯能力、未覆蓋部分特征)的比較，從而更加全面地比較測試輸入生成工具的功能，為測試開發人員提供更加合理有效的指導方案。

[1] The Monkey UI android testing tool[OL].http://developer.android.com/tools/help/monkey.html.

[2] Machiry A,Tahiliani R,Naik M.Dynodroid:an input generation system for Android apps[C]//Joint Meeting on Foundations of Software Engineering.ACM,2013:224-234.

[3] Amalfitano D,Fasolino A R,Tramontana P,et al.Using GUI ripping for automated testing of Android applications[C]//Proceedings of the,Ieee/acm International Conference on Automated Software Engineering.IEEE,2012:258-261.

[4] Mahmood R,Mirzaei N,Malek S.EvoDroid:segmented evolutionary testing of Android apps[C]//The ACM Sigsoft International Symposium.ACM,2014:599-609.

[5] Azim T,Neamtiu I.Targeted and depth-first exploration for systematic testing of android apps[J].ACM SIGPLAN Notices,2013,48(10):641-660.

[6] Yan J,Wu T,Yan J,et al.Target Directed Event Sequence Generation for Android Applications[OL].http://arxiv.org/abs/1607.03258.

[7] Google Play[OL].https://play.google.com/store/apps?hl=zh-CN.

[8] F-Droid[OL].https://f-droid.org/repository/browse/.

[9] 豌豆莢[OL].https://www.wandoujia.com/.

[10] Android Components[OL].https://developer.android.com/guide/components/fundamentals.html.

[11] Choudhary S R,Gorla A,Orso A.Automated Test Input Generation for Android: Are We There Yet?[C]//30th IEEE/ACM International Conference on Automated Software Engineering,ASE,2015.

[12] 王克朝,成堅,王甜甜,等.面向程序分析的插樁技術研究[J].計算機應用研究,2015,32(2):479-484.

ANALYSISANDCOMPARISONOFBLACK-BOXTESTINPUTGENERATIONTOOLSFORANDROIDAPPLICATIONS

Yan Jiwei1,2Huang Xiaowei3Yan Jun1,2,4Zhang Jian1,2Yang Hongli3
1(StateKeyLaboratoryofComputerScience,InstituteofSoftwareChineseAcademyofSciences,Beijing100190,China)2(SchoolofComputerandControlEngineering,UniversityofChineseAcademyofSciences,Beijing100049,China)3(CollegeofComputerScience,BeijingUniversityofTechnology,Beijing100124,China)4(TechnologyCenterofSoftwareEngineering,InstituteofSoftwareChineseAcademyofSciences,Beijing100190,China)

With the rapid development of mobile Internet technology, mobile devices have become an indispensable part of people’s life, in which Android mobile phone occupies the main market for smart phones. Compared with traditional software, Android apps are easy to release and reduction in the development cycle. However, the quality of these applications is hard to ensure. Software testing is the most popular approach used to ensure the quality of software, and its key point is how to produce the suitable test cases. For event-driven Android apps, we concentrate on how to create a reasonable sequence of events to help the test. So far, researchers have developed a variety of tools for Android mobile application test generation. This paper selects three classic tools to make an analysis and comparison on program covering ability, ease of use, compatibility and other characteristics. Finally, some novel solutions are put forward according to the defects of the related testing tools.

Android application Black-box testing Test generation Empirical evaluation

2016-08-12。國家自然科學基金項目(91418206)。燕季薇，碩士生，主研領域：軟件測試。黃曉偉，本科。嚴俊，副研究員。張健，研究員。楊紅麗，副教授。

TP311.5

A

10.3969/j.issn.1000-386x.2017.08.001