全面探討WPF UI自動化測試
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自動化程度仍停留在自動化測試腳本的水平。






















