Interview Questions

What is Gui Map?

Introduction To WinRunner Basics

(Continued from previous question...)

What is Gui Map?

“GUI Map” provides a layer of indirection between the objects described in the script and the widgets created by the application. The GUI Map is made up of all currently loaded GUI Map files. GUI Map files are viewed in the GUI Map Editor. The GUI map file contains the logical names and physical descriptions of GUI objects. WinRunner stores information it learns about a window or object in a GUI Map. The GUI map provides a centralized object repository, allowing testers to verify and modify any tested object. These changes are then automatically propagated to all appropriate scripts, eliminating the need to build new scripts each time the application is modified. When WinRunner runs a test, it uses the GUI map to locate objects. It reads an object’s description in the GUI map and then looks for an object with the same properties in the application being tested. Each of these objects in the GUI Map file will be having a logical name and a physical description. When WinRunner learns the description of a GUI object, it does not learn all its properties. Instead, it learns the minimum number of properties to provide a unique identification of the object. Each object is identified within the scope of its parent window, not the entire application. An Example of how WinRunner uses a logical name and physical description to identify an object:

“Print” for a Print dialog box, or “OK” for an OK button. This short name connects WinRunner to the object’s longer physical description.

Logical Name:

This is the name that appears in the test script when user records an application. Usually WinRunner uses attached text that WinRunner can read as the Logical name. WinRunner checks that there are no other objects in the GUI map with the same name.

set_window ("Readme.doc - WordPad", 10);
menu_select_item ("File; Print... Ctrl+P");
set_window ("Print", 12);
button_press ("OK");
Physical Description:

The physical description contains a list of the object’s physical Properties. The Print dialog box, for example, is identified as a window with the label “Print”

. Readme.doc window: {class: window, label: "Readme.doc - WordPad"}
File menu: {class: menu_item, label: File, parent: None}
Print command: {class: menu_item, label: "Print... Ctrl+P", parent: File}
Print window: {class: window, label: Print}
OK button: {class: push_button, label: OK}

For each class, WinRunner learns a set of default properties. Each default property is classified “obligatory” or “optional”. An obligatory property is always learned (if it exists).

An optional property is used only if the obligatory properties do not provide unique identification of an object. These optional properties are stored in a list. WinRunner selects the minimum number of properties from this list that are necessary to identify the object. It begins with the first property in the list, and continues, if necessary, to add properties to the description until it obtains unique identification for the object. In cases where the obligatory and optional properties do not uniquely identify an object, WinRunner uses a selector to differentiate between them. Two types of selectors are available:

Location selector:-The location selector uses the spatial order of objects within the window, from the top left to the bottom right corners, to differentiate among objects with the same description.

Index selector:-The index selector uses numbers assigned at the time of creation of objects to identify the object in a window. Use this selector if the location of objects with the same description may change within a window.

Consider an example where a form has two OK buttons
set_window ("Form1", 2);
button_press ("OK") ;{ class: push_button, label: OK, MSW_id: 1}
button_press ("OK_1) ;{ class: push_button, label: OK, MSW_id: 2}

WinRunner recorded the object logical names as OK and OK_1, in Physical description, both the buttons is having the same class and label properties. So, WinRunner assigned the third property to both the buttons "MSW_id (Microsoft windows Id) which is assigned by operating system. When we run the script, WinRunner will recognize those objects by MSW_id as the id is different for both the OK buttons. User can modify the logical name or the physical description of an object in a GUI map file using the GUI Map Editor. Changing the logical name of an object is useful when the assigned logical name is not sufficiently descriptive or is too long. Changing the physical description is necessary when the property value of an object changes.

Using the GUI Spy, user can view the properties of any GUI object on users desktop. User use the Spy pointer to point to an object, and the GUI Spy displays the properties and their values in the GUI Spy dialog box. User can choose to view all the properties of an object, or only the selected set of properties that WinRunner learns.

There are two modes for organizing GUI map files.
Global GUI Map file: - a single GUI Map file for the entire application
GUI Map File per Test: - WinRunner automatically creates a GUI Map file for each test created

Global GUI Map File is the default mode. As the name suggests in Global mode a single script is created for the entire application.

Using Rapid Test Script Wizard option we can learn the entire application but this option is not available in the GUI File Test mode.

In Global GUI Map file, it learns all the objects in the window into one temporary GUI Map file. We can see this temporary file by Tools -> GUI Map Editor -> L0 . In this file all objects and their property values will be stored. We need to save this GUI Map file explicitly. If it’s not saved, then all the entries will remain in the temporary file. We can specify whether we have to load this temporary GUI Map file should be loaded each time in the General Options.

In GUI Map File Per Test a script is generated for each and every window/ screen in the application. In GUI Map File Per Test if we save the test script it implicitly saves all the GUI objects in a separate GUI file.

If an object isn't found in the GUI Map during recording, WinRunner reads its attributes and adds it to the Temporary GUI Map file. During playback, it doesn't matter which GUI Map file defines an object. Objects may be identified from any loaded GUI Map file whether it is temporary file or GUI Map file. If the GUI Map already contains an object, another file with that object cannot be loaded into the GUI Map. GUI files with unsaved changes preceded by asterisk (*).Temporary GUI always loads automatically.

WinRunner fails to identify an object in a GUI due to various reasons.
i. The object is not a standard windows object.
ii. If the browser used is not compatible with the WinRunner version, GUI Map Editor will not be able to learn any of the objects displayed in the browser window

The GUI Map Editor displays the various GUI Map files created and the windows and objects learned in to them with their logical name and physical description. We can invoke GUI Map Editor from the Tools Menu in WinRunner. The different options available in the GUI Map Editor are

Learn: -Enables users to learn an individual GUI object, a window, or the entire GUI objects within a window.
Modify:-Opens the Modify dialog box and allows user to edit the logical name and the physical description of the selected GUI object.
Add: -adds a GUI objects to the open GUI Map files.
Delete: -deletes the selected GUI objects from the open GUI Map files.
Copy (Expanded view only): -copies the selected GUI objects to the other GUI map file in the GUI Map Editor.
Move (Expanded view only): -moves the selected GUI objects to the other GUI map file in the GUI Map Editor.
Show: -highlights the selected GUI object if the object is visible on the screen.
Find: -Helps users to easily locate a specific GUI object in the GUI map.
Expand (GUI Files view only): -expands the GUI Map Editor Dialog box, enabling the user to copy or move GUI objects between open GUI Map files.
Collapse (GUI Files view only): -collapses the GUI Map Editor Dialog box.
Trace (GUI Files view only): -Enables user to trace a GUI object that appears in more than one GUI Map file.

User can clear a GUI Map file using the “Clear All” option in the GUI Map Editor. When the user is working with GUI map per test mode and if the user clear the temporary GUI map, the GUI map test information will not be saved with the test and the test may fail.

Filters Options

GUI Map Editor has a Filter option which enables user to define which GUI objects to display in the GUI Map Editor, there are 3 options. Filter by Logical Name:-If selected, displays only those GUI objects whose Logical Names contain the substring user specified.

Filter by Physical Description:-If selected, displays only those GUI objects whose Physical Descriptions contain the substring user specified.

Filter by Class:-If selected, displays only those GUI objects in the class user specified.

Saving Changes to the GUI Map

When the user makes some modification to the physical description or logical name within a GUI map file then the user must save the changes before ending the testing session and exiting WinRunner. User need not save the changes manually if the user is working in the GUI Map File per Test mode. Changes are saved automatically with the test. If the user adds new windows from a loaded GUI map file to the temporary GUI map file, then when the user save the temporary GUI map file, the New Windows dialog box opens. Prompting to add the new windows to the loaded GUI map file or save them in a new GUI map file.

User can load GUI map in two ways
a) Using function
GUI_load (file_name);
file_name The full path of the GUI map.

If the user is not specifying a full path, then WinRunner searches for the GUI map relative to the current file system directory. So, the user must always specify a full path to ensure that WinRunner will find the GUI map.
b) Using map editor

From GUI files drop down in the Map editor the user can select the file name. When the user selects a file name then the GUI file will be loaded.

Unload GUI map files.
To unload a specific GUI Map file
To unload all the GUI Map files loaded in the memory.

While working in the GUI Map File per Test mode, WinRunner automatically creates, saves, and loads a GUI map file with each test user create. When user work in the Global GUI Map File mode it enables user to save information about the GUI of the application in a GUI map that can be referenced by several tests. When the application changes instead of updating each test individually, user can merely update the GUI map that is referenced by the entire group of tests. The GUI Map File Merge Tool enables user to merge multiple GUI map files into a single GUI map file. Before merging GUI map files, user must specify at least two source GUI map files to merge and at least one GUI map file as a target file. The target GUI map file can be an existing file or a new (empty) file.

Auto merge: - The merge tool merges all GUI map files, and prompts user only if there are conflicts to resolve between the files. Manual merge:-user merges each GUI map file manually. The merge tool prevents user from creating conflicts while merging the files.

Many applications contain custom GUI objects. A custom GUI object is any object not belonging to one of the standard classes used by WinRunner these objects are therefore assigned to the generic “object” class. When WinRunner records an operation on a custom object, it generates obj_mouse_click statements in the test script. If a custom object is similar to a standard object, user can map it to one of the standard classes. user can also configure the properties WinRunner uses to identify a custom object during Context Sensitive testing. The mapping and the configuration user set are valid only for the current WinRunner session. To make the mapping and the configuration permanent, user must add configuration statements at the startup test script.

A startup test is a test script that is automatically run each time when the user start WinRunner. User can create startup tests that load GUI map files and compiled modules, configure recording, and start the application under test. User can designate a test as a startup test by entering its location in the Startup Test box in the Environment tab in the General Options dialog box. User can use the RapidTest Script wizard to create a basic startup test called myinit that loads a GUI map file and the application being tested. When working in the GUI Map File per Test mode the myinit test does not load GUI map files.

Sample Startup Test
# Start the Flight application if it is not already displayed on the screen. #invoke_application statement, which starts the application being tested.

if ((rc=win_exists("Flight")) == E_NOT_FOUND)
invoke_application("w:\\flight_app\\flight.exe", "", "w:\\flight_app",SW_SHOW);

# Load the compiled module "qa_funcs". load statements, which load compiled modules #containing user-defined functions that users frequently call from their test scripts.
load ("qa_funcs", 1, 1);

# Load the GUI map file "flight.gui". GUI_load statements, which load one or more GUI #map files. This ensures that WinRunner recognizes the GUI objects in the application #when the user run tests.
GUI_load ("w:\\qa\\gui\\flight.gui");

# Map the custom “borbtn” class to the standard “push_button” class. set_class_map statement configure how WinRunner records GUI objects in application.
set_class_map (“borbtn”, “push_button”);

Deleting a Custom Class
User can delete only custom object classes. The standard classes used by WinRunner cannot be deleted.

Virtual object
Applications may contain bitmaps that look and behave like GUI objects. WinRunner records operations on these bitmaps using win_mouse_click statements. By defining a bitmap as a virtual object, user can instruct WinRunner to treat it like a GUI object such as a virtual push buttons, radio buttons, check buttons, lists, or tables when the user record and run tests. If none of these is suitable, user can map a virtual object to the general object class.

WinRunner identifies a virtual object according to its size and its position within a window, the x, y, width, and height properties are always found in a virtual object’s physical description. If these properties are changed or deleted, WinRunner cannot recognize the virtual object. If the user move or resize an object, user must use the wizard to create a new virtual object. The virtual object should not overlap GUI objects in application (except for those belonging to the generic “object” class, or to a class configured to be recorded as “object”). If a virtual object overlaps a GUI object, WinRunner may not record or execute tests properly on the GUI object.

Advantages of GUI Map
If a button label changes in the application, update the button description once in the GUI map rather than in 500 tests
button_press ("Insert")
instead of
button_press("{class: ThunderSSCommand}");
Use the same script for all platforms, with a different GUI map for each platform

(Continued on next question...)

Other Interview Questions