Introduction to HP WinRunner
HP / Mercury Interactive’s WinRunner is an automated functional GUI testing tool that allows a user to record and play back UI interactions as test scripts.
As a Functional test suite, it works together with HP QuickTest Professional and supports enterprise quality assurance.
It is a functional testing software for enterprise IT applications. It captures, verifies and replays user interactions automatically, so you can identify defects and determine whether business processes work as designed.
The software implements a proprietary Test Script Language (TSL) which is similar to C Language, that allows customization and parameterization of user input.
WinRunner has become obsolete now: On February 15, 2008, HP Software announced the end of support for all versions & all editions of WinRunner.
How WinRunner works: Its intuitive recording process helps you produce robust functional tests.To create a test, It simply records a typical business process by emulating user actions, such as ordering an item or opening a vendor account.
During recording, you can directly edit generated scripts to meet the most complex test requirements. Next, testers can add checkpoints, which compare expected and actual outcomes from the test run.
It offers a variety of checkpoints, including test, GUI, bitmap and web links.
It can also verify database values to determine transaction accuracy and database integrity, highlighting records that have been updated, modified, deleted and inserted.
With a few mouse clicks, the DataDriver Wizard feature lets you convert a recorded business process into a data driven test that reflects the real-life actions of multiple users.
For further test enhancement, the Function Generator feature presents a quick and reliable way to program tests, while the Virtual Object Wizard feature lets you teach WinRunner to recognize, record and replay any unknown or custom object.
As it executes tests, it operates the application automatically, as though a real user were performing each step in the business process. If test execution occurs after hours or in the absence of a quality assurance (QA) engineer, the Recovery Manager and Exception Handling mechanisms automatically troubleshoot unexpected events, errors and application crashes so that tests can complete smoothly.
Once tests are run, it�s interactive reporting tools help your team interpret results by providing detailed, easy-to-read reports that list errors and their origination.
It lets your organization build reusable tests to repeat throughout an application�s lifecycle. Thus, if developers modify an application over time, testers do not need to modify multiple tests. Instead, they can apply changes to the Graphical User Interface (GUI) Map, a central repository of test-related information, and it automatically propagates changes to all relevant scripts.
It records user actions performed on the Application Under Test (AUT) and automatically generates script in TSL or Test Script Language. Verification points can be inserted in the script at the chosen points where we desire to verify the behavior of the application.
Recording Modes of WinRunner:
It supports following two types of recording modes:
1) Context Sensitive Recording: Context Sensitive mode records user actions on the application under test test in terms of selected GUI objects like windows, lists, and buttons etc. while ignoring the actual location of the object on the screen. Every time any action is done on the application under test, a TSL statement gets generated in the test script. This TSL statement describes the details of the object selected and the action performed.
2) Analog Recording: Analog mode records mouse clicks, keyboard inputs, and the precise two dimensional (X, Y) coordinates traversed by the mouse. When the test is run, WinRunner retraces all the mouse tracks. When exact mouse coordinates are important to the test, analog mode is used, e.g. testing a drawing application.
Creation of GUI Map:
Each object has a defined set of properties, which determines its behavior and appearance. WinRunner captures such properties and stores them in a separate file by the name GUI Map. The tool uses these properties to identify and locate GUI objects during a test run.
It supports following two types of GUI Maps:
1) Global GUI Map file: Multiple tests can have reference to a common GUI map file. The advantage of this feature is that, if an object description needs changes and the object happens to be referenced in many tests, then changes in the single Global GUI Map file are sufficient. Maintenance of single GUI map file conserves system resources like its memory, as against maintenance of independent GUI Map files for every test. There is a drawback of this as well, because it needs explicit creation, saving, loading and unloading of the file. WinRunner does not handle such activities automatically. When more than one person is using & changing the file, another user who also happens to work on the file simultaneously needs to be careful that changes made by one person do not override the changes done by the other.
2) GUI Map file for every test: WinRunner creates and maintains an independent GUI map file for every test. This has an advantage that there is no need to bother about creating, saving, and loading GUI map files, since WinRunner shall be doing it automatically. This is quite useful for the beginners. The only drawback is that the maintenance of files is quite cumbersome, since small changes even in object description, calls for changing all the GUI map files referring it.
Logical Name versus Physical Description:
The logical name of an object is a short nickname in addition to a lengthy physical description. The physical description describes the physical properties of the object. The logical name and the physical description combined together helps in maintaining a unique identification for every GUI object. Logical names are frequently used for reference in the actual test. WinRunner checks back the GUI Map file for the test and captures the physical description of every object to identify it.
Knowing GUI objects for Global GUI Map file:
When we work in the Global GUI Map File mode, the information pertaining to the properties of GUI objects need to be provided to the WinRunner. WinRunner can capture this information in the following ways
1) Through the RapidTest Script wizard we can get various properties of all the GUI objects in every window in the application
2) By recording the actions on the application, WinRunner captures the properties of all GUI objects on which all actions have been performed.
3) With the help of GUI Map Editor we can capture all the properties of an individual GUI object, window, or all GUI objects in a window
How to find 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.
Know the Checkpoints:
Checkpoints help us in drawing comparison between the present behavior of the application under the test with respect to the its expected behavior. Following types of checkpoints can be inserted in the tests.
1) GUI checkpoints: are meant for checking the information related to the e.g. we can check whether a particular button is enabled or identify the item selected in a list.
2) Database checkpoints: are meant for checking the data content in a database.
3) Text checkpoints: are meant for reading the text in GUI objects and in bitmaps, which enable us to check their respective contents.
4) Bitmap checkpoints: are meant for comparing the snapshots of some window or an area in the application with respect to the image captured in an earlier version.
How to Run the Tests:
The WinRunner during execution of the test does line by line interpretation. As the test runs, WinRunner operates the application as if someone is actually present at the controls.
WinRunner provides three types of the run modes.
1) Verify mode: Is meant for checking the application
2) Debug mode: Is meant for debugging of the test
3) Update mode: Is meant for updating the desired results.
When a test stops in between an execution due to some syntax error or some or logic error, we can use several methods & tools to identify and isolate the problem.
1) Use of Step commands: Is done to run a single line or some selected section of a test.
2) Use of Breakpoints: Is done to halt the test run at pre-determined points, with a view to enable us to identify the flaws in the test.
3) Use of the Watch List: Is done to monitor the variables, expressions and array elements in the test. During the execution of a test, we can view the values at every break point like after the Step command or at some breakpoint or at the end of the test.