windows平臺UI自動化測試

原文地址：http://www.51testing.com/html/16/n-170116.html

之前寫過一篇跟UI自動化 測 試 有關的技術，談到了一個自動化測試 工具必備的幾個功能，並且也提到了Windows 平臺自動化測試工具所基於的一些技術。下邊就說 一下這些技術的比較和展望，同時也包含了一些糾結……

　　Windows API

　　識 別窗口：須要經過FindWindow和EnumWindows來查找到窗口句柄，而後再調用其它 API(GetWindowText，GetWindowRect, GetWindowLong…)來獲取窗口屬性，以此來找到想要的控件（窗口）

　 　操做窗口和獲取屬性：經過SetWindowText和GetWindowText來操做控件上顯示的文字，經過 SetForegroundWindow設置頂層窗口,GetForegroundWindow獲取當前的頂層窗口，相似的還有 GetActiveWindow和SetActiveWindow。其 它 操做就不一一列舉了……從理論上來講，經過Windows API和Windows Message能夠完成對大部分窗口（控件也是窗口，一塊兒都是窗口）的操做，也能夠獲取部分控件的部分屬性。可是缺點和優勢也比較明顯：

　 　優勢：就是看起來很高深很強大很底層，對標準Windows的控件支持還不錯。

　　缺點：底層意味着複雜，意味着須要多層的封裝，意味着 開發效率低下，也意味着對Windows API的徹底依賴。若是碰到一個非標準（自定義控件），用這種方式實現的自動化工具基本上徹底一籌莫展，即便有開發團隊的支持也很難完成自動化。固然了， 算座標，甚至用全局座標來作也能夠作，但這是野蠻作法，自動化測試的代碼很是不穩定，維護和分析結果的成本也很高。

　　總而言之，言而總 之，沒有哪一個自動化測試工具徹底用Windows API來實現……固然了，也不是說Windows API就沒有用了，基本上全部的自動化工具都會或多或少，或直接或間接的調到Windows API，也沒人敢說他不調一個Windows API就能作自動化測試工具的，最起碼鼠標鍵盤消息的模擬他就無法弄……

　　MSAA - Microsoft Active Accessibility

　　MSAA在1997年在Windows 95中就已經包含的技術，也許你沒有據說過，可是在全部的標準控件中，都實現了MSAA的接口，在微 軟 全部的操做系統 中都集成了MSAA的組件，在這裏，我就不討論 MSAA的歷史和相關技術了，就囉嗦一點點感慨：MSAA天生就不是設計給自動化測試的，它存在的意義在於提供一套接口，讓開發人員能夠方便的給殘疾人開 發可使用的軟件，好比讀屏程序（鼠標移動到按鈕的時候，能夠發出聲音，輔助視力障礙的人操做電腦），從而實現微軟將電腦普及到每個家庭的夢想。

　 　下面進入正題，雖然MSAA不是設計給自動化測試的，可是現有的全部自動化測試工具都是基於或者部分基於MSAA來實現的。MSAA不少時候直接把它叫 作IAccessible，它自己是一個COM組件，最主要是實現了IAccessible的接口，它提供了一些方法，經過這些方法，能夠獲取控件更詳細 的信息，也能夠經過一些方法對控件進行簡單的操做（DoDefaultAction）。有興趣的，能夠參考Microsoft Active Accessibility

　　優勢：比起Windows API來講，用戶只須要跟IAccessible打交道，經過這個接口能得到的控件信息相對豐富不少，基本操做也不須要經過Windows Message的方式來實現。另一個比較大的優勢就是，自定義控件的支持，固然了，並非說開發寫一個自定義控件，這個控件就能夠經過MSAA來識別， 而是說當開發人員在實現自定義控件的時候，能夠實現IAccessible的接口，而且經過這個接口，把一些的屬性和操做暴露出來，測試人員就能夠將這個 控件看成標準控件，並經過MSAA來自動化。看起來麻煩了點，可是最起碼對自動化自定義控件提供了可能。

　　缺點：天生不足，MSAA歷來 就不是給自動化測試設計的，因此也不會考慮自動化測試的需求，獲取到的控件信息比Windows API多，可是相對自動化測試的需求來講仍是遠遠不夠，並且僅僅支持一個基本操做，其它的操做還必須經過Windows Message。另外就是微軟推出WPF之後，MSAA的侷限性越加明顯（這也是由於WPF的控件屬性更加豐富，更具定製性，更自由，用MSAA難以描 述），這也是微軟推出UIAutomation的一個的誘因。

UIAutomation

　　伴隨着自動化測試的應用愈來愈普遍，以及WPF的發佈，微軟在MSAA的基礎上，對MSAA進行封裝，從新設計並實現了 UIAutomation的類庫（.Net），微軟根據自動化測試的需求，從新實現了一套自動化體系，你們能夠看下邊的圖，這個比較準確。今後自動化測試 人員迎來了更廣闊的一片藍天（雖然還飄着點小小的烏雲……），隨之也有了一些小小的糾結：

　　a. UIAutomation （後邊就簡稱爲UIA） Vs MSAA

　　在UIA發佈的時候，基於MSAA的自動化工具已經發展的很是成熟，好比Silktest和WinRunner… 那麼你們在開發一個本身的自動化工具的時候，應該用MSAA呢，仍是UIA？ 這篇文章能夠給一個二者的大概關係：UI Automation and Microsoft Active Accessibility。 按照微軟的想法和設計，UIA是要取代MSAA成爲自動化測試的標準類庫，而且對WPF來講，UIA纔是一等公民。從架構上來說，UIA在針對標準控件的 時候，經過UI Automation Proxy調用了MSAA Server，基本上覆蓋了MSAA的功能：

　　從上邊的圖來看，從理論上來講，UIA應該是能夠徹底替代MSAA的，可是理想和現實每每是有很大差距的，從現實來看，UIA不能徹底替代 MSAA，由於一個經典的UIA的Exception：

　　Exception

　　Time Stamp : 10/9/2009 4:37 PM

　　Element : Element details not available.

　　Name : TreeValidationException

　　Message : UI Automation tree navigation is broken. The parent of one of the descendants exist but the descendant is not the child of the parent

　　Stack Trace :  at UISpy.Base.Tree.BuildTree(AutomationElement element)

　　at UISpy.Base.Tree.BuildTreeAndRelatedTrees(AutomationElement element)

　　只要用過UI Spy（UIA的一個小工具，能夠看到整個UIA的控件樹，相似AccExplorer）的基本上都會碰到，當移動鼠標並識別某個控件時，就有可能看到上 邊的Exception，意思是說，UIA在構造UI樹的時候失敗，鼠標所指向的控件不合法。可是若是你用AccExplorer來看，就徹底沒有這個問 題，控件樹的結構也比較完整。就意味着，你沒法經過遍歷控件樹來找到想要的控件，由於控件根本就沒有構造在UIA的控件樹上，固然也沒法對它進行任何操做 （固然，若是你用屏幕座標，而後經過AutomationElement.FromPoint來作，仍是能夠作的，可是請注意，你使用了屏幕座標）。在一 些小的程序上，可能不是很明顯，若是是大的項目，而且有不少自定義控件的狀況下，這個問題就會被放大，這個Exception就像一個黑洞同樣會吞掉不少 控件，也意味着你須要在不少地方去寫代碼來繞過這個問題，同時也帶來了維護成本的大幅提升。

　　b. Managed vs Unmanaged

　　UIA的類庫是做爲.Net3.0的一部分發布，這就意味着UIA只能用.Net的語言來寫，而且運行在.Net託管堆中，性能就成爲其中一個 問題，雖然我不認爲是很大的一個問題，通常來講自動化測試程序在等待UI反應的時間要遠遠多於這一點點的性能差別。

　　c. In-Process Vs Out-Process

　　儘管大部分的自動化測試工具和測試代碼都是運行在進程外，可是仍是有一些特殊的應用須要在進程內進行，好比在API測試中，須要進行UI交互， 爲了保證API測試的自動化，就必須在進行內寫自動化腳本。MASS是支持進程內操做的，可是UIA沒有宣佈支持，在進程內使用時會有很大的性能問題，也 可能致使一些未知的問題。

　　d. 自定義控件的支持

　　這個UIA就有先天優點了，但也須要開發人員的支持，或者有能力的測試人員也能夠本身實現，這就是UIA中的兩種Provider，一種內建， 一種外置，只要實現了Provider，自定義控件就能夠完美的支持UIA。固然了，對標準控件來講，UIAutomation發佈在Win32控件和 WinForm的控件以後，因此微軟就幫咱們實現好了對應這些控件的Client Provider，因此UIA對於之前的Win32和Winform控件也是完美支持的，對WPF的標準控件就更不用說了，天生就是帶有Provider 支持的。具體的我就不展開了，你們有興趣能夠看這個：UI Automation Providers Overview

Windows Automation API 3.0

　　這個並非新的自動化測試的技術，而是對UIAutomation（UIA）以及MSAA的升級，更準確的說，是UIA SP1，但名字直接跳到3.0，不知道1.0和2.0是否是指的MSAA的版本，因此你們看到這個名字之後不要暈……  順便嘮叨一下微軟的東西，貌似某我的說過，微軟的東西都是在沒有作完的時候就發佈出去，而後過一段兒時間立刻發佈Service Pack，因此微軟的產品必定要等到SP1之後才能用，這個至關準確:）更詳細的介紹你們能夠看這個Blog：Microsoft Windows UI Automation Blog

　　我在這裏就大概說一下，Windows Automation API 3.0是伴隨着Windows 7發佈的，也就是說Windows 7自己就集成了Windows Automation API 3.0因此的組件和功能，再換一句話說就是Windows 7就自動化測試的支持將會更好。最主要的更新以下（與上邊UIA的幾個糾結對應）：

　　a. 更新之後，之前Tree斷掉的問題基本上修復了，我在Windows 7上測試的結果來看，沒發現問題

　　b. 新增了Unmanned API和COM API，這樣直接用Native的C++也能夠來開發基於UIA的自動化工具

　　c. 有了COM API之後，看起來In-Process也不是問題了

　　d. …

　　Windows Automation API 3.0看起來很美，基本上都解決了我上邊說的UIA的問題，讓人感受到這個版本的UIA纔是真正能夠替代MSAA的東西。可是這個Windows Automation API也讓我糾結了好一陣子，差一點就想放棄UIA，從新把Code轉移到MSAA上，最主要的緣由是，Windows Automation API 3.0只支持Windows 7，不能安裝在XP/Vista上，後來通過和他們的鬥爭，有了下邊的Update： http://social.msdn.microsoft.com/Forums/en-AU/windowsaccessibilityandautomation/thread/46e83c55-47b8-4874-9222-7ce2fa58751d

　　因此，對Windows Automation API 3.0的當前狀況就是：

　　若是你僅僅在Windows 7 上作自動化測試，那麼恭喜你，你可使用Windows Automation API 3.0的全部功能，既能夠用Managed code來作，也能夠用Unmanaged code來作。

　　若是你想在Vista上用，裝了那個更新之後，應該就能夠了，我沒試過……

　　若是你想在XP/Server2003上使用，你須要等到今年年末的某個時候（快到了:)）

　　總之，在Windows 7上，怎麼作都行（Managed/Unmanned），在XP/Vista/Server2003上，只能用.Net，並且還會碰到有些控件不在控件樹 上。因此，你們跟我一塊兒期待年末的更新吧……