Anda di halaman 1dari 6

Company & Product Background

Among the Windows-based software products from Mercury Interactive corporation


(NasdaqNM:MERQ) based in Sunnyvale, CA 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, ASP, or Microsoft language, then I suggest that you forget
about WR and get Rational Robot, which is programmed with VB syntax. It's too
much hassle for the little advantage WR provides.
TSL references logical names stored in the GUI Map. This allows one change to be
used for all instances. The RapidTest Script Wizard systematically learns the
properties of GUI objects as it automatically opens windows.
Scripts from WinRunner can be used in LoadRunner, a tool used to expose problems
and predict the behavior of the system infrastructure under simulated loads of
emulated virtual client users.
Test Director can invoke tests remotely, on a scheduled basis when client
machines have network access control set to "User Level
Product Version History
•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.
Product Usage Process
Before you plunge in, keep in mind the Real Benefits and Pitfalls of using
Automated Functional Testing Products
Here is my adaptation of what Mercury's User Guide identifies as the stages in their
"WinRunner Testing Process":
Create/update a GUI Map which provide a handle linking access to objects under
test.
This involves going through every screen in your application. The deliverable at
this early point to build a complete list of screen names and the various scenarios
involving various screens in different sequences of application usage.
A table of screen names in a database or spreadsheet can be used later to control
script execution. Data Driven Testing
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.
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.
Create Test Scripts referencing the GUI map and checkpoints to verify results.
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.
Debug Tests
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.
Run Tests -- emulate user actions and add verification automation to determine
pass or fail.
View Results -- error messages and captured status.
Report Defects -- into TestDirector or other bug tracking system.
Test Script Assets
Here are the artifacts of a complete WinRunner automated testing system:

WinRunner Itself
WinRunner operates in these processes:

Name Mem Usage


wrun.exe 18,752 K
crvw.exe 7,588 K
MDM.EXE 3,080 K
NTVDM.EXE (six_agnt.exe and wowexec.exe) 3,416 K
So, 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":
Physical storage:
The syntax of coding to control WinRunner execution is called TSL (Test Script
Language). The name specified to save TSL code from within WinRunner is used to
create a folder with that name. All TSL code are physically stored in a file always
named "script" with no file extension.
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();

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 into machine code only when WinRunner recognizes a "call"
statement. Example of a call for the "app_init" script:
call cso_init();
call( "C:\\MyAppFolder\\" & "app_init" );
Compiled modules are loaded into memory to be referenced from TSL code in any
module. Example of a load statement:
reload( "C:\\MyAppFolder\\" & "flt_lib" );
or
load( "C:\\MyAppFolder\\" & "flt_lib" );

GUI Map Assets


TSL code identify objects using virtual names. The physical descriptions are
stored in a GUI map.
GUI maps have file extension of .gui . Since they are shared by several scripts,
they are stored in a common folder. GUI map files exceeding 500 items may
cause performance problems for the GUI Map Editor.
•Data tables specify test script execution. They have file extension of .xls
•SQL queries have file extension of .sql
•Checklists have file extension of .chk and are stored in the chklist folder of
each script.
•DLL's access to applications.
•Actual Test Results files
Run from Top -- from the beginning of the current script until the end of the
script. LeftCtrl + F5

Run from arrow on the left grey bar


until the end of the script. LeftCtrl + F7

Step (Over) -- run from arrow on the


left grey bar. F6

Step Into function called by the current statement. LeftCtrl


+ F8
Step to Cursor -- from last line executed to the insertion
point. Not available when the icon is greyed out (disabled). LeftCtrl + F9

Pause after statements have executed. Pause

Stop immediately. LeftCtrl + F3

Data Configuration

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.
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.
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.
Startup Tips

This is the sequence which WinRunner starts up:


Each time WinRunner is invoked, it silently executes a script from C:\Program
Files\Mercury Interactive\WinRunner \dat\tslinit. This script populates the
m_root global variable from getenv ("M_ROOT");
M_ROOT is stored in the WRUN.INI file with a typical value of
C:\Program Files\Mercury Interactive\WinRunner
tslinit runs 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".
This script could be modified, but remember that they will be replaced when a
new version of Winrunner is installed.

We always start the application under test from within


winrunner. This is especially important when doing web testing using internet
browsers.
•Startup test in the Settings ->General Options, Environment tab. This
specification is stored in the WRUN.INI file under the [WrEnv] section. A sample
entry:
XR_TSL_INIT=C:\CPSTests\FltVBInit
Delete Header files upon error
If you get a "header file error" when openning 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.
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
http://www.idg.net/crd_data_19697.html
•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.