燕季薇 黃曉偉 嚴(yán) 俊,4 張 健 楊紅麗

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

?

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

燕季薇1,2黃曉偉3嚴(yán) 俊1,2,4張 健1,2楊紅麗3

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

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

Android應(yīng)用 黑盒測試 測試生成 比較評估

0 引 言

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

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

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

1 Android應(yīng)用組件及應(yīng)用的測試

本節(jié)將對Android應(yīng)用程序組件、Android應(yīng)用測試和程序插樁技術(shù)等相關(guān)背景知識進行介紹。

1.1 Android應(yīng)用程序組件

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

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

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

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

ContentProviderContent Provider是存儲共享數(shù)據(jù)(如聯(lián)系人和短消息)的一個結(jié)構(gòu)化的接口，它統(tǒng)一了數(shù)據(jù)的訪問方式，是應(yīng)用程序間共享數(shù)據(jù)的首選方式。

1.2 Android應(yīng)用程序的測試

Android應(yīng)用的測試過程主要分為三部分：測試輸入，測試中的探索策略，以及測試后的結(jié)果評估指標(biāo)。

1.2.1 測試輸入

Android應(yīng)用是事件驅(qū)動型程序，它通過Android框架借助一系列的事件與環(huán)境進行交互，其輸入事件主要有兩種類型，UI事件和系統(tǒng)事件。

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

系統(tǒng)事件系統(tǒng)事件是指應(yīng)用程序的輸入中與UI無關(guān)的事件，分為應(yīng)用程序廣播和系統(tǒng)服務(wù)廣播兩種。常見的系統(tǒng)事件包括短消息通知、電池電量過低提示，或應(yīng)用的數(shù)據(jù)下載完成通知等。

1.2.2 測試探索策略

探索策略即在當(dāng)前狀態(tài)下選定下一事件的策略方法， 目前國內(nèi)外關(guān)于Android應(yīng)用測試生成的方法主要基于以下幾種策略[11]：

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

模型構(gòu)造的探索策略一些Android測試工具通過構(gòu)造應(yīng)用的GUI模型的方法來生成測試序列。Android應(yīng)用的運行過程可以被看作應(yīng)用狀態(tài)的遷移過程，輸入事件的執(zhí)行將導(dǎo)致應(yīng)用狀態(tài)改變，從而引發(fā)模型中的狀態(tài)遷移。

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

1.2.3 覆蓋率

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

1.3 反編譯與插樁

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

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

2 測試生成工具原理分析

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

2.1 Monkey

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

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

2.2 Dynodroid

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

圖1 Dynodroid架構(gòu)

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

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

2.3 AppTag

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

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

圖2 AppTag的架構(gòu)

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

3 實驗準(zhǔn)備與設(shè)計

這里我們選取來自多個下載平臺的應(yīng)用作為基準(zhǔn)測試集，設(shè)計了統(tǒng)一的測試平臺對三種待測工具進行對比實驗。

3.1 基準(zhǔn)測試集

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

3.2 覆蓋率測試實驗設(shè)計

為了保證對不同工具測試結(jié)果比較的一致性，我們設(shè)計了統(tǒng)一的測試框架。整個過程分為程序插樁、運行控制、測試執(zhí)行和分析報告四個部分，其架構(gòu)如圖 3所示。

圖3 統(tǒng)一的測試框架

3.2.1 程序插樁模塊

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

3.2.2 運行控制模塊

在運行控制模塊，通過編寫控制腳本自動化驅(qū)動測試工具的執(zhí)行?？刂颇_本將適配不同的測試生成工具，讀取用戶配置文件中的運行參數(shù)，完成測試工具初始化；使待測應(yīng)用安裝到目標(biāo)設(shè)備(或模擬器)，并實時監(jiān)控測試工具的運行過程。

3.2.3 測試執(zhí)行模塊

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

3.2.4 分析報告模塊

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

4 測試執(zhí)行及實驗結(jié)果分析

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

4.1 測試參數(shù)確定

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

4.2 實驗結(jié)果分析

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

4.2.1 使用環(huán)境及輸入輸出

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

4.2.2 版本兼容性

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

4.2.3 易用性

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

4.2.4 測試時間

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

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

4.2.5 覆蓋率

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

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

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

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

表2 應(yīng)用類別與測試生成覆蓋率

4.3 工具對比與分析

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

表3 基于實驗的對比分析

續(xù)表3

5 工具評估與改進

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

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

Dynodroid能夠有效地支持系統(tǒng)事件模擬測試，并根據(jù)啟發(fā)式策略擇優(yōu)選擇下一事件。由于它在事件執(zhí)行過程中可以獲取應(yīng)用窗口的結(jié)果反饋，因此可增加局部循環(huán)檢測功能，及時跳出局部循環(huán)，從而減少程序覆蓋需要的事件數(shù)，縮短執(zhí)行時間，增加執(zhí)行效率。

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

6 結(jié) 語

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

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

[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] 王克朝,成堅,王甜甜,等.面向程序分析的插樁技術(shù)研究[J].計算機應(yīng)用研究,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。國家自然科學(xué)基金項目(91418206)。燕季薇，碩士生，主研領(lǐng)域：軟件測試。黃曉偉，本科。嚴(yán)俊，副研究員。張健，研究員。楊紅麗，副教授。

TP311.5

A

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