Interview Questions

How to Create a Test Using Winrunner (1)

Introduction To WinRunner Basics


(Continued from previous question...)

How to Create a Test Using Winrunner (1)

User can create tests using recording or programming or by both. While recording, each operation performed by the user generates a statement in the Test Script Language (TSL). These statements are displayed as a test script in a test window. User can then enhance the recorded test script, either by typing in additional TSL functions and programming elements or by using WinRunner’s visual programming tool, the Function Generator, or using the Function Viewer.

There are 2 modes of recording in WinRunner

1. Context Sensitive mode records the operations user performed on the application by identifying Graphical User Interface (GUI) objects. Context Sensitivity test scripts can be reused in the future version of the application because WinRunner writes a unique description of each selected object to a GUI map file. The GUI map files are maintained separately from test scripts and the same GUI map file (or files) can be used for multiple tests.
For example, if the user clicks the Open button in an Open dialog box, WinRunner records the action and generate a script. When it runs the test, WinRunner looks for the Open dialog box and the Open button represented in the test script. If, in subsequent runs of the test, the button is in a different location in the Open dialog box, WinRunner is still able to find it.

2. Analog mode records mouse clicks, keyboard input, and the exact x-and y-coordinates traveled by the mouse. When the test is run, WinRunner retraces the mouse tracks. Use Analog mode when exact mouse coordinates are important to the test, such as when testing a drawing application.
For example, if the user clicks the Open button in an Open dialog box, WinRunner records the movements of the mouse pointer. If, in subsequent runs of the test, the button is in a different location in the Open dialog box, WinRunner will not able to find it. When recording in Analog mode, use softkeys rather than the WinRunner menus or toolbars to insert checkpoints in order to avoid extraneous mouse movements.

Different recording methods 1) Record 2) Pass up 3) As Object 4) Ignore.

1) Record instructs WinRunner to record all operations performed on a GUI object. This is the default record method for all classes. (The only exception is the static class (static text), for which the default is Pass Up.)

2) Pass Up instructs WinRunner to record an operation performed on this class as an operation performed on the element containing the object. Usually this element is a window, and the operation is recorded as win_mouse_click.

3) As Object instructs WinRunner to record all operations performed on a GUI object as though its class were “object” class.
4) Ignore instructs WinRunner to disregard all operations performed on the class.

Some common Settings we need to set in General Options:
1. Default Recording Mode is Object mode
2. Synch Point time is 10 seconds as default
3. When Test Execution is in Batch Mode ensure all the options are set off so that the Batch test runs uninterrupted.
4. In the Text Recognition if the Application Text is not recognizable then the Default Font Group is set. The Text Group is identified with a User Defined Name and then include in the General Option.


Checkpoints allow user to compare the current behavior of the application being tested to its behavior in an earlier version. If any mismatches are found, WinRunner captures them as actual results. User can add four types of checkpoints to test scripts they are

GUI Checkpoints
Bitmap Checkpoints
Text checkpoints
Database checkpoints


All mouse operations, including those performed on the WinRunner window or WinRunner dialog boxes are recorded during an analog recording session. Therefore, don’t insert checkpoints and synchronization points, or select other WinRunner menu or toolbar options during an analog recording session. Note that even if user chooses to record only on selected applications, user can still create checkpoints and perform all other non-recording operations on all applications. Any checkpoints should not be a component of X & Y Co-ordinate dependant. In practical terms if there is a Check point that is defined on X, Y Parameters then the usability of the control point wouldn't make any sense for the application to test. User cannot insert objects from different windows into a single checkpoint. Don’t use Bitmap or GUI Checkpoints for dynamic verification. These checkpoints are purely for static verifications. There are of course, work-around, but mostly not worth the effort.

GUI checkpoints verify information about GUI objects. For example, user can check that a button is enabled or see which item is selected in a list. There are three types of GUI Check points they are
For Single Property
For Object/Window
For Multiple Objects


GUI checkpoint for single property:-user can check a single property of a GUI object. For example, user can check whether a button is enabled or disabled or whether an item in a list is selected.
GUI checkpoint for object/window:-user can create a GUI checkpoint to check a single object in the application being tested. User can either check the object with its default properties or user can specify multiple properties to check.
GUI checkpoint for multiple objects:-user can create a GUI checkpoint to check multiple objects in the application being tested. User can either check the object with its default properties or user can specify multiple properties of multiple objects to check.


Bitmap Checkpoint checks an object, a window, or an area of a screen in the application as a bitmap. While creating a test, user can indicate what user want to check. WinRunner captures the specified bitmap, stores it in the expected results folder (exp) of the test, and inserts a checkpoint in the test script. While running the test, WinRunner compares the bitmap currently displayed in the application being tested with the expected bitmap stored earlier. In the event of a mismatch, WinRunner captures the current actual bitmap and generates a difference bitmap. By comparing the three bitmaps (expected, actual, and difference), user can identify the nature of the discrepancy there are two types of bitmap check points they are
Bitmap Checkpoint for Object/Window: - user can capture a bitmap of any window or object in the application by pointing to it.
Bitmap Checkpointfor Screen Area:-user defines any rectangular area of the screen and captures it as a bitmap for comparison.

Text checkpoints read and check text in GUI objects and in areas of the screen. While creating a test user has to point to an object or a window containing text. WinRunner reads the text and writes a TSL statement to the test script. Later user can add simple programming elements to test scripts to verify the contents of the text. User should use a text checkpoint on a GUI object only when a GUI checkpoint cannot be used to check the text property. There are two types of Text checkpoints they are
From Object/Window
From Screen Area


Database checkpoints check the contents and the number of rows and columns of a result set, which is based on a query user, create on database. There are three types of database check points they are
Default Check:-used to check the entire contents of a result set, Default Check are useful when the expected results can be established before the test run.
Custom Check:-used to check the partial contents, the number of rows, and the number of columns of a result set.
Runtime Record Check:-user can create runtime database record checkpoints in order to compare the values displayed in the application during the test run with the corresponding values in the database.

(Continued on next question...)

Other Interview Questions