http://www.51testing.com/html/16/n-170116.html
Previously I wrote with UI Automation testing related technology, talked about a test automation tool necessary for several functions, but also mentioned the Windows technical platform automated testing tools is based. Below said about comparing and prospects of these technologies, but also contains some tangled ......
Windows API
Recognition window: the need to look through the FindWindow and EnumWindows to the window handle, then call other API (GetWindowText, GetWindowRect, GetWindowLong ...) to get the window properties, in order to find the control you want (window)
Operating window and access attributes: GetWindowText operated by SetWindowText and text displayed on the control provided by the top-level window SetForegroundWindow, GetForegroundWindow get the current top-level window, and there are similar GetActiveWindow SetActiveWindow. Other operations will not list them ...... In theory, by Windows API and Windows Message can be completed operations for most window (the window controls also are with window), you can also get some of the properties portion of the control. But the advantages and disadvantages are also obvious:
Pros: looks very deep, very powerful is the very bottom of the standard Windows controls that support is not bad.
Disadvantages: the underlying meaning complex, multi-layered packaging needs means, means low development efficiency also means totally dependent on the Windows API. If you hit a non-standard (custom), this way of automated tools to achieve substantially complete loss what to do, even if it is difficult to support the development team to complete automation. Of course, calculate coordinates, even with the global coordinates do can do, but this is a barbaric practice, test automation code is very unstable, the cost of maintenance and analysis of the results is also very high.
All in all, words and short, no automated testing tools use the Windows API to fully realize ...... of course, does not mean that it did not use the Windows API, essentially all of the automation tools will be more or less, directly or indirectly transfer to the Windows API, no one would dare say that he does not transfer a Windows API will be able to do automated testing tools, at least simulate mouse and keyboard messages he would not be able to get ......
MSAA - Microsoft Active Accessibility
In 1997 MSAA technology in Windows 95 it has been included, maybe you have not heard, but in all of the standard controls, have achieved MSAA interface in Microsoft all operating systems are integrated MSAA components, here, I will not discuss MSAA history and related technologies, and on long-winded a little bit of emotion: MSAA is not inherently designed for automated testing, meaning its existence is to provide an interface that allows developers to easily to people with disabilities development can use software, such as screen reader (the mouse button to move to time, may sound, assist visually impaired people to operate a computer), enabling Microsoft to widespread use of computers to every family's dream.
Following entered, although MSAA is not designed for automated testing, but all existing automated testing tools are based or partly based MSAA to achieve. MSAA often directly called it IAccessible, which itself is a COM component, the most important is to achieve IAccessible interface, which provides a number of methods, these methods can obtain more detailed information control, or by a number of methods of control simple operation (DoDefaultAction). Interested can refer to Microsoft Active Accessibility
Advantages: Compared to Windows API, users only need to keep up IAccessible deal, control information can be obtained through this interface is relatively rich in many basic operations do not need to be implemented by Windows Message way. Another advantage is that a relatively large, custom control support, of course, not to say that the development of writing a custom control, this control can be identified by MSAA, but that when developers when implementing a custom control, you can implement IAccessible interface, and through this interface, some of the attributes and operations exposed, testers can use this control as standard controls, and to automate through MSAA. It seems to trouble spots, but at least offers the possibility to automate custom controls.
Disadvantages: lack of natural, MSAA has never been designed for automated testing, so it will not consider the needs of automated testing, access to information and more control than the Windows API, but the relative needs of automated testing is still not enough, and only support a basic operation, other operations must also Message by Windows. The other is after Microsoft's WPF, MSAA limitations more obvious (this is because WPF control properties richer, more customizable, more freedom, difficult to describe with MSAA), which is Microsoft's launch of a UIAutomation incentive.
UIAutomation
With the automated test applications more widely, as well as the release of WPF, Microsoft's MSAA on the basis of MSAA encapsulation, re-designed and implemented UIAutomation library (.Net), Microsoft according to the needs of automated testing, re implement an automated system, we can look at the chart below, this more accurate. From automation testers ushered in a broader blue sky (although still tiny clouds floating point ......), will also have some small tangle:
a. UIAutomation (abbreviated as back to UIA) Vs MSAA
UIA when released, based MSAA automation tools have been developed very mature, such as Silktest and WinRunner ... then everyone in the development of its own automation tools, you should use MSAA, or is UIA? This article can give a rough relationship between the two: UI Automation and Microsoft Active Accessibility. According to Microsoft's ideas and designs, UIA is to replace MSAA become a standard library of automated testing, and for WPF is, UIA is the first-class citizens. Architecturally speaking, UIA in time for the standard controls through UI Automation Proxy called MSAA Server, basically covering the MSAA functionality:
From the top of the map view, in theory, should be able to completely replace the UIA MSAA, but the ideal and the reality is often a big gap, from the practical point of view, UIA can not completely replace MSAA, as a classic of the 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)
As long as the used UI Spy (UIA a gadget, you can see the whole tree UIA controls, similar AccExplorer) basically comes across, when you move the mouse and identify a control, it is possible to see the top of Exception, This means that, UIA failure when constructing UI tree, the mouse is pointing to control illegal. But if you use AccExplorer point of view, it is no problem, the structure of the control tree is relatively intact. It means that you can not find the control you want to control by traversing the tree, because the control structure is simply not in the control tree UIA, of course, it can not carry out any operation (of course, if you use screen coordinates and then by AutomationElement .FromPoint to do, or can do, but please note that you use the screen coordinates). In some small program that may not be obvious, if it is the next big project, and there are a lot of custom case, the problem is magnified, this Exception is like a black hole would swallow up a lot of control, also means you need a lot of places to write code to work around this problem, but also brought a substantial increase in maintenance costs.
b. Managed vs Unmanaged
UIA library as part of .Net3.0 release, which means that the UIA can only be .Net language to write, and run the managed heap in .Net, performance has become one of the problems, although I do not think a big problem, in general, automated testing program in UI response time waiting for much more than this little performance difference.
c. In-Process Vs Out-Process
Although most automated testing tools and test code are running out of process, but there are some special applications need to be in the process, such as in the API testing, the need for UI interactions, in order to ensure that test automation API, you must write automated scripts in the making. MASS is to support the in-process operation, but did not announce UIA support, there will be a lot of performance problems when used in the process may also lead to some unknown issues.
d. custom control support
The UIA will have natural advantages, but also need the support of developers, or the ability of testers can achieve their own, which is two kinds Provider UIA in a built-in, an outboard, as long as the realization of the Provider , custom controls can be the perfect support for UIA. Of course, the standard controls it, UIAutomation released after Win32 controls and WinForm controls, so Microsoft will help us to achieve a good Client Provider corresponding to these controls, the UIA for the previous Win32 and Winform control is the perfect support for the standard WPF controls, not to mention, born with Provider supports. Specifically I will not start, and we are interested can look at this: UI Automation Providers Overview
Windows Automation API 3.0
This is not a new automated testing technology, but, more accurately, to UIAutomation (UIA) and the upgrade MSAA is UIA SP1, but the name to jump directly to 3.0, 1.0 and 2.0 do not know is not referring to the MSAA version so do not faint we see this name after the way ...... nag about Microsoft stuff, looks like someone said, Microsoft's things that are not done in time to go out on the release, then children over a period of time immediately released Service Pack , so Microsoft's product must wait until after SP1 to use, this is quite accurate :) more detail we can see this Blog: Microsoft Windows UI Automation Blog
I am here to say something about, Windows Automation API 3.0 is accompanied by the release of Windows 7, which means that Windows 7 itself integrates Windows Automation API 3.0 so the components and functions, and back word to say that Windows 7 on automated testing support will be better. The main updates are as follows (corresponding to the upper side several entangled the UIA):
a. After the update, the previous Tree broken basically fixes the problem, the results of the tests on my 7 Windows point of view, no problem found
b. Added Unmanned API and COM API, so the direct use of Native C ++ can also be developed based on the UIA automation tools
c. After With COM API, it looks In-Process is not a problem
d. …
Windows Automation API 3.0 beautiful to look at, basically solved the problem of UIA I said above, people feel this version of the UIA is the real alternative to MSAA things. But the Windows Automation API let me tangled for a while, almost wanted to give up the UIA, the Code re-transferred to the MSAA, the main reason is, Windows Automation API 3.0 only supports Windows 7, can not be installed in XP / Vista on, and later through their struggle, with the bottom of the Update: http://social.msdn.microsoft.com/Forums/en-AU/windowsaccessibilityandautomation/thread/46e83c55-47b8-4874-9222-7ce2fa58751d
So, the current situation Windows Automation API 3.0 is:
If you only do automated testing on Windows 7, then congratulations, you can use all the features of Windows Automation API 3.0, both can do with Managed code, you can also do with Unmanaged code.
If you later want to use on Vista, installed the update, it should be on it, I have not tried ......
If you want to use on XP / Server2003, you need to wait until sometime by the end of this year (coming soon :))
In short, on Windows 7, how to do anything (Managed / Unmanned), on XP / Vista / Server2003, only use .Net, but also encountered some control does not control tree. Therefore, we expect the update at the end of it with me ......