概念
GUI（Graphical User Interface，圖形用戶界面）是計算機軟體與用戶進行互動的主要方式。GUI軟體測試是指對使用GUI的軟體進行的軟體測試。
GUI測試覆蓋準則
GUI的存在為用戶的操作帶來了極大的方便，同時，也使得GUI軟體更複雜、更難以測試。GUI軟體的測試由於其凸現出來的/重要性，已日漸引起學術界和工業界的興趣和重視。然而，目前關於GUI軟體測試的研究還處於初級階段：很多問題還沒有解決，GUI軟體測試依然需要較高人工成本，目前的技術還不能滿足保證軟體質量的實際需求。
GUI軟體
用戶操作簡便、直觀；
能夠避免許多無意義的或者錯誤的用戶輸入；
能夠在有限面積內顯示更豐富的信息；
使得軟體更加美觀，易於被用戶所接受。
因此，越來越多的軟體利用GUI來與用戶進行互動，GUI軟體已成為計算機軟體的主流。深入人們日常工作和生活的各種辦公軟體、財務軟體、Internet瀏覽器、Web應用程式，都是GUI軟體。
與不帶GUI的軟體相比，GUI軟體具有很多特性。
(1) GUI軟體接收到的輸入是作用於GUI上的各種事件（Event）；
(2) GUI軟體所能接受的輸入受到GUI本身結構和狀態的限制。GUI本身具有特定的層次結構，同時也具有自身的狀態。GUI軟體運行中，用戶需要根據這些信息來進行軟體操作；
(3) GUI軟體的輸出形式多樣，可能是圖形界面上的變化、圖像、文字或者若干個事件；
(4) 軟體的運行結果不僅僅決定於當前時刻的輸入，與軟體的初始狀態和操作歷史（之前的用戶操作）都有關係；
(5) GUI軟體運行對作業系統依賴性很強。GUI軟體運行過程中經常會調用作業系統的功能，這使得外部設備的狀態，作業系統的狀態都會對GUI軟體的運行產生影響。GUI軟體與作業系統之間的界限變得模糊，許多功能是通過作業系統的接口函式與軟體代碼的互動實現的。
GUI軟體的難點
(1) 測試用例需要專門的定義。測試用例嚴格來說包括軟體輸入及其期望輸出，但通常也將軟體輸入稱為測試用例。而GUI軟體的狀態與測試歷史相關，軟體運行的結果與軟體初始狀態、測試歷史和當前測試輸入都有關係，難以用簡單的數據結構表示；測試的期望輸出也變得很複雜。這使得測試用例的定義變成一個首要問題，有了明確的測試用例的定義才能夠進行進一步的研究。同時，測試用例的定義對測試的效率也會產生直接影響；
(2) 測試用例的生成變得複雜。GUI軟體的測試輸入是事件序列，而這些事件的發生沒有固定的順序，因此GUI軟體的輸入域非常龐大或者無窮。另一方面，GUI軟體的輸入受到GUI的結構和狀態的限制，在其輸入域上的很多事件序列是無效的，無法正確執行或者不會得到軟體的回響。如何獲得有效的測試用例成為生成GUI測試用例的關鍵；
(3) 測試用例的自動執行變得困難。GUI軟體的輸入和輸出是交替進行的，而且測試輸入受到GUI結構和狀態的限制，這些特點使得自動測試時需要時刻監視GUI的結構和狀態；
(4) 測試Oracle問題更加複雜。測試Oracle是判斷軟體是否發生缺陷的判據。一般來說對不同的軟體需要用不同的方法來實現測試Oracle，這本身就是個很複雜的問題。而由於GUI軟體的輸出形式多樣，使得判斷軟體是否發生缺陷首先要通過各種手段辨識出軟體的輸出和狀態，使得測試Oracle問題更加困難；
(5) 需要新的測試覆蓋準則。GUI軟體是事件驅動的，軟體接收到事件後即調用相應的代碼來回響該事件。由於事件的發生沒有固定的順序，而軟體的運行又與測試歷史相關，使得GUI軟體的控制流和數據流都變得極其複雜，直接套用現有的覆蓋準則成本比較高，所以需要研究針對GUI測試的覆蓋準則來指導測試用例的生成和判斷測試的充分性；
(6) GUI軟體的操作剖面受到GUI的影響。很多GUI軟體為用戶提供了若干快捷鍵、捷徑等，這些界面的元素對用戶操作習慣會產生重大影響，在軟體可靠性研究中需要考慮到GUI對操作剖面的影響。
GUI軟體測試方法
GUI軟體測試由於其重要性及其獨有的難點，已日漸引起學術界和軟體產業界的興趣和重視。近年來有不少學者和研究機構對GUI的測試進行了研究，從測試的各個角度提出了很多方法，從軟體測試的各個環節來研究軟體測試。下面從GUI測試覆蓋準則和GUI測試用例生成兩個方面來介紹現有學術界的一些GUI軟體測試方法。
GUI測試覆蓋準則軟體測試覆蓋準則是一個被關注很久的課題，是指測試中對測試需求覆蓋程度的要求。而測試覆蓋率是用來定量描述對測試需求覆蓋程度的度量。可以說覆蓋準則是各種軟體測試技術的核心。常用的覆蓋準則包括：語句覆蓋準則、分支覆蓋準則、條件覆蓋準則、路徑覆蓋準則、狀態覆蓋準則、數據流覆蓋準則等等。這些覆蓋準則多是在上世紀90年代之前被定義的，都不是針對GUI軟體測試的。在GUI軟體測試中，由於其輸入是事件序列，而這個序列是由用戶決定的，具有很大的隨意性和隨機性，這使得GUI軟體的控制流圖和數據流圖比起傳統非GUI軟體要複雜很多，導致這些傳統的覆蓋準則難以使用。因此有必要專門為GUI軟體測試定義新的覆蓋準則。
目前針對GUI測試覆蓋準則的相關研究主要包括以下幾項。
(1) Memon等在提出了基於事件的測試覆蓋準則。他們將被測GUI按照視窗劃分為若干模組，將作用在每個模組內GUI部件上的事件歸為一類，按照這些事件能夠被執行的先後關係創建事件流圖（Event-Flow Graph）。不同GUI部分之間的相互調用則使整體樹（Integrated Tree）來表示。在這兩種模型基礎上，他們定義了若干種模組內覆蓋準則（Intra-Component Coverage Criteria）和模組間覆蓋準則（Inter-Component Coverage Criteria）。模組內覆蓋準則指標包括事件覆蓋準則、事件互動覆蓋準則、長度為n的事件序列覆蓋準則等，這些覆蓋準則實際上是要求測試用例集覆蓋事件流圖上的頂點、邊以及長度為n的路徑，反映了對這一GUI模組測試的充分性。而模組間測試覆蓋準則包括調用覆蓋準則、調用-關閉覆蓋準則以及長度為n的跨模組事件序列覆蓋準則，這些覆蓋準則要求對GUI模組間的調用進行測試。實際上，在Memon等的後續工作中，原本定義於模組內的事件覆蓋率和事件互動覆蓋率也被套用到模組間，是比較常用的GUI測試覆蓋率。
(2) 特定事件序列的測試覆蓋準則。Xie和Memon提出了幾種事件序列的模式，他們通過實驗表明符合這幾種模式的事件序列具有比較高的缺陷檢測能力，因此，在測試用例集應當包含符合這些模式的測試用例。
(3) McMaster等提出了一種用於GUI軟體回歸測試的調用堆疊覆蓋準則（Call stack Coverage）。在軟體的運行過程中，記憶體中有一個稱為調用堆疊的數據結構，這個堆疊中的數據反映了軟體中函式被調用的順序，如果兩個測試用例被執行時其調用堆疊中內容相同，則說明這兩個測試用例調用函式的順序一致。調用堆疊覆蓋準則將函式調用順序相似的測試用例看作等價。在進行回歸測試時，受測試成本限制，可能無法運行現有的所有測試用例，因此需要對測試用例集進行縮減，使用調用堆疊覆蓋率時，需要逐一分析測試用例的調用堆疊，分析器函式調用順序，如果一個測試用例的函式調用順序與前面的測試用例一致，則將這個測試用例看作冗餘。由於這種覆蓋率需要測試用例的運行中的數據，難以用於指導測試用例的生成；而且這種覆蓋準則無法以覆蓋率的形式度量測試的充分性。
(4) Zhao等提出了基於Event Handler的測試覆蓋準則。Event Handler是用於回響用戶輸入事件的代碼，是GUI軟體原始碼的組成部分。Event Handler之間相對獨立，但存在共享變數。如果一個Event Handler調用了一個或多個在另一個Event Handler中定義的變數，則稱這兩個Event Handler為一個Handler Interaction。而基於Event Handler的測試覆蓋準則要求用戶覆蓋a.所有Event Handler, b.所有Handler Interaction。這種覆蓋準則克服了基於事件的覆蓋準則中存在大量冗餘測試需求的問題。
當前國內外學者針對GUI測試用例生成的問題已經提出了若干種方法，可以分為五類：錄製/回放技術、基於有限狀態自動機生成測試用例、基於UML生成GUI測試用例、利用人工智慧方法生成測試用例和基於事件流圖生成測試用例。
a) 錄製/回放技術
HP WinRunner/QuickTest、IBM Rational這類GUI測試工具中提供了測試用例錄製/回放機制，可以將用戶在被測GUI軟體上的操作錄製為測試腳本，而在進行測試時回放這些腳本。這是工業界套用比較廣的一種測試用例生成方法。然而這類方法需要人工設計並錄製測試用例，可以說是僅僅是人工測試的輔助工具。
b) 基於有限狀態自動機生成測試用例
有限狀態自動機（Finite State Machine，簡稱FSM）是一種能夠描述互動式系統的數學模型。GUI軟體作為一種互動式系統，也可以使用FSM進行建模。基於FSM的測試用例生成主要有以下幾種方法。
Belli 在文獻中使用FSM對GUI軟體與用戶的操作以及軟體缺陷進行了建模，並給出算法將FSM轉換為等價正則表達式，然後利用這些等價正則表達式生成GUI測試用例。Chen等以被測軟體GUI上的GUI部件屬性為狀態，事件作為輸出，GUI部件屬性的變化作為輸出，構建FSM，通過FSM上的路徑搜尋得到輸入序列作為測試用例。
上述方法使用直接使用FSM對GUI進行建模，由於存在狀態爆炸的問題，難以處理較大的GUI軟體，FSM模型的創建難度也比較大。Shehady等使用帶變數的有限狀態自動機（Variable Finite State Machine，簡稱VFSM，有的文獻也稱為擴展有限狀態自動機，即Extended Finite State Machine，EFSM）來對GUI軟體進行建模。VFSM可以通過定義變數大大減少狀態空間中狀態的數量。文中創建VFSM時是以當前視窗作為狀態，將測試中操作的或關注的變數加入自動機中；然後給出算法，將VFSM轉化為FSM，再由FSM生成事件序列作為GUI測試用例。但這種方法依然難以套用於大的GUI軟體，創建VFSM難度也比較大，需要很高的人力成本。
White等提出了一種使用多個FSM對被測GUI軟體進行建模的方法，以縮小FSM的規模，減少生成測試用例的個數。這種方法首先將在用戶操作後產生的GUI上可觀察的變化作為一個回響（responsibility）；再對每個回響人工地辨識出一系列GUI部件，通過對這些部件的操作可以產生這個回響，這樣的一系列GUI部件成為一個完全互動序列（Complete Interaction Sequence，簡稱CIS）；然後對每一個CIS建立一個FSM；下一步是利用文中給出的方法將FSM中相對獨立的狀態子集組合成一個超狀態；最後利用變換後的FSM生成測試用例。
Li擴展了White等的工作，將GUI被測軟體在局部和整體兩個層次建模：局部層次上以流圖對GUI軟體行為進行建模；在整體層次上則採用基於CIS的方法建立FSM模型。通過在流圖和FSM上的遍歷，可以得到所需的測試用例。這種方法進一步減少了FSM模型狀態的數量。
上述基於FSM生成測試用例的方法主要問題在於需要對被測GUI軟體手工建立FSM模型，這是一個難度和工作量都很大工作。
c) 基於UML生成GUI測試用例
UML（Unified Modeling Language，統一建模語言）是用來對軟體系統進行可視化建模的一種語言。在軟體開發過程中，人們常用UML來編寫設計文檔。
Vieira等中提出利用UML用例圖和活動圖來生成GUI測試用例的方法。這種方法首先要人工對UML進行標註，然後根據標註後的UML文檔生成測試操作。這類方法使用的前提是具有完善的UML軟體設計文檔或UML軟體規約（Specification），具有較大的局限性；所生成的測試用例還需要人工轉化為測試腳本，或者人工施加到被測軟體上。
d) 利用人工智慧方法生成測試用例
利用人工智慧方法生成測試用例的研究主要是將智慧型規劃方法（Planning）和遺傳算法（Genetic Algorithm）引入GUI測試用例生成。
利用規劃方法生成GUI測試用例是Memon等提出的。這種方法將事件看作引起被測軟體狀態發生變化的操作，將其表示為初始狀態和操作後的狀態，然後用智慧型規劃的方法尋找從給定初始狀態到目標狀態的路徑作為GUI測試用例。這種方法的優點是隨著測試用例的生成，還能得到被測軟體期望到達的狀態或期望輸出，這些信息可用於判斷是否發生軟體失效。但使用這種方法時需要人工確定每個事件的初始狀態和其引起的狀態變化，工作量非常大，難以用於大規模GUI軟體測試。
Kasik等提出了利用遺傳算法創建GUI測試用例的方法。作者認為在GUI測試中熟練測試人員設計的測試用例效率更高，使用遺傳算法對熟練測試人員生成的樣本測試用例集進行學習，然後根據學習的結果來生成新的測試用例。這種方法依然需要較高的人工成本，同時其效果受樣本集的影響很大。
e) 基於事件流圖生成測試用例
事件流圖是Memon等提出的一種描述事件間跟隨關係的模型。所謂跟隨是指在測試中一個事件能夠在另一個事件施加後被施加到被測軟體上。事件流圖中的路徑就是在測試中可以運行的“可行”測試用例序列。在文獻中，Memon等使用遍歷算法在事件流圖上查找特定的路徑來作為GUI測試用例。這種方法沒有明確的目標，會生成大量冗餘測試用例。
事件流圖無法描述事件間跟隨關係發生變化的情況。受到這個限制，這些基於事件流圖的方法生成的測試用例在很多情況下無法順利運行，需要較多的人工操作來修正所生成的測試用例。
f) 基於活動流圖生成測試用例
活動流圖是Zhao提出的一種用於GUI測試用例生成的流圖模型。這種模型改進了事件流圖模型，克服了事件流圖無法處理跟隨關係發生變化的缺點。這種模型是在事件流圖上添加跟隨關係成立條件，然後將所有成立條件的影響封裝到若干個子圖中（這些子圖成為活動），從而生成活動流圖。每個活動都是一個單入單出的有向圖，其中的部分有向邊具有成立條件，可以看作是一個控制流圖。也就是說，每個活動都能夠很容易地轉化為一段測試腳本代碼。根據活動流圖進行路徑搜尋，就可以將不同活動對應的測試腳本組合成滿足某種測試需求的測試用例。
