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

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

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

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

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

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

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

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

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

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

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