WinRunner.info

These notes on the software functionality automated test tool WinRunner from Mercury Interactive focuses on the hardest won (but easily forgotten) insights not obvious from available documentation.

Click here for an alphabetical list of topics:   Benefits of Automated Testing Checkpoints and Checklists Configuration of WinRunner Consultants Certification in WinRunner Custom Functions Custom GUI DataJunction Debugging Aides in WinRunner Installation of WinRunner Functions Flight Sample Test Cases Logic Table Hangouts of WinRunner people Keyboard Configuration Levels of Testing Outcomes from Testing (Logic Table) Performance in WinRunner Test Results Test Assets in WinRunner Transition Testing Utilities from Third Parties Versions of WinRunner

Mercury was the ancient Roman god of merchants and thieves. The Greeks called him "Hermes dolios" — the schemer. He is also called the "winged messenger", as he is usually shown with wings on his helmet and feet, carrying a purse and caduceus (the symbol of commerce). Before he was a day old he stole Apollo's cattle.

Topics this page:

Site Map  
About this site  

Related Topics:
Data Driven Testing 
Transition Testing 
TSL Coding 
WinRunner Functions 
LoadRunner 

Company & Product Background

Among the Windows-based software products from Mercury corporation (NasdaqNM:MERQ) based in Sunnyvale, CA, with R&D in Isreal. WinRunner.com is owned by Mercury Interactive.

Scripts written to control WinRunner is called TSL (Test Script Language) It is based on C language syntax That's why function calls in WinRunner are followed by parameters within parentheses separated by commas. So if your developers only develop in Visual Basic, or ASP, then maybe you should consider Rational Robot, which is controlled with programming in VB syntax. Mercury's competitors in the automated testing market are:


Rational's Robot
Compuware's QARun
Empirix (formerly RSW) e-TEST web testing suite

TSL references logical names stored in the GUI Map. This allows one change to be used for all instances. The RapidTest Script Wizard feature of WinRunner systematically learns the properties of GUI objects as it automatically opens windows.

Winrunner is designed more for testing rich desktop and web applications, not WebForms of Microsoft's .NET applications. For that, use QuickTest first released in 1999. With version 8, Quick Test Pro can competently take over WinRunner, now considered a legacy product within Mercury.

Scripts from WinRunner can be used in LoadRunner to expose problems and predict the behavior of the system infrastructure under simulated loads of emulated virtual client users.

Quality Center (formerly called Test Director) can invoke tests remotely, according to a custom schedule when client machines have network access control set to "User Level".

WinRunner has no ties to Mercury products Topaz (which measures network performance), and SiteScope (which collects measurements on machines).

From Upside article:

Mercury Interactive
Market Share: 4
Innovation: 5
Overseas Strength: 3
Alliances : 4
Growth: 4
" One of the hottest companies in infrastructure, Mercury has taken the once mundane and obscure world of quality assurance and testing and now basically owns it. As high-profile outages such as EBay's continue to put focus on reliability, Mercury is poised to shine. It is one of the few vendors that can test and monitor not only Web systems but ERP and other back-end systems as well. We expect this Mercury to keep rising."

ADT article (June 2004)

---

See how their stock is doing in the dot.bomb economy at MSN Money Central archives

Product Version History

• Version 8.2 became available Aug 15, 2005.
• Version 8.0 became available Jan 2005, but was not very stable.
• Version 7.6 is a point release available Jan 2004.
• Version 7.5 was a major release out March 2002.
• Version 7.01 is the release sent to maintenance licensees on August 2001.
• Version 7.0 (files dated 1/2001) was made available (by request only) on March, 2001.
• Version 6.02 is needed for Windows 2000. KB article 353 says to uninstall Astra QuickTest before running this.
• Don't use Version 6.0 SP1 (2.23 MB Web.z and info.ini files) created 11/29/99. It better supports NS 4.7.
• Remember to reinstall extra add-ins such as Java. (not Webtest, VB, ActiveX)

The WebTest add-in for WR 7 has a Version of "7.0.218.0" obtained from Properties screen, Version tab for the ie4_trap.dll file is in the arch subdirectory of the WinRunner folder.

AFAIK, WinRunner costs $5495, plus $1095 for the Java add-in, more for Test Director. Maintenance fees are an additional 25% per year.

Product Usage Process Risks

Here I have adaptated what Mercury's User Guide identifies as the stages in their "WinRunner Testing Process" (1. Record, 2. Sychornoize 3. Verify 4. Run). by looking at the "real world" viewpoint of process risks to be identified and managed as early as possible:
1. Cost/Benefit — Before you plunge in, keep in mind the Real Benefits and Pitfalls of using Automated Functional Testing Products

   This involves identifying the roles (people) and their use cases to automate, including how to access the applications being automated (the boundaries of the app under test).

2. Testability — Create/update a GUI Map which provide a handle linking access to objects under test.

   The deliverable at this early point to build a complete a) list of every dialog/screen for each step in the application, for different sequences of application usage. b) list of every script file to be created.

   I've found it helpful to take screen shots pasted onto a Word Document so I can make notes and reference during discussions. There I capture the names for each object There are at least two: 1) technical name identified by WinRunner (such as "SysList32") and 2) the logical name humans use (such as "Properties Explorer window").

   Data/Keyword Driven Testing depends on consistent use of names.

   During this initial technical step, scripts are recorded and played back primarily to determine the testability of the application — to determine whether it's feasible to automate and to revise time and labor estimates in light of the revealed complexity of the automation process.

   Ask developers to insert unique "ID's" in the HTML they generate. Not only does this help gui recognition, this will make for more precise communication by avoiding confusion.

3. Reusability — Create Test Scripts referencing the GUI map and checkpoints to verify results.

   If you record scripts into small files and document them properly as you go, the scripts you generate can be quickly located and reused in the next step.

   During this step, identify user functionality you can encapsulate into stand-alone custom functions exercising your application under test. Add result verification to each script. Then create calling scripts which call several common functions in a scenario. The deliverable here is a list of scripts planned. Examples include login, inititating batch processes, etc. These custom scripts should be called by a common framework which reference spreadsheets for data-driven testing.

4. Anticipation — Debug Tests for its ability to handle known and potential conditions.

   During this step, build in your scripts the ability to handle various conditions the application might encounter, such as pop-up error and informational messages. Indent script lines to make easily apparant the script's logic in detecting and responding to various conditions.

   Test automation is as much a serious development effort as the application code, so it pays to apply the same professional disciplines as with application code — comments, code walkthroughs, checkin/checkout revision control, etc. The more quickly and reliable you have to create test code, the more discipline you need "fist time".

5. Runability — emulate user actions to make sure that verifications to determine pass or fail are complete.

   The benefits of using a framework pays off here in enabling multiple tests to be run together (overnight) with minimal human effort.

6. Usefulness — Results from tests need to both highlight issues and also provide, when needed (but only when needed), detailed information for debugging the test script and the app itself.

7. Follow-up — Report defects into TestDirector or other bug tracking system.

8. Regression — Regression tests ensure that the revised application corrects the error.

   This is usually the main reason to automate tests. However, many automated tests often fail here because of the inability to test the app in a "fixed" state. So with critical apps it may be helpful to revise application stub code that you can change to provide the anticipated response after the app is change.

Automated Web Testing Toolkit : Expert Methods for Testing and Managing Web Applications by Stottlemyer, Diane. (New York: John Wiley & Sons, Inc., 2001)

Installation Preparations

Don't Use ATI Video Cards

Text recognition may not work correctly for ATI display adapters.

Login as Administrator

If you're using Windows NT4, login as a user with administrator permissions to install WinRunner.

Don't Let Stalkers Bother You

Disable programs silently lurking in the background to disrupt your installation:
• Screen Savers (especially since OpenGL 3D cuties intermittantly take up a lot of CPU cycles)
• Anti-Virus (McAfee).
• ADSI, which might shut things down automatically.

Get Y2K Compliant

Go to Settings> ControlPanel> RegionalSettings> Date and make sure the four digit year (i.e. M/D/YYYY) is selected. Anything else messes up the time_str( get_time() ); function.

You Gotta Have One

According to WR User Article 305: Before installing WR, make sure you have a C:\Temp folder created.

WinRunner's Registry Entries

WinRunner installation adds keys under the registry key path HKEY_LOCAL_MACHINE\ Software\ Mercury Interactive\ WinRunner\ mainly to expose CurrentVersion information for Installed Components.

When a user changes checks "Allow Test Director to run remotely" from the Environment tab under menu item Settings -> General Options, WinRunner updates the RemoteExecutionEnabled variable of sub-key Integration .

CLASSPATH for Java Add-In

Add a CLASSPATH to Winrunner Java classes in registry key
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Java VM

MSIE Browser Not Helping WR?

From david.weinstein
If you're starting MSIE from within WR and IS is still not recognized, shut them both down, run regedit, locate Registry Key "Browser Helper Objects" from path: HKEY_LOCAL_MACHINE\ SOFTWARE\ Microsoft\ Windows\ CurrentVersion\ Explorer\ Browser Helper Objects and rename it to "Browser Helper Objects.old".

Operating System Files Change Tracking

WinRunner reports the version number and names of all system files it installs or replaces within file misyslog.txt under the dat\ subdirectory of the WinRunner installation folder. It reports the version number of the new (and old, if replaced) files.

Invocation

Start the application under test from within winrunner. This is crucial when doing web testing using internet browsers.

Most people inovke WinRunner by clicking
Programs > WinRunner > WinRunner which opens the wrun.exe program within the arch folder under the folder where WinRunner was installed, which is by default

c:\Program Files\Mercury Interactive\WinRunner

In v7.6 (for whatever reason) WinRunner limits its search path string size to 1024 characters (including drive letters, colons, and slashes — but not the < > angle brackets.)
So just because of this, you may have to install WinRunner in a folder such as "WR76" or "WR82". Before that, try to using the short 8.3 equivalent name with no spaces:

c:\PROGRA~1\MERCUR~1\WINRUN~1

Thus, WinRunner can be started from a batch script from a command prompt, such as:

set doscript="as2"
"c:\PROGRA~1\MERCUR~1\WINRUN~1\arch\wrun.exe" -t "start_tests" -run -f "C:\WINDOWS\wrun.ini"

Rather than hard-coding your search path, specify the win.ini file, which contains the search path used when WinRunner is invoked interactively.

Notice that in the search path each item is surrounded by < > angle brackets and has \\ double slashes between folder levels.

While debugging, consider adding these switches

-def_replay_mode debug -dont_show_welcome -animate -dont_quit

If WinRunner can't startup, it will write out a message to the wrstderr (WinRunner Standard Error) file in folder C:\Documents and Settings\UserID.MGC\Local Settings\Temp\. Here's a DOS batch file using an environment variable to retrieve this file:

cd \
echo %username%
notepad.exe c:\DOCUME~1\%username%\LOCALS~1\Temp\wrstderr
pause

As a precaution

Recovery from WinRunner Crashes

WinRunner operates in these Windows processes:

Image Name		Mem Usage	v7.6 File Bytes	v8.2 File Bytes
	wrun.exe (with no scripts loaded)	18,420 K	4,157,490	4,628,530
	crvw.exe (WinRunner Record/Run Engine)	7,956 K	802,865	815,153
	MDM.EXE (Microsoft Windows Machine Debug Manager) startup program (not a Task Manager process)	3,600 K	-	-
	NTVDM.EXE (six_agnt.exe and wowexec.exe)	3,416 K	-	-

If WinRunner crashes and you don't want to reboot, press Ctrl-Alt-Del, select the Task Manager, click Processes Tab, Image Name. Then click on each of these processes (if they exist) and click "End Process" on each of the above. This should solve this error message in file wrstderr:

Error: open connection to CRV (-1). Exiting...

Exit WinRunner Often

WinRunner automatically creates a ".BAK" copy of script files it opens for editing. Save operations do not update this ".BAK" file. If WinRunner crashes, it will replace the current version of script files with their ".BAK" version.

So exit WinRunner after you make a lot of changes to avoid getting them wiped out.

Zip up your script directory before you open your script after a crash. It's a good idea to archive versions. Rename each file with a sequential number. Move them to an "arc" folder if you don't want to see them.

wrun.ini WinRunner Initialization File

The installer creates the wrun.ini file in folder c:\WINDOWS for Windows XP and C:\WINNT for Windows NT/2000 servers.

If the wrun.ini file is deleted, WinRunner recreates it automatically with default settings.

So if WinRunner is operating weirdly, one thing to try is to shut down WinRunner, delete the wrun.ini file, then re-start WinRunner.

WinRunner can be started from a DOS batch file or a DOS/WSH script file such as:

SET M_ROOT="C:\Program Files\Mercury Interactive\WinRunner" 
%M_ROOT%\arch\wrun.exe -ini C:\WINDOWS\wrun.ini -update_ini

The M_ROOT path should change if WinRunner has been installed to another location.
C:\PROGRA~1\MERCUR~1\WINRUN~1 is the short path.

The -update_ini opens the file file for update. Otherwise, the .ini file is read-only. There are many other run parameters

Specify a different set of parameters for each project. To consolidate all files relevant to that project, copy the C:\Windows\wrun.ini to your own project folder (such as C:\WRProj1), then startup WinRunner with

wrun.exe -ini C:\WRProj1\wrun.ini

This tells WinRunner to open with settings in the wrun.ini file within folder C:\WRProj1.

Grouping	Run Parameter	Getvar/ Setvar	Description
Startup	-f <filename> -D|-E		Specifies a text file containing command line options. The options can appear on the same line, or each on a separate line. This option enables you to circumvent the restriction on the number of characters that can be typed into the Target text box in the Shortcut tab of the Windows Properties dialog box. Entries in this file override the command line.
	-app <app_name>
	-app_params<app_params>
	-app_open_win <app_open_win>
	-ini <wrun.ini path>		Specifies the location of the wrun.ini file, if different than C:\WINDOWS or C:\WINNT.
	-update_ini
	-t <testname>	"testname"	Specifies the name of the test to be loaded in the WinRunner window. This can be the name of a test stored in a folder specified in the search path or the full pathname of any test stored in your system.
	-run		Instructs WinRunner to run the test loaded with the -t command.
	-run_minimized | -animate		-animate instructs WinRunner to execute the loaded test, while the execution arrow displays the line of the test being run.
	-start_minimized <on|off>
	-batch <on|off>	"batch"	Displays whether a test is running in batch mode. In batch mode, WinRunner suppresses messages during a test run so that a test can run unattended. WinRunner also saves all the expected and actual results of a test run in batch mode in one folder, and displays them in one Test Results window. Possible values: on, off (text strings)
	-silent_init	"silent_mode"	Displays whether WinRunner is running in silent mode. In silent mode, WinRunner suppresses messages during a test run so that a test can run unattended. When you run a test remotely from Quality Center, you must run it in silent mode, because no one is monitoring the computer where the test is running to view the messages. Possible values: on, off (text strings)
	-invisible
	-addins <addins>
	-tslinit_exp <folder>		Directs WinRunner to the expected folder to be used when the tslinit script is running.
Run modes	?	"runmode"	Displays the current mode text string (verify, debug, or update)
	-def_replay_mode <verify|debug|update>		The default script run mode.
	-verify <result>		Overrides default and run the test in Verify mode and storing results in the designated subfolder.
	-WR_wait_time <wr_wait_time>		the number of milliseconds to wait between invoking the application and starting WinRunner. (Default = 0 [milliseconds])
	-speed <normal|fast>	"speed"	Sets the default run speed for tests run in Analog mode. Possible values: normal, fast (text strings) Setting the speed to normal runs the test at the speed at which it was recorded. Setting the speed to fast runs the test as fast as the application can receive input.
	-delay <time>
	-delay_msec <time-miliseconds>	"delay_msec"	Sets the sampling interval (in milliseconds) used to determine that a window is stable before capturing it for a Context Sensitive checkpoint or synchronization point. Instructs WinRunner to determine whether a window is stable before capturing it for a bitmap checkpoint or a synchronization point during a test run. To be declared stable, a window must not change between two consecutive samplings. This sampling continues until the window is stable or the timeout (as set with the timeout_msec testing option) is reached. For example, when the delay is two seconds and the timeout is ten seconds, WinRunner checks the window in the application under test every two seconds until two consecutive checks produce the same results or until ten seconds have elapsed.
	-time_diff <time diff>
	-exp <expected>	"exp"	Displays the full path of the expected results directory associated with the current test run. (getvar only)
	-rec_item_name <on|off>		Determines whether WinRunner records non-unique ListBox and ComboBox items by name or by index.
	-dont_quit		Instructs WinRunner not to close after completing the test.
LoadRunner	-vuser <vusernum>
	-scenario <scenarioid>
	-sgroup <sgroupname>
	-masterhost <hostname>
	-masterprogn <prognum>
	-mastervern <vernum>
	-masterstdport <portnum>
Output	-create_unirep_info <on|off>		Generates the necessary information for creating a Unified Report (when WinRunner report view is selected) so that you can choose to view the Unified Report of your tests at a later time.
	-create_text_report <on|off>
	-wr_exception_file <filename>
	-web_exception_file <filename>
	-report_view <winrunner|unified>
	?	"result"	Displays the full path of the verification results directory associated with the current test run. This option has no default value.

Welcome Screen Settings

When WinRunner starts up for the first time, it asks whether you want to create a new script or open an existing script.

Uncheck "Show on startup" because most people open existing scripts to edit rather than starting with a new blank script.

Such action is saved in the [WrEnv] section within the wrun.ini file as entry

ShowWelcome=0

"0" usually means "FALSE" or "NO" or "OFF".
"1" usually means "TRUE" or "YES" or "ON".

This setting can be changed later within WinRunner's GUI toolbar Tools > General Options > General > Startup dialog:

Exit WinRunner after changing any setting because the wrun.ini file is saved to the hard disk only when WinRunner exits.

This setting in the wrun.ini file can be overridden with the wrun.exe invocation program command flag

-dont_show_welcome

Add-In Initialization

When WinRunner starts up for the first time, it asks you which addins you want to load.

Add-in's are what enables WinRunner to recognize and manipulate non-standard objects (classed as text labels, edit fields, list boxes, push buttons, radio buttons, scroll bars, tool bars, etc.) within applications developed using ActiveX, Visual Basic, PowerBuilder, and other utilities.

Each add-in selected during start-up result in the execution of some TSL script in the lib folder where WinRunner was installed:

Add-in	Script	Note
ActiveX controls	oleinit
PowerBuilder	pbinit, oleinit
Visual Basic	vbinit, oleinit	uses ole_ifs.dll
WebTest	webinit	WebTest Add-in
Delphi	dlphinit
Java	java_supp	Java Add-in
Oracle (Applications)	orainit0
Oracle (Developer 2000)	orainit
Siebel	sbl_init
Terminal Emulator	te_init
Year 2000	y2k_init
WRSAFS Components	wrsafsinit

Add-ins on Startup

You can create your own (such as WRAFS did) by following the Customization Guide. But the standard WinRunner installation comes with several "additional support" "hooks" to the operating system:

Selections are stored in the [Wrcfg] section as entry

ADDONS=ActiveX,PB,VB,WebTest,WRSAFS

Uncheck "Show on startup" unless you will be constantly switching among development platforms.

Such action is saved in the [Wrcfg] section within the wrun.ini file as entry

ADDONS_SELECT_TIMEOUT=0

This setting in the wrun.ini file can be overridden with the wrun.exe invocation program command flag

-addins_select_timeout <time>

Only install the add-ins you need.

Add-in Conflict help lists the initialization script for each add-in.

TSL Start

WinRunner begins by silently executing (in the background) scirpt
%M_ROOT%\dat\tslinit

This script populates its m_root global variable by reading the M_ROOT environment variable with function call getenv("M_ROOT");

This information is used to run initialization scripts from the lib folder under the m_root.

wr_gen initilizes external variables which are prepended with an underline.

tslinit also runs an initialization script for each add-in from For example:

• "webinit" is run for the Web add-in.
• For the Visual Basic, add-ins oleinit and vbinit are run, which loads "vblib32".

Don't modify these scripts because they will be replaced whenever Winrunner is installed.

Startup Script

There are several ways to specify the custom script that WinRunner starts.

In Tools > General > Startup

Such action is saved in the [Wrcfg] section within the wrun.ini file as entry

XR_TSL_INIT=

Tools > General Settings

Here is a cross-reference of WinRunner settings in the GUI, the wrun.ini file, run command option, and getvar/setvar:

Tree		Item	Section	Key	Value		Run Parameter (getvar/setvar)	Note
					Default	WRSFAS
General		Back up test script automatically every __ minutes	[WrCfg]	TEST_AUTOSAVE=	10	5	-auto_save <minutes>
		Enable date operations	[WrEnv]	DATE_OPERATIONS=	blank	1=checked	n/a
		Global GUI Map file	[WrCfg]	GUI_BUF_PER_TEST=	1=selected	0=unselected	-gui_buf_ per_test <on|off>
		GUI Map file per test	[WrCfg]		0=unselected	1=selected
		Load temporary GUI map file	[WrCfg]	XR_AUTO_LOAD=	TRUE=selected	1=selected	-auto_load <on|off>	[1]
		Keyboard file:	[WrCfg]	XR_INP_KBD_NAME=	-	%M_ROOT%\dat\win_scan.kbd
Folders		Temporary files:	[WrEnv]	TMP=	-	c:\Temp	("tempdir")
		Temporary GUI map file:	[WrCfg]	XR_AUTO_LOAD_DIR=	-	%M_ROOT%\tmp	-auto_load_dir <path>
		Shared Checklists:	[WrCfg]	XR_SHARED_CHECKLIST_DIR=	%M_ROOT%\chklist	-	("shared_checklist_dir")	[2]
		Documentation files:	[WrEnv]	DOCUMENTATION_DIR=	-	%M_ROOT%\doc\books
		Search path for called tests:	[WrCfg]	XR_SEARCHPATH=	-	<.><%M_ROOT%\lib>	-search_path <path> ("searchpath")
Record	Script Format	String indicating that what follows is a number:	[WrCfg]	HL_LIST_ITEM_ SEPARATOR_STRING=,			("List_item_separator")	[5]
		String for separating Listbox or ComboBox items:	[WrCfg]	HL_LISTVIEW_ITEM_ SEPARATOR_STRING=,			("ListView_item_ separator")	[5]
		String for separating ListView or Treeview items:	[WrCfg]	HL_ITEM_NUMBER_STRING=#			("item_number_seq")	[3]
		String for parsing a TreeView path:	[WrCfg]	HL_TREEVIEW_PATH_ SEPARATOR_STRING=;			("TreeView_path_ separator")	[3]
		Script Readability Insert comments and indent statements	[WrCfg]	TEXT_INDENTATION=	1=selected		-text_indentation <on|off>
		Generate concise, more readable 'type' statements	[WrCfg]	XR_KEY_EDITING=	TRUE	0=unselected	("key_editing")
	Text Recog- nition	Use driver-based text recognition	[WrCfg]			blank=checked		[2]
		Timeout for Text Recognition: msecs	[WrCfg]	XR_TEXT_ RECOGNITION_ TIMEOUT=	500
		Use image-based text recognition - Font group	[WrCfg]	XR_FONT_GROUP=	stand		-fontgrp <groupname> ("fontgrp")
		Insert comment containing recognized text	[WrCfg]	XR_TEXT_REMARKS=	TRUE =checked	1=checked
Run	Settings	Timeout for checkpoints and CS statements:	[WrCfg]	XR_TIMEOUT=	10000	5000	-timeout_msec <time-miliseconds> ("timeout_msec") formerly -timeout <time> ("timeout")	[4]
		Threshold for difference between bitmaps:	[WrCfg]	XR_MIN_DIFF=	1000	0	-min_diff <threshold> ("min_diff")
		Beep when checking a window	[WrCfg]	XR_BEEP=	checked	checked	-beep <on|off>
		Fail test when Context Sensitive errors occur	[WrCfg]	CS_FAIL=	0=unchecked	0=unchecked	-cs_fail <on|off> ("cs_fail")
		Fail test when single property fails	[WrCfg]	SINGLE_PROP_CHECK_FAIL=	1=checked	0=unchecked	-single_prop_ check_fail <on|off> ("single_prop_check_fail")
		Break when verification fails	[WrCfg]	XR_MISMATCH_BREAK=	TRUE	FALSE	-mismatch_break <on|off> ("mismatch_break")	[3]
		Capture bitmap on verification failure	[WrCfg]	XR_CAPTURE_BITMAP=	0=unchecked	0=unchecked	-capture_bitmap <on|off> ("capture_bitmap")
			[WrCfg]	XR_CAPTURE_BITMAP_TYPE=	0=Window	1=Desktop
	Syn- chron- ization	Delay for window synchronization:	[WrCfg]	XR_RETRY_DELAY=	1000	0
		Delay between execution of CS statements:	[WrCfg]	XR_CS_RUN_DELAY=	0	0	-cs_run_delay <miliseconds> ("cs_run_delay")
		Timeout for waiting for synchronization message:	[WrCfg]	XR_SYNCHRONIZATION_TIMEOUT=	2000	0	("synchronization_ timeout")
		Drop synchronization timeout if failed	[WrCfg]	XR_DROP_SYNC_TIMEOUT=	TRUE=checked	0=unchecked	<on|off> ("drop_sync_timeout")	[1]
		Beep when synchronization fails	[WrCfg]	XR_SYNC_FAIL_BEEP=	-	0=FALSE	("sync_fail_beep")
	Email
Noti- fica- tions		Activiate e-mail service	[WrCfg]	XR_EMAIL_SERVICE=	FALSE	1=TRUE	-email_service <on|off> ("email_service")
		Mail Server Server address:	[WrCfg]	-	-	-
		Mail Server Port:	[WrCfg]	XR_EMAIL_SVR_PORT	25	25
		Use authentication	[WrCfg]	XR_EMAIL_AUTH	FALSE=0	0=FALSE

[1] Some values are set at "TRUE" when WinRunner establishes the defaults, but become "1" (which also means TRUE) when the value is changed within WinRunner.
[2] Some values are set at blank and filled in with a default value when other fields in its dialog change value.
[3] Some values begin as "FALSE" and stay in "FALSE" (or begin as "TRUE" or switch to "TRUE").
[4] An exception (bug?): WinRunner 7.6 is storing "Timeout for checkpoints and CS statements" as "FALSE".
[5] This is not created in wrun.ini until a change is made in any field in its screen within Tools > General Options.

Getvar & Setvar

Grouping	Getvar/Setvar Parameter	Description
-	("curr_dir")	Displays the current working directory for the test. (getvar only)
	("enum_descendent_toplevel")	Records actions on the child windows in MDI applications. Possible values: 1,0
	("line_no")	Displays the line number of the current location of the execution marker in the test script.
	("rec_owner_drawn")	Maps all owner-drawn buttons to a standard button class (push_button, radio_button, or check_button), since WinRunner cannot identify the class of owner-drawn buttons and automatically maps them to the general "object" class text strings (object, push_button, radio_button, check_button)

"Hidden" Settings

Several settings in the Win.ini cannot be accessed by a GUI nor programmatically with getvar/setvar:

Test Report User Name

To change the User Name appearing in Test Reports: Open the wrun.ini file and add this under the [WrEnv] section:
LOGname=Bozo

WinRunner needs to be restarted for this to take effect.

Positions from Previous Session

WinRunner is kind enough to invoke itself with the same state that you were in when you exit the program. So it remembers these settings:

Setting	Section	Value in wrun.ini
WR main Window position	[WrWin]	WrX=374 WrY=181 WrMax=1 if maximized
	[GuiEditor]	Left=311 Right=937 Top=-13 Bottom=419 VIEW=0 DESC=1 EXPAND=1 HIGHLIGHT=1 FILTER_NAME_FLAG=0 FILTER_DESC_FLAG=0 FILTER_CLASS_FLAG=0 FILTER_NAME_STRING= FILTER_DESC_STRING= FILTER_CLASS_STRING=
Watch List window position	[WatchList]	Left=0 Right=227 Top=0 Bottom=245
	[GuiVer]	Left=375 Right=961 Top=169 Bottom=479 HIGHLIGHT=1 LARGE_TBAR=1
	[UserBar]
	[SpyDlg]	Left=884 Right=1275 Top=5 Bottom=652 AllAttr=0 SpyOnWin=1

If you have multiple monitors, put the WinRunner Editor window on the right monitor. If you forget to move and save the position, change the win.ini and restart WinRunner.

Internal Limits

WinRunner has defaults which can be overridden by adding an entry in win.ini. Internally, the WinRunner program looks for these settings in win.ini, but uses internal defaults if they have not been added.

Section	Value in wrun.ini	Description
[WrCfg]	MAX_ARR_SIZE = 5000	Defines the maximum number of entries WinRunner allocates for arrays such as its Watch list.

Start-up Debugging

Delete Header files upon error

If you get a "header file error" when opening a script file from another time/machine, delete the files named "header" and "lock". WinRunner automatically re-creates them.

Delete Lock files after lockup

WinRunner locks a script when it is not exited normally. To remove a lock, use Windows Explorer to open the script's folder and manually delete the file named lock.

Physical storage

The syntax of coding to control WinRunner execution is called TSL (Test Script Language)

All TSL code are physically stored in a file always named "script" with no file extension.

The name specified to save TSL code from within WinRunner is used to create a folder with that name.

Functions

The standard functions described in Mercury's TSL Reference Guide and WinRunner User Guide are automatically compiled and loaded into memory when WinRunner starts.

All functions written by users of WinRunner are custom functions.

Compiled TSL code must be organized into functions so that they can be referenced by other TSL statements. Example of TSL code to create a function:

private function func1( in parm1 )
   print( parm1 );
   return(rc);
}

Example of TSL code to reference a custom function with no parameters:

app_close_windows();

WinRunner Guide by Matt Crump and Ivan Maclaine of Qualtech-int in Australia.

WinRunner 7 In A Hurry! Software Test Automation With WinRunner by consultants Thomas Messerschmidt, Mark Harbin of WinRunner In a Hurry.com and 213-810-2589

Java Applications and Applets
Testing Guide.

Main vs. Compiled Modules

Unlike C or Java which require users to perform a separate compilation step using a separate program, you make a Winrunner script module “Compiled” by changing the file's Test type property from the File Properties screen shown at right. Winrunner performs a pre-compilation automatically when it saves a module assigned a property value of “Compiled Module”.

By default, modules containing TSL code have a property value of "main". Main modules are called for execution from within other modules. Main modules are dynamically compiled only when WinRunner recognizes a "call" statement such as:

call cso_init();

call( "C:\\MyAppFolder\\" & "app_init" );

Compiled modules are loaded into memory to be referenced from TSL code in any module:

reload( "C:\\MyAppFolder\\" & "flt_lib" );
or

load( "C:\\MyAppFolder\\" & "flt_lib" );

If during a load command you get the message "The line is too long to be displayed", open the script and check for recent changes, usually misplacement of parentheses, braces, quotes, and other special characters. Try removing all lines within each function (one at a time) to identify. You can also run "c lint" programs to identify indentation.

The edit_set function can work with up to 1020 characters into an edit field. However, the WinRunner screen editor will only work with lines that are a maximum of 253 characters.

Recording Tips

• The most annoying default is Mercury's assignment of the key "F2" to begin recording. Assign a different key, or you'll be ruining scripts and debugging "ghost" code.

• In General Option Run Settings "Timeout for checkpoints and CS statements" default of 10000 (10 seconds) is waaaay too long. You'll save a lot of waiting around if you put it at 500 (half a second).

• Remove code that gets captured when you click on the toolbar to get back to WinRunner.
  set_window ("Shell_TrayWnd", 2);
  toolbar_button_press ("ToolbarWindow32_0", ...

Keyboard Configuration

Introduction: Don't Get Mousey

Get in the habit of controling script execution by pressing softkeys on the keyboard (listed below) rather than clicking the mouse. Some scripts commands assume that the cursor is placed at a certain spot and it won't execute properly if you're moving the mouse around at the same time.



Change Default SoftKey Assignments

Here are several reasons why you may want to configure your own keys to control WinRunner. The default settings for WinRunner keyboard mappings to desired actions can be changed from menu Settings, Editor Options, Key assignments. Alternately, run command softtkey

Rather than having to use both hands to press a combination key (such as Ctrl-F3 to stop execution), you may prefer pressing just a single function key. Before you ask "How lazy can you get?" realize that you want to be able to quickly stop a script that's goes wildly out of control.

By default, WinRunner uses the F2 key to initiate "Record". So if you edit Excel formulas or file names in Windows Explorer while you have WinRunner stopped, you'll probably be inadvertantly recording every keystroke you make. This will corrupt whatever script and gui map you have open in WinRunner.

So how about reassigning the key to LoadRunner's default of Ctrl+R?

Key Assignments Inconsistent

Mercury did not coordinate the assignment of softkey defaults among its WinRunner and LoadRunner products. Mercury's assignments are also not consistent with other popular developer tools:

Debugger Action	WinRunner default	LoadRunner default	MS6 Script Debugger	MS.NET Debugger	Eclipse
Set/Toggle Breakpoint To set a breakpoint, point your mouse to the grey number on the left panel and right-click for the red hand. To remove a breakpoint, right-click again on the red hand.	F9	F9	F9	Ctrl+B	...
Run from Top — from the beginning of the current script until the end of the script.	LeftCtrl + F5	F10	...	F5	...
Run from arrow on the left grey bar until the end of the script.	LeftCtrl + F7	...	Ctrl+Shift+F8	...
Step (Over) — run from arrow on the left grey bar. Stay on current function which executes and then returns.	F6	F10	Shift+F8	F6	...
Step Into function called by the current statement.	LeftCtrl + F8	...	F8	F11	...
Step to Cursor — from last line executed to the insertion point. Not available when the icon is greyed out (disabled).	LeftCtrl + F9	...	...	Ctrl+F10	...
Pause after statements have executed.	Pause	Pause	...	...
Stop immediately.	LeftCtrl + F3	Ctrl+F5	...	Shift+F5	...

WinRunner differentiates between left and right Alt and Ctrl keys.

Action	Default key
Test Results window	RightAlt+F8
Move between panes	F6
Undo	Ctrl+Z
Redo	Shift+Ctrl+Z
Delete current line	Ctrl+Y
Indent	Ctrl+K I
Un Indent select block	Ctrl+K U
Print from selection	Ctrl+K P
Goto Bookmark 9	Ctrl+Q 9
Set   Bookmark 9	Ctrl+K 9
Move Locator	Alt 6
Insert Function from Function Generator	F7

By default, no key is assigned to “Sychronize Bitmap and Location of Window".  So map it to something by using WinRunner utility softkey.exe from the Programs menu where WinRunner is invoked. This program updates wrun.ini .

Data Configuration

WinRunner automatically creates a folder when it saves a new script. Each script folder has these sub-folders:

• a db folder for asc data.

• an exp folder for expected results.

• a debug folder for using during debug runs.

A Separate Folder For Each App

Creating a separate folder for the application under test helps to avoid work on one application impacting other applications. Save scripts under this folder.

This also ensures portability of test assets to other machines.

.

Font Expert

If your AUT uses the Modern, Roman, or Script fonts, you need to first learn them using Font Expert or WinRunner's Text Recognition feature cannot identify them.

.

Data Conversion

• The Data Junction product mentioned in the WinRunner User Guide is a data conversion product from DataJunction.com of Austin, Texas. Download a trial software. Read IDG's Product Evaluation dated May 4, 1998

• The maximum number of records that can be imported into a WinRunner Data Table is 16,384 rows.

• WinRunner has problems processing Excel files which contain more than one sheet.

• A default check treats as an error any difference in the value of data Content or in the ColumnsCount and RowCounts between the expected and results set. Custom checks allow you to select specific properties examined.

.

Test Results

This explains the source of event names on Test Results reports WinRunner generates.

Event	Source of info
start run	Automatically added with the name of the script in Details column and "run" in the Results column.
stop run	Automatically added with the name of the script in Details column and "pass" or "fail" in the Results column.
context sensitive error	Automatically generated when an item is not found in the GUI map or in the application.
User Message	report_msg() function
tl_step	tl_step() function

Some prefer to read the plain-text version of this in the Results.txt file WinRunner generates. But there you can't click on the "Show TSL" icon (after a specific line is highlighted) to open the TSL script file at the line number indicated.



If you press an up/down cursor key (or a wheel mouse) when this dialog first appears, rather than scrolling lines on the page, you will scroll from "debug" to "exp" and other result folders (which are from previous runs). So click on a line first before scrolling.

.

Quality Center

Formerly Test Director.

Quality Center (Test Director)	-dont_connect	Opens WinRunner without connecting to Quality Center, if the Reconnect on startup check box is selected in the Connection to Quality Center dialog box.
	-td_log_dirname <path>
	-td_connection <on|off> ("qc_connection")	Displays whether WinRunner is currently connected to TestDirector. (Formerly td_connection or test_director.)
	-td_server_name <server name> ("qc_server_name")	Displays the name of the Quality Center server to which WinRunner is currently connected. (Formerly td_server_name)
	-td_database_name <database name> ("qc_database_name")	Displays the name of the Quality Center project database to which WinRunner is currently connected. (Formerly td_database_name)
	-td_cycle_name <cycle name> ("qc_cycle_name")	Displays the name of the Quality Center test set (formerly known as "cycle ") for the test. (Formerly td_cycle_name or cycle .)
	-td_user_name <user name> ("qc_user_name")	Displays the user name for opening the selected Quality Center database. (Formerly td_user_name or user)
	-qc_password <password> formerly -td_password <password>	Specifies the password for connecting to a database in a Quality Center server.
	("qc_test_instance")	Displays the instance of the test that is currently opened and running in the Quality Center test set.
	("qc_test_run_id")	displays the run name of the test that is currently opened and running in the Quality Center test set.

[TestDirector]
TDAllowLocalDB=1
ReconnectToServer=0
ReconnectToDB=0
ReconnectOnStart=1
UsePasswordOnStart=1

Advisor & User Group Hangouts

• Free advice: Join the Winrunner maillist started by Software Quality Partners and moderated by Ellen Gallant using the eGroups ONEList system to receive a daily dose of messages from contributors (at the risk of also exposing your email address to junk mailers).

• QA Forums.com hosts an active community with a feature-rich system. They also offer a self-study CBT on WinRunner.

  Party! Worldwide Users Conferences are usually held in Orlando in October. The next one is in Vegas, no longer at the Dolphin Hotel in Disneyworld Florida. If you submit a paper by June 30, you get your $1495 ticket free. from Sarah Petersen at spetersen@mercury.com or 650.603.5440. If you Register early, you get $200 off.

  Local user groups

Consultants: Fee Based Offerings & Jobs

• Shawn LoPorto of Automated Solutions offers WinRunner Training.
• Echo Solutions from New York City.
• Tech South
• GlobalTester
• Proha (formerly Intellisoft) based in Finland and affiliated with Artemis in the US
• Automated Solutions, Inc. from Englewood, CO
• Test Force in New York City.
• PowerTest
• AJ Alhait's Betasoft.com has forums, downloads, and a Career center for QA pros.
• Rick Hower's Software QA Test.com website has QA FAQs and links.

Mercury Product Certification

In March, 2003, Mercury unleashed its CPC (Certified Product Consultant) certification program to weed out all but those with lots of money. Candidates now pay $2,500 for a one-day live exam at a Mercury training office, up from $500 to (within 3 months) fill out (at home by hand) a 80+ page paper CPS (Certified Product Specialist) form.

Mercury's CPS certification program is, the last time I checked, managed by Franz Obermeier (rather than Simran Atwal or Wendy Perilli) in Sunnyvale at 408.822-5579 (fax 822-5517).

Mercury's Certification FAQ

Mercury's Full Certification Policy