摘要
自動化的輸入生成器必須不斷選擇要與之交互的 UI 元素以及與之交互的方式，以便在有限的時間預算內實現較高的覆蓋率。當前，大多數黑盒輸入生成器都採用偽隨機或蠻力搜索的策略，這可能需要很長時間才能找到正確的輸入組合，從而將應用程序帶入新的重要狀態。我們提出了 Humanoid，這是一種基於深度學習的自動化黑盒 Android 應用測試工具。 Humanoid 的關鍵技術是一個深度神經網絡模型，該模型可以瞭解人類用戶如何與應用程序的 GUI 交互，從而從人類交互軌跡中選擇動作。然後，可以將學習到的模型用於指導測試輸入生成，以實現更高的覆蓋率。通過在開源應用程序和市場應用程序上進行的實驗表明，與最新的測試輸入生成器相比，Humanoid 能夠達到更高的覆蓋範圍，並且速度更快。Humanoid 在https://github.com/yzygitzh/Humanoid是開源的，演示視頻可以在https://youtu.be/PDRxDrkyORs上找到。
索引詞-軟件測試，自動測試輸入生成，圖形用戶界面，深度學習，移動應用程序，Android
I 簡介
近年來，移動應用程序（簡稱應用程序）已得到廣泛應用。這些應用在發佈之前需要經過充分的測試。但是，由於發佈週期快和人力資源有限，很難在短時間內手動構建測試用例。為此，學術界和工業界都對移動應用程序的自動測試輸入生成器進行了廣泛的研究。
測試輸入生成器的有效性通常通過其測試覆蓋率來衡量。因此，自動化測試輸入生成器成功的關鍵是為給定的 UI（測試期間的當前 UI）選擇正確的交互，以使所選的交互可能達到新的重要 UI 狀態，從而在有限的時間預算內獲得更高的覆蓋率。因為機器很難理解 GUI 佈局和 GUI 元素中的內容，所以很難確定要單擊哪個按鈕或應該輸入什麼按鈕。因此，大多數現有的測試生成器均使用隨機策略來決定與哪個 GUI 元素交互以及如何交互。儘管還可以進一步優化隨機策略，但是它具有固有的侷限性，因此很難選擇一個有效的方法來查找可以在短時間內將應用程序驅動到重要狀態的交互。
圖 1 人形機器人如何選擇測試輸入的說明。 左側是 AUT 當前 UI 的屏幕截圖，右側列舉了 UI 狀態下最可能的交互。人型機器人根據從人機交互跟蹤中學習的模型來計算每個動作的概率。 概率表示人形機器人將動作選擇為測試輸入的可能性。
與隨機輸入生成器相反，人類測試人員可以輕鬆識別值得與之交互的 UI 元素，即使對於他們從未見過的新應用程序也是如此。根本原因是人類測試人員本身就是應用程序用戶，因此他們已經獲得了有關各種移動應用程序的一些經驗和知識。因此，人類測試人員知道單擊何處以及要輸入什麼內容，以實現更高的覆蓋率，並且花費的時間也更少。
基於此觀察結果，我們提出了 Humanoid，這是一種自動 GUI 測試生成器，能夠生成人類與移動應用程序的交互方式，然後使用學習到的模型像人類測試者一樣指導測試的生成。藉助從跟蹤人類交互過程中獲得的知識，Humanoid 可以根據其重要性和意義在 GUI 頁面上對可能的交互進行優先級排序，如圖 1 所示。在這種模型的指導下，相較於隨機生成的輸入模塊，Humanoid 能夠更快的生成引向重要狀態的測試輸入。
Humanoid 的核心是一個深度神經網絡模型，該模型可以預測哪些 UI 元素更可能被人類用戶與之交互以及如何與之交互。 模型的輸入是當前 UI 狀態以及最近的 UI 轉換，而輸出是 UI 頁面上每個可能動作的預測概率，可用於指導測試輸入生成過程。
我們實施了 Humanoid 並使用從大規模的基於人群的 UI 交互數據集 Rico 中提取的 304,976 個人交互來訓練交互模型。 我們將 Humanoid 與六個最先進的測試生成器進行了比較。 用於測試的應用包括從 AndroTest 數據集獲得的 68 個開源應用和從 Google Play 獲得的 200 個流行應用。 結果表明，Humanoid 能夠實現開源應用程序的 43.1％的行覆蓋率和市場應用程序的 24.1％的活動覆蓋率，明顯高於其他測試生成器使用相同版本的最佳結果（38.8％和 19.7％）。
II 工具設計
Humanoid 的核心是一個交互模型，該模型學習有關人類如何與應用程序交互的模式。基於該模型，整個工作流可以分為兩個階段，其中包括一個用於通過人為生成的交互軌跡來訓練模型的正式階段和一個用於指導測試輸入生成的在線階段。
A． 訓練模型
最終用戶根據他們在應用程序界面（即 GUI）上看到的內容與應用程序進行互動。由於不同的應用程序通常共享相同的 UI 設計模式，因此很直觀的是，人類與 GUI 的交互方式可以在不同的應用程序上進行概括。我們提出的交互模型的目標是捕獲這種可概括的模式。
我們引入了一個概念 UI 上下文來建模人類與應用程序交互時引用的內容。 UI 上下文 contexti 由當前 UI 狀態 si 和三個最新的 UI 轉換（si-1，ai-1），（si-2，ai-2），（si-3，ai-3）組成。當前的 UI 狀態表示用戶在執行操作時看到的內容，而最新的 UI 轉換用於在當前交互會話期間對用戶的基本意圖進行建模。
每個 UI 狀態都表示為雙通道 UI 骨架圖像，其中第一個通道呈現文本 UI 元素的邊界框區域，第二個通道呈現非文本 UI 元素的邊界框區域。 每個動作均由其動作類型和目標位置座標表示。動作類型被編碼為七維向量，其中每個維度都映射到七種動作類型之一，如前所述。行動目標位置被編碼為熱圖。熱圖中的每個像素都是該像素成為動作目標位置的概率。
因此，UI 上下文的表示，即我們的交互模型的輸入，是一堆圖像，包括一個用於當前 UI 狀態的 2 通道圖像和三個最新 UI 轉換的三個 3 通道圖像（每個轉換包括一個 2 UI 狀態的通道圖像和操作的一個 1 通道圖像）。 所有圖像均按比例縮放為 180×320 像素。 為了便於學習，我們還為當前 UI 狀態添加了一個零填充通道。最後，UI 上下文表示為 4×180×320×3 向量。
給定 UI 上下文向量，則交互模型的輸出為兩個條件概率分佈：
1）ptype（t | contexti），表示 t 的概率分佈，即下一個動作的類型，其中 t∈{touch，long touch， 向上滑動，...}。
2）ploc（x，y | contexti），表示屏幕座標 x，y 的概率分佈是下一個動作的目標，其中 0
可以通過以下方式計算對當前 UI 狀態執行每個操作的概率：
然後，動作概率可以用來指導測試輸入的生成。
圖 2 顯示了用於學習上面定義的兩個條件概率分佈的深度神經網絡模型。 它接受當前 UI 上下文 contexti 的表示作為輸入，並輸出 ai 的位置和類型分佈。 該模型使用卷積層來捕獲 GUI 視覺信息，並使用剩餘的 LSTM 模塊來捕獲交互上下文信息。反捲積層和完全連接的層分別用於生成 ai 的位置和類型的分佈。
我們用於訓練交互模型的數據集是從 Rico 處理的，Rico 是一大批來自人群的人類交互數據集。 我們提取了 12278 個交互流，它們屬於 10477 個應用程序，每個交互流平均包含 24.8 個動作。 在訓練過程中，人類用戶採取行動的概率設置為 1，而其他行動的概率設置為 0。
B． 指導測試生成
人型機器人使用 GUI 模型來保存過渡的內存。GUI 模型表示為 UI 過渡圖（UTG），其節點是 UI 狀態，而邊是導致 UI 狀態過渡的動作。
Humanoid 生成兩種類型的測試輸入，包括用於發現應用程序中看不見的行為的探索動作，以及將應用程序驅動到包含未探索動作的已知狀態的導航動作。
在每個步驟中，Humanoid 都會檢查當前狀態下是否存在未開發的動作。 如果有未探索的動作，Humanoid 會選擇探索，而如果當前狀態已被完全探索，Humanoid 會選擇導航。導航過程非常簡單。在探索過程中，Humanoid 獲得了交互模型預測的動作的概率，並根據概率進行加權選擇。
由於將對人類採取的行動分配更高的概率，因此他們有更高的機會被 Humanoid 選擇為測試輸入。 因此，Humanoid 生成的輸入要比隨機選擇的輸入更像人類，這反過來將使應用更快地進入重要的 UI 狀態並導致更高的測試覆蓋率。
圖 2 Humanoid 交互模型體系結構
III 評估
我們通過使用 Humanoid 來測試兩組不同的 Android 應用程序，包括從 AndroTest 獲得的 68 個開源應用程序和從 Google Play 下載的 200 種流行的商業應用程序，對 Humanoid 進行了評估。 我們測量了 Humanoid 的測試覆蓋率和測試進度，並將結果與六個最先進的測試工具進行了比較，包括 Monkey ，PUMA ，Stoat ，DroidMate ，Sapienz 和 DroidBot 。
我們用來進行實驗的機器是一個工作站，該工作站配備兩個 Intel Xeon E5-2620 CPU，64GB RAM 和一個 NVidia GeForce GTX 1080 Ti GPU。 訓練交互模型大約需要 66 個小時。應用模型時，我們在計算機上運行了 4 個 Android 模擬器實例，以並行測試應用程序。
我們使用每種測試工具（具有其默認配置）在 Android 模擬器上運行固定的時間（每個開源應用程序 1 小時，每個市場應用程序 3 小時，因為市場應用程序通常更復雜）。為了適應最新的市場應用程序，大多數工具已在 Android 6.0 上進行了評估。但是，由於 Sapienz 是封閉源代碼，並且僅支持 Android 4.4，因此已在 Android 4.4 上進行了評估。對於每個應用程序和工具，我們記錄了執行每個操作後的最終覆蓋率和漸進覆蓋率。我們將這一過程重複了三遍，並以平均值作為最終結果。
在測試開源應用程序時，每個測試工具所達到的測試覆蓋率幾乎都在 1 小時內收斂。最終線路覆蓋率的總體比較如圖 3 所示。Humanoid 平均達到了 43.1％的線路覆蓋率，這是所有測試輸入生成器中最高的。基於對測試痕跡的手動檢查，Humanoid 的高覆蓋率主要是由於兩個原因：首先，當有大量 UI 元素可供選擇時，Humanoid 能夠識別關鍵 UI 元素並確定其優先級。其次，Humanoid 有較高的機會執行有意義的操作序列，從而可以將應用程序帶入未經開發的核心功能中。
圖 3 不同工具針對開源軟件得到的行覆蓋
有趣的是，採用了隨機探索策略的 Monkey 比除 Humanoid 之外的所有其他基於模型的測試工具具有更高的覆蓋率。Monkey 的性能比大多數其他測試工具都要好的事實也已被其他研究人員證實。主要原因是 Monkey 在相同的時間內可以產生比其他工具更多的輸入。
我們進一步在市場應用程序上進行了實驗，以瞭解 Humanoid 是否仍然更有效。由於源代碼不適用於這些市場應用程序，因此我們無法計算線路覆蓋率，因此我們改用活動覆蓋率（已達成活動的百分比）。
測試工具在 3 小時內達到的最終活動覆蓋率如圖 4 所示。與開源應用程序相似，Humanoid 與其他工具相比也達到了最高的覆蓋率（24.1％）。
圖 5 顯示了漸進覆蓋率 w.r.t. 每個測試工具發送的輸入事件數。 請注意，我們沒有將 Sapienz 包括在漸進覆蓋圖中，因為它發送事件的速度太快，並且由於它是近源的，因此我們無法降低它的速度。在最初的幾個步驟中，由於應用程序才剛剛啟動且所有 UI 狀態都是新的，因此所有測試工具的覆蓋率迅速提高。 Humanoid 人在大約 50 個事件之後開始領先。那是因為那時已經覆蓋了易於訪問的代碼，而其他狀態則隱藏在特定的交互作用之後，而其他測試工具幾乎無法產生這種交互作用。由於某些應用程序的複雜性，它們在測試結束時並未融合。但是，我們認為，即使經過更長的測試時間，Humanoid 也將保持優勢。
圖 5 不同工具的逐步覆蓋
IV 相關工作
自從移動應用盛行以來，自動 GUI 測試生成已成為一個活躍的研究領域。 大多數測試生成器採用三種策略：隨機，基於模型和針對性。
使用隨機策略的典型示例是 Monkey ，該示例在沒有應用程序任何信息的情況下發送動作。 DynoDroid 根據 GUI 佈局篩選出不可接受的事件。 Sapienz 使用遺傳算法搜索可以實現更高覆蓋率的測試序列。
其他幾種測試工具可構建並使用該應用程序的 GUI 模型來生成測試輸入。基於 GUI 模型，測試工具可以生成輸入，這些輸入可以將應用快速導航至未開發狀態。基於模型的策略也可以優化。例如，Stoat 可以基於現有探索來迭代地完善測試策略，而 DroidMate 可以通過從其他應用程序中進行挖掘來推斷 UI 元素的可接受動作。
目標策略旨在解決某些應用程序行為只能通過特定的測試輸入才能揭示的問題。 這些測試工具通常使用複雜的技術，例如數據流分析和符號執行來發現可能導致目標狀態的相互作用。
Humanoid 不同於這些方法，因為它利用了 GUI 視覺信息，這在人類用戶或測試人員瀏覽應用程序時是重要的參考。
V 結論
本工具演示文章介紹了 Humanoid，這是一種適用於 Android 應用程序的新 GUI 測試生成器，能夠通過深度學習生成類似於人類的測試輸入。 Humanoid 採用 DNN 模型，以從大量的人為生成的交互軌跡中學習人類用戶如何瀏覽應用程序。 實驗表明，在學習的模型的指導下，Humanoid 比六個最新的測試工具能夠實現更高的測試覆蓋率和更快的測試範圍。
致謝
本文由南京大學軟件學院 16 級本科生王旭翻譯轉述 感謝國家重點研發計劃（2018YFB1003900）和國家自然科學基金（61832009，61932012）支持！
閱讀更多 慕測科技 的文章
