windows平台UI自動化測試

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