摘要
本文介紹了 iMPAcT 工具，該工具可以測試移動應用程序上的重複行為，即 UI 模式。 該工具使用 Java 實現，並使用了 Android 的 API UI Automator 和 UiAutomation。 該工具會自動瀏覽移動應用程序，以便自動識別和測試 UI 模式。 每個 UI 模式都有一個關聯的測試策略“測試模式”，當找到一個 UI 模式時將應用該策略。 該方法在 UI 模式目錄的頂部工作，該目錄確定要測試的 UI 模式以及它們應具有的正確行為，並且可以用於任何應用程序。
1 引言
如今，智能手機已成為我們日常生活的一部分。到 2013 年，Android 的 Google Play 和 Apple 的 App Store 的可用應用程序數量已經超過了 100 萬，下載量甚至超過了 500 億。
在如此廣闊的市場中，如果開發人員希望其應用程序能夠站得住腳，則應儘可能全面地確保其功能正確性。然而，由於移動應用的特殊性，例如像活動、新的交互手勢和有限的內存這樣的新開發概念，移動測試是一項具有挑戰性的活動。根據 2014-2015 年世界質量報告，執行移動測試的組織數量已從 2012 年的 31％增長到 2013 年的 55％，2014 年接近 87％。該報告還提到了移動測試的最大挑戰是缺乏正確的測試流程和方法，其次是沒有足夠的測試時間，也沒有內部的移動測試環境。因此，自動化移動測試非常重要。
在自動化測試時，重點可以放在測試用例執行的自動化上或它們的生成上。儘管執行測試用例需要解決各種設備和平臺之類的問題，但社區一直將更多的精力集中在自動生成測試用例上。發生這種情況是因為已經有官方框架可以簡化測試的執行：適用於 Android 的 UI Automator 和 Espresso 和適用於 iOS 的 UI Automation API（應用程序編程接口）。
基於模型的測試（MBT）是一種自動生成測試用例的技術，它使用規範/模型作為輸入。 MBT 的兩個主要問題是：1）輸入模型的必要性，從該模型生成測試用例，其手動構建是一個耗時且容易出錯的過程，以及 2）生成的測試用例的組合爆炸式增長。
Chikofsky and Cross 在 1990 年將軟件逆向工程定義為“分析主題系統的過程，以識別系統的組成部分和相互關係，以及創建另一種形式或更高抽象層次的系統表示形式”，並且可以用來簡化為該應用程序獲取輸入模型的過程，這一點已通過該領域的多項工作證明。也有一些研究表明使用模式進行移動測試的有用性。 2009 年，Erik Nilsson 在開發 Android 應用程序和可以幫助解決這些問題的用戶界面（UI）模式時發現了一些反覆出現的問題。 2013 年，Sahami Shirazi 等人研究了 Android 應用程序的佈局，除其他目標外，還試圖驗證這些佈局是否提供了任何 UI 模式。他們得出結論，75.8％的元素的獨特組合在應用程序中僅出現一次。進行這項研究時要考慮對佈局及其元素的靜態分析。還有一些關於移動應用程序中 UI 模式存在的文獻。
本文介紹了 iMPAcT（移動模式測試）工具，該工具對移動應用程序進行了反向工程，以識別被測應用程序（AUT）中存在的 UI 模式並測試其是否正確實現。該方法基於模式目錄的存在，即要測試的 UI 模式集以及相應的測試策略（測試模式）。這些測試模式定義瞭如何測試 UI 模式。該工具對 AUT 進行反向工程，以識別現有的 UI 模式，當找到一個 UI 模式時，將應用相應的測試模式。之後，繼續探索。
本文的其餘部分結構如下。第二部分介紹了 iMPAcT 工具：其遵循的方法，其實現以及模式目錄的草案。 第三節介紹了該工具對社區的貢獻。第四節得出一些結論。
2 iMPAcT 工具
iMPAcT 工具可以自動測試 Android 應用程序上出現的重複性行為（UI 模式）。
A. 模式
Christopher Alexander 首先在建築環境中定義了一種模式，以表示“當前對物理環境的何種安排將能有效解決所提出的問題的最佳猜測”。此後，此定義已應用於不同的研究領域，包括軟件工程，尤其是測試。
本文介紹的工作基於 UI 模式，即應用程序用戶界面上的模式（例如登錄/密碼、操作欄或旋轉屏幕），以及測試模式，即測試 UI 模式的通用策略。
模式被正式定義為一組元組，其中：
G 是模式的 ID（目標）；
V 是一組將輸入數據與所涉及的變量相關聯的對{變量，值}；
A 是要執行的動作序列；
C 是要執行的檢查的集合；
P 是定義應用模式的條件的前提條件（布爾表達式）。
為了執行這些模式，測試人員需要提供（配置）每個變量的值（以 V 為單位）。可以在不同的配置下多次使用同一模式。因此，也可以將模式定義為
即對於每個目標的配置 G [configuration]，如果前提條件（P）成立，將使用相應的輸入值（V）執行一系列動作（A）。最後，執行一組檢查（C）。
在 UI 模式中，P 定義何時驗證模式是否存在，A 定義應執行哪些操作以驗證模式是否存在，而 C 驗證其存在。另一方面，在“測試模式”中，P 定義應何時應用相應的測試策略，A 定義要執行的操作序列以執行測試，而 C 則指示測試是通過還是失敗。
B. 工具
1）方法：在圖 1 中描述了在 iMPAcT（移動模式測試）工具中實現的方法。
圖 1：該方法的架構框架圖
這種方法的想法是測試 Android 移動應用程序（UI 模式）中的重複行為。 因此，它包括在確定應用程序中的 UI 模式（匹配項）的存在並對其進行測試（測試器）的同時，連續地探索 AUT（資源管理器），即應用相關的測試模式。 該方法呈現兩種不同類型的結果：匹配的模式（即應用程序中存在哪些 UI 模式）和失敗（即哪些模式在應用程序中未正確實現）。
2）實現：iMPAcT 工具是用 Java 開發的。 在安裝過程中，必須提供 AUT 的 APK（Android 應用程序軟件包）或 AUT 軟件包的名稱。然後，將 AUT 和 iMPAcT 工具安裝在設備上，並開始 iMPAcT 工具算法的第一次迭代。
代碼 1 顯示了該方法的所有三個階段的迭代：探索、模式匹配和測試。
fire_event 方法在 AUT 上執行事件，嘗試查找 UI 模式並嘗試檢測 UI 模式的存在，最後應用測試模式在找到 UI 模式時執行相應的測試策略（測試模式）。探索通過分析應用程序的當前狀態開始。 此狀態由屏幕上存在的元素的層次結構表示，即屏幕的佈局表示為樹，其中每個節點（代碼 2 中的子代）是屏幕的元素。 如代碼 2 所示實現。
屏幕的讀取是使用 UiAutomation 完成的。 通過此 API，可以訪問當前屏幕的根元素及其子孫（等等）。 它還允許訪問其屬性，例如資源 ID、類型以及它們是否可編輯。
獲得表示屏幕結構的樹後，它確定可以在每個節點中觸發的事件（代碼 3）。 同一節點可能啟用了不同的事件，例如，通常可以單擊按鈕，但有時也可以長按，或者可以編輯編輯文本，有時長按。
接下來，iMPAcT 工具決定要觸發的事件（決定事件）。 該決定是隨機的，並考慮可能發生的事件。
最後，使用 UI Automator 執行所選事件（執行事件）。 儘管也可以在此階段使用 Espresso，但該決定還是落在 UI Automator 上，因為 Espresso 無法訪問和更改執行操作序列（A）所需的系統狀態（例如 Internet 連接） 在某些模式內。
代碼 4 總結了該探索。
在 fire_event 後，該算法嘗試識別現有的 UI 模式（模式匹配），然後應用相應的測試策略（測試）。 這兩個步驟是相似的，因為它們都包含應用第 II-A 節中定義的模式，即驗證其前提條件是否成立，執行操作順序（A）並驗證是否滿足所有檢查條件。
如果在嘗試確定 UI 模式時滿足檢查要求，則認為已找到它。 如果在應用測試模式時滿足檢查要求，則認為相應的重複行為是正確的，即正確實現了相應的 UI 模式。
任何一種模式的應用都遵循代碼 5。
應用測試模式還包括生成帶有測試結果的報告。
C. 模式目錄
這種方法最關鍵的部分之一是要識別的 UI 模式的定義以及相應的測試模式，即模式目錄的定義。 該目錄僅定義一次，並且可以在正向測試中重複使用。
本節介紹了 UI 模式（UIP）和相應的測試模式（TP）的三個示例。 本部分介紹的模式基於 Android 的準則，該準則涉及如何設計和測試應用程序。
1）側面抽屜模式：Android 操作系統提供了幾種瀏覽其不同屏幕和層次結構的形式。 其中之一是側邊抽屜（或導航抽屜）UI 模式，即當用戶從左側邊緣向中心滑動屏幕或單擊導航按鈕上的應用程序圖標時打開的過渡菜單。 AUT 動作欄的左側。 圖 2 描繪了此 UI 模式的示例。
圖 2 側抽屜模式示例
UI 模式是：
目標：“存在側邊抽屜”
V：{}
A：[]
C：{“側邊抽屜存在且被隱藏”}
P：{true}
目標：“側抽屜佔據整個高度”
V：{}
A：[打開側抽屜]
C：{“以最大高度覆蓋屏幕”}
P：{“ 存在 UIP&&側抽屜可用&& TP 不適用於當前活動” }
為了實現此模式，必須：1）通過模擬手指從設備左邊緣向右滑動來打開側抽屜； 2）標識側抽屜，即標識側抽屜層次結構中的第一個元素；和 3）將側抽屜的邊界與設備尺寸進行比較。第二個方面是最具挑戰性的一個方面，它是通過識別具有以下所有特徵的元素來完成的：
- 它不是全屏顯示；
- 從屏幕的左邊緣開始，不佔據整個寬度；
- 它結束於屏幕底部；
- 它至少佔據屏幕高度的一半；
- 它不是屏幕的根元素；
- 它在其他元素的頂部，即它覆蓋了屏幕的其他元素；
- 它具有側邊抽屜的常見結構之一，例如 ListView，其子類型為 View，子類型為 FrameLayout，子類型為 FrameLayout，子類型為其他子項（每個選項）。
2）方向模式：Android 設備有兩種可能的方向：縱向和橫向。旋轉設備時，應用程序的屏幕也會旋轉，並且其佈局也會更新。但是，開發人員應測試兩個主要方面：不會丟失任何用戶輸入數據，而自定義 UI 代碼應處理更改。
UI 模式是：
目標：“可以旋轉”
V：{}
A：[]
C：{“可以旋轉屏幕”}
P：{“ true”}
相應的測試模式是：
目標：“數據不變屏幕旋轉時”
V：{}
A：[讀取屏幕，旋轉屏幕，讀取屏幕]
C：{“用戶輸入的數據未丟失”}
P：{“存在 UIP &&輸入了用戶數據&& TP 不適用於當前活動”}
以及
目標：“ UI 主要組件仍然存在”
V：{}
A：[閱讀屏幕，旋轉屏幕，閱讀屏幕]
C：{“主要組件仍然存在”}
P：{“存在 UIP && TP 不適用於當前活動”}
第一個測試模式的主要挑戰，屏幕旋轉時數據不變是將旋轉前屏幕的元素與旋轉後屏幕的元素匹配，例如沒有唯一標識元素的 ID。因此，為了匹配元素，除了位置（旋轉屏幕時會改變）及其內容（可修改）外，還根據其所有屬性對它們進行逐一比較，因為這會使測試無效，例如編輯文本中的文本或是否在複選框中選中了該元素。
第二個測試模式 UI 的主要組件仍然存在，它驗證旋轉後屏幕的主要組件是否仍然存在。考慮的主要組件是操作欄、側面抽屜、單選按鈕組和 ListView。這些元素必須同時出現在兩個屏幕中，但是它們的內容可能會更改。例如，當旋轉屏幕時，由於空間不足，現在可以在操作欄上顯示位於更多選項下的按鈕。
3）資源依賴模式：多個應用程序使用外部資源，例如 GPS 或 Wifi。此外，其中一些依賴於那些資源的可用性。因此，當資源突然變得不可用時，驗證應用程序是否不會崩潰很重要。
相應的 UI 模式為：
目標：“使用中的資源”
V：{“資源”，資源名稱}
A：[]
C：{“應用程序正在使用資源”}
P：{“ true”}
相應的測試模式是：
目標：“使資源不可用時應用程序不會崩潰”
V：{“資源”，資源名稱}
A：[讀取屏幕，關閉資源，讀取屏幕]
C：{“應用程序沒有崩潰”}
P ：{“ UIP && TP 不適用於當前活動”}
如果該應用程序請求使用許可並且已打開該資源，則該資源被視為正在使用。當前，通過檢測錯誤消息來驗證應用程序是否已崩潰。但是，這仍然需要一些改進。
所有測試模式都依賴於該工具區分活動的能力。目前，該工具認為當出現新屏幕時，它已找到新活動。這樣，所有訪問的屏幕都將被保存，而不考慮其內容（例如，編輯文本元素中的文本），並且在每次屏幕更改交互之後，該工具會將其與保存的屏幕進行比較。
3 對社區的貢獻
iMPAcT 工具為社區和移動應用研究領域的測試帶來了一些好處。 它的一些特徵是：
- 訪問源代碼的逆向工程過程是完全動態的，即，從不訪問源代碼，並且不需要代碼檢測；
- 手動工作整個過程是完全自動化的，因此無需手動工作。
- 重用 UI 模式是重複行為的表示，因此在多個應用程序中都存在。 因此，定義的模式可以在不做任何修改的情況下重複使用。
- 維護和演化模式可以輕鬆添加到目錄中，並且該工具的源代碼結構簡化了添加新交互的過程；
- 可用性使用該工具，用戶無需瞭解被測應用程序或模式的任何知識；
- 創新沒有通過混合逆向工程技術和 UI 模式來簡化移動應用程序測試過程的工具。
開發人員和測試人員可以使用此工具來確保他們正在開發/測試的應用程序符合軟件移動開發和測試指南（或最佳做法）。
4 結論與未來工作
本文介紹了一種工具 iMPAcT，它可以測試 Android 移動應用程序 UI 模式的重複行為。遵循的方法包括一個逆向工程流程，該流程探索 AUT 並識別其中包含的 UI 模式；一個測試流程，該流程應用與所標識的 UI 模式相關聯的預定義測試策略（測試模式）。先前的方法已經證明了定義用於測試重複行為的測試策略的有效性，以及使用反向工程技術改善移動測試的有效性。
該工具以 Java 實現，並利用 UI Automator 和 UiAutomation API 來讀取和瀏覽 AUT。該過程是全自動的，是在必要時僅需要手動配置模式即引入輸入值的手動工作。這種方法提供了對自動測試方法中經常出現的兩個問題的解決方案：定義正確行為的必要性以及生成的測試用例的爆炸式增長。通過定義模式目錄來解決這些問題，該模式目錄包含將測試哪些行為（UI 模式）以及如何對其進行測試（測試模式）。
關於未來的工作，主要有三個方面：實施啟發式方法以改善下一個事件觸發的決策；優化探索的停止條件；通過添加更多模式來不斷改進模式目錄。
致謝
本文由南京大學軟件學院 2020 級碩士生惲葉霄翻譯轉述。
感謝國家重點研發計劃（2018YFB1003900）和國家自然科學基金（61832009，61932012）支持！
閱讀更多 慕測科技 的文章
