GUI測試覆蓋准則 GUI的存在為用戶的操作帶來了極大的方便，同時，也使得GUI軟件更復雜、更難以測試。GUI軟件的測試由於其凸現出來的/重要性，已日漸引起學術界和工業界的興趣和重視。然而，關於GUI軟件測試的研究還處於初級階段：很多問題還沒有解決，GUI軟件測試依然需要較高人工成本，還不能滿足保證軟件質量的實際需求。
GUI的存在為用戶的操作帶來了極大的方便，同時，也使得GUI軟件更復雜、更難以測試。GUI軟件的測試由於其凸現出來的/重要性，已日漸引起學術界和工業界的興趣和重視。然而，關於GUI軟件測試的研究還處於初級階段：很多問題還沒有解決，GUI軟件測試依然需要較高人工成本，還不能滿足保證
軟件質量的實際需求。
GUI軟件
GUI具有以下優點：
(1) 用戶操作簡便、直觀；
(2) 能夠避免許多無意義的或者錯誤的用戶輸入；
(3) 能夠在有限面積內顯示更豐富的信息；
(4) 使得軟件更加美觀，易於被用戶所接受。
與不帶GUI的軟件相比，GUI軟件具有很多特性。
(1) GUI軟件接收到的輸入是作用於GUI上的各種事件（Event）；
(2) GUI軟件所能接受的輸入受到GUI本身結構和狀態的限制。GUI本身具有特定的層次結構，同時也具有自身的狀態。GUI軟件運行中，用戶需要根據這些信息來進行軟件操作；
(3) GUI軟件的輸出形式多樣，可能是圖形界面上的變化、圖像、文字或者若干個事件；
(4) 軟件的運行結果不僅僅決定於當前時刻的輸入，與軟件的初始狀態和操作歷史（之前的用戶操作）都有關系；
(5) 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測試覆蓋准則
軟件測試覆蓋准則是一個被關注很久的課題，是指測試中對測試需求覆蓋程度的要求。而測試覆蓋率是用來定量描述對測試需求覆蓋程度的度量。可以說覆蓋准則是各種
軟件測試技術的核心。常用的覆蓋准則包括：
語句覆蓋准則、
分支覆蓋准則、
條件覆蓋准則、
路徑覆蓋准則、狀態覆蓋准則、
數據流覆蓋准則等等。這些覆蓋准則多是在上世紀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測試用例生成
當前國內外學者針對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測試用例
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) 基於活動流圖生成測試用例