引用：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.

摘要：

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

引言：

現有的許多自動化測試輸入生成技術，它們具有不同的輸入生成方式、測試策略，以及具體啟發式方法。然而，目前尚不清楚這些不同方法的優點和缺點是什么，它們在一般情況下效果如何，以及它們是否需要改進，如何改進。

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

工具介紹：

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

隨機測試策略：

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

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

基于模型的測試策略：

一些Android測試工具構建并使用一個應用程序的GUI模型來生成事件并系統地測試應用程序的行為。這些模型通常是有限狀態機，應用程序的Activity作為狀態，GUI事件作為轉換。一些工具通過區分Activity狀態來構建精確模型（例如，具有啟用和禁用按鈕的相同Activity將被表示為兩個單獨的狀態）。大多數工具動態地構建這樣的模型，并且當生成的所有事件到達的都是已有狀態時停止測試。

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

系統的測試策略：

應用程序的部分行為只能由特定的輸入來觸發，這就是為什么一些Android測試工具使用更復雜的技術（如符號執行和進化算法）來指導測試之前未被覆蓋到的代碼。對于隨機策略無法觸發的應用程序行為，使用系統的測試策略具有明顯的優勢。然而，與使用隨機策略的工具相比，這些工具的可擴展性要低得多。

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

實證研究：

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

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

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

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

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

從圖1中，我們可以看到，平均而言，Dynodroid和Monkey的表現優于其他工具，其次是ACTEve。其他三個工具（即A3E，GUIRipper和PUMA）實現了相當低的覆蓋水平。盡管如此，即使那些平均達到低覆蓋率的工具也可以達到一些應用程序的非常高的覆蓋率（大約80％）。我們手動調查了這些應用程序，發現它們是最簡單的應用程序。

圖1. 各工具在各應用程序上運行10次的覆蓋率差異 圖2. 各工具覆蓋率隨時間的變化

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

圖3顯示故障中只有少數涉及自定義異常（即，在測試中的應用程序中聲明的異常）。其中絕大多數導致標準Java異常，其中最常見的是空指針異常。

總結：

在本文中，我們提出了Android的主要現有測試輸入生成工具（和相應的技術）的比較研究。 我們根據四個標準評估了這些工具：易用性，Android框架兼容性，實現的代碼覆蓋率和故障檢測能力。根據這一比較結果，我們確定并討論了不同技術的優缺點，并強調了該領域未來研究的潛在方向。

致謝

此文由南京大學軟件學院2018級碩士田元漢翻譯轉述。