In this article we will talk about the different recording modes, Object Spy and Object repositories in QTP.
Recording Modes in QTP:
Recording is the most commonly used method to create a test. The basic steps are typically recorded and the test later under goes improvements in order to suit the needs of the testing process.
QTP provides 3 modes of recording:
Though only the normal recording mode gets used most of the times, it is important to know the others too, as the knowledge about the same can come handy when the need arises for them.
Normal Recording mode- The default recording method is always the normal mode. In all our previous articles when we say record we meant the normal mode. So, as we know this method uses the model of Test Objects and Runtime objects to learn and act on the AUT.
Analog recording mode- records the exact mouse and key strokes that the user performs in relation to either the screen or AUT window. The steps that are recorded using this method cannot be edited.
The way this usually gets represented in a code is:
One scenario in which this type of recording can be used is when we are trying to capture a signature.
Low Level recording mode- This mode records the co-ordinates in the application where the operation is performed, irrespective of whether QTP recognizes the specific Object or Operation.
Some important points to note about these different modes are:
- In the middle of recording, we can switch to Analog/Low-level mode, finish the task required and go back to normal recording
- Analog and Low-level recording modes require more memory space than the normal mode.
- Mouse movements are not recorded in the low-level recording mode
- The switch to Analog mode is available only during recording and not during editing
- The test that is recorded in an analog mode will fail if it is run after changing the screen resolution.
The menu option to change the recording mode is:
Object Spy is an extremely helpful tool that QTP has to view the properties and operations of an object in the AUT. The prerequisite to using this tool is that the AUT has to be opened.The Object Spy can be accessed by using “Tools->Object Spy” or by directly clicking on the below
It is also available from the Object repository and Object repository manager windows.
When Object Spy is launched, this is how its interface looks:
By clicking on the pointy hand you can point to any object whose properties you wish to examine. This is how it displays the properties:
As you can see, it shows all the properties of the object and the corresponding values. It shows the object hierarchy. There is also an ‘Operations’ tab which when clicked displays all the operations that can be performed on the test object:
The spy not only displays the properties, it also has a provision that lets the users add a certain object to the OR.
You can do that by clicking on the OR icon with a + in it.
In one of the previous articles we talked about how an OR is like a warehouse where all your objects are stored.
OR has the list of Objects that QTP learned during the record process and the class to which they belong. It stores the set of properties that uniquely identifies the Object (description) and also names the object for the sake of identification in our test, based on its most prominent feature.
The objects that are acted upon during record get automatically added to the OR. Alternately, the user can add additional objects on a need basis. This can be done directly from the OR window or from Object Spy. (Ctrl+R or Resources->Object Repository or click on the icon.)
There are two kinds of repositories:
Every time a test is created we have seen that a call to Action 1 is the only statement by default. We can add other actions and call them as needed. So, for every action QTP creates its own local repository by default. It contains the objects that are related to that particular action.
Conversely, the user may decide to use a common repository for multiple actions in which case, this repository is to be associated with the actions and all of them can share the objects that it contains. This can be done using the “Object Repository manager’. The objects can be exported from a local repository into the shared one to maintain a single location for all the objects. Also, a shared repository is read-only in the action level and any changes to it have to be made via ‘Object Repository manager’.
The repository to be used by an action has to be specified in the action properties.
How is it done practically is something we will look into using some examples later on.
Some of the important points to note here are:
- Even though there is a single shared repository for all actions every action will have its own local repository whether the test uses it or not. For example: For test 1 if there are Action 0, Action 1 and Action 2 and there is a shared repository ORShared, there will be local repositories OR0, OR1 and OR2 by default. However, if all the actions use one shared repository, local OR will be empty.
- If a local OR and Shared OR have an object with the same name, the action will consider the object in its local OR.
- There can be more than one Shared OR’s associated to the same action. If Shared OR1 and Shared OR2 have one object named OBJ1 each and if the action calls for OBJ1 then the order in which the shared ORs were associated will be considered. That means, if Shared OR1 was first associated then the OBJ1 from Shared OR1 will be taken into account.
It goes without saying that having a shared Object Repository is more efficient as it helps in easy maintenance and you can use one object description across multiple actions.
Here we covered some of the key concepts that will enable us to understand and create better QTP Tests. In my opinion information on Actions, Active screen and a rather impromptu but important password encoder tool are few more aspects we will have to cover before we move to more advanced topics.