Mercury WinRunner FAQ

Part:   1  2  3  4  5  6  7  8  9  10  11  12  13  14  15  16  17  18  19  20  21  22  23  24  25  26  27  28  29  30  31  32  33  34  35  36  37  38  39  40  41   42  43  44  45 

WinRunner: Web sites contain Java applets

If your web sites contain Java applets, you need to install Java add-in support for WinRunner.

WinRunner: To Record the Web Application

Recommendation: Set your browser to accept cookies. This will prevent a pop up window asking about the cookie from interfering with your script.

WinRunner: Steps to take before recording:

. Before starting to record, you should close all applications that are not required for testing. (Mail, Explorer, Screen Savers, CD Player etc).
. After installing a new version of Test Director and WinRunner, it is a good idea to make a back up copy of the following ini files to another location(testers choice of location). This is recommended to allow the tester to easily reset their WinRunner/TestDirector environment in the event of system corruption.
c:\windows\wrun.ini
c:\windows\mercury.ini
c:\~\TestDirector\bin\td.ini
c:\~\TestDirector\bin\filters.ini
c:\~\TestDirector\bin\forms.ini
c:\~\TestDirector\bin\grids.ini
c:\~\WinRunner\dat\ddt_func.ini
. Make sure your system is set up with all the necessary library functions that have been created.
. Make sure you create a GUI map and font group for each project.
. In the tsl_init file add the command GUI_close_all();. This command will make sure that no GUI maps are loaded when you bring up the WinRunner application. The benefit of this approach is that it will force the tester to load the correct GUI map for their testing, thus preventing scripting errors and other complications.

WinRunner: Libraries Needed for automation:

A number of libraries have been created to aid in the automation projects. Below is a list of the libraries that should be installed on each individual machine.
. csolib32 - This is a library full of many useful functions. This library was created by Mercury Customer Support and can be found in the following zip file csolib.zip. In order to access the library functions, the tsl_init file needs to be modified to run the cso_init file (which will load the libraries when the WinRunner application boots up).
. WebFunctions - This is a library contains functions designed to run on the YOUR-COMPANY Web systems.

WinRunner: Commands and Checkpoint Verification information for Web:

. Must do a set_window(); command for each action on a new window, this will assist the script in recognizing/resetting the window state and help prevent scripts failing due to slow network/system performance.
. Must add report_msg or tl_step command after each test to record what happens in the test.
. A obj_check_qui statement checks only one object on the window, and win_check_qui statement checks multiple objects in the window.
. The single property check allows you to check a single property of an object. The single property check dialog will add one of the following functions to your script.
button_check_info
edit_check_info
list_check_info
obj_check_info
scroll_check_info
static_check_info
The Object/Window check allows you to check every default object in the window. After it has completed it inserts an obj_check_gui statement in your script.
The Multiple Objects check allows you to check two or more objects in the window. This selection works best, because it first brings up the checkpoint window, then after the user selects add you can navigate to the AUT. Also, for some reason, the data in the object is retrieved with this feature but not the object/window check. After it has completed it inserts a win_check_gui statement in your script.
. There are 3 main types of GUI checks you can do with WinRunner. Single Property and Object/Window checks, and Multiple Objects.
. There are 35 Web functions, that come with the web test add-in. For the full list please see the TSL reference guide. The table below lists the most commonly used functions.

WinRunner: How to Structure tests for Web:

Create Begin and End Scripts. This will ensure that WinRunner starts and stops from the same place.
. Mercury recommends that it is better to use smaller specific GUI maps for your testing than have one large GUI map that encompasses your whole application.
. Comment all major selections or events in the script. This will make debugging easier
. Need to create a init script to load correct GUI map, font group and set option variables.
A few of the options you should set are:
# Turns off real time error message reporting if the test case
# fails. The error is still logged in the test results window.
setvar ("mismatch_break", "off");
# Turn off beeping
setvar ("beep", "off");
setvar ("sync_fail_beep", "off");
# Make sure context sensitive errors don't trigger real time
# failures that stop the script. The error is still logged in the
# test results window.
setvar ("cs_fail", "off");
# Sets time winrunner waits between executing statements
# (Mercury default is 0)
setvar ("cs_run_delay", "500");
# Sets time winrunner waits to make sure window is stable
# (Mercury default is 1000)
setvar ("delay_msec", "500");
# Sets the fail test when single property fails to uncheck (bug - recommend set to un-check) setvar ("single_prop_check_fail", "0");
. Determine all paths to start up directory and then set them in the options window.
. In your closing/ending scripts use the GUI_unload_all command to unload all GUI maps in memory.

Part:   1  2  3  4  5  6  7  8  9  10  11  12  13  14  15  16  17  18  19  20  21  22  23  24  25  26  27  28  29  30  31  32  33  34  35  36  37  38  39  40  41   42  43  44  45