Win Tut

WinRunner Tutorial
DESIGNED BY DAVID C. JACOBS, PH.D.

HOME | LESSON ONE | LESSON TWO | LESSON THREE | LESSON FOUR | LESSON FIVE | LESSON SIX LESSON SEVEN | LESSON EIGHT | LESSON NINE | LESSON TEN | LESSON ELEVEN | LESSON TWELVE
Contents
HOME LESSON ONE LESSON TWO LESSON THREE LESSON FOUR LESSON FIVE LESSON SIX LESSON SEVEN LESSON EIGHT LESSON NINE LESSON TEN LESSON ELEVEN LESSON TWELVE
Introduction
This tutorial has been designed to teach the new WinRunner user how to test GUI software with this automated testing tool. It is assumed that you have knowledge of manual testing procedures and are using WinRunner 6.0. (I have not used the sample tests on WinRunner 7.0.)
Go Straight to the Lesson

Click on One of the Lessons
Go Straight to the Review

Click on One of the Reviews
How to Use this Tutorial You can use this tutorial in any way you wish (except from selling it, etc.), but it has been designed to be used in the following manner:
q
It is best viewed with Internet Explorer, with Medium size text (set this by going to View / Text Size / Medium), and with the resolution set at 800 by 600 Since WinRunner is not going to function well with a browser running that is not part of the test, either print out each lesson and then follow along or in a classroom have two computers running (one running WinRunner and another viewing this tutorial) Follow each lesson from the beginning to the end (and it is best to start at the beginning of the tutorial and proceed through each lesson until you have finished all lessons -- at least for the first time through)
Mercury Interactive Corporation
Printer-Friendly Version of Complete Tutorial
What You Will Learn from This Tutorial In this tutorial, each lesson will be presented to teach you how to operate one aspect of the WinRunner automated testing environment. Except for the first lesson, each lesson will include explanation and an exercise where you will apply what you have learned.
http://www.htmlmule.com/wr/wintut.html (1 of 2) [12/9/2003 12:39:57 AM]
WinRunner Tutorial
Your Responsibilities Your job while using this tutorial is to report any bugs that you might come across to the author at hodos@onebox.com.
HOME | FIRST LESSON
WinRunner and the Mercury Interactive logo are trademarks of Mercury Interactive Corporation. Copyright 2001 David C. Jacobs
http://www.htmlmule.com/wr/wintut.html (2 of 2) [12/9/2003 12:39:57 AM]
WinRunner Tutorial

Contents
HOME LESSON ONE
Lesson One: Introduction In this lesson, you will learn:

q
where the tester fits within software development different types of testing (white box, manual, and automated testing) where automated testing is beneficial and where it is not beneficial how automated testing follows the steps of manual testing some basics about WinRunner
LESSON TWO LESSON THREE LESSON FOUR LESSON FIVE LESSON SIX
q q
LESSON SEVEN LESSON EIGHT LESSON NINE LESSON TEN LESSON ELEVEN LESSON TWELVE
A Basic Overview of Software Development (Software Life Cycle) 1. Client defines what the software should be like (the expected object or the requirements) 2. Developer produces software according to client's requirements 3. Tester tests software against requirements and reports bugs to developer 4. Developer fixes bugs and modifies software according to latest requirements
Types of Testing
1. White Box Testing: The tester examines the code of the AUT (Application Under Testing) to see if the code is written correctly 2. Manual Testing / Black Box Testing: The tester uses the application in order to test it (testing for properties, appearance, and functionality) 3. Automated Testing: The tester creates test scripts that test the application similar
http://www.htmlmule.com/wr/wt1.html (1 of 6) [12/9/2003 12:39:59 AM]
WinRunner Tutorial
to manual testing (testing for properties, appearance, and functionality)

r
Excellent for regression testing, because the same scripts can be run again and again
What are the benefits of automated testing over manual and white box testing?
q
Compared to white box testing:

r
not as expensive in the long run better for functionality and regression testing
Compared to black box testing:

r
more reliable more consistent reusable and repeatable inherent programming capabilities
Which software testing should be automated?

q
Tests that need to be run for every build of the application Tests that use multiple data values for the same actions (data-driven tests) Tests that require detailed information from application internals (e.g., GUI attributes) Stress/load testing Any test that has a repetitive feature (test one object multiple times in one test or test the same objects through multiple builds of the software)
Which software testing should NOT be automated?

WinRunner Tutorial
Usability testing (how easy is the software to use?): the tester needs to use the software as a user One-time testing: automated will be too time consuming ASAP or Quick-look testing: automated will be too time consuming Ad hoc or random testing (testing the software based on hunches): automated will be too time consuming to set up General rule: if improvisation is required or little time is available, avoid automated testing and use manual testing
The Steps of Manual and Automated Testing

q
Automated testing follows the steps of manual testing Manual Testing Steps
1st Step Perform user actions
2nd Step Wait for process to complete
3rd Step Verify AUT
4th Step Repeat for all actions of AUT
Automated Testing Steps 1st Step Generate automated test script 2nd Step Synchronize script and AUT 3rd Step Add verification tests 4th Step Run test scripts
About WinRunner
q
Created by Mercury Interactive, Inc. in 1992 WinRunner is an automated testing tool that tests GUI software and web pages WinRunner combines a GUI software package and scripting language
WinRunner Tutorial
r
GUI software package: Integrated Development Environment (IDE) allows the tester to record, write, edit, run test scripts in one environment Scripting language: Test Script Language (TSL) is based on C
Three aspects of GUI software to test with WinRunner

r
Functions Properties Bitmap features
How WinRunner Basically Tests The tester creates a test script by recording the interaction with the AUT The tester can insert "checkpoints" to test the properties, appearance, and text of objects The tester can enhance test scripts with code The tester can enhance test scripts with data for a data-driven test which inserts data to determine if the AUT will accept it The tester easily runs the test by pressing an icon The tester reads the results A temporary GUI Map file is created while recording; the GUI Map file acts as an interpreter between application and test script
Supported Platforms
q
Windows 95 Windows 98 Windows NT Windows ME Windows 2000
WinRunner Tutorial
Supported Environments
q
Netscape, Microsoft Internet Explorer Java applets, Java applications, JavaScript ActiveX, OCX Controls WAP ERP/CRM applications (Oracle applications, PeopleSoft, SAP, Siebel) Terminal emulators (mainframe, AS/400, Unix servers) Visual Basic C/C++ PowerBuilder Delphi
WinRunner Resources These sources were consulted in the construction of this tutorial and are an execellent guide for further research.
WinRunner User's Guide WinRunner Tutorial TSL Online Reference WinRunner Student Handbook (from Mercury Interactive classes)
HOME | REVIEW THIS LESSON | NEXT LESSON
WinRunner Tutorial
WinRunner Tutorial

Contents
HOME LESSON ONE LESSON TWO LESSON THREE
Lesson Two: Recording Tests, Playback, Context Sensitive and Analog Modes In this lesson, you will learn:
q
how WinRunner tests are recorded how to playback a test the differences between analog and context sensitive recording
LESSON FOUR LESSON FIVE LESSON SIX LESSON SEVEN LESSON EIGHT LESSON NINE LESSON TEN LESSON ELEVEN LESSON TWELVE
q
Creating a Test Script There are two ways to create a test script: 1. Recording the test script as you interact with the application 2. Writing or scripting the test script in test script language (TSL)
How to Record a Test Script

1. Start WinRunner
r
Start / Programs / WinRunner / WinRunner Close the Add-In Manager, by clicking OK If the Welcome to WinRunner dialog appears, uncheck the Show at Startup check box, then close the Welcome to WinRunner dialog by pressing the X in the top right
2. Start the AUT 3. Start a new test script (by pressing the New icon selecting File / New)
WinRunner Tutorial
4. Activate the recording function (by pressing the Record icon or selecting Create / Record - Context Sensitive) 5. Interact with the AUT 6. Stop recording (by pressing the Stop icon) 7. Save the test script
Test 1 Execute the following steps to learn how to record a test script and to test the search function of WordPad: 1. Put a floppy in the a:\ drive 2. Start WinRunner (if you have not already done so)
r
Start / Programs / WinRunner / WinRunner
3. Close all other applications (even the internet browser you are using; this is why it is best to print out this tutorial) 4. Start our AUT (WordPad)
r
Start / Programs / Accessories / WordPad
5. Position the two applications so that they do not overlap

r
Why? So that you can see both applications clearly and so that you can interact with both applications and the actions do not get executed by the incorrect application Position WinRunner on the left and the AUT on the right
6. Start a new test script in WinRunner

r
File / New or press the New icon
7. Start recording
r
Click the red Record icon Or Create / Record - Context Sensitive Or press F2
8. Click inside of WordPad and type these lines:
WinRunner Tutorial
This is the first line. This is the second line. This is the third line. This is the fourth line. 13. Click on the Search icon (binoculars) in WordPad
r
In the Find What text field, type: line Click on Find Next four times Press Cancel
14. In WordPad, click the New icon or select File / New

r
Press OK Do not save changes, by selecting No
15. Stop Recording, by pressing the Stop icon in WinRunner 16. Save the test script in WinRunner
r
File / Save Save In: a:\ drive File Name: test1 Press Save
17. Playback or Run the test script

r
Click the Run from Top icon Or Run / Run from Top
18. Accept the Test Run Name of res1, by pressing OK 19. Examine the Results and then close Results 20. Maximize WinRunner's window and look at the test script; these are our recorded movements interacting with WordPad 21. Click on the Help Icon (arrow and question mark) and then click on the first line (this will explain the syntax of the script) 22. set_window ("Document - WordPad", 3);
WinRunner Tutorial
r
set_window activates the window to receive input "Document - WordPad" is the logical name of WordPad 3 is the number of seconds before the next function in the test script will run (plus the default time)
23. Close the TSL Online Reference window, WordPad, and the test script
What did we learn from this test script? Recording a test script in WinRunner is as simple as pressing the Record icon and interacting with the AUT, and running or playing back the test script will execute the movements that were recorded. In this way, we can test the functionality of the AUT.
Two Recording Modes In WinRunner, when we record a test script, there are two recording modes; test scripts can be in both modes or in either mode. The two modes are:
1. Context Sensitive Mode (the default mode)

r
Context Sensitive statements describe actions made to GUI objects and are recommended for most situations, where the test scripts are:
s
object-based not affected by user interface changes (i.e., movement of objects)
Software examples: menus, icons, check boxes
2. Analog Mode
r
Analog statements are useful for literally describing the keyboard, mouse, and mouse button input of user Test scripts are:
s
screen-coordinate dependent based on mouse and keyboard activities (e.g., mouse movement, press, and release, and keyboard input)
WinRunner Tutorial
Software examples: virtual reality environment, drawing, paint brush strokes
How to Choose Between Context Sensitive and Analog Modes Choose Context Sensistive if: The application contains GUI objects Exact mouse movements are not required You plan to reuse the test in different versions of the application Why? Movements of the GUI objects in different builds will not affect the test. Choose Analog if: The application contains Bitmap areas (e.g., a drawing area) Exact mouse movements are required You do not plan to reuse the test in different versions of the application Why? Movements of the GUI objects in different builds will affect the test.
Test 2: Recorded in Context Sensitive mode, but will not function properly 1. Start a new test in WinRunner (by pressing the New icon) 2. Open Flight Reservation application
r
Start / Programs / WinRunner / Sample Applications / Flight 1A
3. Log on the Flight Reservation application

r
Type your first name in the Agent Name field (your name must be at least four characters long) Type mercury in the Password field and click OK
4. Position the two applications so that they do not overlap 5. Start recording
r
Press the Record icon or select Create / Record - Context Sensitive
6. Open order number 1 in the Flight Reservation application

r
Select File / Open Order Check the Order No. check box in the Open Order window
WinRunner Tutorial
Type 1 in the text box and press OK
7. Open the Fax Order window

r
Select File / Fax Order
8. Enter 408 555 1212 in the Fax Number field 9. Sign your first name in the Agent Signature area by holding down the left mouse button and drawing your name 10. Press the Send icon 11. Stop Recording 12. Save as test2 on your a:\ drive 13. Playback or Run the test script
r
14. Accept the Test Run Name of res1, by pressing OK 15. Notice that WinRunner will not sign your name; it finds Agent Signature area but not the exact place to start writing 16. Examine the Results and then close Results 17. Close the test script
What did we learn from this test script? Given the instructions from the test script, WinRunner can find the object to write in but not the exact place. Because of this, the writing of our name did not take place. Thus, analog mode is required for this to work properly.
Test 3: Same test in Analog Mode 1. Start a new test in WinRunner (by pressing the New icon) 2. Start recording in Analog mode
r
Press the Record icon and F2
WinRunner Tutorial
r
Or select Create / Record - Analog

r
Select File / Open Order Check the Order No. check box in the Open Order window Type 1 in the text box and press OK

r
r
11. Accept the Test Run Name of res1, by pressing OK 12. Examine the Results and then close Results 13. Close the test script and the Flight Reservation application
What did we learn from this test script? With the test script recorded in analog mode, WinRunner can precisely place the mouse pointer in the exact location inside of the drawing window. Because of this, the test script can write our signature and hence perform the test properly.
HOME | PREVIOUS LESSON | REVIEW THIS LESSON | NEXT LESSON
WinRunner Tutorial
WinRunner Tutorial

Contents
Lesson Three: Initial and End Conditions, Organizing Files In this lesson, you will learn:
q
why there is a need to set initial and end conditions how to set initial and end conditions for your tests how WinRunner organizes your files
q q
Why Create Initial and End Conditions? When you record a test script and when you playback a test script, the AUT is run or interacted with; this can change the AUT:
q
by entering data into text fields by enabling icons that were grayed out before the test or graying out buttons that were enabled before the test
Why Is This a Problem?

q
When WinRunner runs a test script, the AUT may not be in the same condition it was before the test The test may not be able to interact with the AUT as the test script describes; thus, the test script will not function properly and will not generate a good test of the AUT
Creating Initial or End Conditions Solves this Problem What is an initial condition? An initial condition is the state of the AUT at the beginning
WinRunner Tutorial
of the test. What is an end condition? The end condition is the state of the AUT after a test has run.
Important Note: The end condition of an AUT after a test has run should not affect a subsequent test upon the AUT. If the subsequent test is affected by the earlier test, the AUT is not being tested properly. In other words, the subsequent test is not reliable or useful.
For example:
1. If a test script instructs WinRunner to open an application to test it, make sure the end condition closes the application (otherwise, running the same test twice may create problems). 2. If a test enters data into text fields, have the end conditions clear the data (as we did with Test 1).
Test 4: A test without proper end conditions 1. Start a new test in WinRunner (by pressing the New icon) 2. Start WordPad
r
3. Position the two applications so that they do not overlap 4. Start Recording in WinRunner (in Context Sensitive Mode)
r
5. Type this in WordPad: WinRunner was created by Mercury Interactive. Mercury Interactive makes a variety of testing tools. Mercury Interactive trades stock with the symbol MERQ. 6. Select the Find icon (binoculars); search for the word: interactive 7. Select Find Next three times and press Cancel
WinRunner Tutorial
8. Stop recording 9. Save as test4 on your a:\drive 10. Playback or Run the test script
r
11. Accept the Test Run Name of res1, by pressing OK 12. Look at the text in WordPad; the same text was entered twice (once when we recorded the test script and another time when we ran the test script)
What did we learn from this test script? The running of this test script entered the same data as the recording of our interaction with the AUT, because it did not clear the data already entered. This could become a problem in a more complicated test.
13. Close the Results, the test script, and WordPad

r
In WordPad, select No to avoid saving changes
Test 5: Same test as Test 4 but with end conditions 1. Start a new test in WinRunner (by pressing the New icon) 2. Start WordPad
r
r
5. Type this in WordPad: WinRunner was created by Mercury Interactive. Mercury Interactive makes a variety of testing tools.
WinRunner Tutorial
Mercury Interactive trades stock with the symbol MERQ. 6. Select the Find icon (binoculars); search for the word: interactive 7. Select Find Next three times and press Cancel 8. Create end conditions to clear the data
r
Select the New icon in Word Pad (this will create end conditions by clearing the data for the next test of WordPad) In the New window of WordPad, select OK Select No for saving changes in WordPad
9. Stop recording 10. Save as test5 on your a:\ drive 11. Playback or Run the test script
r
12. Accept the Test Run Name of res1, by pressing OK 13. Examine and then close the Results 14. Run test script again 15. Accept the Test Run Name of res2, by pressing OK 16. Close the Results, the test script, and WordPad
What did we learn from this script? The end conditions clear the data from the AUT during the running of the test, so that the data will not get in the way of the next running of the test.
How WinRunner Organizes Your Files When you create and run a test script, WinRunner creates a directory with the name of the test.
WinRunner Tutorial
For example, for Test 5, there would be a diretory named Test5. Depending upon configuration of WinRunner, the Test5 directory may contain these subdirectories and files:
a script file a backup script file (if WinRunner is configured to do this) a header file a lock file containing the name of the user and a process id exists while the a test script is open to prevent others from opening it, but it is automatically deleted when the test script is closed a db subdirectory which contains files which influence playback and which should not be changed a res1 subdirectory which contains the first set of results of your test a exp subdirectory which contains the expected results for some tests
A directory for a test could also contain:
a chklist subdirectory which contains the checklists for objects to be checked for GUI tests a debug subdirectory which contains the results of running your test script in debug mode a table file which contains the data for a data-driven test
WinRunner Tutorial

Contents
Lesson Four: Synchronizing Tests In this lesson, you will learn:

q
when you should synchronize a test how to synchronize a test
The Problem that Synchronizing Solves Actions in a test script either set a time for the next action to be executed or they have a default time of 10 seconds. If the AUT does not respond quickly enough to a command in the test script, WinRunner will move on to the next command; a problem may arise because the outcome of the last command did not occur. There are a variety of objects and functions that may cause these; the following are some common objects and functions that may cause synchonization problems:
Software retrieving information from a database Waiting for a window to pop up Waiting for a progress bar to reach 100% Waiting for a status message to appear
If WinRunner waits for these objects and functions for the full ten seconds of the default interval time (or the set time by the function in the script), then it will move on to the next action in the script which may not execute correctly.
WinRunner Tutorial
Entering a Synchronization Point Solves the Problem A synchronization point is a line in the test script that instructs WinRunner to wait for a certain response from the AUT during playback before proceeding to the next line in the test script. Types of Synchronization Cue Window Object State Bitmap Outcome Wait for window Wait for an object state Wait for a bitmap to refresh Test Script Function set_window obj_wait_info obj_wait_bitmap wait
Elapsed Time Wait for a set time to elapse
Important Note: Our software does not currently have a synchronization problem. We will create one by changing the default interval between actions in a test script. This changes the default time for all subsequent test scripts, so you must change it back after you run this test script.
Test 6 1. Start WinRunner (if it is not already running) 2. Start a new test in WinRunner (by pressing the New icon) 3. Start the Flight Reservation application and log in
r
Start / Programs / WinRunner / Sample Applications / Flight 1A In login window, type your name and enter mercury for the password and click OK
4. Position the two applications so that they do not overlap 5. Start Recording
r
6. Create a new order in Flight Reservation application
WinRunner Tutorial
r
File / New Order
7. Fill in flight and passenger information

r
Date of Flight: 02/02/02 Fly From: Los Angeles Fly To: San Francisco Click the Flights button and double click on any flight Name: Steve Johnson Select First Class Click Insert Order
8. Delete the order (this will set the end conditions)

r
Click the Delete Order button Click Yes in the message window to confirm
9. Stop Recording 10. Save as test6 on your a:\ drive
Changing the Default Interval Between Actions in a Test Script Since there is currently no synchronization problem with our test script and AUT, we are going to create one by changing the default time interval between actions. To change this, we do the following steps:
1. Settings / General Options 2. Click the Run tab 3. For Timeout for checkpoints and CS statements, change the value to 1000 milliseconds (which equals 1 second) 4. Click OK
Run Test 6
WinRunner Tutorial
1. Make sure the test6 test window is active in WinRunner, by clicking on the title bar 2. Playback or Run the test script
r
3. Accept the Test Run Name of res1, by pressing OK 4. Notice that WinRunner fails to click the Delete Order button because it is still disabled (WinRunner did not wait until the Insert Order operation was completed) 5. Select Continue in Warning Message Box 6. The test fails again because it cannot find the Flight Reservations Message Box 7. Select Cancel in the Run Wizard dialogue box
Synchronizing the Test 1. Make sure the test6 test window is active in WinRunner, by clicking on the title bar 2. Place the cursor at the point where you want to synchronize the test
r
Add a blank line after the button_press ("Insert Order"); statement Place the cursor in the blank line
3. Synchronize the test so that the test script waits for the "Insert Done" message to appear in the status bar
r
Create / Synchronization Point / For Object/Window Bitmap Use the hand pointer to click the status bar in the Flight Reservation window (where the phrase, "Insert Done...", is) WinRunner will insert an obj_wait_bitmap synchronization point in the test script
4. Manually change the 1 second wait in the script to 10 seconds
Change the following line:
WinRunner Tutorial
obj_wait_bitmap ("StatusBar95", "Img1", 1); To read: obj_wait_bitmap ("StatusBar95", "Img1", 10);
5. Save the test script again 6. Maximize WinRunner
The Syntax of the obj_wait_bitmap Statement To get information on the syntax of the this statement, click on the help icon (arrow and question mark) and then click on the obj_wait_bitmap statement in the test script. obj_wait_bitmap ("StatusBar95", "Img1", 10);
obj_wait_bitmap: the function in the test script which waits for ten seconds for the image to appear before moving on to the next action "StatusBar95": the logical name of the image (your test script may have "Insert Done..." as the logical name) "Img1": the file name of the bitmap (the image) 10: the amount of seconds to wait for the image to appear (plus the default which we changed to one second)
Close the TSL Reference window
Run the Synchronized Test 1. Position the two applications so that they do not overlap 2. Make sure the test6 test window is active in WinRunner, by clicking on the title bar 3. Playback or Run the test script
r
WinRunner Tutorial
4. Accept the Test Run Name of res2, by pressing OK 5. Watch how WinRunner waits for the "Insert Done" message to appear in the status bar 6. Review the results
r
Double click on the "wait for bitmap" event to see the bitmap image WinRunner was waiting for
7. Close the Results, the test script, and the Flight Reservation application
What did we learn from this test script? When testing an AUT with synchronization problems, we must insert a synchronization point to stop WinRunner momentarily in its running of the test script so that the AUT can perform its actions. If we don't do this, the test will not run properly.
Change Time Interval Back to Default 1. Settings / General Options 2. Select Run tab 3. For Timeout for checkpoints and CS statements, change the value to 10000 milliseconds 4. Click OK
Additional Exercise 1. Maximize WinRunner 2. Use the Help icon (arrow and question mark) to determine the action and syntax 3. Write down in your notes answers to the following questions about these lines from our test script:
WinRunner Tutorial
set_window ("Flight Reservation", 2); What is set_window? What is its action? What is "Flight Reservation"? What is 2?
edit_set ("Name:", "Steve Johnson"); What is edit_set? What is its action? What is "Name:"? What is "Steve Johnson"?
button_set ("First", ON); What is button_set? What is its action? What is "First"? What is ON?
WinRunner Tutorial

Contents
Lesson Five: GUI Verification In this lesson, you will learn:

q
what verification is how to insert GUI checkpoints to verify GUI objects
Verification and Manual Testing In manual testing, the tester tests the AUT in order to determine if it meets the specified requirements; this is called "verification." Verification is the process where the tester determines if the actual object (AUT) matches (or is the same as) the expected object (specifications or requirements). If the actual object matches the expected object, the AUT passes the test; if the actual object does not match the expected object, the AUT fails the test.
Actual Object
should match...
Expected Object
The functions, properties, and appearance of the actual object should match the functions, properties, and appearance of the expected object.
WinRunner and Verification Definition: Verification is the process by which WinRunner reports whether expected results are actualized by the application. In other words, verification in WinRunner is checking to see if the actual object matches the expected object when the actual object is driven by a test script in WinRunner. (The verb actualize means to realize in action or to make real.)
WinRunner Tutorial
Functionality testing of a GUI object can be performed by recording the interactions with the AUT and then playing back the test script. The appearance of an AUT can be verified through Bitmap verification. Many of the properties of a GUI object can be verified through inserting GUI checkpoints.
The Four Steps of How WinRunner Verifies 1. The tester stores an expected result with the recorded test script (known as a "Checkpoint") 2. WinRunner captures an actual result during playback 3. WinRunner compares the actual result with the stored, expected result 4. WinRunner reports the comparison outcome as PASS or FAIL
Definition of a Checkpoint: A TSL statement that verifies that the actual object matches the expected object.
GUI Object Verification

q
To verify a GUI object, we use GUI checkpoints; GUI checkpoints are placed in a test script and test a GUI object according to a specific checklist of properties that we create. With GUI checkpoints we can test to determine, for example:
r
if a window is the correct size if a button is enabled or disabled if the correct text is in a text field if boxes are checked or unchecked if a list has the correct number of items
The Process for Establishing GUI Checkpoints 1. Determine the visual cues to verify
WinRunner Tutorial
2. Create the GUI checkpoint 3. Test the checkpoint to ensure that it works for PASS and FAIL conditions (we will not be doing this) 4. Run the recorded test script to verify correct execution
Examples of Visual Cues These examples are changes to the AUT during our interaction with it:
q
a window appears during interaction with AUT an object changes state (for example, from enabled to disabled, from focused to unfocused) output data is returned from the system (for example, the total price of a sale or invoice number) a message is returned from the system (for example, "Purchase completed")
Test 7 1. Start WinRunner 2. Start a new test in WinRunner (by pressing the New icon) 3. Start the Flight Reservation application and log in
r
r
6. Open the Open Order dialog box in Flight Reservation

r
File / Open Order Move the Open Order dialog box so that it does not overlap with WinRunner
WinRunner Tutorial
7. Create a GUI checkpoint for the Order No. check box

r
Create / GUI Checkpoint / For Object/Window Use the hand pointer to double-click on the Order No. check box The Check GUI dialog box opens and displays the available checks Accept the default check ("State"); this will capture the current state ("OFF") of the check box and stores it as expected results Click OK The obj_check_gui statement will appear in the test script
8. Check the Order No. check box and enter 4 as the Order No. 9. Create another GUI checkpoint for the Order No. check box
r
Create / GUI Checkpoint / For Object/Window Use the hand pointer to single click on the Order No. check box WinRunner inserts a checkpoint for the default check ("State") by inserting the obj_check_gui statement in the test script
10. Create a GUI checkpoint for the Customer Name check box
r
Create / GUI Checkpoint / For Object/Window Use the hand pointer to double click on the Customer Name check box Accept the default check "State" Also, select "Enabled" as an additional check The State check captures the current state ("OFF") of the check box; the enabled check captures the current condition ("OFF") of the check box Click OK
11. Click OK in the Open Order dialog box to open the order 12. Stop recording 13. Save as test7 on your a:\ drive 14. Playback or Run the test script
r
WinRunner Tutorial
15. Accept the Test Run Name of res1, by pressing OK 16. Examine the Results
r
Click on end GUI checkpoint They show the expected value and the actual value
17. Close the GUI Checkpoint Results window 18. Close the Results and the Flight Reservation application
The Syntax of the GUI Checkpoint Statement To get information on the syntax of the this statement, click on the help icon (arrow and question mark) and then click on the obj_check_gui statement in the test script. obj_check_gui("Order No.","list1.ckl","gui1",1);
q
obj_check_gui: the function in the test script that performs the GUI verification; it compares the actual GUI object and the expected GUI object "Order No.": logical name of GUI object to be verified "list1.ckl": name of checklist which defines the GUI checks "gui1": captured data in file used as the expected results 1: time interval in seconds (plus default time) to capture data from GUI object
19. Close the TSL Reference window 20. Close the test script
What did we learn from this test script? In order to verify a property of a GUI object, we can insert GUI checkpoints; these checkpoints will verify the properties of the GUI object according to the checklist that we create.
WinRunner Tutorial
WinRunner Tutorial

Contents
Lesson Six: Bitmap Verification In this lesson, you will learn:

q
how to test Bitmap images in your application how to insert Bitmap checkpoints to verify Bitmap images
LESSON FOUR LESSON FIVE LESSON SIX LESSON SEVEN

q
Bitmap Verification Recall that verification is the process by which WinRunner reports whether expected results are actualized by the application With Bitmap verification, WinRunner is comparing a Bitmap image (the actual object) with the expected object pixel by pixel to verify that the actual object matches the expected object
LESSON EIGHT LESSON NINE

q
LESSON TEN LESSON ELEVEN LESSON TWELVE
Bitmap Image (Actual Object)

should match...
Bitmap Image (Expected Object)
The Process for Establishing Bitmap Checkpoints 1. Determine the Bitmap object to verify
2. Create the Bitmap checkpoint 3. Test the Bitmap checkpoint to ensure that it works for PASS and FAIL conditions (optional) 4. Run the recorded test script
WinRunner Tutorial
r
r
6. Open order #6
r
File / Open Order Select the Order No. check box and type 6 Click OK
7. Open the Fax Order dialog box

r
File / Fax Order
8. Enter 347 710 6526 in the Fax Number field 9. Move the Fax Order dialog box so that it does not overlap WinRunner 10. Switch to Analog mode
r
Press the F2 function key
11. Sign your first name in the Agent Signature box with the mouse pointer 12. Switch back to Context Sensitive mode
r
13. Insert a Bitmap checkpoint that verifies your signature

r
Create / Bitmap Checkpoint / For Object/Window Use the hand pointer to click on the Agent Signature box
WinRunner Tutorial
r
WinRunner will capture the Bitmap and will insert the obj_check_bitmap statement in the test script
14. Click the Clear Signature button 15. Insert another Bitmap checkpoint that checks the Agent Signature box
r
Create / Bitmap Checkpoint / For Object/Window Use the hand pointer to click on the Agent Signature box WinRunner will capture the Bitmap and will insert the obj_check_bitmap statement in the test script
16. Click the Cancel button on the Fax Order dialog box 17. Stop recording 18. Save as test8 on your a:\ drive 19. Don't run the test; instead, lets view the expected results first
r
Open the Test Results Window Tools / Test Results View the captured Bitmaps
s
Double click on the first "capture bitmap" event Double click on the second "capture bitmap" event
Close the Test Results window

s
File / Exit

r
21. Accept the Test Run Name of res1, by pressing OK 22. Examine the Results and then close the Results
The Syntax of the obj_check_bitmap Statement To get information on the syntax of the this statement, click on the help icon (arrow and question mark) and then click on the obj_check_bitmap statement in the test script.
WinRunner Tutorial
obj_check_bitmap: the function in the test script that performs the Bitmap verification h "(static)": the logical name of the object "Img1": the file name of the captured Bitmap (the image) 10: the amount of seconds to wait for the image to appear (plus the default time)
22. Close the TSL Online Reference window 23. Close the test script and the Flight Reservation application
What did we learn from this test script? To verify a Bitmap image, we insert a Bitmap checkpoint in the test script to compare the actual Bitmap object with the expected Bitmap object. WinRunner will then compare the actual object and the expected object pixel by pixel to determine if the actual object matches the expected object.
WinRunner Tutorial

Contents
Lesson Seven: Text Verification In this lesson, you will learn:

q
how to test text elements in an application how to insert text checkpoints to verify text elements

q
When to Use Text Verification When text is not part of a GUI object (e.g., a label or caption) When text is part of a bitmap image When text is part of a non-standard, custom GUI object
LESSON EIGHT LESSON NINE LESSON TEN LESSON ELEVEN LESSON TWELVE
q
Functions Used to Read Text If text is:

Use: Context Sensitive functions (e.g., obj_get_info, button_get_info) obj_get_text text reading feature (e.g., win_get_text)
A property of a standard GUI object Part of custom GUI object which cannot be read from the property
Part of Bitmap or in ASCII (not part of GUI object)
Process to Verify Text
WinRunner Tutorial
1. Declare a variable in the script and assign it the expected value (in this test, we will compare the actual text object with the expect text object) 2. Insert a function to read (or get) the actual text from the AUT during playback 3. Insert code to compare the actual value with the expected value 4. Insert code to report the comparison outcome to the WinRunner Test Results (e.g., PASS or FAIL)
Declaring a Variable In TSL, the syntax for declaring a variable is: VariableName="value"; VariableName is the name of the variable. "value" is the value of VariableName as a string item. The variable that we will declare in our next test script will be: VersionNum="Version 1.0";
If-Else Statement We will also include an if-else statement in our test script. This statement will be used to compare the actual text object and the expected text object and to report to us if the actual text object passed or failed the test. The syntax for an if-else statement in TSL is: if (condition) action1 else action2 If the condition is TRUE, then action1 will execute and action2 will be ignored. If the condition is FALSE, then action1 will be ignored and action2 will execute. The code that we will insert in our test script is the following: if (VersionNum == text)
WinRunner Tutorial
tl_step("Check Version",PASS,"Version is correct."); else tl_step("Check Version",FAIL,"Version is incorrect."); This code explained: VersionNum: the variable that will hold the expected value text: the variable that will hold the actual value tl_step: function that inserts a status message in the test results for a single section of the test script The syntax for the tl_step function is: tl_step (step_name, status, description); tl_step: function step_name: the name of the test step status: PASS or FAIL status of test step description: description of status to be printed in results
Passing the Test If the expected text object (expected text value stored in VersionNum) is the same as the actual text object (actual text value) stored in text, then the test step will have the status of PASS and the phrase ("Version is correct.") will print in the results. Failing the Test If the expected text object (expected text value stored in VersionNum) is NOT the same as the actual text object (actual text value) stored in text, then the test step will have the status of FAIL and the phrase ("Version is incorrect.") will print in the results.
How to Read or Get the Text In order to verify the text, we need to get the text. The following describes how to get the text:
1. Go to the window or object in the AUT where you need to get the text
WinRunner Tutorial
2. Use WinRunner to get the text

r
Create / Get Text / From Screen Area
Three Modes to Run a Script In Recall the three modes that you can run a script in:
Verify Debug (we will use debug the first time after we add lines of code to our test script to make sure the code is correct) Update
Test 9: This test will read text from a Bitmap area and then verify it 1. Start WinRunner 2. Start a new test in WinRunner (by pressing the New icon) 3. Start the Flight Reservation application and log in
r
r
6. Open the About window in Flight Reservation application

r
Help / About
7. Read the version number text

r
Create / Get Text / From Screen Area The pointer becomes crosshairs Move the cursor slightly above and to the left of what you want to capture (a quarter inch away from "Version 1.0")
WinRunner Tutorial
Hold down the left mouse button and drag the cursor so that the text you want to capture (and no other text) is enclosed by a rectangle, then release the mouse button Press the right mouse button to complete the operation
8. Close the About window by pressing the OK button 9. Stop recording 10. After the last line of the test script, insert the variable that holds the expected text value VersionNum="Version 1.0"; 12. After the last line of the test script, type in the following code which will verify that the actual text matches the expected text:
if (VersionNum == text) tl_step("Check Version",PASS,"Version is correct."); else tl_step("Check Version",FAIL,"Version is incorrect.");
12. Save as test9 on your a:\ drive 13. Check the test script by running it in debug mode
r
Change mode to debug Run from Top If there are problems, fix your script and run in debug again
14. Playback or Run the test script in verify mode

r
15. Accept the Test Run Name of res1, by pressing OK 16. Examine the Results 17. Close the Results and the Flight Reservation application 18. Open the Flight Reservation (1B)
r
Start / Programs / WinRunner / Sample Applications / Flight 1B
WinRunner Tutorial
19. Playback or Run the test script again with this application in verify mode
r
r
This test should have failed
22. Close the Results, the Flight Reservation application, and the test script
What did we learn from this test script? To verify text that is part of a Bitmap area, the tester must get the text (or read the text), and insert code to verify the text.
Reading Text from an Application If your AUT has an area that generates a total number of orders, etc., you can read the text, place an order, and verify that the order number has gone up by one. To do this, you must: 1. Get the text 2. Add an order 3. Synchronize the test (to ensure the test script waits for order to take place) 4. Get the text again 5. Change the name of the variables 6. Insert an if-else statement
Why Change the Name of a Variable? When we get or read the text twice (once before a new order and once after a new order). The order should increase the number of orders by 1. However, when we get the text, the variable text will be used to hold both values. The first time we get the text we will:
WinRunner Tutorial
Change text to first_total
The second time we get the text, we will:

q
Change text to new_total
In this way, we can verify if new_total is equal to first_total + 1. The code that we will insert in our test script is the following: if (new_total == first_total + 1) tl_step("Graph Total",PASS,"Total is correct."); else tl_step("Graph Total",FAIL,"Total is incorrect."); This code explained: new_total: variable that holds the value after a new order first_total: variable that holds the value before a new order tl_step: function that inserts a status message in the test results for a single section of the test script The syntax for the tl_step function is: tl_step (step_name, status, description); tl_step: function step_name: the name of the test step status: PASS or FAIL status of test step description: description of status to be printed in results
Passing the Test If the AUT correctly adds a number to the total number of orders after a new order, new_total will be equal to first_total + 1. If this occurs, then the test step will have the status of PASS, and the phrase ("Total is incorrect.") will print in the results. Failing the Test
WinRunner Tutorial
If the AUT does not correctly add a number to the total number of orders after a new order, new_total will NOT be equal to first_total + 1. If this occurs, then the test step will have the status of FAIL, and the phrase ("Total is incorrect.") will print in the results.
Test 10: This test will read text that is generated by an application 1. Start WinRunner 2. Start a new test in WinRunner (by pressing the New icon) 3. Start the Flight Reservation application and log in
r
r
6. Open the graph in Flight Reservation

r
Analysis / Graphs Position the graph so that it does not overlap WinRunner
7. Read the total tickets sold from the graph

r
Create / Get Text / From Screen Area Use the crosshairs pointers and the left mouse to drag a rectangle around the total Click the right mouse button to finish the operation WinRunner inserts the obj_get_text statement in the test script
8. Close the graph 9. Create a new order

r
File / New Order
10. Enter flight and passenger information

WinRunner Tutorial
Date of Flight: 02/02/02 Fly From: Denver Fly To: San Francisco Click the Flights button and double click on any flight Name: Sherri Moore Tickets: 1
11. Insert the order, by clicking the Insert Order button 12. Synchronize the test so that it waits for the "Insert Done" message to appear in the status bar
r
Create / Synchronization Point / For Object/Window Bitmap Use hand pointer to click the "Insert Done" message
13. Open the graph again in Flight Reservation application

r
14. Read the total from the graph

r
15. Close the graph 16. Stop recording 17. Save as test10 on your a:\ drive
Inserting an If-Else Statement and Changing the Variable Names 18. In the first obj_get_text statement in the test script, change the variable text to first_total
WinRunner Tutorial
19. In the second obj_get_text statement in the test script, change the variable text to new_total 20. Place the cursor below the last line in the test script 21. Add the following statements to the test script:
if (new_total == first_total + 1) tl_step("Graph Total",PASS,"Total is correct."); else tl_step("Graph Total",FAIL,"Total is incorrect.");
22. Save the test again 23. Check the test script by running it in debug mode
r
24. Change mode to verify and run the test script 25. Examine the Results 26. Close the Results, the Flight Reservation application, and the test script
What did we learn from this test script? To verify text that changes in an AUT (for example, a number total), we must get the text, place an order, get the text again, synchronize the test, change the name of variables, and then insert an if-else statement that verifies that the number of orders is increased by one after an order is placed.
WinRunner Tutorial
WinRunner Tutorial

Contents
Lesson Eight: Introduction to GUI Map Files In this lesson, you will learn:
q
what a GUI map file is how WinRunner creates a GUI map file during recording how the GUI map allows WinRunner to identify objects
LESSON FOUR LESSON FIVE LESSON SIX LESSON SEVEN LESSON EIGHT LESSON NINE LESSON TEN LESSON ELEVEN
q q
GUI Map Files Definition: the GUI map acts as a translator between the AUT and the recorded test script.
LESSON TWELVE
WinRunner adds the names of windows and objects to the GUI Map file as they are encountered by the user during recording The GUI Map contains information that allows TSL statements to be translated into Windows OS commands and vice versa
How Does WinRunner Run the Test Script?

q
When WinRunner executes a TSL statement from the test script, it passes through the GUI map before sending it to Windows OS which will interact with the AUT The AUT's response must also pass through the GUI map
Important Issues in Test Script Creation

q
WinRunner must uniquely identify each object in the Graphical User Interface of the AUT
WinRunner Tutorial
The naming of an object and its corresponding function must be kept together
Some of the Object Attributes Used to Name an Object

q
Class: the type of object, such as window, push_button, list, scroll Label (or attached text): the test that appears on the object, such as a button name or a window title
r
this usually becomes the object's logical name
MSW_id: the Microsoft Windows id assigned to the object during development Parent: the parent of the object (usually a window)
The GUI Map Editor The GUI Map Editor is the WinRunner utility that is used to work with GUI Map files. In this next test, we will use the GUI Map Editor to view GUI objects, their names, and their physical descriptions. How to Open the GUI Map Editor
q
Tools / GUI Map Editor
Test 11: Test created to view a temporary GUI map file 1. Start WinRunner 2. Start a new test in WinRunner (by pressing the New icon) 3. Start Recording
r
4. Start the Flight Reservation application and log in

r
Start / Programs / WinRunner / Sample Applications / Flight 1A In login window, type in your name Use the mouse pointer to switch from the Name text field to the Password text field; do not use the TAB key
WinRunner Tutorial
Enter mercury for the password (do not yet press OK) Press Help and then press OK to exit the Help dialog box Press Cancel and then start the Flight Reservation again
s
In login window, type in your name Use the mouse pointer to switch from the Name text field to the Password text field; do not use the TAB key Enter mercury for the password and click OK
5. Position the two applications so that they do not overlap 6. Close the Flight Reservation application 7. Stop recording 8. Save as test11 on your a:\ drive 9. Do not run this test 10. Maximize WinRunner 11. Open GUI Map Editor
r
Tools / GUI Map Editor In the GUI Map Editor, in the Windows/Objects field, scroll down until you see Login
s
If the GUI objects that are part of the Login window are not showing, double click on Login
Logical Name Login
Physical Description class: window, label: Login, MSW_class: "#32770" class: edit, attached_text: "Agent Name:"
Agent Name:
WinRunner Tutorial
Might not appear: Might not appear: Agent Name:(static) class: static_text, MSW_id: 65535, label: "Agent Name:" Cancel Help class: push_button, label: Cancel class: push_button, label: Help class: push_button, label: OK class: edit, attached_text: "Password:" Might not appear: class: static_text, MSW_id: 65535, label: "Password:"
OK Password:
Might not appear: Password:(static)
Examine the following three TSL statements in the test script that correspond to these objects:
edit_set ("Agent Name:", "David"); password_edit_set("Password:", "kzptnyoslzjsaz"); button_press ("OK");
edit_set ("Agent Name:", "David"); edit_set: function that replaces text in the edit object (edit text field) "Agent Name:": logical name of the edit object to receive input "David": string to be entered into edit object
password_edit_set("Password:", "kzptnyoslzjsaz");
WinRunner Tutorial
password_edit_set: function that enters the password into edit object; it also encrypts the password so that the password is not in the test script "Password:": logical name of the edit object to receive input "kzptnyoslzjsaz": encrypted string item to be entered into edit object
button_press ("OK"); button_press: function that presses a click button "OK": logical name of the button
Close the GUI Map Editor and the test script
The GUI Map Translation

q
The GUI map connects the logical name used in the test script to the physical description used in the AUT to identify the correct test object
Logical name used in test script button_press ("OK");
GUI Map connects logical name in test script to the physical description in the AUT OK { class: push_button, label: OK }
Physical description in the AUT class: push_button, label: OK
During Recording: when you interact with the AUT, WinRunner learns the physical attributes of the AUT and inserts them into the GUI map; it generates a logical name to each object and uses the logical name in the test script During Playback: WinRunner reads the logical name in the test script and translates this into the physical description and then looks for this in the AUT
WinRunner Tutorial
Exercise 1. Create a test script that creates an order with the Flight Reservation application 2. While still recording, view the Graph (Analysis / Graphs) 3. While still recording, view the About Flight Reservation System (Help / About) 4. Stop recording 5. Use the GUI Map Editor to view the GUI objects 6. Write down the physical descriptions for the following GUI objects:
r
"About Flight Reservation System" "Flights Table" Graph
WinRunner Tutorial

Contents
Lesson Nine: Managing GUI Map Files In this lesson, you will learn:
q
two ways to create permanent GUI Map files how to add objects to a GUI Map file use the GUI Spy to read actual object descriptions the syntax to load and unload GUI Map files
q
Two Techniques to Manage GUI Map Files 1. One GUI Map file per test 2. One GUI Map file for many tests
First Technique: One GUI Map File Per Test

During the recording of a test script, WinRunner stores the logical names and descriptions of objects in a temporary GUI Map file. After recording and after WinRunner has created the temporary GUI Map file, you save it to create a permanent GUI Map file.
How to Create a Permanent GUI Map File 1. Record interaction with AUT and save test script 2. Open GUI Map Editor
r
WinRunner Tutorial
If objects are not visible in the Windows/Objects window, select View / GUI Map File / Save Select Save in New File... Select the a:\ drive for Save In: For File Name choose a name similar to the test's name (since for this technique we are using one GUI Map file per test) Select Save
3. Close the GUI Map Editor
r
r
6. Create a new order in Flight Reservation

r
File / New Order

r
Date of Flight: 02/02/02 Fly From: Los Angeles Fly To: San Francisco Click the Flights button and double click on any flight
WinRunner Tutorial
r
Name: Andrew Smith Select First Class Click Insert Order
8. Delete the order by clicking the Delete Order button and then click on Yes in the message window to confirm (this sets the end conditions) 9. Stop Recording 10. Save as test12 on your a:\ drive 11. Open the GUI Map Editor
r
12. Save the GUI Map file (make the temporary GUI Map file a permanent GUI Map file)
r
If objects are not visible in the Windows/Objects window, select View / GUI Map File / Save Select Save in New File... Select the a:\ drive for Save In: For File Name choose test12 Select Save
13. Close the GUI Map Editor 14. Close the test script and the Flight Reservation application
Adding New Objects to a GUI Map File When you saved the GUI Map file above, it has only those items that were in the temporary GUI Map file (that is, only those objects that you interacted with when interacting with the AUT). However, there are more objects that are part of the AUT that you may need to test. For this reason, you will need to add objects to the GUI Map file. Below is the procedure to add windows and objects to a GUI Map file: 1. Interact with the object of the AUT that is not in the permanent GUI Map file while recording
WinRunner Tutorial
2. Open the GUI Map Editor 3. Transfer objects from the temporary GUI Map file to the permanent GUI Map file 4. Save the permanent GUI Map file 5. Close the GUI Map Editor
r
r
6. Press the Help icon (the question mark) 7. Press Search 8. Press Cancel 9. Open the GUI Map Editor
r
10. Press the Expand button

r
If it is not showing, select View / GUI Files
11. On the left side, select test12.gui under GUI File: 12. Notice on the left side, under GUI File: the permanent GUI Map file (test12.gui) is listed on the right side under GUI Map File: the temporary GUI Map file is listed 13. Move objects from temporary GUI Map file to permanent GUI Map file r Highlight objects in Windows/Objects field on the right side
WinRunner Tutorial
r
Press Move and then OK Object should transfer from the temporary GUI Map file to the permanent GUI Map file
14. Save the permanent GUI Map file with its new object or objects r File / Save 15. Close the GUI Map Editor 16. Stop Recording 17. Save as test13 on your a:\ drive 18. Close the test script and the Flight Reservation application
Second Technique: One GUI Map File for Many Tests For this second technique, we will make WinRunner or really the GUI Map Editor learn all the windows and objects of the AUT.
Making the GUI Map Editor Learn the Objects 1. Open AUT 2. Open the GUI Map Editor 3. Click the Learn button and point with the hand pointer to each object of the AUT 4. Save the permanent GUI Map file with a name similar to the AUT (since all tests for the AUT will use this GUI Map file)
Important Note: If you have already saved a permanent file which contains windows and objects of the AUT that you are using the GUI Map Editor to learn, you will be directed to save those new objects in the old permanent file. If you are prompted to add to this other file, click OK.
Test 14: This test will not actually be a test script
WinRunner Tutorial
1. Start WinRunner 2. Start a new test in WinRunner (by pressing the New icon) 3. Start the Flight Reservation application and log in
r
4. Position the two applications so that they do not overlap 5. Open the GUI Map Editor
r
Tools / GUI Map Editor If objects are not showing, select View / GUI Files
6. On the left side, select Temporary under GUI File: 7. Save the temporary (even though it currently has no objects) r File / Save As
r
For File Name: choose flightreservation1a For Save In: choose the a:\ drive Select Save
8. Press the Learn button; the cursor will turn into a hand 9. Single click on the title bar of the AUT (this will make WinRunner learn all the objects of the AUT) 10. Save the objects in the permanent GUI Map file
r
File / Save
WinRunner Tutorial
12. Close the Flight Reservation application
Using the GUI Spy The GUI Spy allows you to look at the AUT and get a complete physical description of each object. The following are the steps to follow to use the GUI Spy:
1. Open AUT 2. Open GUI Spy 3. Press the Spy button 4. Point to any object in the AUT and the GUI Spy will give you a physical description of the object
Test 15: This test will not actually be a test script 1. Start WinRunner 2. Start a new test in WinRunner (by pressing the New icon) 3. Start the Flight Reservation application and log in
r
4. Position the two applications so that they do not overlap 5. Open the GUI Spy 6. Press the Spy button 7. Place the cursor over any object in the AUT and you will be given a physical description 8. Close the GUI Spy 9. Close the Flight Reservation application
WinRunner Tutorial
Loading a GUI Map File There are two ways to load a GUI Map file:
1. In the GUI Map Editor, under GUI File: select the permanent GUI Map file for your test or AUT 2. Add TSL statements to the test script
Adding TSL Statements to Load and Unload GUI Map Files In addition to adding a TSL statement to load a GUI Map file, you should also insert a statement to unload or close the previous GUI Map file.
Syntax for Unloading a GUI Map File: GUI_close_all(); This statement is inserted at the beginning of a test script to close the previous GUI Map file.
Syntax for Loading a GUI Map File: GUI_load("a:\\filename") Important Note: When defining the path to a GUI Map file, always use two back slashes. Since the back slash is a control character in TSL, two are required.
For example, our load statement would be: GUI_load("a:\\test12.gui")
WinRunner and the Mercury Interactive logo are trademarks of Mercury Interactive Corporation.
WinRunner Tutorial
Copyright 2001 David C. Jacobs
WinRunner Tutorial

Contents
Lesson Ten: Batch Tests In this lesson, you will learn:

q
what a batch test is how to create a batch test how to run a batch test and analyze the results how to program a batch test with a for loop
q
Batch Tests Definition: A batch test is a test script that contains call statements that run other test scripts. When a batch statement is run, it opens and executes each test that has been called. A batch test may also include programming elements, such as loops or decisionmaking statments like if-else statements. A batch test appears to be a regular test script, but it differs in two main ways:
it contains call statements to other test scripts it is run in batch mode which instructs WinRunner to suppress messages that might interrupt the test (this allows the tester to run unattended tests)
Call Statements A call statement opens and runs a specific test script. Syntax of a call statement: call "a:\\test1"();
WinRunner Tutorial
Where you would normally put one back slash (between drives, directories, and files), you put two. If you have your test named test10 on the c:\ drive and in a directory named tests the path would look like this: call "c:\\tests\\test10"();
Running in Batch Mode Running the batch test in batch mode will tell WinRunner to suppress messages that would interrupt the test during a regular run of the test scripts. To run in batch mode:
1. Settings / General Options 2. Put a check in the Run in Batch Mode option check box 3. Press OK
We are going to create two test scripts and then create a batch test with them. Test 16 1. Start WinRunner (if it is not already running) 2. Start a new test in WinRunner (by pressing the New icon) 3. Start the Flight Reservation application and log in
r
r

r
File / New Order

r
Date of Flight: 02/02/02
WinRunner Tutorial
Fly From: Frankfurt Fly To: Paris Click the Flights button and double click on any flight Name: Alexander Hamilton Select First Class Click Insert Order

r
9. Stop Recording 10. Save as test16 on your a:\ drive 11. Playback or Run the test script
r
12. Accept the Test Run Name of res1, by pressing OK 13. Examine the Results 14. Close the Results, the test script, and the Flight Reservation application
r
WinRunner Tutorial
5. Start Recording
r

r
File / New Order

r
Date of Flight: 08/07/03 Fly From: Zurich Fly To: Seattle Click the Flights button and double click on any flight Name: Jane Percy Select First Class Click Insert Order

r
r
Batch Test 1 1. Start WinRunner (if it is not already running)
WinRunner Tutorial
2. Start a new test in WinRunner (by pressing the New icon) 3. Start the Flight Reservation application and log in
r
4. Position the two applications so that they do not overlap 5. In the test script, type in the call statements for our last two test scripts: call "a:\\test16"(); call "a:\\test17"(); 8. Configure WinRunner to run this batch test in batch mode
r
Settings / General Options Put a check in the Run in Batch Mode option check box Press OK
9. Save as batch1 on your a:\ drive 10. Playback or Run the test script
r
11. Accept the Test Run Name of res1, by pressing OK 12. Examine the Results 13. Close the Results 14. Don't close the test script and the Flight Reservation application
What did we learn from this batch test? To run more than one test unattended, we can create batch tests will can call numerous test scripts to execute them and it runs in batch mode which will not be interrupted by messages during a test run.
WinRunner Tutorial
Programming a Batch Test with a For Loop We are going to add a for loop to our batch test. This will make WinRunner run these same test scripts multiple times. (This syntax can be used in any test script; it is not restricted to batch tests.) Syntax for a For Loop: for (i=0; i<3; i++) { action to be repeated action to be repeated } i: variable that stores an integer i=0: this initial statement sets the value of i i<3: if this boolean statement will allow the loop to continue i++: this adds 1 to the value of i each time through the loop The curly braces ({}) enclose the functions that will run each time the loop iterates. By enclosing the functions, only these functions will be executed when the loop iterates. Thus, this for loop will execute the actions three times, because the follow of i starts at 0 and the actions execute. The value of i increases by 1 and the actions execute again. They will execute three times, because when i is incremented to 3 the boolean expression will be false and this will stop the loop, and it will be exited.
Batch Test 2 1. Go back into batch1 2. Delete the two current lines of the test script 3. Insert the following syntax: for (i=0; i<3; i++) { call "a:\\test16"(); call "a:\\test17"(); } 10. Save as batch2
r
File / Save As
WinRunner Tutorial
r
For File Name type, batch2 Press Save

r
What did we learn from this batch test? We can add a for loop which will execute the test scripts any number of times that we wish.
Turning Off Batch Mode Since we ran our batch test in batch mode, we have to go back and unselect batch mode so that our next tests are not run in batch mode.
1. Settings / General Options 2. Click on the check in the Run in Batch Mode option check box (this will unselect it) 3. Press OK
WinRunner Tutorial
WinRunner Tutorial

Contents
Lesson Eleven: Data-Driven Tests In this lesson, you will learn:

q
what a data-driven test is how to use the DataDriver Wizard to create a data-driven test how to run a test with several iterations
q
Data-Driven Tests Definition: A data-driven test is a test that instead of having the input of one set of data (for example, entering John Smith as the customer's name for buying tickets) we have multiple sets of data, and with each iteration through the test script WinRunner inserts a different set of data.
How to Create Data-Driven Tests 1. Create a regular test script that inserts one set of data into the AUT
2. Use the DataDriver Wizard to convert test script into a data-driven test script 3. Add statements in your test script to open and close the data table 4. Add statements in your test script to read from the data table and to run in a loop while it applies each set of data 5. Replace fixed values in recorded statements and checkpoint statements with parameters (this is called "parameterizing" the test script)
First, we are going to create a test script that will order a ticket for a flight. Second, we will turn this test script into a data-driven test which will order tickets using different
WinRunner Tutorial
customer names. Our test script will determine if the AUT can receive these different sets of data.
r
r

r
File / New Order

r
Date of Flight: 02/02/02 Fly From: Frankfurt Fly To: Paris Click the Flights button and double click on any flight Name: David Jacobs Click Insert Order

r
WinRunner Tutorial

r
Data-Driven Test 1 1. Save test18 as ddtest1 on your a:\drive 2. Run the DataDriver Wizard
r
Tools / DataDriver Wizard
3. Parameterize the customer's name

r
Read the text displayed in the DataDriver Wizard dialog box Click the Next icon In the Use a new or existing Excel table text field, type: table1.xls Leave table as the variable name Put a check in the Add statements to create a data-driven test check box Put a check in the Parameterize the test check box Select Line by Line Select Next Make sure Do not replace this data is selected and press Next (we do not want to parameterize the date) Make sure Do not replace this data is selected and press Next (we do not want to parameterize the departure city) Make sure Do not replace this data is selected and press Next (we do not want to parameterize the arrival city) Make sure Do not replace this data is selected and press Next (we do not
WinRunner Tutorial
want to parameterize the flight information)

r
Select A new column when the customer's name appears (this we want to parameterize) and then press Next When the DataDriver Wizards says, "Congratulations," press Finish Save the test script again
4. Open the data table to add names

r
Tools / Data Table Notice under the column Name the customer name from our test script Click in the box below the customer name and add: Bill Fairweather Click in the next box down and type: Fridjoff Nansen Click in the next box down and type: Doug Mawson Click in the next box down and type: Helene Cixous
5. Save the table

r
File / Save
6. Close the table

r
File / Close
7. Maximize WinRunner to examine the code in the entire test script
The Parameterized Test Script Code Explained In our data-driven test script, the DataDriver Wizard added ten new lines and changed one line. Lets examine those lines (the new or changed lines are in bold): table = "table1.xls"; rc = ddt_open(table, DDT_MODE_READ); if (rc!= E_OK && rc != E_FILE_OPEN) pause("Cannot open table."); ddt_get_row_count(table,table_RowCount); for(table_Row = 1; table_Row <= table_RowCount; table_Row ++) { ddt_set_row(table,table_Row); set_window ("Flight Reservation", 4); menu_select_item ("File;New Order"); obj_type ("MSMaskWndClass","020202");
WinRunner Tutorial
list_select_item ("Fly From:", "Frankfurt"); # Item Number 1; list_select_item ("Fly To:", "Paris"); # Item Number 3; obj_mouse_click ("FLIGHT", 49, 30, LEFT); set_window ("Flights Table", 1); list_activate_item ("Flight", "13550 ..."); # Item Number 4; set_window ("Flight Reservation", 3); edit_set ("Name:",ddt_val(table,"Name")); button_press ("Insert Order"); set_window ("Flight Reservation", 9); button_press ("Delete Order"); set_window ("Flight Reservations", 1); button_press ("Yes"); } ddt_close(table);
table = "table2.xls"; The variable table will hold the value of the table that we are using in the data-driven test to invoke it when needed.
rc = ddt_open(table, DDT_MODE_READ); The function ddt_open will open our table for our script in read mode; the variable rc holds the function as a value because when the function operates its return status will be the value of the variable and this is used in the next line.
if (rc != E_OK && rc != E_FILE_OPEN) pause("Cannot open table."); The English meaning is this: If the return status of ddt_open is not successful (E_OK) and the return is not that the file is already open (E_FILE_OPEN), then pause and give this message ("Cannot open table."). This is where the variable rc comes in handy. It is being used because when the function ddt_open operates the value of rc will be the return status of the function, and if there is a problem with opening the table the tester is prompted.
ddt_get_row_count(table,table_RowCount); This function retrieves the number of rows in a table; that number then is store by table_RowCount to be used in the for loop.
WinRunner Tutorial
for(table_Row = 1;table_Row <=table_RowCount;table_Row ++) { ... } This for loop is used to loop through the functions inside of the curly braces the same numbers of times as there are rows. If there are five rows in our table, then the for loop will loop five times, and each time it will add new data to one particular place in the AUT. table_Row = 1 is the initializing statement in the for loop; it sets the value of the variable table_Row at 1. This statement is used only once at the beginning of the looping process. table_Row <= table_RowCount is a boolean expression which acts as the on and off switch. If the value of table_Row is less than or equal to table_RowCount, then the loop will continue. Since we know that the value of table_RowCount is 5 because there are five rows, the loop will continue five times through. table_Row ++ adds 1 to the value of table_Row at the end of each loop iteration. Thus, the for loop will execute the functions within the curly braces five times, because the value of table_Row is set at 1 and the loop will continue until the value of table_Row is less than or equal to table_RowCount which we know has the value of 5.
ddt_set_row(table,table_Row); This function will be executed each time through the loop. The function ddt_set_row sets a particular row in our table active. Since table_Row will start at 1 and increment to 5, all the rows in our table will be individually activated through the separate iterations of the for loop.
edit_set("Name:",ddt_val(table,"Name")); This is the only "parameterized" line in our original test script. Originally it was: edit_set("Name:","David Jacobs");. The function ddt_val returns the value of a parameter in the active row in a data table. Thus, since a new line becomes active each time through the loop, different data (the different customer names) are returned and inserted as the customer for a flight reservation.
WinRunner Tutorial
ddt_close(table); This function closes the table used in this data-driven test.
What Will the Data-Driven Test Do? It will create a new order five different times. Each time through the order process it will insert different customer names. The following customer names will individually be inserted for separate orders:
David Jacobs Bill Fairweather Fridjoff Nansen Doug Mawson Helene Cixous
Run the Data-Driven Test 1. Playback or Run the test script

r
2. Accept the Test Run Name of res1 (if it says res2, accept it), by pressing OK 3. Notice the insertion of a different customer name during the different orders 4. Examine the Results 5. Close the Results, the test script, and the Flight Reservation application
What did we learn from this data-driven test script? To create a data-driven test, you utilize the DataDriver Wizard which will walk you through step-by-step in parameterizing a test script so that it will insert different data into the test each time through an iteration of the test.
WinRunner Tutorial
WinRunner Tutorial

Contents
Lesson Twelve: Review for Final Exam
Ways to Study for Final Exam

q
Look over your notes Look over your test scripts Look over the WinRunner tutorial Examine your answers to the review questions

q q
LESSON EIGHT LESSON NINE LESSON TEN LESSON ELEVEN
The Complete Collection of Review Questions 1. What is the tester's role in software development?
LESSON TWELVE
2. What does the tester do in white box testing? 3. How does the tester perform black box testing? 4. What does the tester do in automated testing?
5. What are the benefits of automated testing over white box and black box testing? 6. Name three types of tests that should be automated. 7. Name three types of tests that should NOT be automated.
8. What are the four steps of automated testing? 9. What is an IDE? 10. What are the three aspects of GUI software to test for with WinRunner? 11. What are the two ways to create test scripts?
WinRunner Tutorial
12. What are the four steps to record a test script? 13. Why position WinRunner and the AUT so they do not overlap? 14. What icon is used in WinRunner to get an explanation of the syntax of TSL? 15. What are the two recording modes in WinRunner? 16. Which recording mode is suggested for most situations? 17. Name three reasons why the tester may choose to record in Context Sensitive mode. 18. Name three reasons why the tester may choose to record in Analog mode. 19. When we are recording in WinRunner and interact with the AUT, what does WinRunner do? 20. How does the tester run or playback a test script? 21. Name two ways the AUT can be changed when the tester interacts with it during recording. 22. How might the two changes you listed for Question #1 affect subsequent tests? 23. What are initial conditions? 24. What are end conditions? 25. Why are initial and end conditions necessary? 26. If a test script instructs WinRunner to open an application to test it, what end conditions might be good? 27. If the tester names a test test1, what will be the name of the directory for this test? 28. Why is a lock file created? 29. What is contained in a chklist subdirectory? 30. Name four subdirectories that might be in the directory for the test described in Question #27. 31. If the AUT does not respond quickly enough for an action to be executed in the test script and WinRunner moves to the next action, why would this be a problem? 32. Name three actions that may take the AUT more time to perform that would require synchronization. 33. What is a synchronization point?
WinRunner Tutorial
34. Name four types of synchronization. 35. The AUT we tested did not have a synchronization problem, how did we create the problem? 36. How many milliseconds are in one second?
The following four questions use this line of syntax: obj_wait_bitmap("Insert Done...","Img1",10);
37. In the above statement, what is obj_wait_bitmap? 38. In the above statement, what is "Insert Done..."? 39. In the above statement, what is "Img1"? 40. In the above statement, what is 10? 41. What is verification in manual testing? 42. How is the definition of verification with WinRunner different than with manual testing? 43. What are the four steps of how WinRunner verifies? 44. Name three things that we might test with GUI checkpoints. 45. Name three examples of visual cues that might be used to establish GUI checkpoints.
The following five questions use this line of syntax: obj_check_gui("Order No.","list1.ckl","gui1",1);
46. In the above statement, what is obj_check_gui? 47. In the above statement, what is "Order No."? 48. In the above statement, what is "list1.ckl"? 49. In the above statement, what is "gui1"? 50. In the above statement, what is 1?
WinRunner Tutorial
51. What is bitmap verification? 52. What is the process for establishing bitmap checkpoints? 53. In our test using bitmap checkpoints, why did we switch to analog mode? 54. In our test using bitmap checkpoints, when did WinRunner capture the expected object to compare with the actual object? 55. How can we view the captured expected object before and after we run our test? 56. What statement did WinRunner insert into our test script to test our bitmap image?
The following four questions use this line of syntax: obj_check_bitmap("(static)","Img1",10);
57. In the above statement, what is obj_check_bitmap? 58. In the above statement, what is "(static)"? 59. In the above statement, what is "Img1"? 60. In the above statement, what is 10? 61. Name three times you would use text verification. 62. When setting up a test to verify text, what is the purpose of declaring a variable? 63. In the basic syntax of an if-else statement, if the condition is false, what happens? 64. What does a tl_step do?
The following six questions use these lines of syntax: if (new_total == first_total + 1) tl_step("Graph Total",PASS,"Total is correct."); else tl_step("Graph Total",FAIL,"Total is incorrect.");
65. What line of syntax is the condition? 66. If the AUT functions correctly, what will be the status?
WinRunner Tutorial
67. If the AUT does not function correctly, what will be the status? 68. What is "Graph Total"? 69. Under what conditions would the first action execute? 70. Under what conditions would the second action execute? 71. What is a GUI Map file? 72. As an attribute of an object, what is the class? 73. As an attribute of an object, what is the label or attached text? 74. As an attribute of an object, what is the MSW_id? 75. As an attribute of an object, what is the parent?
The following two questions use this line of syntax: password_edit_set("Password:","kzptnyoslzjsaz");
76. In the above line of syntax, what is password_edit_set? 77. In the above line of syntax, what is "kzptnyoslzjsaz"? 78. What does the GUI map connect together in the test script and in the AUT? 79. During the recording of a test script, what does WinRunner do regarding the GUI Map file? 80. During the playback of a test script, what does WinRunner do regarding the GUI Map file? 81. In general terms, what are the two ways to manage GUI Map files for tests? 82. How does one create a permanent GUI Map file from a temporary GUI Map file? 83. How can one add objects to a permanent GUI Map file? 84. How can one make a GUI Map file for a complete software application? 85. What can you do with the GUI Spy? 86. What are the two ways to load a GUI Map file? 87. What is the syntax for loading a GUI Map file through TSL statements?
WinRunner Tutorial
88. What is the syntax for unloading a GUI Map file through TSL statements? 89. Why use two back slashes (\\) as part of the syntax for loading and unloading GUI Map files? 90. What is a batch test? 91. What are the two main ways that a batch test is different than a regular test script? 92. What does a call statement do? 93. What is the syntax for a call statement? 94. What does running the batch test in batch mode do?
The following four questions use these lines of syntax: for (i=0; i<3; i++) { call "a:\\test16"(); call "a:\\test17"(); }
95. What does i=0 do? 96. What does i<3 do? 97. What does i++ do? 98. How many times will this for loop iterate (or loop) through the call statements? 99. What do the curly braces do? 100. What is a data-driven test? 101. Why create a data-driven test? 102. What is a data table? 103. In a parameterized test script, what will the following two lines of syntax do? if (rc != E_OK && rc != E_FILE_OPEN) pause("Cannot open table."); 105. What does the function ddt_open do? 106. What does the function ddt_get_row_count do?
WinRunner Tutorial
107. What does the function ddt_set_row do? 108. In our parameterized test, different customer names were inserted in the application each time a new order was created; where did the names come from? 109. What does the function ddt_close do? 110. How many times did our parameterized test create an order with a different customer name? How was this number established
HOME | PREVIOUS LESSON | REVIEW THIS LESSON WinRunner and the Mercury Interactive logo are trademarks of Mercury Interactive Corporation. Copyright 2001 David C. Jacobs
WinRunner Tutorial
WinRunner Tutorial
q
It is best viewed with Internet Explorer, with Medium size text (set this by going to View / Text Size / Medium), and with the resolution set at 800 by 600 Since WinRunner is not going to function well with a browser running that is not part of the test, either print out each lesson and then follow along or in a classroom have two computers running (one running WinRunner and another viewing this tutorial) Follow each lesson from the beginning to the end (and it is best to start at the beginning of the tutorial and proceed through each lesson until you have finished all lessons -- at least for the first time through)
1. Introduction 2. Recording Tests, Playback, Context Sensitive and Analog Modes 3. Initial and End Conditions, Organizing Files 4. Synchronizing Tests 5. GUI Verification 6. Bitmap Verification 7. Text Verification 8. Introduction to GUI Map Files 9. Managing GUI Map Files 10. Batch Files 11. Data-Driven Tests 12. Review for Final Exam
where the tester fits within software development different types of testing (white box, manual, and automated testing) where automated testing is beneficial and where it is not beneficial how automated testing follows the steps of manual testing some basics about WinRunner
http://www.htmlmule.com/wr/wt.html (1 of 64) [12/9/2003 12:40:31 AM]
WinRunner Tutorial
1. Client defines what the software should be like (the expected object or the requirements) 2. Developer produces software according to client's requirements 3. Tester tests software against requirements and reports bugs to developer 4. Developer fixes bugs and modifies software according to latest requirements
1. White Box Testing: The tester examines the code of the AUT (Application Under Testing) to see if the code is written correctly 2. Manual Testing / Black Box Testing: The tester uses the application in order to test it (testing for properties, appearance, and functionality) 3. Automated Testing: The tester creates test scripts that test the application similar to manual testing (testing for properties, appearance, and functionality)
r
Excellent for regression testing, because the same scripts can be run again and again
Compared to white box testing:

r
not as expensive in the long run better for functionality and regression testing
Compared to black box testing:

r
more reliable more consistent reusable and repeatable inherent programming capabilities
Tests that need to be run for every build of the application Tests that use multiple data values for the same actions (data-driven tests) Tests that require detailed information from application internals (e.g., GUI attributes)
WinRunner Tutorial
Stress/load testing Any test that has a repetitive feature (test one object multiple times in one test or test the same objects through multiple builds of the software)
Usability testing (how easy is the software to use?): the tester needs to use the software as a user One-time testing: automated will be too time consuming ASAP or Quick-look testing: automated will be too time consuming Ad hoc or random testing (testing the software based on hunches): automated will be too time consuming to set up General rule: if improvisation is required or little time is available, avoid automated testing and use manual testing
Automated testing follows the steps of manual testing Manual Testing Steps
1st Step Perform user actions
2nd Step Wait for process to complete
3rd Step Verify AUT
4th Step Repeat for all actions of AUT
Automated Testing Steps 1st Step Generate automated test script 2nd Step Synchronize script and AUT 3rd Step Add verification tests 4th Step Run test scripts
Created by Mercury Interactive, Inc. in 1992 WinRunner is an automated testing tool that tests GUI software and web pages WinRunner combines a GUI software package and scripting language
WinRunner Tutorial
r
GUI software package: Integrated Development Environment (IDE) allows the tester to record, write, edit, run test scripts in one environment Scripting language: Test Script Language (TSL) is based on C
Three aspects of GUI software to test with WinRunner

r
Functions Properties Bitmap features
How WinRunner Basically Tests The tester creates a test script by recording the interaction with the AUT The tester can insert "checkpoints" to test the properties, appearance, and text of objects The tester can enhance test scripts with code The tester can enhance test scripts with data for a data-driven test which inserts data to determine if the AUT will accept it The tester easily runs the test by pressing an icon The tester reads the results A temporary GUI Map file is created while recording; the GUI Map file acts as an interpreter between application and test script
Windows 95 Windows 98 Windows NT Windows ME Windows 2000
Netscape, Microsoft Internet Explorer Java applets, Java applications, JavaScript ActiveX, OCX Controls
WinRunner Tutorial
q
WAP ERP/CRM applications (Oracle applications, PeopleSoft, SAP, Siebel) Terminal emulators (mainframe, AS/400, Unix servers) Visual Basic C/C++ PowerBuilder Delphi
WinRunner User's Guide WinRunner Tutorial TSL Online Reference WinRunner Student Handbook (from Mercury Interactive classes)
Lesson Two: Recording Tests, Playback, Context Sensitive and Analog Modes In this lesson, you will learn:
q
how WinRunner tests are recorded how to playback a test the differences between analog and context sensitive recording
1. Recording the test script as you interact with the application 2. Writing or scripting the test script in test script language (TSL)
1. Start WinRunner
r
Start / Programs / WinRunner / WinRunner Close the Add-In Manager, by clicking OK If the Welcome to WinRunner dialog appears, uncheck the Show at Startup check box, then close the Welcome to WinRunner dialog by pressing the X in the top right
WinRunner Tutorial
2. Start the AUT 3. Start a new test script (by pressing the New icon selecting File / New) 4. Activate the recording function (by pressing the Record icon or selecting Create / Record Context Sensitive) 5. Interact with the AUT 6. Stop recording (by pressing the Stop icon) 7. Save the test script
1. Put a floppy in the a:\ drive 2. Start WinRunner (if you have not already done so)
r
Start / Programs / WinRunner / WinRunner
3. Close all other applications (even the internet browser you are using; this is why it is best to print out this tutorial) 4. Start our AUT (WordPad)
r

r
Why? So that you can see both applications clearly and so that you can interact with both applications and the actions do not get executed by the incorrect application Position WinRunner on the left and the AUT on the right
6. Start a new test script in WinRunner

r
File / New or press the New icon
7. Start recording
r
Click the red Record icon Or Create / Record - Context Sensitive Or press F2
8. Click inside of WordPad and type these lines: This is the first line. This is the second line. This is the third line.
WinRunner Tutorial
This is the fourth line. 13. Click on the Search icon (binoculars) in WordPad
r
In the Find What text field, type: line Click on Find Next four times Press Cancel
14. In WordPad, click the New icon or select File / New

r
Press OK Do not save changes, by selecting No
15. Stop Recording, by pressing the Stop icon in WinRunner 16. Save the test script in WinRunner
r
File / Save Save In: a:\ drive File Name: test1 Press Save

r
18. Accept the Test Run Name of res1, by pressing OK 19. Examine the Results and then close Results 20. Maximize WinRunner's window and look at the test script; these are our recorded movements interacting with WordPad 21. Click on the Help Icon (arrow and question mark) and then click on the first line (this will explain the syntax of the script) 22. set_window ("Document - WordPad", 3);
r
set_window activates the window to receive input "Document - WordPad" is the logical name of WordPad 3 is the number of seconds before the next function in the test script will run (plus the default time)
23. Close the TSL Online Reference window, WordPad, and the test script
WinRunner Tutorial
What did we learn from this test script? Recording a test script in WinRunner is as simple as pressing the Record icon and interacting with the AUT, and running or playing back the test script will execute the movements that were recorded. In this way, we can test the functionality of the AUT.
1. Context Sensitive Mode (the default mode)

r
Context Sensitive statements describe actions made to GUI objects and are recommended for most situations, where the test scripts are:
s
object-based not affected by user interface changes (i.e., movement of objects)
Software examples: menus, icons, check boxes
2. Analog Mode
r
Analog statements are useful for literally describing the keyboard, mouse, and mouse button input of user Test scripts are:
s
screen-coordinate dependent based on mouse and keyboard activities (e.g., mouse movement, press, and release, and keyboard input) Software examples: virtual reality environment, drawing, paint brush strokes
Choose Context Sensistive if: The application contains GUI objects Exact mouse movements are not required You plan to reuse the test in different versions of the application Why? Movements of the GUI objects in different builds will not affect the test.
Choose Analog if: The application contains Bitmap areas (e.g., a drawing area) Exact mouse movements are required You do not plan to reuse the test in different versions of the application Why? Movements of the GUI objects in different builds will affect the test.
WinRunner Tutorial
1. Start a new test in WinRunner (by pressing the New icon) 2. Open Flight Reservation application
r
3. Log on the Flight Reservation application

r
Type your first name in the Agent Name field (your name must be at least four characters long) Type mercury in the Password field and click OK
4. Position the two applications so that they do not overlap 5. Start recording
r

r

r
r
14. Accept the Test Run Name of res1, by pressing OK 15. Notice that WinRunner will not sign your name; it finds Agent Signature area but not the exact place to start writing 16. Examine the Results and then close Results 17. Close the test script
WinRunner Tutorial
What did we learn from this test script? Given the instructions from the test script, WinRunner can find the object to write in but not the exact place. Because of this, the writing of our name did not take place. Thus, analog mode is required for this to work properly.
1. Start a new test in WinRunner (by pressing the New icon) 2. Start recording in Analog mode
r
Press the Record icon and F2 Or select Create / Record - Analog

r

r
r
11. Accept the Test Run Name of res1, by pressing OK 12. Examine the Results and then close Results 13. Close the test script and the Flight Reservation application
WinRunner Tutorial
What did we learn from this test script? With the test script recorded in analog mode, WinRunner can precisely place the mouse pointer in the exact location inside of the drawing window. Because of this, the test script can write our signature and hence perform the test properly.
Lesson Three: Initial and End Conditions, Organizing Files In this lesson, you will learn:
q
why there is a need to set initial and end conditions how to set initial and end conditions for your tests how WinRunner organizes your files
by entering data into text fields by enabling icons that were grayed out before the test or graying out buttons that were enabled before the test
When WinRunner runs a test script, the AUT may not be in the same condition it was before the test The test may not be able to interact with the AUT as the test script describes; thus, the test script will not function properly and will not generate a good test of the AUT
Important Note: The end condition of an AUT after a test has run should not affect a subsequent test upon the AUT. If the subsequent test is affected by the earlier test, the AUT is not being tested properly. In other words, the subsequent test is not reliable or useful.
For example:
1. If a test script instructs WinRunner to open an application to test it, make sure the end condition closes the application (otherwise, running the same test twice may create problems). 2. If a test enters data into text fields, have the end conditions clear the data (as we did with Test 1).
WinRunner Tutorial
1. Start a new test in WinRunner (by pressing the New icon) 2. Start WordPad
r
r
5. Type this in WordPad: WinRunner was created by Mercury Interactive. Mercury Interactive makes a variety of testing tools. Mercury Interactive trades stock with the symbol MERQ. 6. Select the Find icon (binoculars); search for the word: interactive 7. Select Find Next three times and press Cancel 8. Stop recording 9. Save as test4 on your a:\drive 10. Playback or Run the test script
r
11. Accept the Test Run Name of res1, by pressing OK 12. Look at the text in WordPad; the same text was entered twice (once when we recorded the test script and another time when we ran the test script)
What did we learn from this test script? The running of this test script entered the same data as the recording of our interaction with the AUT, because it did not clear the data already entered. This could become a problem in a more complicated test.
13. Close the Results, the test script, and WordPad

r
In WordPad, select No to avoid saving changes
WinRunner Tutorial
1. Start a new test in WinRunner (by pressing the New icon) 2. Start WordPad
r
r
5. Type this in WordPad: WinRunner was created by Mercury Interactive. Mercury Interactive makes a variety of testing tools. Mercury Interactive trades stock with the symbol MERQ. 6. Select the Find icon (binoculars); search for the word: interactive 7. Select Find Next three times and press Cancel 8. Create end conditions to clear the data
r
Select the New icon in Word Pad (this will create end conditions by clearing the data for the next test of WordPad) In the New window of WordPad, select OK Select No for saving changes in WordPad
9. Stop recording 10. Save as test5 on your a:\ drive 11. Playback or Run the test script
r
12. Accept the Test Run Name of res1, by pressing OK 13. Examine and then close the Results 14. Run test script again 15. Accept the Test Run Name of res2, by pressing OK 16. Close the Results, the test script, and WordPad
WinRunner Tutorial
What did we learn from this script? The end conditions clear the data from the AUT during the running of the test, so that the data will not get in the way of the next running of the test.
a script file a backup script file (if WinRunner is configured to do this) a header file a lock file containing the name of the user and a process id exists while the a test script is open to prevent others from opening it, but it is automatically deleted when the test script is closed a db subdirectory which contains files which influence playback and which should not be changed a res1 subdirectory which contains the first set of results of your test a exp subdirectory which contains the expected results for some tests
A directory for a test could also contain:
a chklist subdirectory which contains the checklists for objects to be checked for GUI tests a debug subdirectory which contains the results of running your test script in debug mode a table file which contains the data for a data-driven test
Lesson Four: Synchronizing Tests In this lesson, you will learn:

q
when you should synchronize a test how to synchronize a test
Software retrieving information from a database
WinRunner Tutorial
Waiting for a window to pop up Waiting for a progress bar to reach 100% Waiting for a status message to appear
If WinRunner waits for these objects and functions for the full ten seconds of the default interval time (or the set time by the function in the script), then it will move on to the next action in the script which may not execute correctly.
Types of Synchronization Cue Window Object State Bitmap Outcome Wait for window Wait for an object state Wait for a bitmap to refresh Test Script Function set_window obj_wait_info obj_wait_bitmap wait
Elapsed Time Wait for a set time to elapse
Important Note: Our software does not currently have a synchronization problem. We will create one by changing the default interval between actions in a test script. This changes the default time for all subsequent test scripts, so you must change it back after you run this test script.
1. Start WinRunner (if it is not already running) 2. Start a new test in WinRunner (by pressing the New icon) 3. Start the Flight Reservation application and log in
r
r
WinRunner Tutorial
r
File / New Order

r
Date of Flight: 02/02/02 Fly From: Los Angeles Fly To: San Francisco Click the Flights button and double click on any flight Name: Steve Johnson Select First Class Click Insert Order

r
1. Settings / General Options 2. Click the Run tab 3. For Timeout for checkpoints and CS statements, change the value to 1000 milliseconds (which equals 1 second) 4. Click OK
1. Make sure the test6 test window is active in WinRunner, by clicking on the title bar 2. Playback or Run the test script
r
3. Accept the Test Run Name of res1, by pressing OK 4. Notice that WinRunner fails to click the Delete Order button because it is still disabled (WinRunner did not wait until the Insert Order operation was completed)
WinRunner Tutorial
5. Select Continue in Warning Message Box 6. The test fails again because it cannot find the Flight Reservations Message Box 7. Select Cancel in the Run Wizard dialogue box
1. Make sure the test6 test window is active in WinRunner, by clicking on the title bar 2. Place the cursor at the point where you want to synchronize the test
r
Add a blank line after the button_press ("Insert Order"); statement Place the cursor in the blank line
3. Synchronize the test so that the test script waits for the "Insert Done" message to appear in the status bar
r
Create / Synchronization Point / For Object/Window Bitmap Use the hand pointer to click the status bar in the Flight Reservation window (where the phrase, "Insert Done...", is) WinRunner will insert an obj_wait_bitmap synchronization point in the test script
4. Manually change the 1 second wait in the script to 10 seconds
Change the following line: obj_wait_bitmap ("StatusBar95", "Img1", 1); To read: obj_wait_bitmap ("StatusBar95", "Img1", 10);
5. Save the test script again 6. Maximize WinRunner
obj_wait_bitmap: the function in the test script which waits for ten seconds for the image to appear before moving on to the next action "StatusBar95": the logical name of the image (your test script may have "Insert Done..." as the logical name) "Img1": the file name of the bitmap (the image) 10: the amount of seconds to wait for the image to appear (plus the default which we changed to one second)
WinRunner Tutorial
Close the TSL Reference window
1. Position the two applications so that they do not overlap 2. Make sure the test6 test window is active in WinRunner, by clicking on the title bar 3. Playback or Run the test script
r
4. Accept the Test Run Name of res2, by pressing OK 5. Watch how WinRunner waits for the "Insert Done" message to appear in the status bar 6. Review the results
r
Double click on the "wait for bitmap" event to see the bitmap image WinRunner was waiting for
What did we learn from this test script? When testing an AUT with synchronization problems, we must insert a synchronization point to stop WinRunner momentarily in its running of the test script so that the AUT can perform its actions. If we don't do this, the test will not run properly.
1. Settings / General Options 2. Select Run tab 3. For Timeout for checkpoints and CS statements, change the value to 10000 milliseconds 4. Click OK
1. Maximize WinRunner 2. Use the Help icon (arrow and question mark) to determine the action and syntax 3. Write down in your notes answers to the following questions about these lines from our test script:
WinRunner Tutorial
set_window ("Flight Reservation", 2); What is set_window? What is its action? What is "Flight Reservation"? What is 2?
edit_set ("Name:", "Steve Johnson"); What is edit_set? What is its action? What is "Name:"? What is "Steve Johnson"?
button_set ("First", ON); What is button_set? What is its action? What is "First"? What is ON?
Lesson Five: GUI Verification In this lesson, you will learn:

q
what verification is how to insert GUI checkpoints to verify GUI objects
If the actual object matches the expected object, the AUT passes the test; if the actual object does not match the expected object, the AUT fails the test.
Actual Object
should match...
Expected Object
The functions, properties, and appearance of the actual object should match the functions, properties, and appearance of the expected object.
WinRunner Tutorial
1. The tester stores an expected result with the recorded test script (known as a "Checkpoint") 2. WinRunner captures an actual result during playback 3. WinRunner compares the actual result with the stored, expected result 4. WinRunner reports the comparison outcome as PASS or FAIL
Definition of a Checkpoint: A TSL statement that verifies that the actual object matches the expected object.
To verify a GUI object, we use GUI checkpoints; GUI checkpoints are placed in a test script and test a GUI object according to a specific checklist of properties that we create. With GUI checkpoints we can test to determine, for example:
r
if a window is the correct size if a button is enabled or disabled if the correct text is in a text field if boxes are checked or unchecked if a list has the correct number of items
1. Determine the visual cues to verify 2. Create the GUI checkpoint 3. Test the checkpoint to ensure that it works for PASS and FAIL conditions (we will not be doing this) 4. Run the recorded test script to verify correct execution
a window appears during interaction with AUT an object changes state (for example, from enabled to disabled, from focused to unfocused) output data is returned from the system (for example, the total price of a sale or invoice number)
WinRunner Tutorial
q
a message is returned from the system (for example, "Purchase completed")
r
r
6. Open the Open Order dialog box in Flight Reservation

r
File / Open Order Move the Open Order dialog box so that it does not overlap with WinRunner
7. Create a GUI checkpoint for the Order No. check box

r
Create / GUI Checkpoint / For Object/Window Use the hand pointer to double-click on the Order No. check box The Check GUI dialog box opens and displays the available checks Accept the default check ("State"); this will capture the current state ("OFF") of the check box and stores it as expected results Click OK The obj_check_gui statement will appear in the test script
8. Check the Order No. check box and enter 4 as the Order No. 9. Create another GUI checkpoint for the Order No. check box
r
Create / GUI Checkpoint / For Object/Window Use the hand pointer to single click on the Order No. check box WinRunner inserts a checkpoint for the default check ("State") by inserting the obj_check_gui statement in the test script
10. Create a GUI checkpoint for the Customer Name check box
r
Create / GUI Checkpoint / For Object/Window
WinRunner Tutorial
r
Use the hand pointer to double click on the Customer Name check box Accept the default check "State" Also, select "Enabled" as an additional check The State check captures the current state ("OFF") of the check box; the enabled check captures the current condition ("OFF") of the check box Click OK
11. Click OK in the Open Order dialog box to open the order 12. Stop recording 13. Save as test7 on your a:\ drive 14. Playback or Run the test script
r
r
Click on end GUI checkpoint They show the expected value and the actual value
17. Close the GUI Checkpoint Results window 18. Close the Results and the Flight Reservation application
obj_check_gui: the function in the test script that performs the GUI verification; it compares the actual GUI object and the expected GUI object "Order No.": logical name of GUI object to be verified "list1.ckl": name of checklist which defines the GUI checks "gui1": captured data in file used as the expected results 1: time interval in seconds (plus default time) to capture data from GUI object
19. Close the TSL Reference window 20. Close the test script
WinRunner Tutorial
What did we learn from this test script? In order to verify a property of a GUI object, we can insert GUI checkpoints; these checkpoints will verify the properties of the GUI object according to the checklist that we create.
Lesson Six: Bitmap Verification In this lesson, you will learn:

q
how to test Bitmap images in your application how to insert Bitmap checkpoints to verify Bitmap images
Recall that verification is the process by which WinRunner reports whether expected results are actualized by the application With Bitmap verification, WinRunner is comparing a Bitmap image (the actual object) with the expected object pixel by pixel to verify that the actual object matches the expected object
Bitmap Image (Actual Object)
should match...
Bitmap Image (Expected Object)
1. Determine the Bitmap object to verify 2. Create the Bitmap checkpoint 3. Test the Bitmap checkpoint to ensure that it works for PASS and FAIL conditions (optional) 4. Run the recorded test script
r
WinRunner Tutorial
r
6. Open order #6
r
File / Open Order Select the Order No. check box and type 6 Click OK
7. Open the Fax Order dialog box

r
File / Fax Order
8. Enter 347 710 6526 in the Fax Number field 9. Move the Fax Order dialog box so that it does not overlap WinRunner 10. Switch to Analog mode
r
11. Sign your first name in the Agent Signature box with the mouse pointer 12. Switch back to Context Sensitive mode
r
13. Insert a Bitmap checkpoint that verifies your signature

r
14. Click the Clear Signature button 15. Insert another Bitmap checkpoint that checks the Agent Signature box
r
16. Click the Cancel button on the Fax Order dialog box 17. Stop recording
WinRunner Tutorial
18. Save as test8 on your a:\ drive 19. Don't run the test; instead, lets view the expected results first
r
Open the Test Results Window Tools / Test Results View the captured Bitmaps
s
Double click on the first "capture bitmap" event Double click on the second "capture bitmap" event
Close the Test Results window

s
File / Exit

r
21. Accept the Test Run Name of res1, by pressing OK 22. Examine the Results and then close the Results
obj_check_bitmap: the function in the test script that performs the Bitmap verification h "(static)": the logical name of the object "Img1": the file name of the captured Bitmap (the image) 10: the amount of seconds to wait for the image to appear (plus the default time)
22. Close the TSL Online Reference window 23. Close the test script and the Flight Reservation application
What did we learn from this test script? To verify a Bitmap image, we insert a Bitmap checkpoint in the test script to compare the actual Bitmap object with the expected Bitmap object. WinRunner will then compare the actual object and the expected object pixel by pixel to determine if the actual object matches the expected object.
WinRunner Tutorial
Lesson Seven: Text Verification In this lesson, you will learn:

q
how to test text elements in an application how to insert text checkpoints to verify text elements
When text is not part of a GUI object (e.g., a label or caption) When text is part of a bitmap image When text is part of a non-standard, custom GUI object
If text is: A property of a standard GUI object Part of custom GUI object which cannot be read from the property Part of Bitmap or in ASCII (not part of GUI object)
Use: Context Sensitive functions (e.g., obj_get_info, button_get_info) obj_get_text text reading feature (e.g., win_get_text)
1. Declare a variable in the script and assign it the expected value (in this test, we will compare the actual text object with the expect text object) 2. Insert a function to read (or get) the actual text from the AUT during playback 3. Insert code to compare the actual value with the expected value 4. Insert code to report the comparison outcome to the WinRunner Test Results (e.g., PASS or FAIL)
VariableName="value"; VariableName is the name of the variable. "value" is the value of VariableName as a string item. The variable that we will declare in our next test script will be:
WinRunner Tutorial
VersionNum="Version 1.0";
If-Else Statement We will also include an if-else statement in our test script. This statement will be used to compare the actual text object and the expected text object and to report to us if the actual text object passed or failed the test. The syntax for an if-else statement in TSL is: if (condition) action1 else action2 If the condition is TRUE, then action1 will execute and action2 will be ignored. If the condition is FALSE, then action1 will be ignored and action2 will execute. The code that we will insert in our test script is the following: if (VersionNum == text) tl_step("Check Version",PASS,"Version is correct."); else tl_step("Check Version",FAIL,"Version is incorrect."); This code explained: VersionNum: the variable that will hold the expected value text: the variable that will hold the actual value tl_step: function that inserts a status message in the test results for a single section of the test script The syntax for the tl_step function is: tl_step (step_name, status, description); tl_step: function step_name: the name of the test step status: PASS or FAIL status of test step description: description of status to be printed in results
Passing the Testing
WinRunner Tutorial
If the expected text object (expected text value stored in VersionNum) is the same as the actual text object (actual text value) stored in text, then the test step will have the status of PASS and the phrase ("Version is correct.") will print in the results. Failing the Test If the expected text object (expected text value stored in VersionNum) is NOT the same as the actual text object (actual text value) stored in text, then the test step will have the status of FAIL and the phrase ("Version is incorrect.") will print in the results.
How to Read or Get the Text In order to verify the text, we need to get the text. The following describes how to get the text:
1. Go to the window or object in the AUT where you need to get the text 2. Use WinRunner to get the text
r
Create / Get Text / From Screen Area
Three Modes to Run a Script In Recall the three modes that you can run a script in:
Verify Debug (we will use debug the first time after we add lines of code to our test script to make sure the code is correct) Update
Test 9: This test will read text from a Bitmap area and then verify it 1. Start WinRunner 2. Start a new test in WinRunner (by pressing the New icon) 3. Start the Flight Reservation application and log in
r

WinRunner Tutorial
5. Start Recording
r
6. Open the About window in Flight Reservation application

r
Help / About
7. Read the version number text

r
Create / Get Text / From Screen Area The pointer becomes crosshairs Move the cursor slightly above and to the left of what you want to capture (a quarter inch away from "Version 1.0") Hold down the left mouse button and drag the cursor so that the text you want to capture (and no other text) is enclosed by a rectangle, then release the mouse button Press the right mouse button to complete the operation
8. Close the About window by pressing the OK button 9. Stop recording 10. After the last line of the test script, insert the variable that holds the expected text value VersionNum="Version 1.0"; 12. After the last line of the test script, type in the following code which will verify that the actual text matches the expected text:
if (VersionNum == text) tl_step("Check Version",PASS,"Version is correct."); else tl_step("Check Version",FAIL,"Version is incorrect.");
12. Save as test9 on your a:\ drive 13. Check the test script by running it in debug mode
r
14. Playback or Run the test script in verify mode

r
Click the Run from Top icon
WinRunner Tutorial
Or Run / Run from Top
15. Accept the Test Run Name of res1, by pressing OK 16. Examine the Results 17. Close the Results and the Flight Reservation application 18. Open the Flight Reservation (1B)
r
Start / Programs / WinRunner / Sample Applications / Flight 1B
19. Playback or Run the test script again with this application in verify mode
r
r
This test should have failed
22. Close the Results, the Flight Reservation application, and the test script
What did we learn from this test script? To verify text that is part of a Bitmap area, the tester must get the text (or read the text), and insert code to verify the text.
Reading Text from an Application If your AUT has an area that generates a total number of orders, etc., you can read the text, place an order, and verify that the order number has gone up by one. To do this, you must: 1. Get the text 2. Add an order 3. Synchronize the test (to ensure the test script waits for order to take place) 4. Get the text again 5. Change the name of the variables 6. Insert an if-else statement
WinRunner Tutorial
Why Change the Name of a Variable? When we get or read the text twice (once before a new order and once after a new order). The order should increase the number of orders by 1. However, when we get the text, the variable text will be used to hold both values. The first time we get the text we will:
Change text to first_total
The second time we get the text, we will:

q
Change text to new_total
In this way, we can verify if new_total is equal to first_total + 1. The code that we will insert in our test script is the following: if (new_total == first_total + 1) tl_step("Graph Total",PASS,"Total is correct."); else tl_step("Graph Total",FAIL,"Total is incorrect."); This code explained: new_total: variable that holds the value after a new order first_total: variable that holds the value before a new order tl_step: function that inserts a status message in the test results for a single section of the test script The syntax for the tl_step function is: tl_step (step_name, status, description); tl_step: function step_name: the name of the test step status: PASS or FAIL status of test step description: description of status to be printed in results
Passing the Testing
WinRunner Tutorial
If the AUT correctly adds a number to the total number of orders after a new order, new_total will be equal to first_total + 1. If this occurs, then the test step will have the status of PASS, and the phrase ("Total is incorrect.") will print in the results. Failing the Test If the AUT does not correctly add a number to the total number of orders after a new order, new_total will NOT be equal to first_total + 1. If this occurs, then the test step will have the status of FAIL, and the phrase ("Total is incorrect.") will print in the results.
Test 10: This test will read text that is generated by an application 1. Start WinRunner 2. Start a new test in WinRunner (by pressing the New icon) 3. Start the Flight Reservation application and log in
r
r
6. Open the graph in Flight Reservation

r
7. Read the total tickets sold from the graph

r
8. Close the graph 9. Create a new order

r
File / New Order
10. Enter flight and passenger information

WinRunner Tutorial
Date of Flight: 02/02/02 Fly From: Denver Fly To: San Francisco Click the Flights button and double click on any flight Name: Sherri Moore Tickets: 1
11. Insert the order, by clicking the Insert Order button 12. Synchronize the test so that it waits for the "Insert Done" message to appear in the status bar
r
Create / Synchronization Point / For Object/Window Bitmap Use hand pointer to click the "Insert Done" message
13. Open the graph again in Flight Reservation application

r
14. Read the total from the graph

r
15. Close the graph 16. Stop recording 17. Save as test10 on your a:\ drive
Inserting an If-Else Statement and Changing the Variable Names 18. In the first obj_get_text statement in the test script, change the variable text to first_total 19. In the second obj_get_text statement in the test script, change the variable text to new_total 20. Place the cursor below the last line in the test script
WinRunner Tutorial
21. Add the following statements to the test script:
if (new_total == first_total + 1) tl_step("Graph Total",PASS,"Total is correct."); else tl_step("Graph Total",FAIL,"Total is incorrect.");
22. Save the test again 23. Check the test script by running it in debug mode
r
24. Change mode to verify and run the test script 25. Examine the Results 26. Close the Results, the Flight Reservation application, and the test script
What did we learn from this test script? To verify text that changes in an AUT (for example, a number total), we must get the text, place an order, get the text again, synchronize the test, change the name of variables, and then insert an if-else statement that verifies that the number of orders is increased by one after an order is placed.
Lesson Eight: Introduction to GUI Map Files In this lesson, you will learn:
q
what a GUI map file is how WinRunner creates a GUI map file during recording how the GUI map allows WinRunner to identify objects
GUI Map Files Definition: the GUI map acts as a translator between the AUT and the recorded test script.
WinRunner Tutorial
q
WinRunner adds the names of windows and objects to the GUI Map file as they are encountered by the user during recording The GUI Map contains information that allows TSL statements to be translated into Windows OS commands and vice versa
How Does WinRunner Run the Test Script?

q
When WinRunner executes a TSL statement from the test script, it passes through the GUI map before sending it to Windows OS which will interact with the AUT The AUT's response must also pass through the GUI map
Important Issues in Test Script Creation

q
WinRunner must uniquely identify each object in the Graphical User Interface of the AUT The naming of an object and its corresponding function must be kept together
Some of the Object Attributes Used to Name an Object

q
Class: the type of object, such as window, push_button, list, scroll Label (or attached text): the test that appears on the object, such as a button name or a window title
r
this usually becomes the object's logical name
MSW_id: the Microsoft Windows id assigned to the object during development Parent: the parent of the object (usually a window)
The GUI Map Editor The GUI Map Editor is the WinRunner utility that is used to work with GUI Map files. In this next test, we will use the GUI Map Editor to view GUI objects, their names, and their physical descriptions. How to Open the GUI Map Editor
q
Test 11: Test created to view a temporary GUI map file

WinRunner Tutorial
1. Start WinRunner 2. Start a new test in WinRunner (by pressing the New icon) 3. Start Recording
r
4. Start the Flight Reservation application and log in

r
Start / Programs / WinRunner / Sample Applications / Flight 1A In login window, type in your name Use the mouse pointer to switch from the Name text field to the Password text field; do not use the TAB key Enter mercury for the password (do not yet press OK) Press Help and then press OK to exit the Help dialog box Press Cancel and then start the Flight Reservation again
s
In login window, type in your name Use the mouse pointer to switch from the Name text field to the Password text field; do not use the TAB key Enter mercury for the password and click OK
5. Position the two applications so that they do not overlap 6. Close the Flight Reservation application 7. Stop recording 8. Save as test11 on your a:\ drive 9. Do not run this test 10. Maximize WinRunner 11. Open GUI Map Editor
r
Tools / GUI Map Editor In the GUI Map Editor, in the Windows/Objects field, scroll down until you see Login
s
If the GUI objects that are part of the Login window are not showing, double click on Login
WinRunner Tutorial
Logical Name Login
Physical Description class: window, label: Login, MSW_class: "#32770" class: edit, attached_text: "Agent Name:"
Agent Name:
Might not appear: Might not appear: Agent Name:(static) class: static_text, MSW_id: 65535, label: "Agent Name:" Cancel Help OK Password: Might not appear: Password:(static) class: push_button, label: Cancel class: push_button, label: Help class: push_button, label: OK class: edit, attached_text: "Password:" Might not appear: class: static_text, MSW_id: 65535, label: "Password:"
Examine the following three TSL statements in the test script that correspond to these objects:
edit_set ("Agent Name:", "David"); password_edit_set("Password:", "kzptnyoslzjsaz"); button_press ("OK");
edit_set ("Agent Name:", "David"); edit_set: function that replaces text in the edit object (edit text field) "Agent Name:": logical name of the edit object to receive input "David": string to be entered into edit object
WinRunner Tutorial
password_edit_set("Password:", "kzptnyoslzjsaz"); password_edit_set: function that enters the password into edit object; it also encrypts the password so that the password is not in the test script "Password:": logical name of the edit object to receive input "kzptnyoslzjsaz": encrypted string item to be entered into edit object
button_press ("OK"); button_press: function that presses a click button "OK": logical name of the button
Close the GUI Map Editor and the test script
The GUI Map Translation

q
The GUI map connects the logical name used in the test script to the physical description used in the AUT to identify the correct test object
Logical name used in test script button_press ("OK");
GUI Map connects logical name in test script to the physical description in the AUT OK { class: push_button, label: OK }
Physical description in the AUT
class: push_button, label: OK
During Recording: when you interact with the AUT, WinRunner learns the physical attributes of the AUT and inserts them into the GUI map; it generates a logical name to each object and uses the logical name in the test script During Playback: WinRunner reads the logical name in the test script and translates this into the physical description and then looks for this in the AUT
WinRunner Tutorial
Exercise 1. Create a test script that creates an order with the Flight Reservation application 2. While still recording, view the Graph (Analysis / Graphs) 3. While still recording, view the About Flight Reservation System (Help / About) 4. Stop recording 5. Use the GUI Map Editor to view the GUI objects 6. Write down the physical descriptions for the following GUI objects:
r
"About Flight Reservation System" "Flights Table" Graph
Lesson Nine: Managing GUI Map Files In this lesson, you will learn:
q
two ways to create permanent GUI Map files how to add objects to a GUI Map file use the GUI Spy to read actual object descriptions the syntax to load and unload GUI Map files
Two Techniques to Manage GUI Map Files 1. One GUI Map file per test 2. One GUI Map file for many tests
First Technique: One GUI Map File Per Test During the recording of a test script, WinRunner stores the logical names and descriptions of objects in a temporary GUI Map file. After recording and after WinRunner has created the temporary GUI Map file, you save it to
WinRunner Tutorial
create a permanent GUI Map file.
How to Create a Permanent GUI Map File 1. Record interaction with AUT and save test script 2. Open GUI Map Editor
r
Tools / GUI Map Editor If objects are not visible in the Windows/Objects window, select View / GUI Map File / Save Select Save in New File... Select the a:\ drive for Save In: For File Name choose a name similar to the test's name (since for this technique we are using one GUI Map file per test) Select Save
r
r
6. Create a new order in Flight Reservation

r
File / New Order

r
Date of Flight: 02/02/02
WinRunner Tutorial
r
Fly From: Los Angeles Fly To: San Francisco Click the Flights button and double click on any flight Name: Andrew Smith Select First Class Click Insert Order
8. Delete the order by clicking the Delete Order button and then click on Yes in the message window to confirm (this sets the end conditions) 9. Stop Recording 10. Save as test12 on your a:\ drive 11. Open the GUI Map Editor
r
12. Save the GUI Map file (make the temporary GUI Map file a permanent GUI Map file)
r
If objects are not visible in the Windows/Objects window, select View / GUI Map File / Save Select Save in New File... Select the a:\ drive for Save In: For File Name choose test12 Select Save
13. Close the GUI Map Editor 14. Close the test script and the Flight Reservation application
Adding New Objects to a GUI Map File When you saved the GUI Map file above, it has only those items that were in the temporary GUI Map file (that is, only those objects that you interacted with when interacting with the AUT). However, there are more objects that are part of the AUT that you may need to test. For this reason, you will need to add objects to the GUI Map file. Below is the procedure to add windows and objects to a GUI Map file: 1. Interact with the object of the AUT that is not in the permanent GUI Map file while recording
WinRunner Tutorial
2. Open the GUI Map Editor 3. Transfer objects from the temporary GUI Map file to the permanent GUI Map file 4. Save the permanent GUI Map file 5. Close the GUI Map Editor
r
r
6. Press the Help icon (the question mark) 7. Press Search 8. Press Cancel 9. Open the GUI Map Editor
r
10. Press the Expand button

r
If it is not showing, select View / GUI Files
11. On the left side, select test12.gui under GUI File: 12. Notice on the left side, under GUI File: the permanent GUI Map file (test12.gui) is listed on the right side under GUI Map File: the temporary GUI Map file is listed 13. Move objects from temporary GUI Map file to permanent GUI Map file r Highlight objects in Windows/Objects field on the right side
r
Press Move and then OK Object should transfer from the temporary GUI Map file to the permanent GUI Map file
WinRunner Tutorial
14. Save the permanent GUI Map file with its new object or objects r File / Save 15. Close the GUI Map Editor 16. Stop Recording 17. Save as test13 on your a:\ drive 18. Close the test script and the Flight Reservation application
Second Technique: One GUI Map File for Many Tests For this second technique, we will make WinRunner or really the GUI Map Editor learn all the windows and objects of the AUT.
Making the GUI Map Editor Learn the Objects 1. Open AUT 2. Open the GUI Map Editor 3. Click the Learn button and point with the hand pointer to each object of the AUT 4. Save the permanent GUI Map file with a name similar to the AUT (since all tests for the AUT will use this GUI Map file)
r
WinRunner Tutorial
4. Position the two applications so that they do not overlap 5. Open the GUI Map Editor
r
Tools / GUI Map Editor If objects are not showing, select View / GUI Files
6. On the left side, select Temporary under GUI File: 7. Save the temporary (even though it currently has no objects) r File / Save As
r
For File Name: choose flightreservation1a For Save In: choose the a:\ drive Select Save
8. Press the Learn button; the cursor will turn into a hand 9. Single click on the title bar of the AUT (this will make WinRunner learn all the objects of the AUT) 10. Save the objects in the permanent GUI Map file
r
File / Save
11. Close the GUI Map Editor 12. Close the Flight Reservation application
Using the GUI Spy The GUI Spy allows you to look at the AUT and get a complete physical description of each object. The following are the steps to follow to use the GUI Spy:
1. Open AUT
WinRunner Tutorial
2. Open GUI Spy 3. Press the Spy button 4. Point to any object in the AUT and the GUI Spy will give you a physical description of the object
r
4. Position the two applications so that they do not overlap 5. Open the GUI Spy 6. Press the Spy button 7. Place the cursor over any object in the AUT and you will be given a physical description 8. Close the GUI Spy 9. Close the Flight Reservation application
Loading a GUI Map File There are two ways to load a GUI Map file:
1. In the GUI Map Editor, under GUI File: select the permanent GUI Map file for your test or AUT 2. Add TSL statements to the test script
Adding TSL Statements to Load and Unload GUI Map Files In addition to adding a TSL statement to load a GUI Map file, you should also insert a statement to unload or close the previous GUI Map file.
Syntax for Unloading a GUI Map File:

WinRunner Tutorial
GUI_close_all(); This statement is inserted at the beginning of a test script to close the previous GUI Map file.
Syntax for Loading a GUI Map File: GUI_load("a:\\filename") Important Note: When defining the path to a GUI Map file, always use two back slashes. Since the back slash is a control character in TSL, two are required.
For example, our load statement would be: GUI_load("a:\\test12.gui") Lesson Ten: Batch Tests In this lesson, you will learn:
q
what a batch test is how to create a batch test how to run a batch test and analyze the results how to program a batch test with a for loop
Batch Tests Definition: A batch test is a test script that contains call statements that run other test scripts. When a batch statement is run, it opens and executes each test that has been called. A batch test may also include programming elements, such as loops or decision-making statments like ifelse statements. A batch test appears to be a regular test script, but it differs in two main ways:
it contains call statements to other test scripts it is run in batch mode which instructs WinRunner to suppress messages that might interrupt the test (this allows the tester to run unattended tests)
WinRunner Tutorial
Call Statements A call statement opens and runs a specific test script. Syntax of a call statement: call "a:\\test1"(); Where you would normally put one back slash (between drives, directories, and files), you put two. If you have your test named test10 on the c:\ drive and in a directory named tests the path would look like this: call "c:\\tests\\test10"();
Running in Batch Mode Running the batch test in batch mode will tell WinRunner to suppress messages that would interrupt the test during a regular run of the test scripts. To run in batch mode:
1. Settings / General Options 2. Put a check in the Run in Batch Mode option check box 3. Press OK
We are going to create two test scripts and then create a batch test with them. Test 16 1. Start WinRunner (if it is not already running) 2. Start a new test in WinRunner (by pressing the New icon) 3. Start the Flight Reservation application and log in
r
r

r
File / New Order
WinRunner Tutorial

r
Date of Flight: 02/02/02 Fly From: Frankfurt Fly To: Paris Click the Flights button and double click on any flight Name: Alexander Hamilton Select First Class Click Insert Order

r
r
r
WinRunner Tutorial

r
File / New Order

r
Date of Flight: 08/07/03 Fly From: Zurich Fly To: Seattle Click the Flights button and double click on any flight Name: Jane Percy Select First Class Click Insert Order

r
r
Batch Test 1 1. Start WinRunner (if it is not already running) 2. Start a new test in WinRunner (by pressing the New icon) 3. Start the Flight Reservation application and log in
WinRunner Tutorial
r
4. Position the two applications so that they do not overlap 5. In the test script, type in the call statements for our last two test scripts: call "a:\\test16"(); call "a:\\test17"(); 8. Configure WinRunner to run this batch test in batch mode
r
Settings / General Options Put a check in the Run in Batch Mode option check box Press OK
9. Save as batch1 on your a:\ drive 10. Playback or Run the test script
r
What did we learn from this batch test? To run more than one test unattended, we can create batch tests will can call numerous test scripts to execute them and it runs in batch mode which will not be interrupted by messages during a test run.
Programming a Batch Test with a For Loop We are going to add a for loop to our batch test. This will make WinRunner run these same test scripts multiple times. (This syntax can be used in any test script; it is not restricted to batch tests.) Syntax for a For Loop: for (i=0; i<3; i++)
WinRunner Tutorial
{ action to be repeated action to be repeated } i: variable that stores an integer i=0: this initial statement sets the value of i i<3: if this boolean statement will allow the loop to continue i++: this adds 1 to the value of i each time through the loop The curly braces ({}) enclose the functions that will run each time the loop iterates. By enclosing the functions, only these functions will be executed when the loop iterates. Thus, this for loop will execute the actions three times, because the follow of i starts at 0 and the actions execute. The value of i increases by 1 and the actions execute again. They will execute three times, because when i is incremented to 3 the boolean expression will be false and this will stop the loop, and it will be exited.
Batch Test 2 1. Go back into batch1 2. Delete the two current lines of the test script 3. Insert the following syntax: for (i=0; i<3; i++) { call "a:\\test16"(); call "a:\\test17"(); } 10. Save as batch2
r
File / Save As For File Name type, batch2 Press Save

r
WinRunner Tutorial
What did we learn from this batch test? We can add a for loop which will execute the test scripts any number of times that we wish.
Turning Off Batch Mode Since we ran our batch test in batch mode, we have to go back and unselect batch mode so that our next tests are not run in batch mode.
1. Settings / General Options 2. Click on the check in the Run in Batch Mode option check box (this will unselect it) 3. Press OK
Lesson Eleven: Data-Driven Tests In this lesson, you will learn:

q
what a data-driven test is how to use the DataDriver Wizard to create a data-driven test how to run a test with several iterations
Data-Driven Tests Definition: A data-driven test is a test that instead of having the input of one set of data (for example, entering John Smith as the customer's name for buying tickets) we have multiple sets of data, and with each iteration through the test script WinRunner inserts a different set of data.
How to Create Data-Driven Tests 1. Create a regular test script that inserts one set of data into the AUT 2. Use the DataDriver Wizard to convert test script into a data-driven test script
WinRunner Tutorial
3. Add statements in your test script to open and close the data table 4. Add statements in your test script to read from the data table and to run in a loop while it applies each set of data 5. Replace fixed values in recorded statements and checkpoint statements with parameters (this is called "parameterizing" the test script)
First, we are going to create a test script that will order a ticket for a flight. Second, we will turn this test script into a data-driven test which will order tickets using different customer names. Our test script will determine if the AUT can receive these different sets of data.
r
r

r
File / New Order

r
Date of Flight: 02/02/02 Fly From: Frankfurt Fly To: Paris Click the Flights button and double click on any flight Name: David Jacobs Click Insert Order
WinRunner Tutorial
r
r
Data-Driven Test 1 1. Save test18 as ddtest1 on your a:\drive 2. Run the DataDriver Wizard
r
Tools / DataDriver Wizard
3. Parameterize the customer's name

r
Read the text displayed in the DataDriver Wizard dialog box Click the Next icon In the Use a new or existing Excel table text field, type: table1.xls Leave table as the variable name Put a check in the Add statements to create a data-driven test check box Put a check in the Parameterize the test check box Select Line by Line Select Next Make sure Do not replace this data is selected and press Next (we do not want to parameterize the date) Make sure Do not replace this data is selected and press Next (we do not want to parameterize the departure city)
WinRunner Tutorial
Make sure Do not replace this data is selected and press Next (we do not want to parameterize the arrival city) Make sure Do not replace this data is selected and press Next (we do not want to parameterize the flight information) Select A new column when the customer's name appears (this we want to parameterize) and then press Next When the DataDriver Wizards says, "Congratulations," press Finish Save the test script again
4. Open the data table to add names

r
Tools / Data Table Notice under the column Name the customer name from our test script Click in the box below the customer name and add: Bill Fairweather Click in the next box down and type: Fridjoff Nansen Click in the next box down and type: Doug Mawson Click in the next box down and type: Helene Cixous
5. Save the table

r
File / Save
6. Close the table

r
File / Close
7. Maximize WinRunner to examine the code in the entire test script
The Parameterized Test Script Code Explained In our data-driven test script, the DataDriver Wizard added ten new lines and changed one line. Lets examine those lines (the new or changed lines are in bold): table = "table1.xls"; rc = ddt_open(table, DDT_MODE_READ); if (rc!= E_OK && rc != E_FILE_OPEN) pause("Cannot open table."); ddt_get_row_count(table,table_RowCount); for(table_Row = 1; table_Row <= table_RowCount; table_Row ++) { ddt_set_row(table,table_Row); set_window ("Flight Reservation", 4);
WinRunner Tutorial
menu_select_item ("File;New Order"); obj_type ("MSMaskWndClass","020202"); list_select_item ("Fly From:", "Frankfurt"); # Item Number 1; list_select_item ("Fly To:", "Paris"); # Item Number 3; obj_mouse_click ("FLIGHT", 49, 30, LEFT); set_window ("Flights Table", 1); list_activate_item ("Flight", "13550 ..."); # Item Number 4; set_window ("Flight Reservation", 3); edit_set ("Name:",ddt_val(table,"Name")); button_press ("Insert Order"); set_window ("Flight Reservation", 9); button_press ("Delete Order"); set_window ("Flight Reservations", 1); button_press ("Yes"); } ddt_close(table);
table = "table2.xls"; The variable table will hold the value of the table that we are using in the data-driven test to invoke it when needed.
rc = ddt_open(table, DDT_MODE_READ); The function ddt_open will open our table for our script in read mode; the variable rc holds the function as a value because when the function operates its return status will be the value of the variable and this is used in the next line.
if (rc != E_OK && rc != E_FILE_OPEN) pause("Cannot open table."); The English meaning is this: If the return status of ddt_open is not successful (E_OK) and the return is not that the file is already open (E_FILE_OPEN), then pause and give this message ("Cannot open table."). This is where the variable rc comes in handy. It is being used because when the function ddt_open operates the value of rc will be the return status of the function, and if there is a problem with opening the table the tester is prompted.
ddt_get_row_count(table,table_RowCount); This function retrieves the number of rows in a table; that number then is store by table_RowCount to be used in the for loop.
WinRunner Tutorial
for(table_Row = 1;table_Row <=table_RowCount;table_Row ++) { ... } This for loop is used to loop through the functions inside of the curly braces the same numbers of times as there are rows. If there are five rows in our table, then the for loop will loop five times, and each time it will add new data to one particular place in the AUT. table_Row = 1 is the initializing statement in the for loop; it sets the value of the variable table_Row at 1. This statement is used only once at the beginning of the looping process. table_Row <= table_RowCount is a boolean expression which acts as the on and off switch. If the value of table_Row is less than or equal to table_RowCount, then the loop will continue. Since we know that the value of table_RowCount is 5 because there are five rows, the loop will continue five times through. table_Row ++ adds 1 to the value of table_Row at the end of each loop iteration. Thus, the for loop will execute the functions within the curly braces five times, because the value of table_Row is set at 1 and the loop will continue until the value of table_Row is less than or equal to table_RowCount which we know has the value of 5.
ddt_set_row(table,table_Row); This function will be executed each time through the loop. The function ddt_set_row sets a particular row in our table active. Since table_Row will start at 1 and increment to 5, all the rows in our table will be individually activated through the separate iterations of the for loop.
edit_set("Name:",ddt_val(table,"Name")); This is the only "parameterized" line in our original test script. Originally it was: edit_set("Name:","David Jacobs");. The function ddt_val returns the value of a parameter in the active row in a data table. Thus, since a new line becomes active each time through the loop, different data (the different customer names) are returned and inserted as the customer for a flight reservation.
ddt_close(table); This function closes the table used in this data-driven test.
What Will the Data-Driven Test Do?
WinRunner Tutorial
It will create a new order five different times. Each time through the order process it will insert different customer names. The following customer names will individually be inserted for separate orders:
David Jacobs Bill Fairweather Fridjoff Nansen Doug Mawson Helene Cixous
Run the Data-Driven Test 1. Playback or Run the test script

r
2. Accept the Test Run Name of res1 (if it says res2, accept it), by pressing OK 3. Notice the insertion of a different customer name during the different orders 4. Examine the Results 5. Close the Results, the test script, and the Flight Reservation application
What did we learn from this data-driven test script? To create a data-driven test, you utilize the DataDriver Wizard which will walk you through step-bystep in parameterizing a test script so that it will insert different data into the test each time through an iteration of the test.
Lesson Twelve: Review for Final Exam
Ways to Study for Final Exam

q
Look over your notes Look over your test scripts
WinRunner Tutorial
Look over the WinRunner tutorial Examine your answers to the review questions
The Complete Collection of Review Questions 1. What is the tester's role in software development? 2. What does the tester do in white box testing? 3. How does the tester perform black box testing? 4. What does the tester do in automated testing? 5. What are the benefits of automated testing over white box and black box testing? 6. Name three types of tests that should be automated. 7. Name three types of tests that should NOT be automated. 8. What are the four steps of automated testing? 9. What is an IDE? 10. What are the three aspects of GUI software to test for with WinRunner? 11. What are the two ways to create test scripts? 12. What are the four steps to record a test script? 13. Why position WinRunner and the AUT so they do not overlap? 14. What icon is used in WinRunner to get an explanation of the syntax of TSL? 15. What are the two recording modes in WinRunner? 16. Which recording mode is suggested for most situations? 17. Name three reasons why the tester may choose to record in Context Sensitive mode. 18. Name three reasons why the tester may choose to record in Analog mode. 19. When we are recording in WinRunner and interact with the AUT, what does WinRunner do? 20. How does the tester run or playback a test script? 21. Name two ways the AUT can be changed when the tester interacts with it during recording. 22. How might the two changes you listed for Question #1 affect subsequent tests?
WinRunner Tutorial
23. What are initial conditions? 24. What are end conditions? 25. Why are initial and end conditions necessary? 26. If a test script instructs WinRunner to open an application to test it, what end conditions might be good? 27. If the tester names a test test1, what will be the name of the directory for this test? 28. Why is a lock file created? 29. What is contained in a chklist subdirectory? 30. Name four subdirectories that might be in the directory for the test described in Question #27. 31. If the AUT does not respond quickly enough for an action to be executed in the test script and WinRunner moves to the next action, why would this be a problem? 32. Name three actions that may take the AUT more time to perform that would require synchronization. 33. What is a synchronization point? 34. Name four types of synchronization. 35. The AUT we tested did not have a synchronization problem, how did we create the problem? 36. How many milliseconds are in one second?
The following four questions use this line of syntax: obj_wait_bitmap("Insert Done...","Img1",10);
37. In the above statement, what is obj_wait_bitmap? 38. In the above statement, what is "Insert Done..."? 39. In the above statement, what is "Img1"? 40. In the above statement, what is 10? 41. What is verification in manual testing? 42. How is the definition of verification with WinRunner different than with manual testing? 43. What are the four steps of how WinRunner verifies?
WinRunner Tutorial
44. Name three things that we might test with GUI checkpoints. 45. Name three examples of visual cues that might be used to establish GUI checkpoints.
The following five questions use this line of syntax: obj_check_gui("Order No.","list1.ckl","gui1",1);
46. In the above statement, what is obj_check_gui ? 47. In the above statement, what is "Order No." ? 48. In the above statement, what is "list1.ckl" ? 49. In the above statement, what is "gui1" ? 50. In the above statement, what is 1 ? 51. What is bitmap verification? 52. What is the process for establishing bitmap checkpoints? 53. In our test using bitmap checkpoints, why did we switch to analog mode? 54. In our test using bitmap checkpoints, when did WinRunner capture the expected object to compare with the actual object? 55. How can we view the captured expected object before and after we run our test? 56. What statement did WinRunner insert into our test script to test our bitmap image?
The following four questions use this line of syntax: obj_check_bitmap("(static)","Img1",10);
57. In the above statement, what is obj_check_bitmap? 58. In the above statement, what is "(static)"? 59. In the above statement, what is "Img1"? 60. In the above statement, what is 10? 61. Name three times you would use text verification. 62. When setting up a test to verify text, what is the purpose of declaring a variable?
WinRunner Tutorial
63. In the basic syntax of an if-else statement, if the condition is false, what happens? 64. What does a tl_step do?
The following six questions use these lines of syntax: if (new_total == first_total + 1) tl_step("Graph Total",PASS,"Total is correct."); else tl_step("Graph Total",FAIL,"Total is incorrect.");
65. What line of syntax is the condition? 66. If the AUT functions correctly, what will be the status? 67. If the AUT does not function correctly, what will be the status? 68. What is "Graph Total"? 69. Under what conditions would the first action execute? 70. Under what conditions would the second action execute? 71. What is a GUI Map file? 72. As an attribute of an object, what is the class? 73. As an attribute of an object, what is the label or attached text? 74. As an attribute of an object, what is the MSW_id? 75. As an attribute of an object, what is the parent?
The following two questions use this line of syntax: password_edit_set("Password:","kzptnyoslzjsaz");
76. In the above line of syntax, what is password_edit_set? 77. In the above line of syntax, what is "kzptnyoslzjsaz"? 78. What does the GUI map connect together in the test script and in the AUT? 79. During the recording of a test script, what does WinRunner do regarding the GUI Map file? 80. During the playback of a test script, what does WinRunner do regarding the GUI Map file?
WinRunner Tutorial
81. In general terms, what are the two ways to manage GUI Map files for tests? 82. How does one create a permanent GUI Map file from a temporary GUI Map file? 83. How can one add objects to a permanent GUI Map file? 84. How can one make a GUI Map file for a complete software application? 85. What can you do with the GUI Spy? 86. What are the two ways to load a GUI Map file? 87. What is the syntax for loading a GUI Map file through TSL statements? 88. What is the syntax for unloading a GUI Map file through TSL statements? 89. Why use two back slashes (\\) as part of the syntax for loading and unloading GUI Map files? 90. What is a batch test? 91. What are the two main ways that a batch test is different than a regular test script? 92. What does a call statement do? 93. What is the syntax for a call statement? 94. What does running the batch test in batch mode do?
The following four questions use these lines of syntax: for (i=0; i<3; i++) { call "a:\\test16"(); call "a:\\test17"(); }
95. What does i=0 do? 96. What does i<3 do? 97. What does i++ do? 98. How many times will this for loop iterate (or loop) through the call statements? 99. What do the curly braces do? 100. What is a data-driven test? 101. Why create a data-driven test?
WinRunner Tutorial
102. What is a data table? 103. In a parameterized test script, what will the following two lines of syntax do? if (rc != E_OK && rc != E_FILE_OPEN) pause("Cannot open table."); 105. What does the function ddt_open do? 106. What does the function ddt_get_row_count do? 107. What does the function ddt_set_row do? 108. In our parameterized test, different customer names were inserted in the application each time a new order was created; where did the names come from? 109. What does the function ddt_close do? 110. How many times did our parameterized test create an order with a different customer name? How was this number established
WinRunner Tutorial WinRunner and the Mercury Interactive logo are trademarks of Mercury Interactive Corporation. Copyright 2001 David C. Jacobs

Win Tut

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Win Tut

Uploaded by

Copyright:

Available Formats

WinRunner Tutorial

DESIGNED BY DAVID C. JACOBS, PH.D.

Go Straight to the Lesson

Go Straight to the Review

Mercury Interactive Corporation

Printer-Friendly Version of Complete Tutorial

http://www.htmlmule.com/wr/wintut.html (1 of 2) [12/9/2003 12:39:57 AM]

HOME | FIRST LESSON

http://www.htmlmule.com/wr/wintut.html (2 of 2) [12/9/2003 12:39:57 AM]

DESIGNED BY DAVID C. JACOBS, PH.D.

Lesson One: Introduction In this lesson, you will learn:

Mercury Interactive Corporation

http://www.htmlmule.com/wr/wt1.html (1 of 6) [12/9/2003 12:39:59 AM]

to manual testing (testing for properties, appearance, and functionality)

Compared to white box testing:

Compared to black box testing:

Which software testing should be automated?

Which software testing should NOT be automated?

The Steps of Manual and Automated Testing

1st Step Perform user actions

2nd Step Wait for process to complete

3rd Step Verify AUT

4th Step Repeat for all actions of AUT

http://www.htmlmule.com/wr/wt1.html (3 of 6) [12/9/2003 12:39:59 AM]

Three aspects of GUI software to test with WinRunner

Functions Properties Bitmap features

Windows 95 Windows 98 Windows NT Windows ME Windows 2000

http://www.htmlmule.com/wr/wt1.html (4 of 6) [12/9/2003 12:39:59 AM]

HOME | REVIEW THIS LESSON | NEXT LESSON

http://www.htmlmule.com/wr/wt1.html (5 of 6) [12/9/2003 12:39:59 AM]

http://www.htmlmule.com/wr/wt1.html (6 of 6) [12/9/2003 12:39:59 AM]

DESIGNED BY DAVID C. JACOBS, PH.D.

How to Record a Test Script

Printer-Friendly Version of Complete Tutorial

http://www.htmlmule.com/wr/wt2.html (1 of 8) [12/9/2003 12:40:02 AM]

Start / Programs / WinRunner / WinRunner

Start / Programs / Accessories / WordPad

5. Position the two applications so that they do not overlap

6. Start a new test script in WinRunner

File / New or press the New icon

8. Click inside of WordPad and type these lines:

http://www.htmlmule.com/wr/wt2.html (2 of 8) [12/9/2003 12:40:02 AM]

14. In WordPad, click the New icon or select File / New

Press OK Do not save changes, by selecting No

17. Playback or Run the test script

http://www.htmlmule.com/wr/wt2.html (3 of 8) [12/9/2003 12:40:02 AM]

1. Context Sensitive Mode (the default mode)

object-based not affected by user interface changes (i.e., movement of objects)

Software examples: menus, icons, check boxes

http://www.htmlmule.com/wr/wt2.html (4 of 8) [12/9/2003 12:40:02 AM]

Software examples: virtual reality environment, drawing, paint brush strokes

Start / Programs / WinRunner / Sample Applications / Flight 1A

3. Log on the Flight Reservation application

Press the Record icon or select Create / Record - Context Sensitive

6. Open order number 1 in the Flight Reservation application

http://www.htmlmule.com/wr/wt2.html (5 of 8) [12/9/2003 12:40:02 AM]

Type 1 in the text box and press OK

7. Open the Fax Order window

Select File / Fax Order

Press the Record icon and F2

http://www.htmlmule.com/wr/wt2.html (6 of 8) [12/9/2003 12:40:02 AM]

Or select Create / Record - Analog

3. Open order number 1 in the Flight Reservation application