Android的自動測試輸入生成:我們完成了嗎?
引用：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
表1. Android Apps測試輸入生成工具總覽。淺灰色行表示在本文實驗中研究的工具
實證研究：
實驗使用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. 各工具的易用性和在常用Android版本上的相容性
2.程式碼覆蓋率和故障檢測能力
從圖1中，我們可以看到，平均而言，Dynodroid和Monkey的表現優於其他工具，其次是ACTEve。其他三個工具（即A3E，GUIRipper和PUMA）實現了相當低的覆蓋水平。儘管如此，即使那些平均達到低覆蓋率的工具也可以達到一些應用程式的非常高的覆蓋率（大約80％）。我們手動調查了這些應用程式，發現它們是最簡單的應用程式。
圖1. 各工具在各應用程式上執行10次的覆蓋率差異 圖2. 各工具覆蓋率隨時間的變化
圖2顯示所有工具在幾分鐘內（5到10之間）達到最大覆蓋範圍，唯一的例外是GUIRipper。 造成這種差異的可能原因是GUIRipper經常從其初始狀態重新啟動測試，此操作比較耗時。 （這實際上是SwiftHand通過實施限制重啟次數的測試策略來解決的主要問題。）
圖3. 各工具觸發的故障分佈
圖3顯示故障中只有少數涉及自定義異常（即，在測試中的應用程式中宣告的異常）。其中絕大多數導致標準Java異常，其中最常見的是空指標異常。
總結：
在本文中，我們提出了Android的主要現有測試輸入生成工具（和相應的技術）的比較研究。 我們根據四個標準評估了這些工具：易用性，Android框架相容性，實現的程式碼覆蓋率和故障檢測能力。根據這一比較結果，我們確定並討論了不同技術的優缺點，並強調了該領域未來研究的潛在方向。
致謝
此文由南京大學軟體學院2018級碩士田元漢翻譯轉述。