Winrunner

WinRunner was a popular software testing tool developed by Mercury Interactive, which later
became part of Hewlett Packard (HP). However, it's important to note that as of my last
knowledge update in January 2022, WinRunner is considered outdated and has been officially
retired.

WinRunner was primarily designed for functional testing of graphical user interface (GUI)
applications. It supported both Windows and web-based applications. Here are

Some key features and functionalities of WinRunner:

Record and Playback: WinRunner allowed testers to record their interactions with the
application and then play them back to automate repetitive test scenarios.

GUI Testing: It was particularly strong in testing GUI-based applications. It could recognize
various GUI objects, such as buttons, menus, and dialog boxes, and perform actions on
them.

Data-Driven Testing: WinRunner supported data-driven testing, allowing testers to

parameterize their tests and use different sets of data for multiple test iterations.

Scripting Language: WinRunner used a proprietary scripting language called TSL (Test
Script Language) for creating more complex and customized test scripts.

Integration with Test Management: It could be integrated with test management tools to
manage test scripts, execution results, and overall test management.

Verification Points: WinRunner allowed the insertion of verification points to check

whether the application behaved as expected at specific points during test execution.

Winrunner environment

Windows

C++, Visual Basic, Java, PowerBuilder, Stingray, Smalltalk

Web

Web Applications
Other technologies

SAP, Siebel, Oracle, PeopleSoft, ActiveX

Win runner testing process

1) Create a GUI map:

WinRunner must learn to recognize the objects in an application in order to run tests The preferred way to
teach your objects depends on the GUI map mode

2) Create tests:

● Winrunner writes scripts automatically when recording actions in application

● One can program directly in Mercury interactive script language(TSL)

3) Debug tests:

You debug the test to check that they operate smoothly and without interruption

4) Run test:

● Run test in verify mode t test your application

● It compares the current data of application being tested to the expected data captured earlier

● If any mismatch are found, winrunner captures them as actual results

5) View results:

● After each run it displays result in report

● The report details all the major events that occurred during the run such as checkpoint, error
message, system message, user message

6) Report defects:

If a test run fails due to a defect it will report directly in report window

Winrunner Object Identification Process

GUI Configuration Tool

The tool determines what properties of objects are recorded

GUI Spy

Allows users to view the property of an object without recording it

GUI Map Editor

Holds information recorded about each object allowing the test to identify the object during execution

Recording Modes
Context-Sensitive mode statements can be recorded or programmed

● Exact mouse movements are not required

● record: button press, win activate

● button_press ("OK");

● recommended for most situations due to greater robustness

Analog mode statements are rarely programmed, mostly recorded and edited

● Exact mouse movements are required

● recond: move locator, type, mtype
● Analog statements are useful for literally describing the keyboard, mouse, and mouse button input
of the user

Advantages
● Enables Rapid Testing

● Provides Consistency

● Reusability of tests

● Customizable for future changes

Disadvantages
● Doesn’t apply for Stress or Load or Scalability Testing.

● Doesn’t support .net programming

● Tester should have programming knowledge/experience

● It doesn’t support multimedia systems.

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.

Debugging Tools:

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.