摘要：
Android 應用程序（應用程序）在軟件市場中所佔份額不斷增長。自動化的測試輸入生成器是用於測試和安全性分析的最新技術。
我們引入 DroidMate-2（DM-2），該平臺可輕鬆幫助開發人員和研究人員定製，開發和測試新的測試生成器。 DM-2 可以在不更改應用程序工具或操作系統的情況下使用，作為真實設備上的測試生成器和用於應用程序測試或迴歸測試的仿真器。此外，它通過輕量級的應用程序工具提供靈敏的資源監視或阻止功能，通過功能完善的應用程序工具提供開箱即用的語句覆蓋率度量以及本機實驗的可重複性。在我們的實驗中，我們通過測量語句覆蓋率將 DM-2 與 DroidBot（一種最新的測試生成器）進行了比較。我們的結果表明，DM-2 不到 DroidBot 所需時間的 2/3 即可達到其峰覆蓋率的 96％，從而可以進行更好，更高效的測試。在短期運行（5 分鐘）中，DM-2 優於 DroidBot 7％，而在長期運行（1 小時）中，此差異增加到 8％。
關鍵詞：動態分析，測試生成，Android
1. 引言
Android 移動應用程序市場非常不穩定，並且與 Google Play 商店中的數百萬個應用程序（應用程序）競爭激烈。應用程序的質量對於在這樣的市場中保持競爭力至關重要，而測試是質量控制的核心技術。
由於手動應用程序測試昂貴且費力，因此已經開發了幾種用於自動測試生成的工具。但是，隨著測試技術的改進，自動測試不斷髮展，應用程序的複雜性也在不斷增加。這導致對更先進的測試技術的永無止境的需求，以儘可能有效地涵蓋應用行為。質量控制通常意味著無缺陷的應用程序，而測試生成器則主要關注功能測試。如最近的 Facebook 事件所示，這已不再足夠。隨著安全性和隱私性日益突出，安全性分析應成為測試和開發週期的一部分。
本文介紹了 DM-2，它是原始 DroidMate 項目的擴展和改進版本。 DroidMate 是具有 API 監視功能的測試輸入生成器，而 DM-2 提供了易於使用的機制，以在可以立即使用的策略選擇基礎上實施系統的測試策略，例如隨機，基於適應性或已記錄執行的回放。 DM-2 仍然可以作為隨機測試輸入生成器直接使用，但是，除了主要的性能改進外，其改進的設計還為開發人員和研究人員提供了輕鬆實現和組合自己的自定義策略的方法，同時抽象了所有 Android 細節，例如應用設置或設備通訊即可。每個策略都是根據可自由配置的條件自動選擇的，例如，條件是否存在許可請求，接受該條件可以很容易地表示為對許可請求標識符的當前可見元素的布爾檢查。所有這些測試生成算法都可以從分析期間監視、模擬或阻止敏感資源以及新的動態生成和可擴展的應用程序模型中受益，該模型允許使用上下文感知的探索策略。 DM-2 可以在物理設備和仿真器上以 6（API 23）和 8（API 26）之間的常規 Android 版本運行，而無需設備根目錄或操作系統（OS）修改。它提供開箱即用的測試可重複性，以及通過應用 instrumentation 進行的語句覆蓋率分析。
2. 工具設計
DM-2 的體系結構由三個主要組件組成，如圖 1 中的虛線框所示。
探索引擎——在主機 PC 上運行，負責（即時地）創建 UI 狀態模型，並基於一套可配置的勘探策略來決定與被測應用程序的交互；
監控代理——在設備上運行，負責攔截應用程序與 Android OS 之間的 API 調用，以記錄、阻止或模擬這些 API 調用的響應；
圖 1：DM-2 的概念體系結構，突出顯示了開發人員可以在其中添加自定義實現（淺灰色）以及 DM-2 擴展的原始 DroidMate 組件的位置（虛線）。
自動化引擎——由 PC 接口和設備組件組成，它們通過 TCP 通信以執行設備上探索引擎確定的操作。 因此，設備本身可以通過 Android 的本地 UiAutomator 進行控制。
2.1 探索引擎
最初，DroidMate 的測試生成使用探索循環，在每個執行的設備動作之後，確定下一步應該發出什麼交互。 DM-2 通過探索策略池和選擇器池擴展了該機制，這些池基於選擇器模型的當前狀態來確定下一次交互（請參閱第 2.1.3 節）。每個選擇器都基於當前和先前的模型狀態以編程方式指定它是否能夠處理當前狀態，如果可以，則應激活哪種特定策略。為了應對同時滿足多個條件的情況，必須為每個選擇器指定唯一的優先級。對於探索循環中的任何迭代，都會選擇優先級最高的選擇器，該選擇器可以處理當前狀態，並且使用其策略來計算下一個設備交互。
在執行每個設備操作後，DM-2 將獲取當前設備屏幕（窗口轉儲）和屏幕截圖以及潛在的 logcat 異常。使用此信息，可以按 App Model 中所述導出新的 App 狀態。此外，所有註冊的模型功能都將收到有關此狀態轉換的通知。這些模型功能提供了允許模型擴展的界面，例如所有 UI 元素的黑名單，這些擴展使應用程序崩潰或探索陷入停滯。
然後，新狀態將在探索循環的下一次迭代中用作應用程序的當前狀態。該循環持續進行，直到任何策略觸發終止操作為止。
2.1.1 策略選擇器。 DM-2 支持標準的定義，以確定針對不同情況的最佳策略，例如，當請求許可或探索陷入困境時。 這些條件稱為選擇器。
形式上，選擇器定義為一對（p，f（c）→s），其中 p 是其優先級，f（c）是從模型上下文 c（例如，當前狀態或動作跟蹤）到探索策略 s 的映射。 DM-2 計算選擇標準是否滿足 f（c），然後選擇最重要的成功選擇器。 即，具有最高優先級的人返回了策略 s，以用於導出下一個設備交互。
DM-2 提供了一組選擇器來激活第 2.1.2 節中所述的默認策略。可以通過命令行或在配置文件中配置要使用的選擇器集。可以實現自定義選擇器，也可以修改現有選擇器（例如更改優先級），並將其傳遞給 DM-2 的初始化。
2.1.2 策略。與應用程序的交互可以很簡單，例如單擊座標（x，y），也可以很複雜，例如關閉應用程序，啟用設備 wi-fi，藍牙並從其初始屏幕重新啟動應用程序。這種複雜的相互作用被抽象為探索行為。探索動作確定自動化引擎應執行哪些特定的設備動作序列。根據應用程序模型的當前狀態，策略決定下一步應該發出哪些探索動作。
DM-2 附帶了一系列策略，例如，它能夠隨機瀏覽任意應用程序，而無需任何其他元信息，標籤或手動用戶交互。除了隨機探索外，DM-2 還提供以下默認策略：
重置 重新啟用 wi-fi，觸發主屏幕按鈕並從其主要活動啟動應用程序。
中止 關閉應用程序並完成探索。
返回 按下設備的返回按鈕。
BiasedRandom 從當前屏幕中隨機選擇一個 UI 元素（在瀏覽最少的元素中），然後單擊或長按該元素。特別是，我們計算在特定狀態的上下文中單擊任何 UI 元素的頻率以及在所有狀態中單擊的頻率。通過確定在當前狀態的上下文中交互最少的可交互元素，並通過總體交互數最小值對它們進行過濾，可以計算出交互最少的 UI 元素。如果此計算導致不止一個 UI 元素，則在其中隨機選擇目標。優先使用屬於應用程序包的應用程序來指導探索，而不是應用程序內部功能。
隨機 隨機單擊屏幕上任何 UI 元素的座標，類似於 Monkey。
適度比例 使用靜態挖掘的交互模型來預測每個 UI 元素髮生事件的概率，然後將這些概率用作隨機選擇的偏差。
重播 從先前記錄的模型軌跡中選擇下一個有效交互，然後重播它。
2.1.3 應用模型。探索期間構建的應用程序模型由具有一組 UI 元素的 UI 狀態構成。這些 UI 元素中的某些元素是可交互的，這意味著用戶可以例如對它們進行打勾、單擊或長按。這種交互（過渡）可能導致進入另一種狀態。儘管 Android 允許開發人員為任何 UI 元素指定資源 ID，但它是可選的，很少使用。因此，我們會根據顯示和描述文本（如果有）的串聯或從屏幕截圖截取的圖像字節，以 UUID（來自 Java 默認庫）的形式計算其 id wId 來唯一標識 UI 元素。除了唯一的 ID 外，我們還通過將所有與狀態相關的屬性（例如位置、選中、啟用、可點擊等）轉換為字符串並計算其 UUID，來計算表示 UI 元素配置的 propId。
我們旨在確定概念上相同的狀態，即在渲染中的細微差別（如突出顯示先前交互的元素）不應被解釋為不同的狀態。此外，我們會忽略不屬於該應用程序的 UI 元素，即具有不同的包名稱的元素；以及對 UI 狀態的概念身份而言非必需的不可交互且簡單的結構化元素。但是，我們仍然希望能夠區分，例如，是否選中了處於相同概念狀態的複選框。為此，我們通過元組 stateId =（uniqueId，configId）指定狀態的標識 ID。其中 uniqueId 為屬於應用程序的所有 UI 元素的 wId 的並集，這些元素可交互或在元素層次結構中為葉子（非葉元素用於佈局和視覺表示），而 configId 是當前所有可見的 UI 元素的 propId。
此唯一 ID 的度量標準使我們能夠有效地重新標識概念上相同的 UI 狀態以及在不同 UI 狀態（例如菜單或幫助按鈕）中重複出現的 UI 元素，而與它們的位置或佈局無關。configId 的度量允許識別每個 UI 狀態探索了哪些配置。這兩種功能對於高級勘探策略都是必不可少的。
2.2 自動化引擎
自動化引擎使用基於動作和響應的同步協議來抽象化和管理探索與應用之間的所有通信。策略一次將一個動作發送到自動化引擎（PC 端），該引擎將其轉發到其設備上的實例，並在處理該動作時停止探索。
設備上的自動化引擎將動作轉換為自動化命令或 API 調用。在發佈對探索的響應之前，設備上的自動化引擎必須等待，直到應用穩定為止，即直到它完成執行之前的操作並且與應用中的至少一個元素進行交互為止。這種同步是大多數 Android 測試生成器的自然瓶頸，它們允許狀態感知 UI 操作。但是，有必要正確模擬用戶的行為，即必須等到加載新屏幕後才能繼續進行。
執行操作的時間因所執行的功能而不同（勾選複選框要比單擊登錄按鈕更快）以及外部因素（例如網絡速度和服務器可用性）要快。自動化引擎應對以下不同的加載時間：首先，它等待設備空閒，即準備好再次接收和處理命令。然後，它等待直到至少一個 UI 元素可以與之交互。它丟棄僅在此過渡期間顯示的任何 UI 元素（例如進度條），因為它們不提供任何可探究的行為。
應用穩定後，設備上的自動化引擎會向 PC 對應方發出包含設備的結構（屏幕轉儲）和視覺（屏幕快照）狀態的響應，然後將其轉發給探索引擎進行處理。
2.3 監視代理
監視代理是部署到設備的有效負載，可以用作應用程序和操作系統之間的代理。 它監視隱私敏感資源的可配置列表，並在不更改應用程序代碼的情況下攔截 API 調用。 此功能僅在具有 ARM 處理器體系結構的物理設備或仿真器上可用。為了使用它，必須在啟動應用之前對應用進行檢測，以激活此有效負載。 DM-2 通過其內聯機制提供了這種檢測功能，該機制將激活調用插入到應用程序入口點中的有效負載，從而使應用程序的其餘部分保持不變。
圖 2：測試數據集在 DM-2、DroidBot 和 Monkey 之間的平均覆蓋時間。
雖然最初是為 API 監視而開發的，但是監視代理允許為每個 API 觸發自定義代碼，並可以分別定義安全策略，例如模擬或阻止 API 訪問。 啟用後，監視代理的標準模擬行為是為原始類型的 API 返回默認值，例如，對於整數，返回 0；對於字符串，返回空字符串。 阻止時，默認情況下會引發安全異常。
3. 實證評估
我們進行了一系列實驗，以評估 DM-2 的效率和效果。特別是，我們旨在回答以下研究問題：DM-2 是否比目前的工具更快地達到覆蓋率峰值？
我們將 DM-2 與 DroidBot 進行了比較，後者具有類似的功能，並且已被證明優於大多數當前的測試生成器和 Android 的標準測試生成器 Monkey。作為評估指標，我們使用了語句覆蓋率，該語句覆蓋率已被廣泛用於確定測試工具的有效性，並且被認為是故障檢測的良好預測器。我們對 11 種不同的應用程序中的所有工具進行了評估，這些應用程序是從文章 Guiding App Testing With Mined Interaction Models 中隨機選擇的。在真實的 Google Nexus 5X 設備上，每次應用探索都進行了 1 個小時，每個應用運行 10 次以減輕噪音。
我們在圖 2 中的結果表明，對於測試的應用程序集，具體策略優於純隨機事件。儘管 Monkey 比其他工具實現了更多的輸入類型（例如，滑動和縮放），但其總體覆蓋率最差。對於具有“更深功能”的應用尤其如此，這意味著用戶必須在幾個屏幕上導航，直到可以訪問某些功能。
DroidBot 和 DM-2 都試圖系統地探索不同的 UI 元素。 DroidBot 採用深度優先策略，而 DM-2 使用 BiasedRandom。這個事實以及 DM-2 的更好性能（每個動作用 2s 而不是 3-4s）導致更快，更有效的探索。平均而言，DM-2 在 1 小時後的覆蓋率比 DroidBot 好 8％，在 5 分鐘的運行中有 7％的差異。此外，此圖還顯示 DM-2 在大約 15 分鐘內達到了其最大覆蓋率的 96％，而 DroidBot 在大約 24 分鐘內達到了相同的定量。
4. 使用場景
我們將 DM-2 的模塊化架構和開箱即用的功能視為一種對研究和行業都有利的工具。 下面我們描述了一些可以應用 DM-2 的方案。
記錄並重播系統測試。在測試執行期間，DM-2 記錄了執行的每個動作，看到的 UI 元素和達到的狀態，它還提供了現成的語句覆蓋範圍度量。可以執行初始 DM-2 運行或具有不同配置的一組運行來測試系統。在發佈新版本的應用程序期間，可以重播這些測試並執行以下評估：（1）在先前的應用程序版本上測試的功能是否仍能正常工作？ （2）是否有以前測試過的代碼段不再測試？
敏感的資源影響分析。 DM-2 可用於分析訪問限制對敏感資源的影響。雖然 DroidMate 能夠監視 API 訪問，但是它沒有提供任何限制或模擬它們的方法。通過將 DM-2 的 API 限制功能與其記錄和重播功能以及代碼覆蓋率指標結合起來，可以測量訪問限制對敏感資源的訪問時的影響。
應用行為分析。 DM-2 在探索期間創建一個應用程序模型，該模型可用於生成新的測試輸入。可以使用自定義功能輕鬆擴展此模型，例如單擊帶有特定文本標籤的 UI 元素後觸發的跟蹤 API。
先前的研究證明，此類信息可用於識別應用類別內的異常行為。我們的模型允許使用上下文感知（當前和先前的應用程序狀態）以及更精細的粒度級別進行此類研究。
新的測試生成策略。 DM-2 的架構為開發新的 Android 測試生成算法提供了重要幫助。 DM-2 可用於抽象所有低級 Android 通信並從應用的模型表示創建測試，從而減輕了開發工作。另外，DM-2 提供了本地實驗的可重複性（通過記錄和重放）以及覆蓋率指標，用於技術之間的比較。
5. 總結
我們介紹了 DM-2，這是一個用於 Android 測試生成的平臺，可以在所有現有的 Android 6 至 8.1 版本中使用。 雖然 DM-2 可以直接用於隨機測試，具有 API 監視和特權限制，或者用於記錄和重播系統測試，但其主要優點是簡化了不同測試生成策略的開發、組合、擴展和比較。 DM-2 通過抽象化所有與設備相關的問題並提供動態構建的應用程序模型來簡化開發人員的工作，該模型可用於驗證測試標準或用於策略開發。 我們的評估表明，DM-2 不僅能夠實現比最新技術和 Android 標準測試生成器更好的覆蓋範圍，而且還能夠更早達到峰值覆蓋範圍，從而實現更快、更高效的測試。
摘要：
Android 應用程序（應用程序）在軟件市場中所佔份額不斷增長。自動化的測試輸入生成器是用於測試和安全性分析的最新技術。
我們引入 DroidMate-2（DM-2），該平臺可輕鬆幫助開發人員和研究人員定製，開發和測試新的測試生成器。 DM-2 可以在不更改應用程序工具或操作系統的情況下使用，作為真實設備上的測試生成器和用於應用程序測試或迴歸測試的仿真器。此外，它通過輕量級的應用程序工具提供靈敏的資源監視或阻止功能，通過功能完善的應用程序工具提供開箱即用的語句覆蓋率度量以及本機實驗的可重複性。在我們的實驗中，我們通過測量語句覆蓋率將 DM-2 與 DroidBot（一種最新的測試生成器）進行了比較。我們的結果表明，DM-2 不到 DroidBot 所需時間的 2/3 即可達到其峰覆蓋率的 96％，從而可以進行更好，更高效的測試。在短期運行（5 分鐘）中，DM-2 優於 DroidBot 7％，而在長期運行（1 小時）中，此差異增加到 8％。
關鍵詞：動態分析，測試生成，Android
1. 引言
Android 移動應用程序市場非常不穩定，並且與 Google Play 商店中的數百萬個應用程序（應用程序）競爭激烈。應用程序的質量對於在這樣的市場中保持競爭力至關重要，而測試是質量控制的核心技術。
由於手動應用程序測試昂貴且費力，因此已經開發了幾種用於自動測試生成的工具。但是，隨著測試技術的改進，自動測試不斷髮展，應用程序的複雜性也在不斷增加。這導致對更先進的測試技術的永無止境的需求，以儘可能有效地涵蓋應用行為。質量控制通常意味著無缺陷的應用程序，而測試生成器則主要關注功能測試。如最近的 Facebook 事件所示，這已不再足夠。隨著安全性和隱私性日益突出，安全性分析應成為測試和開發週期的一部分。
本文介紹了 DM-2，它是原始 DroidMate 項目的擴展和改進版本。 DroidMate 是具有 API 監視功能的測試輸入生成器，而 DM-2 提供了易於使用的機制，以在可以立即使用的策略選擇基礎上實施系統的測試策略，例如隨機，基於適應性或已記錄執行的回放。 DM-2 仍然可以作為隨機測試輸入生成器直接使用，但是，除了主要的性能改進外，其改進的設計還為開發人員和研究人員提供了輕鬆實現和組合自己的自定義策略的方法，同時抽象了所有 Android 細節，例如應用設置或設備通訊即可。每個策略都是根據可自由配置的條件自動選擇的，例如，條件是否存在許可請求，接受該條件可以很容易地表示為對許可請求標識符的當前可見元素的布爾檢查。所有這些測試生成算法都可以從分析期間監視、模擬或阻止敏感資源以及新的動態生成和可擴展的應用程序模型中受益，該模型允許使用上下文感知的探索策略。 DM-2 可以在物理設備和仿真器上以 6（API 23）和 8（API 26）之間的常規 Android 版本運行，而無需設備根目錄或操作系統（OS）修改。它提供開箱即用的測試可重複性，以及通過應用 instrumentation 進行的語句覆蓋率分析。
2. 工具設計
DM-2 的體系結構由三個主要組件組成，如圖 1 中的虛線框所示。
探索引擎——在主機 PC 上運行，負責（即時地）創建 UI 狀態模型，並基於一套可配置的勘探策略來決定與被測應用程序的交互；
監控代理——在設備上運行，負責攔截應用程序與 Android OS 之間的 API 調用，以記錄、阻止或模擬這些 API 調用的響應；
圖 1：DM-2 的概念體系結構，突出顯示了開發人員可以在其中添加自定義實現（淺灰色）以及 DM-2 擴展的原始 DroidMate 組件的位置（虛線）。
自動化引擎——由 PC 接口和設備組件組成，它們通過 TCP 通信以執行設備上探索引擎確定的操作。 因此，設備本身可以通過 Android 的本地 UiAutomator 進行控制。
2.1 探索引擎
最初，DroidMate 的測試生成使用探索循環，在每個執行的設備動作之後，確定下一步應該發出什麼交互。 DM-2 通過探索策略池和選擇器池擴展了該機制，這些池基於選擇器模型的當前狀態來確定下一次交互（請參閱第 2.1.3 節）。每個選擇器都基於當前和先前的模型狀態以編程方式指定它是否能夠處理當前狀態，如果可以，則應激活哪種特定策略。為了應對同時滿足多個條件的情況，必須為每個選擇器指定唯一的優先級。對於探索循環中的任何迭代，都會選擇優先級最高的選擇器，該選擇器可以處理當前狀態，並且使用其策略來計算下一個設備交互。
在執行每個設備操作後，DM-2 將獲取當前設備屏幕（窗口轉儲）和屏幕截圖以及潛在的 logcat 異常。使用此信息，可以按 App Model 中所述導出新的 App 狀態。此外，所有註冊的模型功能都將收到有關此狀態轉換的通知。這些模型功能提供了允許模型擴展的界面，例如所有 UI 元素的黑名單，這些擴展使應用程序崩潰或探索陷入停滯。
然後，新狀態將在探索循環的下一次迭代中用作應用程序的當前狀態。該循環持續進行，直到任何策略觸發終止操作為止。
2.1.1 策略選擇器。 DM-2 支持標準的定義，以確定針對不同情況的最佳策略，例如，當請求許可或探索陷入困境時。 這些條件稱為選擇器。
形式上，選擇器定義為一對（p，f（c）→s），其中 p 是其優先級，f（c）是從模型上下文 c（例如，當前狀態或動作跟蹤）到探索策略 s 的映射。 DM-2 計算選擇標準是否滿足 f（c），然後選擇最重要的成功選擇器。 即，具有最高優先級的人返回了策略 s，以用於導出下一個設備交互。
DM-2 提供了一組選擇器來激活第 2.1.2 節中所述的默認策略。可以通過命令行或在配置文件中配置要使用的選擇器集。可以實現自定義選擇器，也可以修改現有選擇器（例如更改優先級），並將其傳遞給 DM-2 的初始化。
2.1.2 策略。與應用程序的交互可以很簡單，例如單擊座標（x，y），也可以很複雜，例如關閉應用程序，啟用設備 wi-fi，藍牙並從其初始屏幕重新啟動應用程序。這種複雜的相互作用被抽象為探索行為。探索動作確定自動化引擎應執行哪些特定的設備動作序列。根據應用程序模型的當前狀態，策略決定下一步應該發出哪些探索動作。
DM-2 附帶了一系列策略，例如，它能夠隨機瀏覽任意應用程序，而無需任何其他元信息，標籤或手動用戶交互。除了隨機探索外，DM-2 還提供以下默認策略：
重置 重新啟用 wi-fi，觸發主屏幕按鈕並從其主要活動啟動應用程序。
中止 關閉應用程序並完成探索。
返回 按下設備的返回按鈕。
BiasedRandom 從當前屏幕中隨機選擇一個 UI 元素（在瀏覽最少的元素中），然後單擊或長按該元素。特別是，我們計算在特定狀態的上下文中單擊任何 UI 元素的頻率以及在所有狀態中單擊的頻率。通過確定在當前狀態的上下文中交互最少的可交互元素，並通過總體交互數最小值對它們進行過濾，可以計算出交互最少的 UI 元素。如果此計算導致不止一個 UI 元素，則在其中隨機選擇目標。優先使用屬於應用程序包的應用程序來指導探索，而不是應用程序內部功能。
隨機 隨機單擊屏幕上任何 UI 元素的座標，類似於 Monkey。
適度比例 使用靜態挖掘的交互模型來預測每個 UI 元素髮生事件的概率，然後將這些概率用作隨機選擇的偏差。
重播 從先前記錄的模型軌跡中選擇下一個有效交互，然後重播它。
2.1.3 應用模型。探索期間構建的應用程序模型由具有一組 UI 元素的 UI 狀態構成。這些 UI 元素中的某些元素是可交互的，這意味著用戶可以例如對它們進行打勾、單擊或長按。這種交互（過渡）可能導致進入另一種狀態。儘管 Android 允許開發人員為任何 UI 元素指定資源 ID，但它是可選的，很少使用。因此，我們會根據顯示和描述文本（如果有）的串聯或從屏幕截圖截取的圖像字節，以 UUID（來自 Java 默認庫）的形式計算其 id wId 來唯一標識 UI 元素。除了唯一的 ID 外，我們還通過將所有與狀態相關的屬性（例如位置、選中、啟用、可點擊等）轉換為字符串並計算其 UUID，來計算表示 UI 元素配置的 propId。
我們旨在確定概念上相同的狀態，即在渲染中的細微差別（如突出顯示先前交互的元素）不應被解釋為不同的狀態。此外，我們會忽略不屬於該應用程序的 UI 元素，即具有不同的包名稱的元素；以及對 UI 狀態的概念身份而言非必需的不可交互且簡單的結構化元素。但是，我們仍然希望能夠區分，例如，是否選中了處於相同概念狀態的複選框。為此，我們通過元組 stateId =（uniqueId，configId）指定狀態的標識 ID。其中 uniqueId 為屬於應用程序的所有 UI 元素的 wId 的並集，這些元素可交互或在元素層次結構中為葉子（非葉元素用於佈局和視覺表示），而 configId 是當前所有可見的 UI 元素的 propId。
此唯一 ID 的度量標準使我們能夠有效地重新標識概念上相同的 UI 狀態以及在不同 UI 狀態（例如菜單或幫助按鈕）中重複出現的 UI 元素，而與它們的位置或佈局無關。configId 的度量允許識別每個 UI 狀態探索了哪些配置。這兩種功能對於高級勘探策略都是必不可少的。
2.2 自動化引擎
自動化引擎使用基於動作和響應的同步協議來抽象化和管理探索與應用之間的所有通信。策略一次將一個動作發送到自動化引擎（PC 端），該引擎將其轉發到其設備上的實例，並在處理該動作時停止探索。
設備上的自動化引擎將動作轉換為自動化命令或 API 調用。在發佈對探索的響應之前，設備上的自動化引擎必須等待，直到應用穩定為止，即直到它完成執行之前的操作並且與應用中的至少一個元素進行交互為止。這種同步是大多數 Android 測試生成器的自然瓶頸，它們允許狀態感知 UI 操作。但是，有必要正確模擬用戶的行為，即必須等到加載新屏幕後才能繼續進行。
執行操作的時間因所執行的功能而不同（勾選複選框要比單擊登錄按鈕更快）以及外部因素（例如網絡速度和服務器可用性）要快。自動化引擎應對以下不同的加載時間：首先，它等待設備空閒，即準備好再次接收和處理命令。然後，它等待直到至少一個 UI 元素可以與之交互。它丟棄僅在此過渡期間顯示的任何 UI 元素（例如進度條），因為它們不提供任何可探究的行為。
應用穩定後，設備上的自動化引擎會向 PC 對應方發出包含設備的結構（屏幕轉儲）和視覺（屏幕快照）狀態的響應，然後將其轉發給探索引擎進行處理。
2.3 監視代理
監視代理是部署到設備的有效負載，可以用作應用程序和操作系統之間的代理。 它監視隱私敏感資源的可配置列表，並在不更改應用程序代碼的情況下攔截 API 調用。 此功能僅在具有 ARM 處理器體系結構的物理設備或仿真器上可用。為了使用它，必須在啟動應用之前對應用進行檢測，以激活此有效負載。 DM-2 通過其內聯機制提供了這種檢測功能，該機制將激活調用插入到應用程序入口點中的有效負載，從而使應用程序的其餘部分保持不變。
圖 2：測試數據集在 DM-2、DroidBot 和 Monkey 之間的平均覆蓋時間。
雖然最初是為 API 監視而開發的，但是監視代理允許為每個 API 觸發自定義代碼，並可以分別定義安全策略，例如模擬或阻止 API 訪問。 啟用後，監視代理的標準模擬行為是為原始類型的 API 返回默認值，例如，對於整數，返回 0；對於字符串，返回空字符串。 阻止時，默認情況下會引發安全異常。
3. 實證評估
我們進行了一系列實驗，以評估 DM-2 的效率和效果。特別是，我們旨在回答以下研究問題：DM-2 是否比目前的工具更快地達到覆蓋率峰值？
我們將 DM-2 與 DroidBot 進行了比較，後者具有類似的功能，並且已被證明優於大多數當前的測試生成器和 Android 的標準測試生成器 Monkey。作為評估指標，我們使用了語句覆蓋率，該語句覆蓋率已被廣泛用於確定測試工具的有效性，並且被認為是故障檢測的良好預測器。我們對 11 種不同的應用程序中的所有工具進行了評估，這些應用程序是從文章 Guiding App Testing With Mined Interaction Models 中隨機選擇的。在真實的 Google Nexus 5X 設備上，每次應用探索都進行了 1 個小時，每個應用運行 10 次以減輕噪音。
我們在圖 2 中的結果表明，對於測試的應用程序集，具體策略優於純隨機事件。儘管 Monkey 比其他工具實現了更多的輸入類型（例如，滑動和縮放），但其總體覆蓋率最差。對於具有“更深功能”的應用尤其如此，這意味著用戶必須在幾個屏幕上導航，直到可以訪問某些功能。
DroidBot 和 DM-2 都試圖系統地探索不同的 UI 元素。 DroidBot 採用深度優先策略，而 DM-2 使用 BiasedRandom。這個事實以及 DM-2 的更好性能（每個動作用 2s 而不是 3-4s）導致更快，更有效的探索。平均而言，DM-2 在 1 小時後的覆蓋率比 DroidBot 好 8％，在 5 分鐘的運行中有 7％的差異。此外，此圖還顯示 DM-2 在大約 15 分鐘內達到了其最大覆蓋率的 96％，而 DroidBot 在大約 24 分鐘內達到了相同的定量。
4. 使用場景
我們將 DM-2 的模塊化架構和開箱即用的功能視為一種對研究和行業都有利的工具。 下面我們描述了一些可以應用 DM-2 的方案。
記錄並重播系統測試。在測試執行期間，DM-2 記錄了執行的每個動作，看到的 UI 元素和達到的狀態，它還提供了現成的語句覆蓋範圍度量。可以執行初始 DM-2 運行或具有不同配置的一組運行來測試系統。在發佈新版本的應用程序期間，可以重播這些測試並執行以下評估：（1）在先前的應用程序版本上測試的功能是否仍能正常工作？ （2）是否有以前測試過的代碼段不再測試？
敏感的資源影響分析。 DM-2 可用於分析訪問限制對敏感資源的影響。雖然 DroidMate 能夠監視 API 訪問，但是它沒有提供任何限制或模擬它們的方法。通過將 DM-2 的 API 限制功能與其記錄和重播功能以及代碼覆蓋率指標結合起來，可以測量訪問限制對敏感資源的訪問時的影響。
應用行為分析。 DM-2 在探索期間創建一個應用程序模型，該模型可用於生成新的測試輸入。可以使用自定義功能輕鬆擴展此模型，例如單擊帶有特定文本標籤的 UI 元素後觸發的跟蹤 API。
先前的研究證明，此類信息可用於識別應用類別內的異常行為。我們的模型允許使用上下文感知（當前和先前的應用程序狀態）以及更精細的粒度級別進行此類研究。
新的測試生成策略。 DM-2 的架構為開發新的 Android 測試生成算法提供了重要幫助。 DM-2 可用於抽象所有低級 Android 通信並從應用的模型表示創建測試，從而減輕了開發工作。另外，DM-2 提供了本地實驗的可重複性（通過記錄和重放）以及覆蓋率指標，用於技術之間的比較。
5. 總結
我們介紹了 DM-2，這是一個用於 Android 測試生成的平臺，可以在所有現有的 Android 6 至 8.1 版本中使用。 雖然 DM-2 可以直接用於隨機測試，具有 API 監視和特權限制，或者用於記錄和重播系統測試，但其主要優點是簡化了不同測試生成策略的開發、組合、擴展和比較。 DM-2 通過抽象化所有與設備相關的問題並提供動態構建的應用程序模型來簡化開發人員的工作，該模型可用於驗證測試標準或用於策略開發。 我們的評估表明，DM-2 不僅能夠實現比最新技術和 Android 標準測試生成器更好的覆蓋範圍，而且還能夠更早達到峰值覆蓋範圍，從而實現更快、更高效的測試。
致謝
本文由南京大學軟件學院 2020 級碩士生王旭翻譯轉述。 感謝國家重點研發計劃（2018YFB1003900）和國家自然科學基金（61832009，61932012）支持！
閱讀更多 慕測科技 的文章
