Win Runner Fundamentals

The 5 major areas to know for WinRunner are listed below with SOME of the subtopics called out for each of the major topics:
1) GUI Map
- Learning objects
- Mapping custom objects to standard objects
2) Record/Playback
- Record modes: Context Sensitive and Analog
- Playback modes: (Batch), Verify, Update, Debug
3) Synchronization
- Using wait parameter of functions
- Wait window/object info
- Wait Bitmap
- Hard wait()
4) Verification/Checkpoints
- Window/object GUI checkpoints
- Bitmap checkpoints
- Text checkpoints (requires TLS)
5) TLS (Test Script Language)
- To enhance scripts (flow control, parameterization, data driven test, user defined functions,...
________________________________________
1. Calling Scripts and Expected Results
When running in non-batch mode, WinRunner will always look in the calling scripts \exp directory for the checks. When running in batch mode, WinRunner will look in the called script's \exp directory.
There is a limitation, though. WinRunner will only look in the called script's \exp directory one call level deep. For example, in bacth mode:
script1:
gui_check(...); #will look in script1\exp
call "script2" ();

script2:
gui_check(...); #will look in script2\exp
call "script3" ();

script3:
gui_check(...); #will look in script2\exp (and cause an error)

In non bacth mode:

script1:
gui_check(...); #will look in script1\exp
call "script2" ();

script2:
gui_check(...); #will look in script1\exp (and cause an error)
call "script3" ();

script3:
gui_check(...); #will look in script1\exp (and cause an error)
________________________________________
2. Run Modes
3. Batch mode will write results to the individual called test.
4. Interactive (non-batch) mode writes to the main test.

________________________________________
5. Data Types
TSL supports two data types: numbers and strings, and you do not have to declare them. Look at the on-line help topic for some things to be aware of:
"TSL Language", "Variables and Constants", "Type (of variable or constant)"
Generally, you shouldn't see any problems with comparisons.
However, if you perform arithmetic operations you might see some unexpected behavior (again check out the on-line help mentioned above).
var="3abc4";
rc=var + 2; # rc will be 5 :-)
________________________________________
6. Debugging
When using pause(x); for debugging, wrap the variable with brackets to easily see if "invisible" characters are stored in the variable (i.e., \n, \t, space, or Null) pause("[" & x & "]");
Use the debugging features of WinRunner to watch variables. "invisible" characters will show themselves (i.e., \n, \t, space)
Examples:
Variable pause(x); pause("[" & x & "]");
x="a1"; a1 [a1]
x="a1 "; a1 [a1 ]
x="a1\t"; a1 [a1 ]
x="a1\n"; a1 [a1
]
x=""; []
________________________________________
7. Block Comments
To temporarily comment out a block of code use:
if (TRUE)
{
... block of code to be commented out!!
}
________________________________________
8. Data Driven Test ddt_* functions vs getline/split
Personally I do not care one way or another about the ddt_* or getline/split functions. They both do almost the same thing. There are some arguably good benefits to using ddt_*, but most of them are focused on the data management. In general you can always keep the data in Excel and perform a Save As to convert the file to a delimited text file.
One major difference is in the performance of playing back a script that has a huge data file. The ddt_* functions currently can not compare to the much faster getline/split method.
But here is an area to consider: READABILITY I personally do not like scripts with too many nested function calls (which the parameterize value method does) because it may reduce the readability for people with out a programming background.
Example:
edit_set("FirstName", ddt_val(table, "FirstName"));
edit_set("LastName", ddt_val(table, "LastName"));
So what I typically do is, declare my own variables at the beginning of the script, assign the values to them, and use the variable names in the rest of the script. It doesn't matter if I'm using the getline/split or ddt_val functions. This also is very useful when I may need to change the value of a variable, because they are all initialized at the top of the script (whenever possible).
Example with ddt_* functions in a script:
FIRSTNAME=ddt_val(table, "FirstName");
LASTNAME=ddt_val(table, "LastName");
...
edit_set("FirstName", FIRSTNAME);
edit_set("LastName", LASTNAME);
And most of the time I have a driving test which calls another test and passes an array of data to be used to update a form.
Example with ddt_* functions before calling another
script:

# Driver script will have
...
MyPersonArray [ ] =
{
"FIRSTNAME" = ddt_val(table, "FirstName");
"LASTNAME" = ddt_val(table, "LastName");
}

call AddPerson(MyPersonArray)
...

# Called script will have
edit_set("FirstName", Person["FIRSTNAME"]);
edit_set("LastName", Person["LASTNAME"]);
So as you can see, there are many ways to do the same thing. What people must keep in mind is the skill level of the people that may inherit the scripts after they are created. And a consistent method should be used throughout the project.

________________________________________
9. String Vs Number Comparison
10. String Vs Number comparisons are not a good thing to do.
11. Try this sample to see why:
12.
13. c1=47.88 * 6;
14. c2="287.28";
15.
16. #Prints a decimal value while suppressing non-significant zeros
17. #and converts the float to a string.
18. c3 = sprintf ("%g", c1);

19. pause ("c1 = [" & c1 & "]\nc2 = [" & c2 & "]\nc3 = [" & c3 & "]\n" & "c1 - c2 =
20. [" & c1 - c2 & "]\nc1 - c3 = [" & c1 - c3 & "]\nc2 - c3 = [" & c2 - c3 & "]");

How to Create a Test Using Winrunner (1)

User can create tests using recording or programming or by both. While recording, each operation performed by the user generates a statement in the Test Script Language (TSL). These statements are displayed as a test script in a test window. User can then enhance the recorded test script, either by typing in additional TSL functions and programming elements or by using WinRunner�s visual programming tool, the Function Generator, or using the Function Viewer.

There are 2 modes of recording in WinRunner

1. Context Sensitive mode records the operations user performed on the application by identifying Graphical User Interface (GUI) objects. Context Sensitivity test scripts can be reused in the future version of the application because WinRunner writes a unique description of each selected object to a GUI map file. The GUI map files are maintained separately from test scripts and the same GUI map file (or files) can be used for multiple tests.
For example, if the user clicks the Open button in an Open dialog box, WinRunner records the action and generate a script. When it runs the test, WinRunner looks for the Open dialog box and the Open button represented in the test script. If, in subsequent runs of the test, the button is in a different DemoUrl in the Open dialog box, WinRunner is still able to find it.

2. Analog mode records mouse clicks, keyboard input, and the exact x-and y-coordinates traveled by the mouse. When the test is run, WinRunner retraces the mouse tracks. Use Analog mode when exact mouse coordinates are important to the test, such as when testing a drawing application.
For example, if the user clicks the Open button in an Open dialog box, WinRunner records the movements of the mouse pointer. If, in subsequent runs of the test, the button is in a different DemoUrl in the Open dialog box, WinRunner will not able to find it. When recording in Analog mode, use softkeys rather than the WinRunner menus or toolbars to insert checkpoints in order to avoid extraneous mouse movements.

Different recording methods 1) Record 2) Pass up 3) As Object 4) Ignore.

1) Record instructs WinRunner to record all operations performed on a GUI object. This is the default record method for all classes. (The only exception is the static class (static text), for which the default is Pass Up.)

2) Pass Up instructs WinRunner to record an operation performed on this class as an operation performed on the element containing the object. Usually this element is a window, and the operation is recorded as win_mouse_click.

3) As Object instructs WinRunner to record all operations performed on a GUI object as though its class were �object� class.
4) Ignore instructs WinRunner to disregard all operations performed on the class.

Some common Settings we need to set in General Options:
1. Default Recording Mode is Object mode
2. Synch Point time is 10 seconds as default
3. When Test Execution is in Batch Mode ensure all the options are set off so that the Batch test runs uninterrupted.
4. In the Text Recognition if the Application Text is not recognizable then the Default Font Group is set. The Text Group is identified with a User Defined Name and then include in the General Option.