Winrunner Notes - Basic

Like every other automation tool, Winrunner records our actions on the application being tested and generates script automatically in TSL(Test Script Language), which is similar to C Language. Where ever we want to verify the application behaviour, we can insert verification points in the script and presto! our automation script is ready.Following is the quick notes on Winrunner basics.

Recording Modes

Winrunner supports 2 types of recording modes - Context sensitive recording and Analog recording.

Context Sensitive: Context Sensitive mode records your actions on the application being tested in terms of the GUI objects you select (such as windows, lists, and buttons), while ignoring the physical location of the object on the screen. Every time you perform an operation on the application being tested, a TSL statement describing the object selected and the action performed is generated in the test script.

Analog: 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 your test, such as when testing a drawing application.

GUI Map

Each object has a defined set of properties that determines its behavior and appearance. WinRunner learns these properties and stores them in a separate file called GUI Map. The tool uses these properties to identify and locate GUI objects during a test run.

Winrunner supports two types of GUI Maps - Global GUI Map file and GUI Map file per test

Global GUI Map file: Multiple tests can reference a common GUI map file. The advantage of this type is, if a object description is changed and this object is referred in multiple tests, then you need to make changes in only one file, if all these tests are using the same global GUI map file. Also you save memory, if you maintain one GUI map file, instead of one for each test. There are disadvantages too.If we use this type, then we need to explicitly create, save, load and unload the file.These tasks won't be taken care by winrunner automatically. Also, one more disadvantage is, if the file is used by multiple people, care should be taken that one person changes to the file don't override the changes done by the other.

GUI Map file per test: For each test created, winrunner creates and maintains a separate GUI map file.The main advantage is you do not need to worry about creating, saving, and loading GUI map files, winrunner does it automatically.This is recommended for beginners.The disadvantage being, if there is change in objects description, then all GUI map files referring it need to changed, so maintenance is a little tedious.

Logical name vs Physical Description: The logical name is actually a short nickname for the object's lenghty physical description. The physical description contains a list of the object's physical properties. The logical name and the physical description together ensure that each GUI object has its own unique identification.In the actual test, you usually refer the object with their logical names.Winrunner consults the GUI Map file for the test and gets the physical description to identify the object.

Learning GUI objects for Global GUI Map file: When you work in the Global GUI Map File mode, you need to teach WinRunner the information it needs about the properties of GUI objects. WinRunner can learn this information in the following ways

-By using the RapidTest Script wizard to learn the properties of all GUI objects in every window in your application
-By recording your actions on the application, winrunner learn the properties of all GUI objects on which you performed actions.
-By using the GUI Map Editor to learn the properties of an individual GUI object, window, or all GUI objects in a window

Finding an Object or Window in the GUI Map: When the cursor is on a statement in your test script that references a GUI object or window, you can right-click and select Find in GUI Map.

Checkpoints

Checkpoints enable you to compare the current behavior of your application to its expected behavior. You can add four types of checkpoints to your tests:

1. GUI checkpoints check information about GUI objects. For example, you can check that a button is enabled or see which item is selected in a list.
2. Database checkpoints check the data content in a database.
3. Text checkpoints read text in GUI objects and in bitmaps, and enable you to check their contents.
4. Bitmap checkpoints compare a "snapshot" of a window or an area in your application to an image captured in an earlier version.

Running Tests

When you run a test, WinRunner interprets your test, line by line. As the test runs, WinRunner operates your application as though a person were at the controls. WinRunner provides three run modes.

1. Verify mode, to check your application
2. Debug mode, to debug your test
3. Update mode, to update the expected results

Debugging Tools

If a test stops running because it encountered an error in syntax or logic, several tools can help you to identify and isolate the problem.

1. Step commands run a single line or a selected section of a test.
2. Breakpoints pause a test run at pre-determined points, enabling you to identify flaws in your test.
3. The Watch List monitors variables, expressions and array elements in your test.During a test run, you can view the values at each break in the test run such as after a Step command, at a breakpoint, or at the end of a test.

Supported Environments

WinRunner includes support for testing applications developed with PowerBuilder, Visual Basic, ActiveX, and MFC.
Mercury Interactive also provides testing solutions for other leading application development and deployment environments such as the Web, Java, Enterprise Resource Planning (ERP) applications, Wireless Application Protocol (WAP), Oracle, Delphi, and Siebel.