UIAutomation和WPF
UIAutomation是微軟從Windows Vista開始推出的一套全新UI自動化測試技術， 簡稱UIA。在最新的Windows SDK中，UIA和MSAA等其它支持UI自動化技術的組件放在一起發布，叫做Windows Automation API。
和前面的介紹相比，我傾向於認為UIA是一項自動化測試“技術”，而MSAA和Win32 API只是實現自動化測試的兩種“方法”。這里區分“技術”和 “方法”的原因是， 一項“技術”往往有獨立的模型，體貼的開發接口，用來專門解決某一類的問題，同時允許不同的實現細節。UIA可以被看作“技術”，是因為：
UIA定義了全新的、針對UI自動化的接口和模式。 分別是支持對UI元素進行遍歷和條件化查詢的TreeWalker/FindAll。定義了讀寫UI元素屬性的UIA Property， 包括Name、 ID、Type、ClassName、Location、 Visibility等等。定義了UI元素行為的UIA Pattern， 比如Select、Expand、Resize、 Check、Value等等。 還引入了UIA Event接口，可以讓測試程序在某些事件發生后得到通知，比如新窗口打開事件等。
以往的Win32和MSAA 設計出發點並不是為解決UI自動化。Win32旨在提供的通用開發接口， MSAA旨在提供程序的多種訪問方式。相反，UIA的設計目的，以及新引入的模式和接口都完全是針對UI自動化測試的。
在后面的文章中我們會詳細分析UIA的內部實現。可以看到，UIA這一套接口和模式，可以在不同平台，不同開發工具中實現和使用。其內部實現方式也因地制宜， 前后的兼容性都照顧得很好。 同時，UIA提供了托管的和非托管兩種API，這些都是Win32和MSAA無法比擬的。
下面一段簡單的C#代碼演示了如何使用UIA測試Windows自帶計算器完成計算3+5-2的操作（下述代碼可能需要修改以適應不同Windows版本的calc.exe程序。本代碼使用Visual Studio 2008針對Windows 2008 Server R2 English 編寫）
UIA的優勢
UIA的優勢非常明顯,主要包括以下幾點:
1. 適應不同類型的UI程序，包括Win32、WinForm、 WPF和Silverlight。 由於WPF和Silverlight中的子窗口和控件並不是傳統的HWND，所以Win32 API和MSAA無能為力。 而UIA可以直接支持這兩種程序。
2. 兼容傳統的Win32和MSAA模式。 前面提到過，UIA技術的內部實現可以多樣化。 這一點在下一篇文章中會詳細討論。 UIA通過一項叫做UIA<->MSAA的橋技術， 針對傳統程序， 可以在內部實現中借用MSAA的接口和直接調用Win32 API。這樣不需要對控件或者程序的既有實現做任何改動， 就可以直接適用於UIA的新模式。
3. 新引入的TreeWalker、UIA Event、Pattern、 Property模式易於使用，貼合自動化測試。這些模式高度抽象了各種UI自動化測試的需求，同時又不和傳統模式相沖突。比如執行點擊按鈕操作， 傳統方法要么模擬鼠標鍵盤操作，要么發送Windows Message，而Message還分為WM_COMMAND或者WM_BUTTONDOWN。 而通過UIA Pattern， 統一歸類於Invoke接口，這個接口對於測試者來說就統一了。無論是Win32、 WPF還是Silverlight按鈕，都可以通過統一接口執行， 從而把具體實現隔離開。同時， 調用者若希望繼續沿用鍵盤鼠標模擬，仍舊可以通過SendKey加上UIA獲取坐標的方法實現。而UIA Event和對UI元素支持條件化區域化搜索，更是極大簡化了測試人員的工作。
4. 提供托管的和非托管接口， 方便各種工具的開發人員。 同時提供了簡潔方便的方式支持UI程序和控件開發人員擴展，自定義UIA的實現。比如通過AutomationPeer來擴展 基於WPF的控件， 通過實現簡單的IRawElementProviderSimple來擴展基於WinForm的控件等。具體細節在下一篇文章中會詳細介紹。
5. 針對WPF程序，除了支持基本的端對端（End to End）UI自動化以外，還支持基於AutomationPeer的單元測試。具體例子可以參考UI Automation in Silverlight - Simulating User Interactions
6. 提供了完善的工具、文檔、開發包、例子程序等。比如通過UI Spy（圖三）獲取任意窗口或者元素的UIA信息。
圖三：UI Spy
自動化技術和自動化框架
前面提到了UIA作為全新UI自動化測試技術的優勢，但這並不能解決所有的UI 自動化問題。 自動化框架正是為了自動化技術沒有完全解決的問題。比如：
1. 自動化中的同步和等待。 對於稍復雜的UI 程序，測試程序往往需要根據測試目標的狀態決定 下一步的操作。 比如測試文件另存為功能的時候，若保存路徑是網絡路徑，可能會因為網絡延遲導致整個UI停頓比較長的時間。這個時候測試，程序如果不顧當前狀態而簡單地執行下一步操作，比如新建文件， 很可能會因為UI延遲而失敗。 正確的做法是，測試程序應該等待文件保存成功返回后，再進行下一步操作。 這就是自動化中同步和等待的一個例子。實現同步和等待有多種方法，最簡單粗暴的做法是硬編碼一個長時間的 Sleep在測試代碼中。 稍微好一點的做法可以采取小時間片的輪詢狀態檢查， 或者反復重試。 借助 UIA的Event Pattern，可以嘗試捕獲另存為窗口的關閉WindowClosedEvent。 如果要做得完善一點， 可以把多種方法結合， 另外再額外檢查目標程序的CPU使用情況，消息循環是否有回應，設定超時時間等等。
2. 冗繁的編碼過程。 對於一個UI窗口，里面可能有幾十個子控件或者子窗口。 在編寫測試代碼的時候， 如果對這些子元素的獲取，操作不能簡化， 勢必導致代碼冗繁，難以維護。 借助自動代碼生成和ORM (Object Role Modeling)等技術， 可以解決這個問題。 比如可以用工具把窗口及其子元素的關系和搜索條件都序列化到XML文件中， 然后采用ORM技術即可在代碼中輕松獲取子元素。
3. 多語言和本地化測試。多語言和本地化的測試對UI來說顯得尤為重要。 UI程序往往通過資源文件來定義所顯示的內容， 這就要求自動化測試要可以方便讀取和定位程序的資源文件， 來支持多語言和本地化測試。
4. 支持工具和輔助函數的匱乏。 對於大的項目研發， 通過好的工具來減小開發成本是非常必要的。 就UI自動化來說， 如果自動化測試用例可以通過一次錄制，多次播放來做的話，成本會減少很多。 在VS2010中就提供了這樣的錄制-播放功能。 詳細視頻可以參考How to create record and playback Test Cases in Visual Studio Beta2。
5. 區分功能性測試和用戶真實行為模擬。 前面提到， 就點擊按鈕功能來說， 可以通過SendKey來模擬鼠標操作， 或者通過Windows Message來直接觸發點擊事件。 這兩種不同方法各有優劣。 比如當按鈕被其它元素遮擋， 通過SendKey進行模擬就會導致失敗，而直接發送Windows Message還是會成功。 孰優孰劣取決於要達到的目的。 如果單純為了測試按鈕點擊后導致的結果，通過Windows Message來模擬就省去了很多麻煩。 相反， 如果是界面測試， 通過SendKey來模擬就可以讓按鈕被遮擋的bug暴露出來， 而Windows Message則不能發現這樣的問題。
所以，單純的某個自動化技術或者方法也無法滿足需求。為了解決上述問題，各種自動化測試框架逐漸涌現和發展。微軟內部有多個不同的自動化框架，設計理念和側重點各有不同。 Visual Studio 2010將加入對自動化測試的支持。 在CodePlex上面， 也可以找到多種框架，比如White和UI Automation Verify。