WinRunner; Introduction

WinRunner

Introduction

Mercury interactive win runner is a testing tool to do functional/ regression testing. Using win runner, you can record GUI operations. While recording, win runner automatically creates a test script. This test script can be run automatically later on for carrying out unattended testing. The Important aspects of win runner are:

You can do functional/ regression testing of a variety of application software written in programming languages such as powerbuilder, visual basic, C/ C++ and java. You can do testing in different windows operating systems and different browser environment. You can record GUI operations in the record mode. Win runner automatically creates a test script. This test can be modified and can be executed later on in unattended mode. You can add checkpoints to compare actual and expected results. The checkpoints can be GUI checkpoints, Bitmap checkpoints and synchronization checkpoints. Data driver wizard provides the facility to convert a record test into a data driven test. So, you can replace data with variables within a test script. The virtual object wizard of win runner is used to teach win runner to recognize, record and replay custom objects. The reporting tools provide facility to generate automatically the test reports and analyze the defects. Win runner can be integrated with the testing management tools to automate many activities in the testing process.

Recording Test Case

WinRunner

Recording Test Case

To test any application, you can run the application and understand its operation. Then you can invoke win runner, again run the application and record the GUI operations. During the recording mode, win runner will capture all the actions, which button you pressed, where you clicked the mouse etc. You need to work with the application as usual and perform all the actions to be tested. Once the recording is completed, win runner generates a script in TSL. You can run this test script to view the results of the test cases.

There are two modes of testing:

Context sensitive Context sensitive mode records your operations in terms of the GUI objects in your application. Win runner identifies each object you click, and the type of operation you perform. For example, if you record a mouse click on the OK button in the flight reservation login window, win runner records the following TSL: button_press (“OK”) When you run the script, win runner reads the command, looks for the OK button and presses it. Analog In analog mode, Win runner records the exact coordinates traveled by mouse, as well as mouse clicks the keyboard input.

Recording in context sensitive mode

Start win runner Choose PROGRAMS> WINRUNNER Open a new test Click on NEW TEST button when win runner gets open. Start the flight reservation application and log in. Choose PROGRAMS> WIN RUNNER> SAMPLE APPLICATION> FLIGHT 1A on the start menu. In the login window type your name and password and click OK button. Start recording in context sensitive mode. Choose CREATE> RECORD- CONTEXT SENSITIVE or click RECORD button on toolbar. Open order #2 In flight reservation application, choose FILE>OPEN ORDER. In the open order dialog box, select ORDER NO. check box. Type 2 in the box and click OK button. Stop recording Choose CREATE>STOP RECORDING or click STOP button on toolbar of win runner. Save the test Choose FILE>SAVE or click SAVE button on toolbar.

Recording in Analog mode

Start recording in context sensitive mode. Choose CREATE>RECORD-CONTEXT SENSITIVE or click the RECORD button on the toolbar. Open the fax order form and fill in the fax number. In the flight reservation application, choose FILE>FAX ORDER and type fax no. Select the send signature with order check box. Sign the fax in Analog mode. Press F2 on your keyboard or click the RECORD button to switch analog mode and sign your name in agent signature box. Switch back to context sensitive mode and send the fax. Press F2 or click on record button again. Stop recording. Choose CREATE>STOP RECORDING or click the STOP button. Save the test Choose FILE>SAVE or click SAVE button.

To view the presentation of Recording in Analog Mode, click here!

Running the Test

WinRunner

Running the Test

You are now ready to run your recorded test script and to analyze the test results. Win runner provides three modes for running tests. You can select a mode from toolbar.

Use verify mode when running a test to check that the behavior of your application, and when you want to save the test result. Use Debug mode when you want to check that the test script runs smoothly without error in syntax. Use Update mode when you want to create new expected results for a GUI checkpoint or Bitmap checkpoint.

GUI Map File

WinRunner

GUI Map File

In win runner, if you run a test without loading thee corresponding GUI map file, it generates an error as it fails to identify the controls used in the test cases. For example, suppose you have recorded a test for inverse function for the calculator application and forgot to save its GUI map file. When you close the test case and again open it run the test case, an error message is generated.

Even if you save the GUI map file but forget to load the corresponding GUI map file, generates the error message.

Win runner may generate some ambiguous or wrong results but not errors if the application is not brought back to base state before trying to run the application.

Adding GUI objects to the GUI Map

WinRunner

Adding GUI objects to the GUI Map

If you’re application contains some new objects, you can add them to the GUI map without running the rapid test script wizard again. You simply use the learn button in the GUI map editor to learn descriptions of the objects. You can learn the description of a single object or all the objects in a window.

Open the flight reservation login window. Choose PROGRAMS>WIN RUNNER>SAMPLE APPLICATION>FLIGHT 1A on the start menu. Open the GUI map In win runner, choose TOOLS>GUI MAP EDITOR. Learn all the objects in the login window. Click the LEARN button. Use the pointer to click the objects in login window. A message appears to learn all the objects in the window. Click yes. Win runner a description of each object in the login window. Save the new objects in the GUI map. Choose TOOLS>GUI MAP EDITOR. Choose VIEW>GUI FILES. Choose FILE>SAVE. Click yes or ok to add the new objects or new window to your GUI map. Close the login window.

Checking GUI objects

WinRunner

Checking GUI objects

When working with an application, you can determine whether it is functioning properly according to the behavior of GUI objects. If a GUI object does not respond to input as expected, a defect probably exists somewhere in application’s code. You check GUI objects by GUI checkpoints. A GUI checkpoint examines the behavior of an object’s properties.

To create GUI checkpoint for a single object, you first point to your application. If you click the object, a checklist with the default checks for the object is inserted into your test script. A checklist contains information about the GUI object and the selected properties to check.

Checking a single property

In order to check a single property of one particular object, you need to create the checkpoint for a single object as follows.

•Go to CREATE>GUI CHECKOINTS>FOR SINGLE PROPERTY

On selecting this option, it prompts you to select the object for which the checkpoint has to be created. Select the required object. It will then display the check property dialog box.

Select the required property, on which the object has to be checked, by selecting a value from property. Win runner will automatically assigns the default value to that function.

Checking a single object

If you want to create checkpoints for multiple properties of a single object, then checkpoint for single object is used. The checkpoint can be created as follows:

•Go to CREATE>GUI CHECKOINTS>FOR SINGLE OBJECT/WINDOW.

Checking for multiple objects

The checkpoints for multiple objects can also be created. This is used to check the property of various objects. To create checkpoints for multiple objects, select “for multiple object”.

•Go to CREATE>GUI CHECKOINTS>FOR MULTIPLE OBJECTS.

Adding GUI checkpoints to a test script

WinRunner

Adding GUI checkpoints to a test script

An example of adding GUI checkpoints to test script:

Start win runner and open a new test. Choose PROGRAMS>WIN RUNNER on start menu. Click NEW TEST button. Start the flight reservation application and log in. Choose PROGRAMS>WIN RUNNER>SAMPLE APPLICATION>FLIGHT 1A on the start menu. Then write your name and password in login window and click ok button. Start recording in context sensitive mode. Choose CREATE>RECORDING or click record button. Open the order dialog box. Choose FILE>OPEN ORDER in the flight reservation application. Create a GUI checkpoint for the order number check box. Choose CREATE>GUI CHECKPOINT>FOR OBJECT/ WINDOW. Then double click the object/ window where you want a checkpoint. Enter the order no. Click ok button Stop recording. Choose CREATE>STOP RECORDING or click the STOP button.

The GUI checkpoint can be for single property or object/ window or for multiple objects.

To view the animated presentation of GUI Checkpoints, click here!

Synchronizing the test

WinRunner

Synchronizing the test

In this, you will insert a synchronization pointing the test script created.

Make sure that the test script window is active Place the cursor where you want to synchronize the test. Add a blank line below the insert order statement. Place the cursor at the beginning of the blank line. Synchronize the test so that it waits for the “Insert done” message to appear in the status bar. Choose CREATE>SYNCHRONIZATION POINT>FOR OBJECT/ WINDOW BITMAP. Manually change the one second wait in the test script to a 10 second wait. Save the test Choose FILE>SAVE or click SAVE button.

a

Changing the synchronization setting

The default intervals that win runner wait for an application to respond to input is 10 seconds. We can add a synchronization point to solve it.

Open general option dialog box. Choose SETTINGS>GENERAL OPTION. Click the Run tab. Change the value to 1000 milliseconds Click OK to close the dialog box.

Synchronizing the test

WinRunner

Synchronizing the test

In this, you will insert a synchronization pointing the test script created.

Make sure that the test script window is active Place the cursor where you want to synchronize the test. Add a blank line below the insert order statement. Place the cursor at the beginning of the blank line. Synchronize the test so that it waits for the “Insert done” message to appear in the status bar. Choose CREATE>SYNCHRONIZATION POINT>FOR OBJECT/ WINDOW BITMAP. Manually change the one second wait in the test script to a 10 second wait. Save the test Choose FILE>SAVE or click SAVE button.

Changing the synchronization setting

The default intervals that win runner wait for an application to respond to input is 10 seconds. We can add a synchronization point to solve it.

Open general option dialog box. Choose SETTINGS>GENERAL OPTION. Click the Run tab. Change the value to 1000 milliseconds Click OK to close the dialog box.

Bitmap checkpoint

WinRunner

Bitmap checkpoint

If your application contains bitmap areas, such as drawings of graphs, you can check these areas using a bitmap checkpoint. A bitmap checkpoint compares captured bitmap images pixel by pixel. Win runner captures a bitmap image and saves it as expected results. When you run the test, win runner compares the expected and actual values. If any differences are detected, you can view a picture of the differences from the test result.

Adding Bitmap checkpoint to a test script:

Start win runner and open a new test Choose PROGRAMS>WIN RUNNER on Start menu. Click NEW TEST button. Start the flight reservation application and log in. Choose PROGRAMS>WIN RUNNER>SAMPLE APPLICATION>FLIGHT 1A on the start menu. Then write your name and password in login window and click OK button. Start recording in context sensitive mode. Choose CREATE>RECORDING or click Record button Open order In the flight reservation application, choose FILE>OPEN ORDER. In open order dialog box, select the order no. Click OK to open the order. Open the fax order dialog box. Choose FILE>FAX ORDER. Enter a 10- digit fax number in the fax number box. Switch to analog mode of recording. Press F2 on your keyboard or click record button. Sign your name in the agent signature box. Switch back to context sensitive mode. Press F2 on your keyboard or click record button. Insert a bitmap checkpoint that checks your signature. Choose CREATE>BITMAP CHECKPOINT>FOR OBJECT/ WINDOW. Click the cancel button on the fax order dialog box. Stop recording. Choose CREATE>STOP RECORDING or click the STOP button. Save the test Choose FILE>SAVE or click SAVE button

Data Driven testing

WinRunner

Data Driven testing

Once the test script is created, we may sometimes want to check how the test script behaves for multiple data. This can be done by creating that many number of test cases and by running each test case individually, which is very long process. In such cases we use of data driven wizard. This involves 3 steps.

Inserting the statements to open and close the data table. Retrieving that data from the data table. Replacing the static values with the variables containing the retrieved value from the data table. This is known as parameterize the test.

Converting test to Data Driven test

Create a new test script. Run the Data Driven test. Choose TOOLS> DATA DRIVER WIZARD. Create a data table for the test. You can create a new or use existing excel table box. The data driver wizard creates an Excel table with this name. Assign a table variable name. Select global parameterization options. Select Add statements to create a data driven test. Select parameterize the test and choose line by line option. When you select parameterize the test, you instruct win runner to find fixed values in recorded statements and selected checkpoints and to replace them with the parameter. Select the data to parameterize.

Adding Data to the Data table

When you will parameterize your test, you can add the data that the parameterized test will use.

Open the data table. Choose TOOLS>DATA TABLE. Add data to the table. Save and close the table. Choose FILE>SAVE from the data table menu. Save the test Choose FILE>SAVE button.

Data driven testing tips

You can parameterize only part of your test script or a loop within it, and a single data driven test can contain more than one parameterized loop. You can open and save data tables other than default data table. This enables you to use several different data tables in one test script. You can parameterize statements containing GUI checkpoints, bitmap checkpoints and synchronization points. You can use the data table in same way as an excel spreadsheet, including inserting formulas in to cells.

You can change the active row, or read from a non active row during the test run by using TSL statements.

Rapid test script wizard

WinRunner

Rapid test script wizard

The rapid test script wizard is the fastest way of performing the test process. It systematically opens up all the windows in the application, stores the learnt information in the GUI map file and generates the test cases based on the information learnt from the application. It is possible to apply these tests only on those applications, which opens window upon performing some task. Let us take an example to apply this wizard on calculator.

Open the rapid test script wizard Choose CREATE>RAPID TEST SCRIPT WIZARD When you select the Rapid test script wizard It will display the welcome screen. Click NEXT to walk through the wizard. When you click the next button, a dialog box will be displayed, prompting you to select the application to be tested. Press the hand button and click on the main application title bar. This will capture the title of the window and display it on the ‘window name’. Click the NEXT button. Select the tests to be performed by the rapid script wizard on the application. When you click NEXT button, it asks you whether to pause before learning the next window. To pause, check the ‘Pause to confirm for each window’ checkbox. Click NEXT to proceed. Win runner now prompts you to select the learning flow. By default it is set to ‘Express’ where it learns the entire application using win runner defaults. If ‘comprehensive’ is selected, then it pauses after each window allowing you to provide the learning flow information. Click learn to allow win runner learn the application. When you click the ‘Learn’ button, it starts learning the main window of the application and displays the lists of items it has learnt by categorizing them into ‘Objects that open a window’ and ‘Objects that don’t open a window’. After it learns all the windows, it asks you whether to start this application whenever you invoke win runner. Select the default option. All the information that win runner learns about the application is stored in a file ‘myinit’. Select the location where the file has to be stored and click next button. Win runner prompts you to specify the location where the GUI regression test, user interface test and the template are to be stored. Enter some names or leave the default names. When the rapid test script wizard successfully learns all the windows in the application, it will show the last screen.

Why test failed?

WinRunner

Why test failed?

Rapid test wizard does not provide statements in the test script for closing the windows. In the preceding example, win runner opened ‘about calculator’ dialog and without closing the ‘about calculator’ dialog, it is trying to set focus to the ‘calculator’ window and as a result test fails.

To overcome this, manually you need to close the previous window before trying to open the next window. To close the ‘about calculator’ window before setting the focus on to calculator, insert the following statement:

Win_close(“About calculator”);

While learning the windows, win runner stores the images of the windows internally and creates a checkpoint for each image automatically. When the user runs the test script, if any of the window does not matched the captured image, it will give mismatch error.

Consider the ‘About calculator’ dialog box. In this dialog box the system resources may vary. While learning this window, the “system resources” was 71%, but while running, if this value changes, then win runner will find mismatch. So see whether the value of “system resources” is 71% or not. Then run the test script. It will show the result.

Program tests with TSL

When you record a test, win runner generates TSL statements in a test script each time you click a GUI object or type on the keyboard. In addition to the recorded TSL functions, TSL includes any other built in functions which can increase the power and flexibility of your tests. You can quickly add these functions to a test script using win runner’s visual programming tool, the function generator. The functional generator enables you to add TSL functions in two ways:

You can point to a GUI object and let win runner suggest an appropriate function. You can then insert this function in to the test script. You can select functions from a list. Functions appear by category and alphabetically.

You can further enhance your test scripts by adding logic. Type programming elements such as conditional statements, loops and arithmetic operators directly into the test window.

Recording a Basic test script

WinRunner

Recording a Basic test script

Start win runner and open a new test. Choose PROGRAMS>WIN RUNNER on Start menu. Click NEW TEST button. Start the flight reservation application and log in. Choose PROGRAMS>WIN RUNNER>SAMPLE APPLICATION>FLIGHT 1A on the start menu. Then write your name and password in login window and click OK button Start recording in context sensitive mode. Choose CREATE>RECORDING or click Record button. Open order In the flight reservation application, choose FILE>OPEN ORDER. In open order dialog box, select the order no. Click OK to open the order. Open the fax order dialog box. Choose FILE>FAX ORDER Click “cancel” to close the dialog box. Stop recording. Save the test.