摘要
無論是在平板電腦、智慧手機還是桌面平臺上執行，圖形使用者介面（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）支援！