Win Tut

8/6/2019 Win Tut

1/151

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

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

on WinRunner 7.0.)

Go Straight to the Lesson

Go Straight to the Review

How to Use this Tutorial

You can use this tutorial in any way you wish (except from selling it, etc.), but it has

designed to be used in the following manner:

q It is best viewed with Internet Explorer, with Medium size text (set this by goi

to View / Text Size / Medium), and with the resolution set at 800 by 600

q Since WinRunner is not going to function well with a browser running that is n

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)

q 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 finish

all lessons -- at least for the first time through)

What You Will Learn from This Tutorial

In this tutorial, each lesson will be presented to teach you how to operate one aspect o

the WinRunner automated testing environment. Except for the first lesson, each lesso

will include explanation and an exercise where you will apply what you have learned

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

Mercury Interactive

Corporation

Printer-Friendly Version

of Complete Tutorial

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

Click on One of the Lessons Click on One of the Reviews
http://www-heva.mercuryinteractive.com/http://www-heva.mercuryinteractive.com/http://www-heva.mercuryinteractive.com/http://www-heva.mercuryinteractive.com/http://www-heva.mercuryinteractive.com/

8/6/2019 Win Tut

2/151

WinRunner Tutorial

Your Responsibilities

Your job while using this tutorial is to report any bugs that you might come across to

author at [email protected].

HOME | FIRST LESSON

WinRunner and the Mercury Interactive logo are trademarks of Mercury Interactive Corporation.

Copyright 2001 David C. Jacobs

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

8/6/2019 Win Tut

3/151

WinRunner Tutorial




Lesson One: Introduction

In this lesson, you will learn:

q where the tester fits within software development

q different types of testing (white box, manual, and automated testing)

q where automated testing is beneficial and where it is not beneficial

q how automated testing follows the steps of manual testing

q some basics about WinRunner

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 U

Testing) to see if the code is written correctly

2. Manual Testing / Black Box Testing: The tester uses the application in order

test it (testing for properties, appearance, and functionality)

3. Automated Testing: The tester creates test scripts that test the application sim

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

Mercury Interactive

Corporation



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

8/6/2019 Win Tut

4/151

WinRunner Tutorial

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

r Excellent for regression testing, because the same scripts can be run ag

and again

What are the benefits of automated testing over manual and white boxtesting?

q Compared to white box testing:

r not as expensive in the long run

r better for functionality and regression testing

q Compared to black box testing:

r more reliable

r more consistent

r reusable and repeatable

r inherent programming capabilities

Which software testing should be automated?

q Tests that need to be run for every build of the application

q Tests that use multiple data values for the same actions (data-driven tests)

q Tests that require detailed information from application internals (e.g., GUI

attributes)

q Stress/load testing

q Any test that has a repetitive feature (test one object multiple times in one test

test the same objects through multiple builds of the software)

Which software testing should NOT be automated?


8/6/2019 Win Tut

5/151

WinRunner Tutorial

q Usability testing (how easy is the software to use?): the tester needs to use the

software as a user

q One-time testing: automated will be too time consuming

q ASAP or Quick-look testing: automated will be too time consuming

q Ad hoc or random testing (testing the software based on hunches): automated be too time consuming to set up

q 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 2nd Step 3rd Step 4th Step

Perform user

actions

Wait for process to

complete

Verify AUT Repeat for all

actions of AUT

Automated Testing Steps

1st Step 2nd Step 3rd Step 4th Step

Generate

automated test

script

Synchronize script

and AUT

Add verification

tests

Run test scripts

About WinRunner

q Created by Mercury Interactive, Inc. in 1992

q WinRunner is an automated testing tool that tests GUI software and web page

q WinRunner combines a GUI software package and scripting language


8/6/2019 Win Tut

6/151

WinRunner Tutorial

r GUI software package: Integrated Development Environment (IDE)

allows the tester to record, write, edit, run test scripts in one environme

r Scripting language: Test Script Language (TSL) is based on C

q Three aspects of GUI software to test with WinRunner

r Functions

r Properties

r Bitmap features

q How WinRunner Basically Tests

r The tester creates a test script by recording the interaction with the AU

r The tester can insert "checkpoints" to test the properties, appearance, an

text of objects

r The tester can enhance test scripts with code

r The tester can enhance test scripts with data for a data-driven test whic

inserts data to determine if the AUT will accept it

r The tester easily runs the test by pressing an icon

r The tester reads the results

r A temporary GUI Map file is created while recording; the GUI Map fil

acts as an interpreter between application and test script

Supported Platforms

q Windows 95

q Windows 98

q Windows NT

q Windows ME

q Windows 2000


8/6/2019 Win Tut

7/151

WinRunner Tutorial

Supported Environments

q Netscape, Microsoft Internet Explorer

q Java applets, Java applications, JavaScript

q ActiveX, OCX Controls

q

WAP

q ERP/CRM applications (Oracle applications, PeopleSoft, SAP, Siebel)

q Terminal emulators (mainframe, AS/400, Unix servers)

q Visual Basic

q C/C++

q PowerBuilder

q Delphi

WinRunner Resources

These sources were consulted in the construction of this tutorial and are an execellent

guide for further research.

q WinRunner User's Guide

q WinRunner Tutorial

q TSL Online Reference

q WinRunner Student Handbook (from Mercury Interactive classes)

HOME | REVIEW THIS LESSON | NEXT LESSON



http://www.htmlmule.com/wr/rev1.htmlhttp://www.htmlmule.com/wr/rev1.html

8/6/2019 Win Tut

8/151

WinRunner Tutorial


8/6/2019 Win Tut

9/151

WinRunner Tutorial




Lesson Two:

Recording Tests, Playback, Context Sensitive and Analog Modes


q how WinRunner tests are recorded

q how to playback a test

q the differences between analog and context sensitive recording

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

r Close the Add-In Manager, by clicking OK

r If the Welcome to WinRunner dialog appears, uncheck the Show at Sta

check box, then close the Welcome to WinRunner dialog by pressing th

in the top right

2. Start the AUT

3. Start a new test script (by pressing the New icon selecting File / New)

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

Mercury Interactive

Corporation




8/6/2019 Win Tut

10/151

WinRunner Tutorial

4. Activate the recording function (by pressing the Record icon or selecting Crea

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 wh

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 th

incorrect application

r 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

r Or Create / Record - Context Sensitive

r Or press F2

8. Click inside of WordPad and type these lines:


8/6/2019 Win Tut

11/151

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

r Click on Find Next four times

r Press Cancel

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

r Press OK

r 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

r Save In: a:\ drive

r File Name: test1

r Press Save

17. Playback or Run the test script

r Click the Run from Top icon

r 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 ourecorded movements interacting with WordPad

21. Click on the Help Icon (arrow and question mark) and then click on the line (this will explain the syntax of the script)

22. set_window ("Document - WordPad", 3);


8/6/2019 Win Tut

12/151

WinRunner Tutorial

r set_window activates the window to receive input

r "Document - WordPad" is the logical name of WordPad

r 3 is the number of seconds before the next function in the test sc

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 th

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; tscripts 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 obje

and are recommended for most situations, where the test scriptsare:

s object-based

s not affected by user interface changes (i.e., movement ofobjects)

r Software examples: menus, icons, check boxes

2. Analog Mode

r Analog statements are useful for literally describing the keyboar

mouse, and mouse button input of user

r Test scripts are:

s screen-coordinate dependent

s based on mouse and keyboard activities (e.g., mousemovement, press, and release, and keyboard input)


8/6/2019 Win Tut

13/151

WinRunner Tutorial

s Software examples: virtual reality environment, drawing, pbrush strokes

How to Choose Between Context Sensitive and Analog Modes

Choose Context Sensistive if: Choose Analog if:

The application contains GUI objectsThe application contains Bitmap areas

(e.g., a drawing area)

Exact mouse movements are not required Exact mouse movements are required

You plan to reuse the test in different

versions of the applicationWhy? Movements of the GUI objects in

different builds will not affect the test.

You do not plan to reuse the test in

different versions of the applicationWhy? Movements of the GUI objects in

different builds will affect the test.

Test 2: Recorded in Context Sensitive mode, but will not function prope

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 bleast four characters long)

r Type mercury in the Password field and click OK


5. Start recording

r Press the Record icon or select Create / Record - Context Sensi

6. Open order number 1 in the Flight Reservation application

r Select File / Open Order

r Check the Order No. check box in the Open Order window


8/6/2019 Win Tut

14/151

WinRunner Tutorial

r 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 lemouse button and drawing your name

10. Press the Send icon

11. Stop Recording

12. Save as test2 on your a:\ drive





15. Notice that WinRunner will not sign your name; it finds Agent Signaturearea but not the exact place to start writing


17. Close the 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


2. Start recording in Analog mode

r Press the Record icon and F2


8/6/2019 Win Tut

15/151

WinRunner Tutorial

r Or select Create / Record - Analog

3. Open order number 1 in the Flight Reservation application

r Select File / Open Order

r Check the Order No. check box in the Open Order window

r Type 1 in the text box and press OK

4. Open the Fax Order window

r Select File / Fax Order


6. Sign your first name in the Agent Signature area by holding down the lemouse button and drawing your name

7. Press the Send icon

8. Stop Recording







13. Close the test script and the Flight Reservation application


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, t

test script can write our signature and hence perform the test properly.

HOME | PREVIOUS LESSON | REVIEW THIS LESSON | NEXT LESSON


8/6/2019 Win Tut

16/151

WinRunner Tutorial




8/6/2019 Win Tut

17/151

8/6/2019 Win Tut

18/151

WinRunner Tutorial

of the test.

What is an end condition? The end condition is the state of the AUT after a test has r

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 notbeing 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

end condition closes the application (otherwise, running the same test twice m

create problems).

2. If a test enters data into text fields, have the end conditions clear the data (as w

did with Test 1).

Test 4: A test without proper end conditions


2. Start WordPad



4. Start Recording in WinRunner (in Context Sensitive Mode)

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

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 MER

6. Select the Find icon (binoculars); search for the word: interactive

7. Select Find Next three times and press Cancel


8/6/2019 Win Tut

19/151

WinRunner Tutorial

8. Stop recording

9. Save as test4 on your a:\drive




11. Accept the Test Run Name ofres1, 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)


The running of this test script entered the same data as the recording of our interacti

with the AUT, because it did not clear the data already entered. This could become aproblem 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


2. Start WordPad



4. Start Recording in WinRunner (in Context Sensitive Mode)


5. Type this in WordPad:

WinRunner was created by Mercury Interactive.

Mercury Interactive makes a variety of testing tools


8/6/2019 Win Tut

20/151

WinRunner Tutorial

Mercury Interactive trades stock with the symbol MER

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)

r In the New window of WordPad, select OK

r Select No for saving changes in WordPad

9. Stop recording






13. Examine and then close the Results

14. Run test script again


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 th

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 o

the test.


8/6/2019 Win Tut

21/151

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 an

files:

q a script file

q a backup script file (if WinRunner is configured to do this)

q a header file

q a lock file containing the name of the user and a process id exists while the a t

script is open to prevent others from opening it, but it is automatically deleted

when the test script is closed

q a db subdirectory which contains files which influence playback and which sh

not be changed

q a res1 subdirectory which contains the first set of results of your test

q a exp subdirectory which contains the expected results for some tests

A directory for a test could also contain:

q a chklist subdirectory which contains the checklists for objects to be checked

GUI tests

q a debug subdirectory which contains the results of running your test script in

debug mode

q a table file which contains the data for a data-driven test





8/6/2019 Win Tut

22/151

WinRunner Tutorial




Lesson Four:

Synchronizing Tests


q when you should synchronize a test

q 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

default time of 10 seconds.

If the AUT does not respond quickly enough to a command in the test script, WinRun

will move on to the next command; a problem may arise because the outcome of the l

command did not occur.

There are a variety of objects and functions that may cause these; the following are so

common objects and functions that may cause synchonization problems:

q Software retrieving information from a database

q Waiting for a window to pop up

q Waiting for a progress bar to reach 100%

q Waiting for a status message to appear

If WinRunner waits for these objects and functions for the full ten seconds of the defa

interval time (or the set time by the function in the script), then it will move on to the

action in the script which may not execute correctly.

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

Mercury Interactive

Corporation




8/6/2019 Win Tut

23/151

WinRunner Tutorial

Entering a Synchronization Point Solves the Problem

A synchronization point is a line in the test script that instructs WinRunner to wait f

certain response from the AUT during playback before proceeding to the next line in

test script.

Types of Synchronization

Cue Outcome Test Script Function

Window Wait for window set_window

Object State Wait for an object state obj_wait_info

Bitmap Wait for a bitmap to refresh obj_wait_bitmap

Elapsed Time Wait for a set time to elapse wait

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)


3. Start the Flight Reservation application and log in


r In login window, type your name and enter mercury for the password

click OK


5. Start Recording


6. Create a new order in Flight Reservation application


8/6/2019 Win Tut

24/151

WinRunner Tutorial

r File / New Order

7. Fill in flight and passenger information

r Date of Flight: 02/02/02

r Fly From: Los Angeles

r Fly To: San Francisco

r Click the Flights button and double click on any flight

r Name: Steve Johnson

r Select First Class

r Click Insert Order

8. Delete the order (this will set the end conditions)

r Click the Delete Order button

r Click Yes in the message window to confirm

9. Stop Recording


Changing the Default Interval Between Actions in a Test Script

Since there is currently no synchronization problem with our test script and AUT, we

going to create one by changing the default time interval between actions. To change

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


8/6/2019 Win Tut

25/151

WinRunner Tutorial

1. Make sure the test6 test window is active in WinRunner, by clicking on the tit

bar





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 comple

5. Select Continue in Warning Message Box

6. The test fails again because it cannot find the Flight Reservations Message Bo

7. Select Cancel in the Run Wizard dialogue box

Synchronizing the Test


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

r Place the cursor in the blank line

3. Synchronize the test so that the test script waits for the "Insert Done" message

appear in the status bar

r Create / Synchronization Point / For Object/Window Bitmap

r Use the hand pointer to click the status bar in the Flight Reservation

window (where the phrase, "Insert Done...", is)

r WinRunner will insert an obj_wait_bitmap synchronization point

the test script

4. Manually change the 1 second wait in the script to 10 seconds

Change the following line:


8/6/2019 Win Tut

26/151

WinRunner Tutorial

obj_wait_bitmap ("StatusBar95", "Img1", 1);

To read:


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 a

question mark) and then click on the obj_wait_bitmap statement in the test scrip


q obj_wait_bitmap: the function in the test script which waits for ten secon

for the image to appear before moving on to the next action

q "StatusBar95": the logical name of the image (your test script may have

"Insert Done..." as the logical name)

q "Img1": the file name of the bitmap (the image)

q 10: the amount of seconds to wait for the image to appear (plus the default wh

we changed to one second)

Close the TSL Reference window

Run the Synchronized Test



bar





8/6/2019 Win Tut

27/151

WinRunner Tutorial


5. Watch how WinRunner waits for the "Insert Done" message to appear in the s

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


When testing an AUT with synchronization problems, we must insert a

synchronization point to stop WinRunner momentarily in its running of the test scripso 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


2. Select Run tab

3. For Timeout for checkpoints and CS statements, change the value to 10000

milliseconds

4. Click OK

Additional Exercise


2. Use the Help icon (arrow and question mark) to determine the action and synt

3. Write down in your notes answers to the following questions about these lines

from our test script:


8/6/2019 Win Tut

28/151

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?





8/6/2019 Win Tut

29/151

WinRunner Tutorial




Lesson Five:

GUI Verification


q what verification is

q 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 specifi

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 actualobject 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 functi

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 i

checking to see if the actual object matches the expected object when the actual objec

driven by a test script in WinRunner. (The verb actualize means to realize in action o

make real.)

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

Mercury Interactive

Corporation




8/6/2019 Win Tut

30/151

WinRunner Tutorial

Functionality testing of a GUI object can be performed by recording the interactions w

the AUT and then playing back the test script. The appearance of an AUT can be veri

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 matc

the expected object.

GUI Object Verification

q To verify a GUI object, we use GUI checkpoints; GUI checkpoints are placed

a test script and test a GUI object according to a specific checklist of propertiethat we create.

q With GUI checkpoints we can test to determine, for example:

r if a window is the correct size

r if a button is enabled or disabled

r if the correct text is in a text field

r if boxes are checked or unchecked

r if a list has the correct number of items

The Process for Establishing GUI Checkpoints

1. Determine the visual cues to verify


8/6/2019 Win Tut

31/151

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

q an object changes state (for example, from enabled to disabled, from focused t

unfocused)

q output data is returned from the system (for example, the total price of a sale o

invoice number)

q a message is returned from the system (for example, "Purchase completed")

Test 7

1. Start WinRunner





click OK


5. Start Recording


6. Open the Open Order dialog box in Flight Reservation

r File / Open Order

r Move the Open Order dialog box so that it does not overlap with

WinRunner


8/6/2019 Win Tut

32/151

WinRunner Tutorial

7. Create a GUI checkpoint for the Order No. check box

r Create / GUI Checkpoint / For Object/Window

r Use the hand pointer to double-click on the Order No. check box

r The Check GUI dialog box opens and displays the available checks

r Accept the default check ("State"); this will capture the current state

("OFF") of the check box and stores it as expected results

r Click OK

r 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 Use the hand pointer to single click on the Order No. check box

r WinRunner inserts a checkpoint for the default check ("State") by inser

the obj_check_gui statement in the test script

10. Create a GUI checkpoint for the Customer Name check box


r Use the hand pointer to double click on the Customer Name check box

r Accept the default check "State"

r Also, select "Enabled" as an additional check

r The State check captures the current state ("OFF") of the check box; th

enabled check captures the current condition ("OFF") of the check box

r Click OK

11. Click OK in the Open Order dialog box to open the order

12. Stop recording






8/6/2019 Win Tut

33/151

WinRunner Tutorial


16. Examine the Results

r Click on end GUI checkpoint

r 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


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

q "Order No.": logical name of GUI object to be verified

q "list1.ckl": name of checklist which defines the GUI checks

q "gui1": captured data in file used as the expected results

q 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


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 th

we create.


8/6/2019 Win Tut

34/151

WinRunner Tutorial





8/6/2019 Win Tut

35/151

WinRunner Tutorial




Lesson Six:

Bitmap Verification


q how to test Bitmap images in your application

q how to insert Bitmap checkpoints to verify Bitmap images

Bitmap Verification

q Recall that verification is the process by which WinRunner reports whether

expected results are actualized by the application

q With Bitmap verification, WinRunner is comparing a Bitmap image (the actua

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)

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 conditi

(optional)

4. Run the recorded test script

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

Mercury Interactive

Corporation




8/6/2019 Win Tut

36/151

WinRunner Tutorial

Test 8

1. Start WinRunner





click OK


5. Start Recording


6. Open order #6

r File / Open Order

r Select the Order No. check box and type 6

r Click OK

7. Open the Fax Order dialog box

r File / Fax Order


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 Press the F2 function key

13. Insert a Bitmap checkpoint that verifies your signature

r Create / Bitmap Checkpoint / For Object/Window

r Use the hand pointer to click on the Agent Signature box


8/6/2019 Win Tut

37/151

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

r Use the hand pointer to click on the Agent Signature box

r 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


19. Don't run the test; instead, lets view the expected results first

r Open the Test Results Window

r Tools / Test Results

r View the captured Bitmaps

s Double click on the first "capture bitmap" event

s Double click on the second "capture bitmap" event

r Close the Test Results window

s File / Exit





22. Examine the Results and then close the Results

The Syntax of the obj_check_bitmap Statement


question mark) and then click on the obj_check_bitmap statement in the test scr


8/6/2019 Win Tut

38/151

8/6/2019 Win Tut

39/151

WinRunner Tutorial




Lesson Seven:

Text Verification


q how to test text elements in an application

q how to insert text checkpoints to verify text elements

When to Use Text Verification

q When text is not part of a GUI object (e.g., a label or caption)

q When text is part of a bitmap image

q When text is part of a non-standard, custom GUI object

Functions Used to Read Text

If text is: Use:

A property of a standard GUI objectContext Sensitive functions (e.g.,

obj_get_info, button_get_info)

Part of custom GUI object which cannot

be read from the property

obj_get_text

Part of Bitmap or in ASCII (not part of

GUI object)text reading feature (e.g., win_get_text

Process to Verify Text

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

Mercury Interactive

Corporation




8/6/2019 Win Tut

40/151

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 (

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 ofVariableName 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

compare the actual text object and the expected text object and to report to us if the ac

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)


8/6/2019 Win Tut

41/151

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 sec

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

the actual text object (actual text value) stored in text, then the test step will have th

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 wil

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 ge

text:

1. Go to the window or object in the AUT where you need to get the text


8/6/2019 Win Tut

42/151

8/6/2019 Win Tut

43/151

WinRunner Tutorial

r Hold down the left mouse button and drag the cursor so that the text yo

want to capture (and no other text) is enclosed by a rectangle, then rele

the mouse button

r 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 t

value

VersionNum="Version 1.0";

12. After the last line of the test script, type in the following code which will verif

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.");


13. Check the test script by running it in debug mode

r Change mode to debug

r Run from Top

r If there are problems, fix your script and run in debug again

14. Playback or Run the test script in verify mode





17. Close the Results and the Flight Reservation application

18. Open the Flight Reservation (1B)

r Start / Programs / WinRunner / Sample Applications / Flight 1B


8/6/2019 Win Tut

44/151

WinRunner Tutorial

19. Playback or Run the test script again with this application in verify mode





r This test should have failed

22. Close the Results, the Flight Reservation application, and the test script


To verify text that is part of a Bitmap area, the tester must get the text (or read thetext), 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 ord

The order should increase the number of orders by 1. However, when we get the text,

variable text will be used to hold both values. The first time we get the text we will:


8/6/2019 Win Tut

45/151

WinRunner Tutorial

q 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 ifnew_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 sec

of the test script

The syntax for thetl_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


8/6/2019 Win Tut

46/151

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 st

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




r In login window, type your name and enter mercury for the password click OK


5. Start Recording


6. Open the graph in Flight Reservation

r Analysis / Graphs

r 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

r Use the crosshairs pointers and the left mouse to drag a rectangle aroun

the total

r Click the right mouse button to finish the operation

r 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


8/6/2019 Win Tut

47/151

WinRunner Tutorial


r Fly From: Denver



r Name: Sherri Moore

r 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

status bar

r Create / Synchronization Point / For Object/Window Bitmap

r Use hand pointer to click the "Insert Done" message

13. Open the graph again in Flight Reservation application

r Analysis / Graphs

r Position the graph so that it does not overlap WinRunner

14. Read the total from the graph

r Create / Get Text / From Screen Area

r Use the crosshairs pointers and the left mouse to drag a rectangle aroun

the total

r Click the right mouse button to finish the operation

r WinRunner inserts the obj_get_text statement in the test script

15. Close the graph

16. Stop recording


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


8/6/2019 Win Tut

48/151

WinRunner Tutorial

19. In the second obj_get_text statement in the test script, change the variable tex

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 Change mode to debug

r Run from Top

r If there are problems, fix your script and run in debug again

24. Change mode to verify and run the test script


26. Close the Results, the Flight Reservation application, and the test script


To verify text that changes in an AUT (for example, a number total), we must get th

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

increased by one after an order is placed.





8/6/2019 Win Tut

49/151

WinRunner Tutorial


8/6/2019 Win Tut

50/151

WinRunner Tutorial




Lesson Eight:

Introduction to GUI Map Files


q what a GUI map file is

q how WinRunner creates a GUI map file during recording

q 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.

q WinRunner adds the names of windows and objects to the GUI Map file as theare encountered by the user during recording

q The GUI Map contains information that allows TSL statements to be translate

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 thro

the GUI map before sending it to Windows OS which will interact with the AU

q 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

the AUT

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

Mercury Interactive

Corporation




8/6/2019 Win Tut

51/151

8/6/2019 Win Tut

52/151

WinRunner Tutorial

r Enter mercury for the password (do not yet press OK)

r Press Help and then press OK to exit the Help dialog box

r Press Cancel and then start the Flight Reservation again

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

r In login window, type in your name

r Use the mouse pointer to switch from the Name text field to the Passwo

text field; do not use the TAB key

r Enter mercury for the password and click OK


6. Close the Flight Reservation application

7. Stop recording


9. Do not run this test


11. Open GUI Map Editor

r Tools / GUI Map Editor

r In the GUI Map Editor, in the Windows/Objects field, scroll down unti

you see Login

s If the GUI objects that are part of the Login window are not

showing, double click on Login

Logical Name Physical Description

Login class: window,label: Login,

MSW_class: "#32770"

Agent Name: class: edit,

attached_text: "Agent Name:"


8/6/2019 Win Tut

53/151

8/6/2019 Win Tut

54/151

WinRunner Tutorial

password_edit_set: function that enters the password into edit object

also encrypts the password so that the password is not in the test scrip

"Password:": logical name of the edit object to receive input

"kzptnyoslzjsaz": encrypted string item to be entered into edit objec

button_press ("OK");

button_press: function that presses a click button

"OK": logical name of the button

r 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

GUI Map connects logical

name in test script to the

physical description in the

AUT

Physical description in t

AUT

button_press ("OK"); OK

{

class: push_button,

label: OK

}

class: push_button,

label: OK

q 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

logical name to each object and uses the logical name in the test script

q 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


8/6/2019 Win Tut

55/151

8/6/2019 Win Tut

56/151

WinRunner Tutorial




Lesson Nine:

Managing GUI Map Files


q two ways to create permanent GUI Map files

q how to add objects to a GUI Map file

q use the GUI Spy to read actual object descriptions

q 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 sa

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


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

Mercury Interactive

Corporation




8/6/2019 Win Tut

57/151

WinRunner Tutorial

r If objects are not visible in the Windows/Objects window, select View

GUI Map

r File / Save

r Select Save in New File...

r Select the a:\ drive for Save In:

r 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)

r Select Save

3. Close the GUI Map Editor

Test 12

1. Start WinRunner




r In login window, type your name and enter mercury for the password a

click OK


5. Start Recording


6. Create a new order in Flight Reservation

r File / New Order



r Fly From: Los Angeles




8/6/2019 Win Tut

58/151

WinRunner Tutorial

r Name: Andrew Smith



8. Delete the order by clicking the Delete Order button and then click on Yes in t

message window to confirm (this sets the end conditions)

9. Stop Recording


11. Open the GUI Map Editor


12. Save the GUI Map file (make the temporary GUI Map file a permanent GUI M

file)

r If objects are not visible in the Windows/Objects window, select View

GUI Map

r File / Save

r Select Save in New File...

r Select the a:\ drive for Save In:

r For File Name choose test12

r Select Save



Adding New Objects to a GUI Map File

When you saved the GUI Map file above, it has only those items that were in thetemporary 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

you may need to test. For this reason, you will need to add objects to the GUI Map fil

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


8/6/2019 Win Tut

59/151

WinRunner Tutorial


3. Transfer objects from the temporary GUI Map file to the permanent GUI Map

4. Save the permanent GUI Map file


Test 13

1. Start WinRunner





click OK


5. Start Recording


6. Press the Help icon (the question mark)

7. Press Search

8. Press Cancel



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.g

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


8/6/2019 Win Tut

60/151

WinRunner Tutorial

r Press Move and then OK

r Object should transfer from the temporary GUI Map file to the perman

GUI Map file

14. Save the permanent GUI Map file with its new object or objects

r File / Save


16. Stop Recording



Second Technique: One GUI Map File for Many Tests

For this second technique, we will make WinRunner or really the GUI Map Editor lea

all the windows and objects of the AUT.

Making the GUI Map Editor Learn the Objects

1. Open AUT


3. Click the Learn button and point with the hand pointer to each object of the AU

4. Save the permanent GUI Map file with a name similar to the AUT (since all te

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 tAUT 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


8/6/2019 Win Tut

61/151

8/6/2019 Win Tut

62/151

WinRunner Tutorial


Using the GUI Spy

The GUI Spy allows you to look at the AUT and get a complete physical description

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 physicaldescription of the object

Test 15: This test will not actually be a test script

1. Start WinRunner





click OK


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



8/6/2019 Win Tut

63/151

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 fo

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

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 M

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")




8/6/2019 Win Tut

64/151

8/6/2019 Win Tut

65/151

WinRunner Tutorial




Lesson Ten:

Batch Tests


q what a batch test is

q how to create a batch test

q how to run a batch test and analyze the results

q 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 decisiomaking statments like if-else statements.

A batch test appears to be a regular test script, but it differs in two main ways:

q it contains call statements to other test scripts

q 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"();

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

Mercury Interactive

Corporation




8/6/2019 Win Tut

66/151

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:


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






click OK


5. Start Recording


6. Create a new order in Flight Reservation application

r File / New Order




8/6/2019 Win Tut

67/151

WinRunner Tutorial

r Fly From: Frankfurt

r Fly To: Paris


r Name: Alexander Hamilton



8. Delete the order (this will set the end conditions)

r Click the Delete Order button

r Click Yes in the message window to confirm

9. Stop Recording








Test 17






click OK



8/6/2019 Win Tut

68/151

8/6/2019 Win Tut

69/151

8/6/2019 Win Tut

70/151

8/6/2019 Win Tut

71/151

WinRunner Tutorial

r For File Name type, batch2

r Press Save







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 w

wish.

Turning Off Batch Mode

Since we ran our batch test in batch mode, we have to go back and unselect batch mo

so that our next tests are not run in batch mode.


2. Click on the check in the Run in Batch Mode option check box (this will unsel

it)

3. Press OK





8/6/2019 Win Tut

72/151

WinRunner Tutorial


8/6/2019 Win Tut

73/151

WinRunner Tutorial




Lesson Eleven:

Data-Driven Tests


q what a data-driven test is

q how to use the DataDriver Wizard to create a data-driven test

q 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 da

(for example, entering John Smith as the customer's name for buying tickets) we hav

multiple sets of data, and with each iteration through the test script WinRunner insert

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 lowhile 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, w

will turn this test script into a data-driven test which will order tickets using different

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

Mercury Interactive

Corporation




8/6/2019 Win Tut

74/151

8/6/2019 Win Tut

75/151

WinRunner Tutorial






14. Close the Results

15. Don't close the test script and the Flight Reservation application

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

r Click the Next icon

r In the Use a new or existing Excel table text field, type: table1.xls

r Leave table as the variable name

r Put a check in the Add statements to create a data-driven test check box

r Put a check in the Parameterize the test check box

r Select Line by Line

r Select Next

r Make sure Do not replace this data is selected and press Next (we do no

want to parameterize the date)

r Make sure Do not replace this data is se

Win Tut

Documents

Transcript of Win Tut