WPF UI自動化測試的實現，需要許多技術的支持，實行起來還是一個比較繁瑣的步驟。在這里我們會為大家詳細解析這些方法的應用。#t#

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

作為UI自動化服務提供者，在開發一個應用程序的時候，必須注意最終用戶通過標準鍵盤和鼠標操作UI對象進行交互的行為。一旦這些關鍵行為被確定，則其相應的反映UI元素功能和行為的UI自動化控制模式就需要被應用程序實現。比如，要實現一個組合框對象，就需要確定用戶對組合框所進行的操作控制模式，用戶通常需要調用組合框的折疊和展開模式去隱藏和顯示其可選擇項列表，也需要調用其編輯模式通過鍵盤輸入增加一個新的選擇項。

UI自動化服務提供者實現控制模式的接口位于System.Windows.Automation.Provider 名字空間中，其所有控制模式接口都包含后綴“Provider”，比如調用模式接口 IInvokeProvider，文本模式接口ITextProvider等。所有標準WPF控制項自動支持UI自動化，應用程序自定義的控制項必須提供支持UI自動化的訪問類和接口。

作為WPF 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自動化操作和控制。

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

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

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