NEW USER

Reply

New Forum

WinRunner fails to identify an object in a GUI due to various reasons.
> The object is not a standard windows object.
> 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.

Add-Ins are used in WinRunner to load functions specific to the particular add-in to the memory. While creating a script only those functions in the addin selected will be listed in the function generator and while executing the script only those functions in the loaded add-in will be executed else WinRunner will give an error message saying it does not recognize the function.

There are two type of recording in WinRunner.
> Context Sensitive recording records the operations we perform on our application by identifying Graphical User Interface (GUI) objects.
> Analog recording records keyboard input, mouse clicks, and the precise x- and y-coordinates traveled by the mouse pointer across the screen.

When we work with WinRunner, We can choose to save our tests directly to our TestDirector database or while creating a test case in the TestDirector we can specify whether the script in automated or manual. And if it is automated script then.

We can check a single property of a GUI object. For example, we can check whether a button is enabled or disabled or whether an item in a list is selected. To create a GUI checkpoint for a property value, use the Check Property dialog box to add one of the following functions to the test script :
button_check_info
scroll_check_info
edit_check_info
static_check_info
list_check_info
win_check_info
obj_check_info
Syntax : button_check_info (button, property, property_value );
edit_check_info ( edit, property, property_value );

Before creating a test, We can document information about the test in the General and Description tabs of the Test Properties dialog box. We can enter the name of the test author, the type of functionality tested, a detailed description of the test, and a reference to the relevant functional specifications document.

Synchronization points enable we to solve anticipated timing problems between the test and our application. For example : if we create a test that opens a database application, We can add a synchronization point that causes the test to wait until the database records are loaded on the screen. For Analog testing, we can also use a synchronization point to ensure that WinRunner repositions a window at a specific location. When we run a test, the mouse cursor travels along exact coordinates. Repositioning the window enables the mouse pointer to make contact with the correct elements in the window.

When We test our application, We may want to check how it performs the same operations with multiple sets of data. We can create a data driven test with a loop that runs ten times : each time the loop runs, it is driven by a different set of data. In order for WinRunner to use data to drive the test, we must link the data to the test script which it drives. This is called parameterizing our test. The data is stored in a data table. We can perform these operations manually, or We can use the DataDriver Wizard to parameterize we test and store the data in a data table.