https://www.cnblogs.com/yufun/archive/2009/10/10/1580132.html
【這里的自動化測試專指GUI自動化（不包含Web）】
以前寫過一篇跟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，而且還會碰到有些控件不在控件樹上。所以，大家跟我一起期待年底的更新吧……
Note:
1. 多謝xiongli，推薦大家去看這篇文章，確實寫的很精彩 http://eparg.spaces.live.com/blog/cns!59BFC22C0E7E1A76!4008.entry
2. 任何幫助都不如Spec寫的明白，啥也不說了 UI Automation Community Promise Specification