WPF強化了用戶界面的自動化測試，使測試人員可以從繁瑣的UI測試中解脫出來，將更多的精力用于更加底層的測試工作。

　　從Visual Studio2005開始，微軟將測試集成到其開發工具中，從工具上保證了測試工作在軟件生命周期中的重要地位。而從NET3.0的WPF開始，微軟通過其UI的自動化支持，協助開發人員為界面元素建立自動化測試標識。

　　WPF的UI自動化技術

　　WPF為Windows桌面應用程序和WEB應用程序提供了一個智能客戶端開發模型，以方便構建豐富統一的UI、媒體、圖形圖像、動畫和文檔等。一方面WPF可以促使開發人員更積極地參與到用戶界面的開發，另一方面提升用戶體驗的滿意度。

　　在傳統的軟件開發中，用戶界面開發費工費時，并且跨越了表現層和技術層，使一般的程序員都苦惱不已。WPF則從技術層面上減輕了這種復雜性，提升了開發人員參與用戶界面設計開發的積極性。

　　UI自動化對大多數用戶界面元素提供可編程訪問，即通過除標準輸入輸出 (比如鍵盤鼠標) 方式以外的方法操作UI。UI自動化核心層屏蔽不同框架技術下多種UI元素的差異，確保UI自動化客戶應用程序能在多種框架技術下工作。比如，WPF按鈕的內容(Content)屬性，標準Win32按鈕的標題(Caption)屬性以及HTML頁面上顯示圖像的替換文字(ALT)屬性等都映射為WPF中UI自動化視圖中單一的名字(Name)屬性。藉此，一些輔助技術產品和自動化測試框架可獲得其所需要的獲取用戶界面信息統一的程序化訪問方法，此外，通過自動化的用戶界面技術，應用開發商也可以提高其產品的易用性。

　　UI自動化模型

　　現有技術下實現UI自動化測試系統開發需要通過不同方法獲得和展現UI元素信息，開發人員需要花費大量的時間和精力去搜集這些必需的UI元素信息，而不能集中精力于系統特征和功能的實現上。借助于WPF的UI自動化所提供的統一的控制模式，通過其等價的名字屬性 (NameProperty) 就可以輕松實現對不同UI元素的統一控制。UI自動化技術減少了此類應用系統的開發成本，將成為下一代輔助訪問技術產品和自動化測試系統主要的界面信息資源提供者。

　　UI自動化包括兩部分。UI自動化服務提供者 (UI Automation Providers) 和UI自動化客戶程序 (UI Automation Clients) 。UI自動化服務提供者是提供UI自動化服務的應用程序，比如Word, Excel及其它基于Windows的應用程序 等，為用戶通過輔助程序技術對其訪問提供支持。UI自動化客戶端程序是實現用戶界面自動化訪問的輔助技術程序，比如Word和Excel中供應用程序訪問的對象模型及其宏腳本等。相應的，對開發人員來說，可以通過調用UI自動化提供者應用程序接口(UI Automation Providers API)創建用戶界面控制元素，也可以通過調用UI自動化客戶端應用程序接口(UI Automation Clients API)創建應用程序，通過UI自動化核心層與UI自動化界面控制元素進行通訊。

　　UI自動化通過把界面上一個個的UI元素作為自動化元素 (AutomationElement)暴露給客戶端應用程序供其調用。所有UI自動化元素組成以桌面(Desktop)為根節點的樹型層次結構，樹狀結構包含所有正在運行的應用程序，每一個正在運行的應用程序都是這個根的子節點，其每一個可能與用戶進行互動的界面元素都是一系列層次化的自動化元素(AutomationElement)。樹型層次結構通過原始視圖(Raw View) 的形式展現給客戶端，客戶端可以通過過濾自動化元素樹的原始視圖 (Raw View) ，得到控制項視圖 (Control View) 和內容項視圖 (Content View) 。 NET3.0提供UI 探測程序UISpy.exe供開發人員調用以察看UI自動化元素視圖。

　　自動化元素 ( AutomationElement)對象包括UI元素在界面上所呈現的兩類共有屬性。一個是控制類型屬性(Control Type)，控制類型屬性定義界面元素的基本表現形式和功能，并以此作為單一的識別實體。比如，按鈕Button類型或者多選框Check Box類型。一個是控制模式(Control Patterns)，控制模式提供一個統一的方法來構建和表達控制類型所擁有的功能。比如，可以對擁有被調用功能的控制類型比如按鈕Button類型使用調用模式，對編輯類控制類型使用文本模式等。控制模式通過公開方法調用使客戶端得到界面元素進一步的詳細信息并提供輸入。微軟鑒別出18種控制模式，通過這18種控制模式可以展現出任何類UI元素及其任意組合所能實現的所有事情。

　　注意，控制類型和控制模式之間并不是一一對應的關系。一個控制模式可以被多種控制類型支持，一個控制類型也可以支持多種控制模式，每一個組合都展現其不同的行為樣式。比如，一個下拉框類型(Combo Box)具有至少兩種控制模式:一個是呈現其折疊和展開能力的模式(ExpandCollapsePattern)，另一個是呈現其選擇項的可選擇模式(SelectionItemPattern)。

　　WPF的UI自動化測試

　　我們知道，現有技術條件下實現UI自動化測試系統開發需要分別實現不同技術條件下的UI元素的鑒別和控制，實現復雜而且有效性不高。而借助于WPF的UI自動化所提供的統一的控制模式就可以輕松實現。

　　作為UI自動化服務提供者，在開發一個應用程序的時候，必須注意最終用戶通過標準鍵盤和鼠標操作UI對象進行交互的行為。一旦這些關鍵行為被確定，則其相應的反映UI元素功能和行為的UI自動化控制模式就需要被應用程序實現。比如，要實現一個組合框對象，就需要確定用戶對組合框所進行的操作控制模式，用戶通常需要調用組合框的折疊和展開模式去隱藏和顯示其可選擇項列表，也需要調用其編輯模式通過鍵盤輸入增加一個新的選擇項。UI自動化服務提供者實現控制模式的接口位于System.Windows.Automation.Provider 名字空間中，其所有控制模式接口都包含后綴“Provider”，比如調用模式接口 IInvokeProvider，文本模式接口ITextProvider等。所有標準WPF控制項自動支持UI自動化，應用程序自定義的控制項必須提供支持UI自動化的訪問類和接口。

　　作為UI自動化客戶端，通過調用UI自動化的控制模式類提供的方法和屬性得到UI元素的控制信息和內容信息，達到對UI操作和控制目的。這些控制模式類位于System.Windows.Automation名字空間，其所有控制模式類都包含后綴“Pattern” ，比如調用模式類InvokePattern，文本模式類TextPattern等。

　　控制模式將一個界面元素對象所支持的結構，方法，屬性和事件結合在一起。控制模式對于UI元素的關系相比于接口對于COM對象的關系。對于COM，我們可以通過詢問COM對象得到它所支持的接口，然后通過接口調用對應的COM功能。對于UI自動化對象，客戶端可以通過詢問UI對象得到它所支持的控制模式，然后通過其控制模式調用得到其結構、方法、屬性和事件，從而實現和UI的交互。

　　例如，提供者實現了多行文本編輯控制的滾動模式接口IScrollProvider，當一個客戶端程序探測到這個界面元素支持滾動模式，則可以通過調用滾動模式類ScrollPattern得到這個文本編輯框的屬性、方法和事件來收集所支持的文本滾動信息，通過程序化的方法實現文本編輯框內容的滾動。

　　綜上所述，WPF的UI自動化技術旨在提供一個統一的UI控制訪問方式，由UI自動化服務提供者 (UI Automation Providers) 實現控制模式接口，UI自動化客戶程序 (UI Automation Clients) 則通過調用相應的控制模式類來實現UI自動化操作和控制。

　　軟件測試的花費往往很高。自動化是一個節省時間和成本的好辦法。但是軟件自動化測試的工具和技術，往往缺乏通用的適用性和伸縮性。為了實現測試過程的自動化，我們依據軟件需求或規格設計說明書，針對測試對象，自動生成測試用例，使測試能自動執行，自動驗證其正確性。

　　在整個軟件測試過程中，由于UI在提升用戶體驗方面的特殊作用，UI級別的測試不但在于驗證系統的正確性和有效性，而且在驗證整個系統的易用性、行為一致性和穩定性方面有著非常重要的作用。

　　但UI自動化測試歷來困難。一般來說，一個系統大量的UI人為干預，都需要測試。今天我們還沒有一個完全能達到此一目標而頗具規模的系統。UI自動化程度仍停留在自動化測試腳本的水平。