How HP UFT/QTP Recognizes Objects for Recording & Playback
Posted on Dec, 2012 by Admin
While delivering our HP UFT/QTP training course, I am frequently asked why it is necessary to launch the application under test (AUT) after QTP (QuickTest Pro) has launched (and the appropriate add-ins are loaded).
The simple answer is that UFT/QTP recognizes objects by “hooking” into the AUT. This is accomplished by “watching” for applications to hook into so UFT can interact with the AUT to support record and replay functionality as well as expose the underlying objects. The potential side effect of not launching QTP before the AUT is that the objects may not be recognized properly and recording or playback is unsuccessful.
The technical answer is more complex and there is very little information detailing the underlying technology. It is helpful to understand how objects are recognized and interacted with from a technical perspective to realize potential implications.
Note: Throughout this article I will use UFT (Unified Functional Testing) and QTP (QuickTest Pro) interchangeably. Both refer to the GUI component of UFT, also known as QTP.
Hooking explained
Interaction with the AUT in UFT is achieved through hooking and instrumentation – in the case of Windows based applications, Windows Hooks.
“A hook is a mechanism by which an application can intercept events, such as messages, mouse actions, and keystrokes. A function that intercepts a particular type of event is known as a hook procedure. A hook procedure can act on each event it receives, and then modify or discard the event.”
http://msdn.microsoft.com/en-us/library/windows/desktop/ms644959(v=vs.85).aspx
Hooking allows external applications to gain control and alter application behavior. Application events, function calls and messages can be intercepted without access to the source code. Simply put, hooking allows UFT to “spy” on the application.
Windows processes are launched in an isolated virtual address space (VAS). Upon execution of an application, Windows identifies import references and searches for the required DLLs to load in order support these references. Hooks can be implemented through physical modification (reverse engineering) or runtime modification (DLL injection). Instrumentation is similar to hooking but it implements more advanced debugging capabilities and is achieved at compile time (more on this later).
UFT “watches” for applications that are launched, specifically relating to the loaded add-ins, and injects DLL code (hooks) into the process memory. This is runtime modification. Nearly all add-ins are comprised of hooking DLLs.
Hooking is primarily used in the recording functionality of QTP. By hooking into the AUT, application events can be exposed, observed and recorded by third party applications (i.e., QTP).
After QTP injects the appropriate DDLs into the AUT process during runtime, the GUI objects are obtained by querying the API of the platform. This allows for the GUI object’s native properties to be exposed to QTP in the Object Spy and during recording and playback of scripts. The GUI object structure of the application is exposed, unveiling the object hierarchy for navigation and object discovery.
If the AUT is launched before UFT, the hooking mechanism is not loaded into process memory. The side effect is that UFT cannot intercept events in the AUT and objects cannot be properly identified or interacted with.
What QTP hooking looks like
By using Sysinternals’ Process Explorer, we can observe the DLLs that are loaded into process memory. In the example below, I compare and identify the hooking DLLs that are loaded into Internet Explorer (iexplore.exe) by QuickTest Pro when selecting the web add-in.
Opening Internet Explorer before QTP (without hooks)
Opening Internet Explorer after QTP (with hooks)
By comparing both lists of loaded DLLs, it is possible to identify exactly what hooking DLLs are injected into the iexplore.exe process. They are listed below:
bbHookLoaderU.dll QuickTest Professional (Unicode) Hewlett-Packard Development Company, L.P. C:\Program Files (x86)\HP\QuickTest Professional\bin\bbHookLoaderU.dll HookMgr.dll QuickTest Professional (Unicode) Hewlett-Packard Development Company, L.P. C:\Program Files (x86)\HP\QuickTest Professional\bin\HookMgr.dll ie_hooksU.dll QuickTest Professional (Unicode) Hewlett-Packard Development Company, L.P. C:\Program Files (x86)\HP\QuickTest Professional\bin\ie_hooksU.dll ime_srv.dll QuickTest Professional (Unicode) Hewlett-Packard Development Company, L.P. C:\Program Files (x86)\HP\QuickTest Professional\bin\ime_srv.dll MfxApplicationU.dll QuickTest Professional (Unicode) Hewlett-Packard Development Company, L.P. C:\Program Files (x86)\HP\QuickTest Professional\bin\MfxApplicationU.dll MicAgentInjector.dll QuickTest Professional (Unicode) Hewlett-Packard Development Company, L.P. C:\Program Files (x86)\HP\QuickTest Professional\bin\MicAgentInjector.dll mmalloc_logic.dll Hewlett-Packard Company C:\Program Files (x86)\HP\QuickTest Professional\bin\mmalloc_logic.dll mosifs32.dll Hewlett-Packard Company C:\Program Files (x86)\HP\QuickTest Professional\bin\mosifs32.dll SharedMemoryProcU.dll QuickTest Professional (Unicode) Hewlett-Packard Development Company, L.P. C:\Program Files (x86)\HP\QuickTest Professional\bin\SharedMemoryProcU.dll thrdutil.dll Hewlett-Packard Company C:\Program Files (x86)\HP\QuickTest Professional\bin\thrdutil.dll WIAgentLogFileU.dll QuickTest Professional (Unicode) Hewlett-Packard Development Company, L.P. C:\Program Files (x86)\HP\QuickTest Professional\bin\WIAgentLogFileU.dll
Implications of hooking
When QuickTest Pro is first launched, the Add-in Manager dialog is presented. This dialog states, “To maximize performance and object identification reliability, load only the add-ins you need.” Application performance can be significantly degraded if too many add-ins, or hooks, are loaded. Directly from the Windows Hooks (Overview) page we see a reference to this fact:
“Hooks tend to slow down the system because they increase the amount of processing the system must perform for each message. You should install a hook only when necessary, and remove it as soon as possible.”
Unnecessarily loading hooking DLLs (add-ins) can not only degrade performance but it can also interfere with properly exposing the GUI objects for identification. In addition, a poorly coded hooking DLL can impact the overall behavior of the application.
Source code instrumentation vs. Hooking
Source code instrumentation is achieved at compile time by including a third party library consisting of code that exposes the application layer events and objects. Once this library is included in the application, code is added at the time of GUI object creation (i.e., constructors) that exposes the object’s native properties and events.
Application developers tend resist this method because they do not want to include code developed by a third party that they may not have control over. Automation engineers are generally indifferent as long as the end result is the same as hooking, but prefer to avoid having to go through the internal processes and channels to approve third party code integration during application development. It is easier to hook into an application during runtime than to implement additional code at compile time, therefore hooking is more commonly used in functional test automation than source code instrumentation.
Recall that hooking allows events to be intercepted through runtime modification (DLL injection). Hooking, at its very essence, is code injection.
Both source code instrumentation and hooking modify the AUT. The difference lies in the implementation – code is either injected during application compilation or runtime execution. The end result is essentially the same. Both methods have the potential to inadvertently introduce defects into the application.
Your thoughts…
Do you think compile time instrumentation or runtime hooking has less of an impact on automation and overall application quality?
If you find this post informative, please share it using the links below or obtain free updates through our RSS feed.
