引用：S. R. Choudhary, A. Gorla, and A. Orso. Automated Test Input Generation for Android: Are We There Yet? In 30th IEEE/ACM International Conference on Automated Software Engineering (ASE 2015), 2015.

摘要：

同所有軟件一樣，移動(dòng)應(yīng)用程序（Apps）必須進(jìn)行全面的測試，以確保其具有開發(fā)者預(yù)期的行為和表現(xiàn)。因此，近年來，研究人員和從業(yè)人員都開始研究移動(dòng)應(yīng)用程序自動(dòng)化測試的方法。特別是，由于Android的開源特性及其巨大的市場占比，已有大量針對Android應(yīng)用程序測試輸入（通常是GUI事件，如點(diǎn)擊、滑動(dòng)、輸入）生成工具的研究。目前，有許多這類工具，它們有著不同的測試輸入生成方式、測試策略以及不同的特定啟發(fā)式方法。為了更好地理解這些現(xiàn)有方法的優(yōu)點(diǎn)和缺點(diǎn)，并了解如何提升工具的效果，我們對Android現(xiàn)有的主要測試輸入生成工具進(jìn)行了全面的比較。我們根據(jù)四個(gè)指標(biāo)評估這些工具的有效性：易用性，多平臺兼容性，代碼覆蓋率以及檢測故障的能力。我們的結(jié)果清晰地展示了Android應(yīng)用程序輸入生成的***技術(shù)，并確定了未來的研究方向，如果經(jīng)過適當(dāng)?shù)匮芯?，可以為Android帶來更有效和高效的測試工具。

引言：

現(xiàn)有的許多自動(dòng)化測試輸入生成技術(shù)，它們具有不同的輸入生成方式、測試策略，以及具體啟發(fā)式方法。然而，目前尚不清楚這些不同方法的優(yōu)點(diǎn)和缺點(diǎn)是什么，它們在一般情況下效果如何，以及它們是否需要改進(jìn)，如何改進(jìn)。

為了回答這些問題，我們提出了一個(gè)針對Android現(xiàn)有測試輸入生成技術(shù)的比較研究.1該研究有兩個(gè)目標(biāo)。***個(gè)目標(biāo)是評估這些技術(shù)（和相應(yīng)的工具），對它們進(jìn)行比較，評估其可能更適合于哪種測試環(huán)境（例如，應(yīng)用類型）。我們的第二個(gè)目標(biāo)是更好地理解Android測試輸入生成中涉及的一般權(quán)衡(tradeoffs)，并確定可以進(jìn)行改進(jìn)的現(xiàn)有技術(shù)或定義新技術(shù)。

工具介紹：

Android測試輸入生成工具根據(jù)其不同的測試策略可以分為以下3類：

隨機(jī)測試策略：

基于隨機(jī)測試策略的輸入生成器的優(yōu)點(diǎn)是它們可以高效地生成事件，這使得它們特別適合于壓力測試。它們的主要缺點(diǎn)是隨機(jī)策略幾乎不能產(chǎn)生特定的輸入。此外，這些工具不知道已經(jīng)涵蓋了應(yīng)用程序的多少行為，因此可能會產(chǎn)生冗余事件。***，它們沒有測試完成的停止標(biāo)準(zhǔn)，而是采用手動(dòng)指定的超時(shí)。

使用此策略的工具：Monkey，Dynodroid，Null intent fuzzer，Intent Fuzzer，DroidFuzzer。

基于模型的測試策略：

一些Android測試工具構(gòu)建并使用一個(gè)應(yīng)用程序的GUI模型來生成事件并系統(tǒng)地測試應(yīng)用程序的行為。這些模型通常是有限狀態(tài)機(jī)，應(yīng)用程序的Activity作為狀態(tài)，GUI事件作為轉(zhuǎn)換。一些工具通過區(qū)分Activity狀態(tài)來構(gòu)建精確模型（例如，具有啟用和禁用按鈕的相同Activity將被表示為兩個(gè)單獨(dú)的狀態(tài)）。大多數(shù)工具動(dòng)態(tài)地構(gòu)建這樣的模型，并且當(dāng)生成的所有事件到達(dá)的都是已有狀態(tài)時(shí)停止測試。

使用此策略的工具：GUIRipper，ORBIT，A3E-Depth-First，SwiftHand，PUMA

系統(tǒng)的測試策略：

應(yīng)用程序的部分行為只能由特定的輸入來觸發(fā)，這就是為什么一些Android測試工具使用更復(fù)雜的技術(shù)（如符號執(zhí)行和進(jìn)化算法）來指導(dǎo)測試之前未被覆蓋到的代碼。對于隨機(jī)策略無法觸發(fā)的應(yīng)用程序行為，使用系統(tǒng)的測試策略具有明顯的優(yōu)勢。然而，與使用隨機(jī)策略的工具相比，這些工具的可擴(kuò)展性要低得多。

使用此策略的工具：A3E-Targeted，EvoDroid，ACTEve，JPF-Android

實(shí)證研究：

實(shí)驗(yàn)使用4個(gè)指標(biāo)來評估測試輸入生成工具：易用性，多平臺兼容性，代碼覆蓋率以及檢測故障的能力。我們一共選用了68個(gè)Android移動(dòng)應(yīng)用程序，使用VirtualBox來提供實(shí)驗(yàn)用的虛擬機(jī)，每個(gè)虛擬機(jī)配置為2核6GB RAM，并配置了三種Android版本的虛擬機(jī)，分別對應(yīng)的SDK版本是：10 (Gingerbread)，16 (Ice-cream sandwich)核19 (Kitkat)。對于每一個(gè)工具在每個(gè)應(yīng)用程序上的一次運(yùn)行，我們都會重置一次虛擬機(jī)，并重復(fù)10次，取實(shí)驗(yàn)數(shù)據(jù)的均值。

對于每一次運(yùn)行，我們使用Emma (http://emma.sourceforge.net/)收集代碼覆蓋率。我們通過收集虛擬機(jī)測試過程中的log（也稱為logcat）來獲取應(yīng)用程序故障，并且我們會人工審核這些應(yīng)用程序故障的真實(shí)性。

1.易用性和多平臺兼容性

表2報(bào)告該工具是否開箱即用（NO EFFORT），是否需要一些努力（LITTLE EFFORT），無論是正確配置還是修復(fù)小問題，或是否需要付出巨大努力（MAJOR EFFORT）。截至目前，我們只是報(bào)告我們安裝每個(gè)工具的經(jīng)驗(yàn)。

2.代碼覆蓋率和故障檢測能力

從圖1中，我們可以看到，平均而言，Dynodroid和Monkey的表現(xiàn)優(yōu)于其他工具，其次是ACTEve。其他三個(gè)工具（即A3E，GUIRipper和PUMA）實(shí)現(xiàn)了相當(dāng)?shù)偷母采w水平。盡管如此，即使那些平均達(dá)到低覆蓋率的工具也可以達(dá)到一些應(yīng)用程序的非常高的覆蓋率（大約80％）。我們手動(dòng)調(diào)查了這些應(yīng)用程序，發(fā)現(xiàn)它們是最簡單的應(yīng)用程序。

圖1. 各工具在各應(yīng)用程序上運(yùn)行10次的覆蓋率差異 圖2. 各工具覆蓋率隨時(shí)間的變化

圖2顯示所有工具在幾分鐘內(nèi)（5到10之間）達(dá)到***覆蓋范圍，唯一的例外是GUIRipper。 造成這種差異的可能原因是GUIRipper經(jīng)常從其初始狀態(tài)重新啟動(dòng)測試，此操作比較耗時(shí)。 （這實(shí)際上是SwiftHand通過實(shí)施限制重啟次數(shù)的測試策略來解決的主要問題。）

圖3顯示故障中只有少數(shù)涉及自定義異常（即，在測試中的應(yīng)用程序中聲明的異常）。其中絕大多數(shù)導(dǎo)致標(biāo)準(zhǔn)Java異常，其中最常見的是空指針異常。

總結(jié)：

在本文中，我們提出了Android的主要現(xiàn)有測試輸入生成工具（和相應(yīng)的技術(shù)）的比較研究。 我們根據(jù)四個(gè)標(biāo)準(zhǔn)評估了這些工具：易用性，Android框架兼容性，實(shí)現(xiàn)的代碼覆蓋率和故障檢測能力。根據(jù)這一比較結(jié)果，我們確定并討論了不同技術(shù)的優(yōu)缺點(diǎn)，并強(qiáng)調(diào)了該領(lǐng)域未來研究的潛在方向。

致謝

此文由南京大學(xué)軟件學(xué)院2018級碩士田元漢翻譯轉(zhuǎn)述。