GUI測試過程有如下幾個階段：
1、 決定[url=javascript:;]測試[/url]目标。在GUI測試的第一個階段，首先要決定測試什麼，即決定對哪些GUI事件或事件序列進行測試。
2、 生成測試輸入。GUI測試輸入可以參照軟體的規格說明或軟體的結構，它由初始條件和事件序列構成。
3、 生成預期輸出。對應測試輸入中事件序列的每個事件，生成每個事件執行後的預期結果。
4、 測試的執行及驗證。在測試輸入中的初始條件下，順序執行事件序列中的事件，并對比每個事件的預期輸出與實際輸出。當兩者出現不比對的情況時，表示目前測試不能通過。
5、 判斷測試的充分性。在執行了部分或全部的測試後，分析所有測試執行情況，判斷是否達到預期的要求。
6、 回歸測試。當程式變更後，針對GUI的變化情況，選擇部分的測試用例或重新生成新的測試用例對更改部分進行重新測試。
對于大部分的GUI測試，都需要執行以上的6個步驟，其中每個步驟都可以手工完成或者依靠工具自動完成。現有一些獨立的[url=javascript:;]自動化[/url][url=javascript:;]技術[/url]或工具，如利用規範化的需求說明生成測試用例，利用有限狀态機模型來生成測試用例，利用錄制/回放工具來錄制事件序列，利用對象捕獲工具生成預期狀态，利用腳本實作測試的自動執行，利用測試資料表驅動測試的自動執行，以及一些回歸測試方法。雖然這些方法可以對測試的某個過程實作自動化，但是會由于[url=javascript:;]其它[/url]非自動化過程而降低整體測試效率，難以展現[url=javascript:;]自動化測試[/url]的優勢。即便将所有過程的自動化工具和技術結合在一起，還要考慮到對所有技術的[url=javascript:;]學習[/url]情況及其相容性問題。是以，實際上很難有效的利用這些工具或技術來解決具體測試問題。
現有的測試開發環境與MI及[url=javascript:;]IBM[/url]的測試架構雖然在一定程度上內建了各種[url=javascript:;]測試技術[/url]，但是它們卻存在種種問題。例如架構中測試用例的生成和維護不能自動執行，影響測試的效率；架構中手工生成檢測點和驗證點的方法影響了測試的效果；架構中的腳本構架影響了測試的可維護性；隻能對較小規模的GUI進行全面的測試，影響測試的通用性等等。是以，要建立一個全面有效的GUI整體測試架構，必須要符合架構的高效性、相容性、有效性、可維護性和通用性等方面的要求。
1.整體測試架構
作者建構的GUI整體測試架構如圖1所示，它包括8個組成部分：GUI相關模型、測試相關資料、測試腳本架構、測試用例生成、測試執行和驗證、測試用例維護、測試覆寫評估和核心控制引擎。其中GUI相關模型全面的描述了GUI的結構和功能，是其它組成部分的基礎。測試相關資料和測試腳本架構控制了測試資源，将測試設計和測試執行相分離，為測試的自動執行提供支援。測試覆寫評估采用了一種基于事件的覆寫評估标準，利用GUI事件以及事件間的互動情況來判斷測試是否達到預期的程度。
核心控制引擎協調架構中的所有部分，共同完成GUI測試活動。在執行測試前，它首先稽核測試相關資料的正确性和完整性，然後生成部分測試用例。經覆寫評估部分調整後，确定測試用例集合。在測試執行測試過程中，以測試相關資料和測試用例集合作為輸入，運作測試執行和驗證。當遇到問題時，停止目前執行并調用新的測試用例繼續執行測試。在回歸測試前，當被測程式有所變更時，測試用例維護部分重新對所有的測試用例進行維護，修複失效的測試用例。
圖 1 整體測試架構 架構的測試用例生成部分采用了一種基于覆寫的方法，自動生成能夠快速滿足覆寫标準的測試用例，并在生成測試用例的同時自動産生其預期輸出。架構應用測試資料和測試腳本來實作測試執行過程的自動化。作者應用了一種新型的方法全面的對GUI測試用例進行維護，自動修複由于GUI的更改而失效的測試用例。這些技術符合整體架構的高效性要求。
架構中的GUI相關模型，使測試的各個過程中所用的技術彼此相容，全面的描述了GUI的結構和功能，可以有效的輔助測試用例生成和維護、執行和驗證、以及覆寫評估等過程的實作，符合架構的相容性要求。同時，這些GUI模型與應用平台無關，便于開發和使用，并且适用于不同規模的GUI程式，滿足通用性的要求。
架構的測試腳本和測試相關資料控制了測試資源，應用一套完全資料驅動腳本架構，使用獨立的腳本處理所有的測試類型和測試項目，取消了對測試腳本維護的開銷。另外，以測試資料驅動測試腳本執行，控制測試執行的流程和動作，将測試腳本的維護[url=javascript:;] 工作[/url]轉移到資料表上，滿足了整個架構的可維護性要求。
替代傳統的手工生成預期輸出狀态，架構采用一種全新的結果驗證機制。在測試用例生成的同時，根據事件的類型及其所處環境自動産生預期輸出，并從預期輸出中擷取必要資訊與實際運作結果進行比較。這樣解決了手工操作所遺漏的重要狀态和關鍵屬性等問題，滿足了高整體架構的可靠性要求。
2.GUI模型
為了滿足整體測試架構的要求，将多種測試技術內建在一起，需要應用統一的GUI模型。模型不但要全面有效的描述GUI的各種特性，還要有助于整體架構功能的實作，輔助測試用例生成和維護、測試執行與驗證，以及測試覆寫評估等過程。另外，模型還應該适用于廣泛的應用程式，且便于開發和使用。
GUI的對象包含許多類型，如視窗、下拉菜單、按鈕、滾動條等等，使用者通過執行相應的動作與GUI進行互動。每個對象具有許多屬性，這些屬性值随條件的不同而改變。規模龐大的GUI可以被分割為許多較小的部分，它是具有層次性的，不同的模式視窗屬于不同的層次。例如當執行某些動作打開模式視窗後，輸入焦點會從原來的視窗中轉移到目前模式視窗範圍内。總結GUI的特點，對GUI可做如下定義：
定義1：GUI是具有層次性的軟體系統，每個層次包含多個對象，每個對象對應多個屬性，不同的屬性值使GUI具有不同的狀态。通過接收使用者和系統産生的事件，GUI的狀态會發生改變，并以圖形的形式做出相應的響應。
GUI是以圖形的形式顯示的軟體系統，它所包含對象的屬性值随着條件的不同而變動，使GUI輸出的也随之變化。由GUI變動産生的輸出可以看作是它的狀态，即一系列對象和這些對象所包含的屬性的集合。GUI的狀态可定義成三元組：
1. O = {o1, o2, o3, …, om}
2. P(o)={p1,p2,p3,…pn}, p = Property(object,value)
3. S =P(o1)? P(o2)? …? P(om)
對象集合O={o1,o2,o3,…,om}指GUI中包含的所有對象，屬性集合P(o)={p1,p2,p3,…pn}指對象o?O所包含的全部屬性。每個屬性可以表示成p=property(object,value), 屬性p為布爾值，表示該屬性為真還是假；第一個參數是對象object?O，表示該屬性所隸屬的對象；Value指屬性的值。例如屬性p=Color(Label,red),表示當對象Label的顔色為red時，p=true；當對象Label的顔色不為red時，p=false。
GUI的狀态可以描述成是一些資訊的集合，這些資訊包括GUI的對象類型和對象的屬性。例如圖2(A)中是一個IE的打開對話框，以及“打開”标簽和“取消”按鈕的部分屬性。圖2(B)是該GUI的目前狀态，它是由部分對象和對象的部分屬性所構成。對象的屬性在GUI的執行過程中是可變化的，在某些狀态下屬性的值為真，而在其它的狀态下，屬性的值可能為假，屬性的變化使GUI的狀态也随之改變。屬性在某些條件下會變得沒有意義。例如當視窗win存在時，屬性background-color(win,red)是有意義的；當視窗win關閉後，屬性background-color(win,red)就變得沒有意義了。
