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，而且還會碰到有些控制元件不在控制元件樹 上。所以，大家跟我一起期待年底的更新吧……