摘要
無論是在平板電腦、智能手機還是桌面平臺上運行，圖形用戶界面（GUI）都是當今應用程序的重要組成部分。由於 GUI 通常是人類交互的唯一組件，因此它要求進行徹底的測試，以確保高效和令人滿意的用戶體驗。作為幾乎所有應用程序組件之間的粘合劑，GUI 還可以用於系統級測試。但是，GUI 測試本質上是困難的，並且即使使用保證自動化的現代工具，也通常需要大量的體力勞動。本文介紹了一個名為 GUITest 的 Java 庫，它允許為複雜的應用程序生成完全自動化的 GUI 健壯性測試，而無需手動生成模型或輸入序列。我們將解釋它的運行方式，並在對 Microsoft Word 進行測試的過程中首先展示其適用性和有效性。
關鍵詞
GUI 測試、自動化測試、健壯性測試
一 導言
圖形用戶界面（GUI）代表了軟件組件與其最終用戶之間的主要連接點，幾乎可以在所有現代應用程序中找到。供應商努力構建更直觀和高效的界面，以保證更好的用戶體驗，使其功能更強大，但同時也更復雜。尤其是自從智能手機和平板電腦的興起，這種複雜性已經達到了一個新的級別，並威脅到了應用程序在 GUI 級別的有效可測試性。為了應對這一挑戰，使測試過程自動化是很有必要的。
捕獲和重放（CR）工具有望在圖形用戶界面級別實現自動化測試。然而，它們一直都是有爭議的，因為它們需要測試人員進行大量的手動操作，他們仍然需要記錄和維護輸入序列。尤其是在頻繁更改 GUI 的情況下，CR 工具會產生很高的維護成本。儘管 CR 方法有缺點，但它是有價值的，因為測試用例是由具有領域知識的人生成的。但是，當今的 GUI 的複雜性，與測試它們相關的體力勞動以及隨之而來的維護成本，要求一種具有真正自動測試環境的補充方法。在這種環境下，測試用例的生成、執行和評估應該在沒有人為干預的情況下進行。這是相當困難的，因為 GUI 是為人類而不是為程序設計的。程序需要以編程方式訪問 GUI 的狀態，以便能夠以點擊、擊鍵和手勢的形式模擬人類的行為。因此，我們開發了 GUITest，這是一個 Java 庫，它允許為複雜的圖形應用程序編寫自動化的健壯性測試。在下面，我們將解釋 GUITest 是如何工作的，它與現有的工具和庫有何區別，以及它在涉及複雜的非 Java 桌面應用程序的第一次測試中是如何執行的。
二 方法
圖 1 可視化了一個人在使用圖形用戶界面時所經歷的基本過程。在圖（a）中，我們可以看到一個帶有相應圖標的手機應用程序面板。僅僅通過觀察屏幕，大多數人就直觀地知道哪些動作可以在這種特定的狀態下執行。例如，可以輕觸五個應用程序項中的一個，或向左或向右滑動以顯示其他項。如果用戶單擊左下角的項目（b），瀏覽器應用程序將啟動（c），提供多種操作可供選擇（d）。例如，在點擊搜索字段之後，會出現一個虛擬鍵盤（e），然後他必須再次決定執行哪個操作。通過重複這個過程，可以生成任意的輸入序列，從而驅動 GUI。
為了讓程序以類似的方式驅動 GUI，有必要收集關於 GUI 狀態的足夠信息，GUI 狀態構成了其小部件的狀態（即控制元件）。為了能夠執行合理的操作，它需要確定在特定狀態下可見的所有小部件的類型、位置、大小和其他屬性。GUITest 可以以小部件樹的形式確定被測系統（SUT）的當前 GUI 狀態。窗口小部件樹是當前在屏幕上可見的窗口小部件的分層組合，以及相關窗口小部件屬性的值。圖 2 顯示了這樣一個圖片樹（a）的示例。有了這些信息，一個自動測試程序可以計算出合理的默認操作：可以點擊啟用的按鈕、圖標和超鏈接，可以點擊文本字段並填充文本，可以拖動屏幕、滾動條和滑塊等。GUITest 允許模擬簡單的操作（點擊，按鍵）以及複雜的操作（拖放操作、手寫和其他手勢等），因此甚至可以驅動複雜的 GUI。表 1 列出了 GUITest 的一些特性。
三 第一次測驗
為了評估 GUITest 的功能，我們為 microsoft word for mac 實現了一個健壯性測試。其目標是開發一個程序，生成隨機輸入序列並自動檢測 SUT 的崩潰。如果 a）SUT 意外終止或者 b）GUI 在超過 60 秒的時間內沒有響應輸入，我們認為 SUT 已經崩潰。我們利用 GUITest 的功能編寫了一個完全自動化的測試，無需監督。因此我們不得不
- 提供 Word 可執行文件的名稱及其配置文件的位置：在每次執行 Word 之前，需要還原配置文件，以確保序列生成和回放期間的相同啟動條件。如果這些條件不同（例如，由於上次運行更改了“選項”對話框中的值），則可能無法重播崩潰序列。
- 定義要執行的操作集：如前所述，GUITest 已經為大多數小部件派生了默認操作。但是，可能需要包括其他操作，比如將剪貼畫符號拖到文檔中（參見圖 3）。可能還需要禁止某些操作，例如：在初始測試期間，程序執行系統菜單中的“關機”和“重新啟動”菜單項，從而終止整個機器。在文件對話框的上下文中出現的其他問題：在這些對話框中，程序可以創建、刪除或移動文件，這可能會導致嚴重損壞，具體取決於它在文件系統中瀏覽的位置。打印對話框等也應小心處理。圖 3 顯示了可以執行的典型操作以及我們故意不允許的某些小部件（注意打印、保存和打開工具項以及 Apple 和“Word”菜單項）。最後，我們在一個具有更嚴格訪問權限的專用用戶帳戶中運行該程序，以防止潛在的損害。
為了能夠重播崩潰運行，我們將生成的序列的長度限制為 200 個操作。每次運行之後，測試程序都會停止 SUT，保存序列（如果它導致崩潰），恢復配置文件，重新啟動 SUT 並繼續生成下一個測試用例。我們總共編寫了四個 Java 類文件，總共 314 個 LOC。自動測試運行了 18 小時，產生了 672 個序列。其中 9 個序列導致 Microsoft Word 崩潰並顯示錯誤消息。我們能夠重放其中的六個。然而，有三個很難重放，因為重放期間的計時起了重要作用：在一些運行期間，一個序列使 SUT 崩潰，而在另一些運行期間，SUT 通過時沒有任何問題。我們認為這與難以控制的外部因素（內存消耗、處理器利用率、線程調度…）有關。我們目前正在努力改進序列回放，並正在考慮使用一個虛擬機更好地控制這些條件。另一個選擇是視頻記錄整個測試過程，這將使序列回放不再必要。
四 其他工具和技術
有各種工具可用於 GUI 測試，包括商業、開源和科學產品。其中很大一部分屬於捕獲和重播（CR）或腳本類別。流行的商業工具是 eggPlant，TestComplete，QF-test。開源工具包括 Abbot、Selenium 和 SWTBot。如前所述，這些工具通常會導致大量的手工勞動，特別是當一個 GUI 經常發生變化，從而導致記錄的測試用例中斷並需要修復時。然而，由於測試用例是由人工記錄的（可能對 SUT 有很好的瞭解），因此它們非常有效。
在 GUI 測試方面，有一些比 CR 方法更自動化的科學方法：在 Atif Memon 領導下開發的 GUITest 框架中實現了一個有趣的方法。他們的想法是遍歷 GUI（通過系統地單擊 widgets）並自動生成一個模型（以事件流圖的形式），通過應用幾個覆蓋率標準從中派生測試用例。[4] 概述他們的工作。不幸的是，在他們的實驗中，他們只測試小型 Java 應用程序（其中一些是合成的，一些是學生開發的小型辦公套件的一部分），這些應用程序只通過執行單擊來執行。它們在執行序列時有問題，因為它們來自的 GUI 模型是一個近似值。因此，它們生成短序列（3 到 20 個動作），然後應用遺傳算法自動修復。
Artzi 等人為 JavaScript web 應用程序執行反饋導向的隨機測試用例生成。他們的目標是找到具有高代碼覆蓋率的測試套件，以及顯示編程錯誤（如無效的 html 或運行時異常）的序列。他們開發了一個名為 Artemis 的框架，該框架通過調用適當的處理程序方法併為它們提供必要的參數來觸發事件。為了指導他們的搜索，他們使用優先級函數：他們隨機選擇事件處理程序，但更喜歡那些在過去的序列中只實現了低分支覆蓋率的事件處理程序。
Marchetto 和 Tonella 使用元啟發式算法為 AJAX 應用程序生成測試套件。它們執行應用程序以獲得有限狀態機。此計算機中的狀態是應用程序的 DOM 樹（文檔對象模型）的實例，轉換是事件（來自服務器/用戶輸入的消息）。從這個 FSM 中，他們計算出語義交互事件的集合。目標是生成具有最大多樣事件交互序列的測試套件，即每對連續事件在語義上相互作用的序列。
我們的方法的優點是，它可以與大型的本機應用程序一起工作，它可以使用複雜的操作驅動這些應用程序。上述方法要麼調用事件處理程序（不適用於許多 GUI 技術），要麼只執行簡單的操作（單擊）。此外，我們的技術既不需要人工勞動（生成輸入序列或模型），也不需要對 SUT 的源代碼進行檢測。雖然對於[4]中提出的方法也是如此，但它們只生成短序列，其中許多序列是無效的。因此，這些序列需要修復，根據作者的說法，可能需要幾天甚至幾周的時間。最後，所提出的技術具有非常低的維護成本，因為即使 GUI 發生更改，測試也將繼續工作。然而，我們知道，目前我們的方法非常簡單（隨機操作選擇），只適合於查找導致崩潰的嚴重故障。它可能受益於上述方法的想法，反之亦然。
五 結論和今後的工作
在本文中，我們介紹了 Microsoft Word 的健壯性測試，該測試是在 GUI 測試庫 GUITest 的幫助下實現的。 儘管此測試非常簡單，但結果還是很有希望的，並且表明了該方法的適用性，甚至適用於具有複雜接口的大規模 GUI 應用程序。 將來，我們將重點關注以下幾個方面：
- 更復雜的操作選擇：我們計劃應用機器學習技術和元啟發式方法來查找更可能導致 SUT 崩潰的序列（例如，消耗大量內存或執行時間較長的序列）。在早期的工作中我們提出了一些關於這如何工作的想法。
- 細粒度的預言：我們將努力發現除崩潰以外的故障。重點是學習如何區分正確和錯誤行為的自動化技術。
- 其他 GUI 技術：目前，GUITest 只支持在 MacOSX 下運行的應用程序。我們已經對其他平臺進行了可行性研究，並在未來計劃中支持 Windows。我們還考慮在平板電腦或智能手機平臺上實施這種方法。
致謝
本文由南京大學軟件學院 2020 級碩士生李彤宇翻譯轉述。 感謝國家重點研發計劃（2018YFB1003900）和國家自然科學基金（61832009，61932012）支持！
閱讀更多 慕測科技 的文章
