Win Runner Questions 123

1) How you used WinRunner in your project?
a. Yes, I have been WinRunner for creating automates scripts for GUI, functional
and regression testing of the AUT.
2) Explain WinRunner testing process?
a. WinRunner testing process involves six main stages
i. Create GU !ap ile so that WinRunner can recogni!e the GUI ob"ects
in the application being tested
ii. Create test scripts b# recording, programming, or a combination of both.
While recording tests, insert chec$points %here #ou %ant to chec$ the
response of the application being tested.
iii. "e#ug $est% run tests in &ebug mode to ma$e sure the# run smoothl#
i&. Run $ests% run tests in 'erif# mode to test #our application.
&. 'iew Results% determines the success or failure of the tests.
&i. Report "e(ects% If a test run fails due to a defect in the application being
tested, #ou can report information about the defect directl# from the Test
Results %indo%.
)) W*at in contained in t*e GU +ap?
a. WinRunner stores information it learns about a %indo% or ob"ect in a GUI (ap.
When WinRunner runs a test, it uses the GUI map to locate ob"ects. It reads an
ob"ect)s description in the GUI map and then loo$s for an ob"ect %ith the same
properties in the application being tested. *ach of these ob"ects in the GUI (ap
file %ill be having a logical name and a ph#sical description.
#. There are + t#pes of GUI (ap files.
i. Glo#al GU !ap (ile, a single GUI (ap file for the entire application
ii. GU !ap ,ile per $est% WinRunner automaticall# creates a GUI (ap file
for each test created.
-) How does WinRunner recogni.e o#jects on t*e application?
a. WinRunner uses the GUI (ap file to recogni!e ob"ects on the application. When
WinRunner runs a test, it uses the GUI map to locate ob"ects. It reads an ob"ect)s
description in the GUI map and then loo$s for an ob"ect %ith the same properties
in the application being tested.
/) Ha&e you created test scripts and w*at is contained in t*e test scripts?
a. Yes I have created test scripts. It contains the statement in (ercur# Interactive)s
Test -cript .anguage /T-.0. These statements appear as a test script in a test
%indo%. You can then enhance #our recorded test script, either b# t#ping in
additional T-. functions and programming elements or b# using WinRunner)s
visual programming tool, the unction Generator.
0) How does WinRunner e&aluates test results?
a. ollo%ing each test run, WinRunner displa#s the results in a report. The report
details all the ma"or events that occurred during the run, such as chec$points,
error messages, s#stem messages, or user messages. If mismatches are detected at
chec$points during the test run, #ou can vie% the expected results and the actual
results from the Test Results %indo%.
1) Ha&e you per(or+ed de#ugging o( t*e scripts?
a. Yes, I have performed debugging of scripts. We can debug the script b# executing
the script in the debug mode. We can also debug script using the -tep, -tep Into,
-tep out functionalities provided b# the WinRunner.
2) How do you run your test scripts?
a. We run tests in 'erif# mode to test #our application. *ach time WinRunner
encounters a chec$point in the test script, it compares the current data of the
application being tested to the expected data captured earlier. If an# mismatches
#. are found, WinRunner captures them as actual results.
3) How do you analy.e results and report t*e de(ects?
a. ollo%ing each test run, WinRunner displa#s the results in a report. The report
details all the ma"or events that occurred during the run, such as chec$points,
error messages, s#stem messages, or user messages. If mismatches are detected at
chec$points during the test run, #ou can vie% the expected results and the actual
results from the Test Results %indo%. If a test run fails due to a defect in the
application being tested, #ou can report information about the defect directl# from
the Test Results %indo%. This information is sent via e1mail to the 2ualit#
assurance manager, %ho trac$s the defect until it is fixed.
14) W*at is t*e use o( $est "irector so(tware?
a. Test&irector is (ercur# Interactive)s soft%are test management tool. It helps
2ualit# assurance personnel plan and organi!e the testing process. With
Test&irector #ou can create a database of manual and automated tests, build test
c#cles, run tests, and report and trac$ defects. You can also create reports and
graphs to help revie% the progress of planning tests, running tests, and trac$ing
defects before a soft%are release.
11) How you integrated your auto+ated scripts (ro+ $est"irector?
a. When #ou %or$ %ith WinRunner, #ou can choose to save #our tests directl# to
#our Test&irector database or %hile creating a test case in the Test&irector %e can
specif# %hether the script in automated or manual. And if it is automated script
then Test&irector %ill build a s$eleton for the script that can be later modified into
one %hich could be used to test the AUT.
12) W*at are t*e di((erent +odes o( recording?
a. There are t%o t#pe of recording in WinRunner.
i. Context 5ensiti&e recording records the operations #ou perform on #our
application b# identif#ing Graphical User Interface /GUI0 ob"ects.
ii. 6nalog recording records $e#board input, mouse clic$s, and the precise
x1 and #1coordinates traveled b# the mouse pointer across the screen.
1)) W*at is t*e purpose o( loading WinRunner 6dd7ns?
a. Add1Ins are used in WinRunner to load functions specific to the particular add1in
to the memor#. While creating a script onl# those functions in the add1in selected
%ill be listed in the function generator and %hile executing the script onl# those
functions in the loaded add1in %ill be executed else WinRunner %ill give an error
message sa#ing it does not recogni!e the function.
1-) W*at are t*e reasons t*at WinRunner (ails to identi(y an o#ject on t*e GU?
a. WinRunner fails to identif# an ob"ect in a GUI due to various reasons.
i. The ob"ect is not a standard %indo%s ob"ect.
ii. If the bro%ser used is not compatible %ith the WinRunner version, GUI
(ap *ditor %ill not be able to learn an# of the ob"ects displa#ed in the
bro%ser %indo%.
1/) W*at do you +ean #y t*e logical na+e o( t*e o#ject.
a. An ob"ect)s logical name is determined b# its class. In most cases, the logical
name is the label that appears on an ob"ect.
10) ( t*e o#ject does not *a&e a na+e t*en w*at will #e t*e logical na+e?
a. If the ob"ect does not have a name then the logical name could be the attached
text.
11) W*at is t*e di((erent #etween GU +ap and GU +ap (iles?
a. The GUI map is actuall# the sum of one or more GUI map files. There are t%o
modes for organi!ing GUI map files.
i. Glo#al GU !ap (ile, a single GUI (ap file for the entire application
ii. GU !ap ,ile per $est% WinRunner automaticall# creates a GUI (ap file
for each test created.
#. GUI (ap file is a file %hich contains the %indo%s and the ob"ects learned b# the
WinRunner %ith its logical name and their ph#sical description.
12) How do you &iew t*e contents o( t*e GU +ap?
a. GUI (ap editor displa#s the content of a GUI (ap. We can invo$e GUI (ap
*ditor from the Tools (enu in WinRunner. The GUI (ap *ditor displa#s the
various GUI (ap files created and the %indo%s and ob"ects learned in to them
%ith their logical name and ph#sical description.
13) W*en you create GU +ap do you record all t*e o#jects o( speci(ic o#jects?
a. If %e are learning a %indo% then WinRunner automaticall# learns all the ob"ects
in the %indo% else %e %ill %e identif#ing those ob"ect, %hich are to be learned in
a %indo%, since %e %ill be %or$ing %ith onl# those ob"ects %hile creating scripts.
24) W*at is t*e purpose o( set8window co++and?
a. -et3Windo% command sets the focus to the specified %indo%. We use this
command to set the focus to the re2uired %indo% before executing tests on a
particular %indo%.
5yntax, set_window(<logical name>, time);
The logical name is the logical name of the %indo% and time is the time the execution
has to %ait till it gets the given %indo% into focus.
21) How do you load GU +ap?
a. We can load a GUI (ap b# using the GUI3load command.
5yntax% GUI_load(<file_name>);
22) W*at is t*e disad&antage o( loading t*e GU +aps t*roug* start up scripts?
a. If %e are using a single GUI (ap file for the entire AUT then the memor# used b#
the GUI (ap ma# be much high.
#. If there is an# change in the ob"ect being learned then WinRunner %ill not be able
to recogni!e the ob"ect, as it is not in the GUI (ap file loaded in the memor#. -o
%e %ill have to learn the ob"ect again and update the GUI ile and reload it.
2)) How do you unload t*e GU +ap?
a. We can use GUI3close to unload a specific GUI (ap file or else %e call use
GUI3close3all command to unload all the GUI (ap files loaded in the memor#.
5yntax% GUI_close(<file_name>); or GUI_close_all;
2-) W*at actually *appens w*en you load GU +ap?
a. When %e load a GUI (ap file, the information about the %indo%s and the ob"ects
%ith their logical names and ph#sical description are loaded into memor#. -o
%hen the WinRunner executes a script on a particular %indo%, it can identif# the
ob"ects using this information loaded in the memor#.
2/) W*at is t*e purpose o( t*e te+p GU +ap (ile?
a. While recording a script, WinRunner learns ob"ects and %indo%s b# itself. This is
actuall# stored into the temporar# GUI (ap file. We can specif# %hether %e have
to load this temporar# GUI (ap file should be loaded each time in the General
4ptions.
20) W*at is t*e extension o( gui +ap (ile?
a. The extension for a GUI (ap file is 5.gui6.
21) How do you (ind an o#ject in an GU +ap.
a. The GUI (ap *ditor is been provided %ith a ,ind and 5*ow 7uttons.
i. To find a particular ob"ect in the GUI (ap file in the application, select
the ob"ect and clic$ the 5*ow %indo%. This blin$s the selected ob"ect.
ii. To find a particular ob"ect in a GUI (ap file clic$ the ,ind button, %hich
gives the option to select the ob"ect. When the ob"ect is selected, if the
ob"ect has been learned to the GUI (ap file it %ill be focused in the GUI
(ap file.
22) W*at di((erent actions are per(or+ed #y (ind and s*ow #utton?
a. To find a particular ob"ect in the GUI (ap file in the application, select the ob"ect
and clic$ the 5*ow %indo%. This blin$s the selected ob"ect.
#. To find a particular ob"ect in a GUI (ap file clic$ the ,ind button, %hich gives
the option to select the ob"ect. When the ob"ect is selected, if the ob"ect has been
learned to the GUI (ap file it %ill be focused in the GUI (ap file.
23) How do you identi(y w*ic* (iles are loaded in t*e GU +ap?
a. The GUI (ap *ditor has a drop do%n 5GU ,ile6 displa#ing all the GUI (ap
files loaded into the memor#.
)4) How do you +odi(y t*e logical na+e or t*e p*ysical description o( t*e o#jects in
GU +ap?
a. You can modif# the logical name or the ph#sical description of an ob"ect in a GUI
map file using the GUI (ap *ditor.
)1) W*en do you (eel you need to +odi(y t*e logical na+e?
a. 8hanging the logical name of an ob"ect is useful %hen the assigned logical name
is not sufficientl# descriptive or is too long.
)2) W*en it is appropriate to c*ange p*ysical description?
a. 8hanging the ph#sical description is necessar# %hen the propert# value of an
ob"ect changes.
))) How WinRunner *andles &arying window la#els?
a. We can handle var#ing %indo% labels using regular expressions. WinRunner
uses t%o 5hidden6 properties in order to use regular expression in an ob"ect)s
ph#sical description. These properties are regexp8la#el and regexp8!5W8class.
i. The regexp8la#el propert# is used for %indo%s onl#. It operates 5behind
the scenes6 to insert a regular expression into a %indo%)s label
description.
ii. The regexp8!5W8class propert# inserts a regular expression into an
ob"ect)s !5W8class. It is obligator# for all t#pes of %indo%s and for the
ob"ect class ob"ect.
)-) W*at is t*e purpose o( regexp8la#el property and regexp8!5W8class property?
a. The regexp8la#el propert# is used for %indo%s onl#. It operates 5behind the
scenes6 to insert a regular expression into a %indo%)s label description.
#. The regexp8!5W8class propert# inserts a regular expression into an ob"ect)s
!5W8class. It is obligator# for all t#pes of %indo%s and for the ob"ect class
ob"ect.
)/) How do you suppress a regular expression?
a. We can suppress the regular expression of a %indo% b# replacing the
regexp8la#el propert# %ith la#el propert#.
)0) How do you copy and +o&e o#jects #etween di((erent GU +ap (iles?
a. We can cop# and move ob"ects bet%een different GUI (ap files using the GUI
(ap *ditor. The steps to be follo%ed are,
i. 8hoose $ools 9 GU !ap Editor to open the GUI (ap *ditor.
ii. 8hoose 'iew 9 GU ,iles.
iii. 8lic$ Expand in the GU !ap Editor. The dialog box expands to displa#
t%o GUI map files simultaneousl#.
i&. 'ie% a different GUI map file on each side of the dialog box b# clic$ing
the file names in the GUI ile lists.
&. In one file, select the ob"ects #ou %ant to cop# or move. Use the 5*i(t :ey
and;or Control :ey to select +ultiple o#jects. To select all ob"ects in a
GUI map file, choose Edit 9 5elect 6ll.
&i. 8lic$ Copy or !o&e.
&ii. To restore the GUI (ap *ditor to its original si!e, clic$ Collapse.
)1) How do you select +ultiple o#jects during +erging t*e (iles?
a. Use the 5*i(t :ey and;or Control :ey to select +ultiple o#jects. To select all
ob"ects in a GUI map file, choose Edit 9 5elect 6ll.
)2) How do you clear a GU +ap (iles?
a. We can clear a GUI (ap file using the 5Clear 6ll6 option in the GUI (ap *ditor.
)3) How do you (ilter t*e o#jects in t*e GU +ap?
a. GUI (ap *ditor has a ilter option. This provides for filtering %ith 9 different
t#pes of options.
i. .ogical name displa#s onl# ob"ects %ith the specified logical name.
ii. :h#sical description displa#s onl# ob"ects matching the specified ph#sical
description. Use an# substring belonging to the ph#sical description.
iii. 8lass displa#s onl# ob"ects of the specified class, such as all the push
buttons.
-4) How do you con(igure GU +ap?
a. When WinRunner learns the description of a GUI ob"ect, it does not learn all its
properties. Instead, it learns the minimum number of properties to provide a
uni2ue identification of the ob"ect.
#. (an# applications also contain custom GUI ob"ects. A custom ob"ect is an#
ob"ect not belonging to one of the standard classes used b# WinRunner. These
ob"ects are therefore assigned to the generic 5ob"ect6 class. When WinRunner
records an operation on a custom ob"ect, it generates o#j8+ouse8 statements in
the test script.
c. If a custom ob"ect is similar to a standard ob"ect, #ou can map it to one of the
standard classes. You can also configure the properties WinRunner uses to
identif# a custom ob"ect during 8ontext -ensitive testing. The mapping and the
configuration #ou set are valid onl# for the current WinRunner session. To ma$e
the mapping and the configuration permanent, #ou must add configuration
statements to #our startup test script.
-1) W*at is t*e purpose o( GU +ap con(iguration?
a. GUI (ap configuration is used to map a custom ob"ect to a standard ob"ect.
-2) How do you +a:e t*e con(iguration and +appings per+anent?
a. The mapping and the configuration #ou set are valid onl# for the current
WinRunner session. To ma$e the mapping and the configuration permanent, #ou
must add configuration statements to #our startup test script.
-)) W*at is t*e purpose o( GU spy?
a. Using the GUI -p#, #ou can vie% the properties of an# GUI ob"ect on #our
des$top. You use the -p# pointer to point to an ob"ect, and the GUI -p# displa#s
the properties and their values in the GUI -p# dialog box. You can choose to vie%
all the properties of an ob"ect, or onl# the selected set of properties that
WinRunner learns.
--) W*at is t*e purpose o( o#ligatory and optional properties o( t*e o#jects?
a. or each class, WinRunner learns a set of default properties. *ach default propert#
is classified 5o#ligatory6 or 5optional6.
i. An o#ligatory propert# is al%a#s learned /if it exists0.
ii. An optional propert# is used onl# if the obligator# properties do not
provide uni2ue identification of an ob"ect. These optional properties are
stored in a list. WinRunner selects the minimum number of properties
from this list that are necessar# to identif# the ob"ect. It begins %ith the
first propert# in the list, and continues, if necessar#, to add properties to
the description until it obtains uni2ue identification for the ob"ect.
-/) W*en t*e optional properties are learned?
a. An optional propert# is used onl# if the obligator# properties do not provide
uni2ue identification of an ob"ect.
-0) W*at is t*e purpose o( location indicator and index indicator in GU +ap
con(iguration?
a. In cases %here the obligator# and optional properties do not uni2uel# identif# an
ob"ect, WinRunner uses a selector to differentiate bet%een them. T%o t#pes of
selectors are available,
i. A location selector uses the spatial position of ob"ects.
;. The location selector uses the spatial order of ob"ects %ithin the
%indo%, from the top left to the bottom right corners, to
differentiate among ob"ects %ith the same description.
ii. An index selector uses a uni2ue number to identif# the ob"ect in a
%indo%.
;. The index selector uses numbers assigned at the time of creation of
ob"ects to identif# the ob"ect in a %indo%. Use this selector if the
location of ob"ects %ith the same description ma# change %ithin a
%indo%.
-1) How do you *andle custo+ o#jects?
a. A custom ob"ect is an# GUI ob"ect not belonging to one of the standard classes
used b# WinRunner. WinRunner learns such ob"ects under the generic 5ob"ect6
class. WinRunner records operations on custom ob"ects using o#j8+ouse8
statements.
#. If a custom ob"ect is similar to a standard ob"ect, #ou can map it to one of the
standard classes. You can also configure the properties WinRunner uses to
identif# a custom ob"ect during 8ontext -ensitive testing.
-2) W*at is t*e na+e o( custo+ class in WinRunner and w*at +et*ods it applies on t*e
custo+ o#jects?
a. WinRunner learns custom class ob"ects under the generic 5ob"ect6 class.
WinRunner records operations on custom ob"ects using o#j8 statements.
-3) n a situation w*en o#ligatory and optional #ot* t*e properties cannot uni<uely
identi(y an o#ject w*at +et*od WinRunner applies?
a. In cases %here the obligator# and optional properties do not uni2uel# identif# an
ob"ect, WinRunner uses a selector to differentiate bet%een them. T%o t#pes of
selectors are available,
i. A location selector uses the spatial position of ob"ects.
ii. An index selector uses a uni2ue number to identif# the ob"ect in a
%indo%.
/4) W*at is t*e purpose o( di((erent record +et*ods 1) Record 2) =ass up )) 6s >#ject
-) gnore.
a. Record instructs WinRunner to record all operations performed on a GUI ob"ect.
This is the default record method for all classes. /The onl# exception is the static
class /static text0, for %hich the default is :ass Up.0
#. =ass Up instructs WinRunner to record an operation performed on this class as an
operation performed on the element containing the ob"ect. Usuall# this element is
a %indo%, and the operation is recorded as win8+ouse8clic:.
c. 6s >#ject instructs WinRunner to record all operations performed on a GUI
ob"ect as though its class %ere 5ob"ect6 class.
d. gnore instructs WinRunner to disregard all operations performed on the class.
/1) How do you (ind out w*ic* is t*e start up (ile in WinRunner?
a. The test script name in the -tartup Test box in the *nvironment tab in the General
4ptions dialog box is the start up file in WinRunner.
/2) W*at are t*e &irtual o#jects and *ow do you learn t*e+?
a. Applications ma# contain bitmaps that loo$ and behave li$e GUI ob"ects.
WinRunner records operations on these bitmaps using %in3mouse3clic$
statements. 7# defining a bitmap as a virtual ob"ect, #ou can instruct WinRunner
to treat it li$e a GUI ob"ect such as a push button, %hen #ou record and run tests.
#. Using the 'irtual 4b"ect %i!ard, #ou can assign a bitmap to a standard ob"ect
class, define the coordinates of that ob"ect, and assign it a logical name.
$o de(ine a &irtual o#ject using t*e 'irtual >#ject wi.ard%
i. 8hoose Tools < 'irtual 4b"ect Wi!ard. The 'irtual 4b"ect %i!ard opens.
8lic$ =ext.
ii. In the 8lass list, select a class for the ne% virtual ob"ect. If ro%s that are
displa#ed in the %indo%. or a table class, select the number of visible
ro%s and columns. 8lic$ =ext.
iii. 8lic$ (ar$ 4b"ect. Use the crosshairs pointer to select the area of the
virtual ob"ect. You can use the arro% $e#s to ma$e precise ad"ustments to
the area #ou define %ith the crosshairs. :ress *nter or clic$ the right
mouse button to displa# the virtual ob"ect)s coordinates in the %i!ard. If
the ob"ect mar$ed is visible on the screen, #ou can clic$ the >ighlight
button to vie% it. 8lic$ =ext.
i&. Assign a logical name to the virtual ob"ect. This is the name that appears
in the test script %hen #ou record on the virtual ob"ect. If the ob"ect
contains text that WinRunner can read, the %i!ard suggests using this text
for the logical name. 4ther%ise, WinRunner suggests &irtual8o#ject,
&irtual8pus*8#utton, &irtual8list, etc.
&. You can accept the %i!ard)s suggestion or t#pe in a different name.
WinRunner chec$s that there are no other ob"ects in the GUI map %ith the
same name before confirming #our choice. 8lic$ =ext.
/)) How you created you test scripts 1) #y recording or 2) progra++ing?
a. :rogramming. I have done complete programming onl#, absolutel# no recording.
/-) W*at are t*e two +odes o( recording?
a. There are + modes of recording in WinRunner
i. Context 5ensiti&e recording records the operations #ou perform on #our
application b# identif#ing Graphical User Interface /GUI0 ob"ects.
ii. 6nalog recording records $e#board input, mouse clic$s, and the precise
x1 and #1coordinates traveled b# the mouse pointer across the screen.
//) W*at is a c*ec:point and w*at are di((erent types o( c*ec:points?
a. 8hec$points allo% #ou to compare the current behavior of the application being
tested to its behavior in an earlier version.
You can add four t#pes of chec$points to #our test scripts,
i. GU c*ec:points verif# information about GUI ob"ects. or example, #ou
can chec$ that a button is enabled or see %hich item is selected in a list.
ii. ?it+ap c*ec:points ta$e a 5snapshot6 of a %indo% or area of #our
application and compare this to an image captured in an earlier version.
iii. $ext c*ec:points read text in GUI ob"ects and in bitmaps and enable #ou
to verif# their contents.
i&. "ata#ase c*ec:points chec$ the contents and the number of ro%s and
columns of a result set, %hich is based on a 2uer# #ou create on #our
database.
/0) W*at are data dri&en tests?
a. When #ou test #our application, #ou ma# %ant to chec$ ho% it performs the same
operations %ith multiple sets of data. You can create a data1driven test %ith a loop
that runs ten times, each time the loop runs, it is driven b# a different set of data.
In order for WinRunner to use data to drive the test, #ou must lin$ the data to the
test script %hich it drives. This is called parameteri!ing #our test. The data is
stored in a data table. You can perform these operations manuall#, or #ou can use
the &ata&river Wi!ard to parameteri!e #our test and store the data in a data table.
/1) W*at are t*e sync*roni.ation points?
a. -#nchroni!ation points enable #ou to solve anticipated timing problems bet%een
the test and #our application. or example, if #ou create a test that opens a
database application, #ou can add a s#nchroni!ation point that causes the test to
%ait until the database records are loaded on the screen.
#. or Analog testing, #ou can also use a s#nchroni!ation point to ensure that
WinRunner repositions a %indo% at a specific location. When #ou run a test, the
mouse cursor travels along exact coordinates. Repositioning the %indo% enables
the mouse pointer to ma$e contact %ith the correct elements in the %indo%.
/2) W*at is para+eteri.ing?
a. In order for WinRunner to use data to drive the test, #ou must lin$ the data to the
test script %hich it drives. This is called parameteri!ing #our test. The data is
stored in a data table.
/3) How do you +aintain t*e docu+ent in(or+ation o( t*e test scripts?
a. 7efore creating a test, #ou can document information about the test in the General
and &escription tabs of the Test :roperties dialog box. You can enter the name of
the test author, the t#pe of functionalit# tested, a detailed description of the test,
and a reference to the relevant functional specifications document.
04) W*at do you &eri(y wit* t*e GU c*ec:point (or single property and w*at co++and
it generates@ explain syntax?
a. You can chec$ a single propert# of a GUI ob"ect. or example, #ou can chec$
%hether a button is enabled or disabled or %hether an item in a list is selected. To
create a GUI chec$point for a propert# value, use the 8hec$ :ropert# dialog box
to add one of the follo%ing functions to the test script,
i. button3chec$3info
ii. scroll3chec$3info
iii. edit3chec$3info
i&. static3chec$3info
&. list3chec$3info
&i. %in3chec$3info
&ii. ob"3chec$3info
5yntax% button_check_info (button, propert, propert_!alue );
edit_check_info ( edit, propert, propert_!alue );
01) W*at do you &eri(y wit* t*e GU c*ec:point (or o#ject;window and w*at co++and
a. You can create a GUI chec$point to chec$ a single ob"ect in the application being
tested. You can either chec$ the ob"ect %ith its default properties or #ou can
specif# %hich properties to chec$.
#. Creating a GU C*ec:point using t*e "e(ault C*ec:s
i. You can create a GUI chec$point that performs a default chec$ on the
propert# recommended b# WinRunner. or example, if #ou create a GUI
chec$point that chec$s a push button, the default chec$ verifies that the
push button is enabled.
ii. To create a GUI chec$point using default chec$s,
;. 8hoose 8reate < GUI 8hec$point < or 4b"ect?Windo%, or clic$
the GUI 8hec$point for 4b"ect?Windo% button on the User
toolbar. If #ou are recording in Analog mode, press the 8>*8@
GUI 4R 47A*8T?WI=&4W soft$e# in order to avoid
extraneous mouse movements. =ote that #ou can press the
8>*8@ GUI 4R 47A*8T?WI=&4W soft$e# in 8ontext
-ensitive mode as %ell. The WinRunner %indo% is minimi!ed, the
mouse pointer becomes a pointing hand, and a help %indo% opens
on the screen.
+. 8lic$ an ob"ect.
9. WinRunner captures the current value of the propert# of the GUI
ob"ect being chec$ed and stores it in the test)s expected results
folder. The WinRunner %indo% is restored and a GUI chec$point
is inserted in the test script as an ob"3chec$3gui statement
5yntax, win_check_gui ( window, checklist, e"pected_results_file, time );
c. Creating a GU C*ec:point #y 5peci(ying w*ic* =roperties to C*ec:
d. You can specif# %hich properties to chec$ for an ob"ect. or example, if #ou
create a chec$point that chec$s a push button, #ou can choose to verif# that it is in
focus, instead of enabled.
e. $o create a GU c*ec:point #y speci(ying w*ic* properties to c*ec:%
i. 8hoose 8reate < GUI 8hec$point < or 4b"ect?Windo%, or clic$ the GUI
8hec$point for 4b"ect?Windo% button on the User toolbar. If #ou are
recording in Analog mode, press the 8>*8@ GUI 4R
47A*8T?WI=&4W soft$e# in order to avoid extraneous mouse
movements. =ote that #ou can press the 8>*8@ GUI 4R
47A*8T?WI=&4W soft$e# in 8ontext -ensitive mode as %ell. The
WinRunner %indo% is minimi!ed, the mouse pointer becomes a pointing
hand, and a help %indo% opens on the screen.
ii. &ouble1clic$ the ob"ect or %indo%. The 8hec$ GUI dialog box opens.
iii. 8lic$ an ob"ect name in the 4b"ects pane. The :roperties pane lists all the
properties for the selected ob"ect.
i&. -elect the properties #ou %ant to chec$.
;. To edit the expected value of a propert#, first select it. =ext, either
clic$ the *dit *xpected 'alue button, or double1clic$ the value in
the *xpected 'alue column to edit it.
+. To add a chec$ in %hich #ou specif# arguments, first select the
propert# for %hich #ou %ant to specif# arguments. =ext, either
clic$ the -pecif# Arguments button, or double1clic$ in the
Arguments column. =ote that if an ellipsis /three dots0 appears in
the Arguments column, then #ou must specif# arguments for a
chec$ on this propert#. /You do not need to specif# arguments if a
default argument is specified.0 When chec$ing standard ob"ects,
#ou onl# specif# arguments for certain properties of edit and static
text ob"ects. You also specif# arguments for chec$s on certain
properties of nonstandard ob"ects.
9. To change the vie%ing options for the properties of an ob"ect, use
the -ho% :roperties buttons.
B. 8lic$ 4@ to close the 8hec$ GUI dialog box. WinRunner captures
the GUI information and stores it in the test)s expected results
folder. The WinRunner %indo% is restored and a GUI chec$point
is inserted in the test script as an ob"3chec$3gui or a
%in3chec$3gui statement.
ob#_check_gui ( ob#ect, checklist, e"pected results file, time );
02) W*at do you &eri(y wit* t*e GU c*ec:point (or +ultiple o#jects and w*at
co++and it generates@ explain syntax?
a. $o create a GU c*ec:point (or two or +ore o#jects%
i. 8hoose 8reate < GUI 8hec$point < or (ultiple 4b"ects or clic$ the GUI
8hec$point for (ultiple 4b"ects button on the User toolbar. If #ou are
recording in Analog mode, press the 8>*8@ GUI 4R (U.TI:.*
47A*8T- soft$e# in order to avoid extraneous mouse movements. The
8reate GUI 8hec$point dialog box opens.
ii. 8lic$ the Add button. The mouse pointer becomes a pointing hand and a
help %indo% opens.
iii. To add an ob"ect, clic$ it once. If #ou clic$ a %indo% title bar or menu bar,
a help %indo% prompts #ou to chec$ all the ob"ects in the %indo%.
i&. The pointing hand remains active. You can continue to choose ob"ects b#
repeating step 9 above for each ob"ect #ou %ant to chec$.
&. 8lic$ the right mouse button to stop the selection process and to restore
the mouse pointer to its original shape. The 8reate GUI 8hec$point dialog
box reopens.
&i. The 4b"ects pane contains the name of the %indo% and ob"ects included in
the GUI chec$point. To specif# %hich ob"ects to chec$, clic$ an ob"ect
name in the 4b"ects pane. The :roperties pane lists all the properties of the
ob"ect. The default properties are selected.
;. To edit the expected value of a propert#, first select it. =ext, either
clic$ the *dit *xpected 'alue button, or double1clic$ the value in
the *xpected 'alue column to edit it.
+. To add a chec$ in %hich #ou specif# arguments, first select the
propert# for %hich #ou %ant to specif# arguments. =ext, either
clic$ the -pecif# Arguments button, or double1clic$ in the
Arguments column. =ote that if an ellipsis appears in the
Arguments column, then #ou must specif# arguments for a chec$
on this propert#. /You do not need to specif# arguments if a default
argument is specified.0 When chec$ing standard ob"ects, #ou onl#
specif# arguments for certain properties of edit and static text
ob"ects. You also specif# arguments for chec$s on certain
properties of nonstandard ob"ects.
9. To change the vie%ing options for the properties of an ob"ect, use
the -ho% :roperties buttons.
&ii. To save the chec$list and close the 8reate GUI 8hec$point dialog box,
clic$ 4@. WinRunner captures the current propert# values of the selected
GUI ob"ects and stores it in the expected results folder. A %in3chec$3gui
statement is inserted in the test script.
ob#_check_gui ( ob#ect, checklist, e"pected results file, time );
0)) W*at in(or+ation is contained in t*e c*ec:list (ile and in w*ic* (ile expected results
are stored?
a. The chec$list file contains information about the ob"ects and the properties of the
ob"ect %e are verif#ing.
#. The guiA.c*: file contains the expected results %hich is stored in the exp folder
0-) W*at do you &eri(y wit* t*e #it+ap c*ec: point (or o#ject;window and w*at
a. You can chec$ an ob"ect, a %indo%, or an area of a screen in #our application as a
bitmap. While creating a test, #ou indicate %hat #ou %ant to chec$. WinRunner
captures the specified bitmap, stores it in the expected results folder /exp0 of the
test, and inserts a chec$point in the test script. When #ou run the test, WinRunner
compares the bitmap currentl# displa#ed in the application being tested %ith the
expected bitmap stored earlier. In the event of a mismatch, WinRunner captures
the current actual bitmap and generates a difference bitmap. 7# comparing the
three bitmaps /expected, actual, and difference0, #ou can identif# the nature of the
discrepanc#.
#. When %or$ing in 8ontext -ensitive mode, #ou can capture a bitmap of a %indo%,
ob"ect, or of a specified area of a screen. WinRunner inserts a chec$point in the
test script in the form of either a %in3chec$3bitmap or ob"3chec$3bitmap
statement.
c. =ote that %hen #ou record a test in Analog mode, #ou should press the 8>*8@
7IT(A: 4 WI=&4W soft$e# or the 8>*8@ 7IT(A: 4 -8R**= AR*A
soft$e# to create a bitmap chec$point. This prevents WinRunner from recording
extraneous mouse movements. If #ou are programming a test, #ou can also use
the Analog function chec$3%indo% to chec$ a bitmap.
d. $o capture a window or o#ject as a #it+ap%
i. 8hoose 8reate < 7itmap 8hec$point < or 4b"ect?Windo% or clic$ the
7itmap 8hec$point for 4b"ect?Windo% button on the User toolbar.
Alternativel#, if #ou are recording in Analog mode, press the 8>*8@
7IT(A: 4 47A*8T?WI=&4W soft$e#. The WinRunner %indo% is
minimi!ed, the mouse pointer becomes a pointing hand, and a help
%indo% opens.
ii. :oint to the ob"ect or %indo% and clic$ it. WinRunner captures the bitmap
and generates a %in3chec$3bitmap or ob"3chec$3bitmap statement in the
script. The T-. statement generated for a %indo% bitmap has the
follo%ing s#ntax,
%in3chec$3bitmap / ob"ect, bitmap, time 0C
iii. or an ob"ect bitmap, the s#ntax is,
ob"3chec$3bitmap / ob"ect, bitmap, time 0C
i&. or example, %hen #ou clic$ the title bar of the main %indo% of the light
Reservation application, the resulting statement might be,
%in3chec$3bitmap /Dlight ReservationD, DImg+D, ;0C
&. >o%ever, if #ou clic$ the &ate of light box in the same %indo%, the
statement might be,
ob"3chec$3bitmap /D&ate of light,D, DImg;D, ;0C
5yntax$ ob#_check_bitmap ( ob#ect, bitmap, time %, ", , width, height& );
0/) W*at do you &eri(y wit* t*e #it+ap c*ec:point (or screen area and w*at co++and
a. You can define an# rectangular area of the screen and capture it as a bitmap for
comparison. The area can be an# si!e, it can be part of a single %indo%, or it can
intersect several %indo%s. The rectangle is identified b# the coordinates of its
upper left and lo%er right corners, relative to the upper left corner of the %indo%
in %hich the area is located. If the area intersects several %indo%s or is part of a
%indo% %ith no title /for example, a popup %indo%0, its coordinates are relative
to the entire screen /the root %indo%0.
#. $o capture an area o( t*e screen as a #it+ap%
i. 8hoose 8reate < 7itmap 8hec$point < or -creen Area or clic$ the
7itmap 8hec$point for -creen Area button. Alternativel#, if #ou are
recording in Analog mode, press the 8>*8@ 7IT(A: 4 -8R**=
AR*A soft$e#. The WinRunner %indo% is minimi!ed, the mouse pointer
becomes a crosshairs pointer, and a help %indo% opens.
ii. (ar$ the area to be captured, press the left mouse button and drag the
mouse pointer until a rectangle encloses the areaC then release the mouse
button.
iii. :ress the right mouse button to complete the operation. WinRunner
captures the area and generates a %in3chec$3bitmap statement in #our
script.
i&. The %in3chec$3bitmap statement for an area of the screen has the
follo%ing s#ntax,
win_check_bitmap ( window, bitmap, time, ", , width, height );
00) W*at do you &eri(y wit* t*e data#ase c*ec:point de(ault and w*at co++and it
generates@ explain syntax?
a. 7# adding runtime database record chec$points #ou can compare the information
in #our application during a test run %ith the corresponding record in #our
database. 7# adding standard database chec$points to #our test scripts, #ou can
chec$ the contents of databases in different versions of #our application.
#. When #ou create database chec$points, #ou define a 2uer# on #our database, and
#our database chec$point chec$s the values contained in the result set. The result
set is set of values retrieved from the results of the 2uer#.
c. You can create runtime database record chec$points in order to compare the
values displa#ed in #our application during the test run %ith the corresponding
values in the database. If the comparison does not meet the success criteria #ou
d. specif# for the chec$point, the chec$point fails. You can define a successful
runtime database record chec$point as one %here one or more matching records
%ere found, exactl# one matching record %as found, or %here no matching
records are found.
e. You can create standard database chec$points to compare the current values of the
properties of the result set during the test run to the expected values captured
during recording or other%ise set before the test run. If the expected results and
the current results do not match, the database chec$point fails. -tandard database
chec$points are useful %hen the expected results can be established before the test
run.
5yntax, db_check(<checklist_file>, <e"pected_restult>);
(. You can add a runtime database record chec$point to #our test in order to compare
information that appears in #our application during a test run %ith the current
value/s0 in the corresponding record/s0 in #our database. You add runtime
database record chec$points b# running the Runtime Record 8hec$point %i!ard.
When #ou are finished, the %i!ard inserts the appropriate d#8record8c*ec:
statement into #our script.
5yntax%
db_record_check('hecklist(ile)ame,*uccess'onditions,+ecord)umber );
C*ec:list,ileBa+e A file created b# WinRunner and saved in the testEs
chec$list folder. The file contains information about the data to be captured during
the test run and its corresponding field in the database. The file is created based
on the information entered in the Runtime Record 'erification %i!ard.
5uccessConditions 8ontains one of the follo%ing values,
;. &'R34=*34R3(4R*3(AT8> 1 The chec$point passes if one or
more matching database records are found.
+. &'R34=*3(AT8> 1 The chec$point passes if exactl# one matching
database record is found.
9. &'R3=43(AT8> 1 The chec$point passes if no matching database
records are found.
RecordBu+#er An out parameter returning the number of records in the
database.
01) How do you *andle dyna+ically c*anging area o( t*e window in t*e #it+ap
c*ec:points?
a. The difference bet%een bitmaps option in the Run Tab of the general options
defines the minimum number of pixels that constitute a bitmap mismatch
02) W*at do you &eri(y wit* t*e data#ase c*ec: point custo+ and w*at co++and it
a. When #ou create a custom chec$ on a database, #ou create a standard database
chec$point in %hich #ou can specif# %hich properties to chec$ on a result set.
#. You can create a custom chec$ on a database in order to,
i. chec$ the contents of part or the entire result set
ii. edit the expected results of the contents of the result set
iii. count the ro%s in the result set
i&. count the columns in the result set
c. You can create a custom chec$ on a database using 4&78, (icrosoft Fuer# or
&ata Aunction.
03) W*at do you &eri(y wit* t*e sync point (or o#ject;window property and w*at
a. -#nchroni!ation compensates for inconsistencies in the performance of #our
application during a test run. 7# inserting a s#nchroni!ation point in #our test
script, #ou can instruct WinRunner to suspend the test run and %ait for a cue
before continuing the test.
#. You can a s#nchroni!ation point that instructs WinRunner to %ait for a specified
ob"ect or %indo% to appear. or example, #ou can tell WinRunner to %ait for a
%indo% to open before performing an operation %ithin that %indo%, or #ou ma#
%ant WinRunner to %ait for an ob"ect to appear in order to perform an operation
on that ob"ect.
c. You use the ob"3exists function to create an ob"ect s#nchroni!ation point, and #ou
use the %in3exists function to create a %indo% s#nchroni!ation point. These
functions have the follo%ing s#ntax,
5yntax%
ob#_e"ists ( ob#ect %, time & );
win_e"ists ( window %, time & );
14) W*at do you &eri(y wit* t*e sync point (or o#ject;window #it+ap and w*at
a. You can create a bitmap s#nchroni!ation point that %aits for the bitmap of an
ob"ect or a %indo% to appear in the application being tested.
#. &uring a test run, WinRunner suspends test execution until the specified bitmap is
redra%n, and then compares the current bitmap %ith the expected one captured
earlier. If the bitmaps match, then WinRunner continues the test.
5yntax%
ob#_wait_bitmap ( ob#ect, image, time );
win_wait_bitmap ( window, image, time 0C
11) W*at do you &eri(y wit* t*e sync point (or screen area and w*at co++and it
a. or screen area verification %e actuall# capture the screen area into a bitmap and
verif# the application screen area %ith the bitmap file during execution
5yntax% ob#_wait_bitmap(ob#ect, image, time, ", , width, height);
12) How do you edit c*ec:list (ile and w*en do you need to edit t*e c*ec:list (ile?
a. WinRunner has an edit chec$list file option under the create menu. -elect the
5*dit GUI 8hec$list6 to modif# GUI chec$list file and 5*dit &atabase 8hec$list6
to edit database chec$list file. This brings up a dialog box that gives #ou option to
select the chec$list file to modif#. There is also an option to select the scope of the
chec$list file, %hether it is Test specific or a shared one. -elect the chec$list file,
clic$ 4@ %hich opens up the %indo% to edit the properties of the ob"ects.
1)) How do you edit t*e expected &alue o( an o#ject?
a. We can modif# the expected value of the ob"ect b# executing the script in the
Update mode. We can also manuall# edit the guiG.ch$ file %hich contains the
expected values %hich come under the exp folder to change the values.
1-) How do you +odi(y t*e expected results o( a GU c*ec:point?
a. We can modif# the expected results of a GUI chec$point be running the script
containing the chec$point in the update mode.
1/) How do you *andle 6cti&eC and 'isual #asic o#jects?
a. WinRunner provides %ith add1ins for ActiveH and 'isual basic ob"ects. When
loading WinRunner, select those add1ins and these add1ins provide %ith a set of
functions to %or$ on ActiveH and '7 ob"ects.
10) How do you create >"?C <uery?
a. We can create 4&78 2uer# using the database chec$point %i!ard. It provides
%ith option to create an -F. file that uses an 4&78 &-= to connect to the
database. The -F. ile %ill contain the connection string and the -F. statement.
11) How do you record a data dri&en test?
a. We can create a data1driven testing using data from a flat file, data table or a
database.
i. Using ,lat ,ile, %e actuall# store the data to be used in a re2uired format
in the file. We access the file using the ile manipulation commands, reads
data from the file and assign the variables %ith data.
ii. "ata $a#le% It is an excel file. We can store test data in these files and
manipulate them. We use the Iddt8A) functions to manipulate data in the
data table.
iii. "ata#ase% %e store test data in the database and access these data using
Id#8A) functions.
12) How do you con&ert a data#ase (ile to a text (ile?
a. You can use &ata Aunction to create a conversion file %hich converts a database to
a target text file.
13) How do you para+eteri.e data#ase c*ec: points?
a. When #ou create a standard database chec$point using 4&78 /(icrosoft Fuer#0,
#ou can add parameters to an -F. statement to parameteri!e the chec$point. This
is useful if #ou %ant to create a database chec$point %ith a 2uer# in %hich the
-F. statement defining #our 2uer# changes.
24) How do you create para+eteri.e 5DE co++ands?
a. A parameteri!ed 2uer# is a 2uer# in %hich at least one of the fields of the
W>*R* clause is parameteri!ed, i.e., the value of the field is specified b# a
2uestion mar$ s#mbol / J 0. or example, the follo%ing -F. statement is based
on a 2uer# on the database in the sample light Reservation application,
i. *,-,'. (lights/0eparture, (lights/(light_)umber, (lights/0a_1f_2eek
(+13 (lights (lights 24,+, ((lights/0eparture56) 7)0
((lights/0a_1f_2eek56)
-*.*8T defines the columns to include in the 2uer#.
R4( specifies the path of the database.
W>*R* /optional0 specifies the conditions, or filters to use in the 2uer#.
&eparture is the parameter that represents the departure point of a flight.
&a#34f3Wee$ is the parameter that represents the da# of the %ee$ of a flight.
#. When creating a database chec$point, #ou insert a db3chec$ statement into #our
test script. When #ou parameteri!e the -F. statement in #our chec$point, the
d#8c*ec: function has a fourth, optional, argument, the para+eter8array
argument. A statement similar to the follo%ing is inserted into #our test script,
db_check(8list9/cdl8, 8db!f98, )1_-I3I., db!f9_params);
The para+eter8array argument %ill contain the values to substitute for the
parameters in the parameteri!ed chec$point.
21) Explain t*e (ollowing co++ands%
a. db3connect
i. to connect to a database
db_connect(<session_name>, <connection_string>);
#. db3execute32uer#
i. to execute a 2uer#
db_e"ecute_:uer ( session_name, *;-, record_number );
record_number is the out value.
c. db3get3field3value
i. returns the value of a single field in the specified ro%3index and column
in the session3name database session.
db_get_field_!alue ( session_name, row_inde", column );
d. db3get3headers
i. returns the number of column headers in a 2uer# and the content of the
column headers, concatenated and delimited b# tabs.
db_get_headers ( session_name, header_count, header_content );
e. db3get3ro%
i. returns the content of the ro%, concatenated and delimited b# tabs.
db_get_row ( session_name, row_inde", row_content );
(. db3%rite3records
i. %rites the record set into a text file delimited b# tabs.
db_write_records ( session_name, output_file % , headers % , record_limit & & );
g. db3get3last3error
i. returns the last error message of the last 4&78 or &ata Aunction operation
in the session3name database session.
db_get_last_error ( session_name, error );
*. db3disconnect
i. disconnects from the database and ends the database session.
db_disconnect ( session_name );
i. db3d"3convert
i. runs the d"s3file &ata Aunction export file. When #ou run this file, the &ata
Aunction *ngine converts data from one spo$e /source0 to another /target0.
The optional parameters enable #ou to override the settings in the &ata
Aunction export file.
db_d#_con!ert ( d#s_file % , output_file % , headers % , record_limit & & & );
22) W*at c*ec: points you will use to read and c*ec: text on t*e GU and explain its
syntax?
a. You can use text chec$points in #our test scripts to read and chec$ text in GUI
ob"ects and in areas of the screen. While creating a test #ou point to an ob"ect or a
%indo% containing text. WinRunner reads the text and %rites a T-. statement to
the test script. You ma# then add simple programming elements to #our test
scripts to verif# the contents of the text.
#. You can use a text chec$point to,
i. Read text from a GUI ob"ect or %indo% in #our application, using
o#j8get8text and win8get8text
ii. -earch for text in an ob"ect or %indo%, using win8(ind8text and
o#j8(ind8text
iii. (ove the mouse pointer to text in an ob"ect or %indo%, using
o#j8+o&e8locator8text and win8+o&e8locator8text
i&. 8lic$ on text in an ob"ect or %indo%, using o#j8clic:8on8text and
win8clic:8on8text
2)) Explain Get $ext c*ec:point (ro+ o#ject;window wit* syntax?
a. We use ob#_get_te"t (<logical_name>, <out_te"t>) function to get the text from
an ob"ect
#. We use win_get_te"t (window, out_te"t %, "9, 9, "<, <&) function to get the text
from a %indo%.
2-) Explain Get $ext c*ec:point (ro+ screen area wit* syntax?
a. We use win_get_te"t (window, out_te"t %, "9, 9, "<, <&) function to get the text
from a %indo%.
2/) Explain Get $ext c*ec:point (ro+ selection Fwe# only) wit* syntax?
a. Returns a text string from an ob"ect.
web_ob#_get_te"t (ob#ect, table_row, table_column, out_te"t %, te"t_before,
te"t_after, inde"&);
i. ob#ect The logical name of the ob"ect.
ii. table_row If the ob"ect is a table, it specifies the location of the ro%
%ithin a table. The string is preceded b# the K character.
iii. table_column If the ob"ect is a table, it specifies the location of the
column %ithin a table. The string is preceded b# the K character.
i&. out_te"t The output variable that stores the text string.
&. te"t_before &efines the start of the search area for a particular text
string.
&i. te"t_after &efines the end of the search area for a particular text
string.
&ii. inde" The occurrence number to locate. /The default parameter number
is numbered ;0.
20) Explain Get $ext c*ec:point we# text c*ec:point wit* syntax?
a. We use web_ob#_te"t_e"ists function for %eb text chec$points.
web_ob#_te"t_e"ists ( ob#ect, table_row, table_column, te"t_to_find %, te"t_before,
te"t_after& );
a. ob#ect The logical name of the ob"ect to search.
b. table_row If the ob"ect is a table, it specifies the location of the ro% %ithin a
table. The string is preceded b# the character K.
c. table_column If the ob"ect is a table, it specifies the location of the column %ithin
a table. The string is preceded b# the character K.
d. te"t_to_find The string that is searched for.
e. te"t_before &efines the start of the search area for a particular text string.
f. te"t_after &efines the end of the search area for a particular text string.
21) W*ic* $5E (unctions you will use (or
a. -earching text on the %indo%
i. find_te"t ( string, out_coord_arra, search_area %, string_def & );
string The string that is searched for. The string must be complete,
contain no spaces, and it must be preceded and follo%ed b# a space outside
the 2uotation mar$s. To specif# a literal, case1sensitive string, enclose the
string in 2uotation mar$s. Alternativel#, #ou can specif# the name of a string
variable. In this case, the string variable can include a regular expression.
out_coord_arra The name of the arra# that stores the screen
coordinates of the text /see explanation belo%0.
search_area The area to search, specified as coordinates x;,#;,x+,#+.
These define an# t%o diagonal corners of a rectangle. The interpreter
searches for the text in the area defined b# the rectangle.
string_def &efines the t#pe of search to perform. If no value is
specified, /L or A.-*, the default0, the search is for a single complete %ord
onl#. When ;, or TRU*, is specified, the search is not restricted to a single,
complete %ord.
#. getting the location of the text string
i. win_find_te"t ( window, string, result_arra %, search_area %,
string_def & & );
window The logical name of the %indo% to search.
string The text to locate. To specif# a literal, case sensitive string, enclose
the string in 2uotation mar$s. Alternativel#, #ou can specif# the name of a
string variable. The value of the string variable can include a regular
expression. The regular expression should not include an exclamation mar$
/M0, ho%ever, %hich is treated as a literal character. or more information
regarding Regular *xpressions, refer to the DUsing Regular *xpressionsD
chapter in #our UserEs Guide.
result_arra The name of the output variable that stores the location of
the string as a four1element arra#.
search_area The region of the ob"ect to search, relative to the %indo%.
This area is defined as a pair of coordinates, %ith x;,#;,x+,#+ specif#ing
an# t%o diagonall# opposite corners of the rectangular search region. If this
parameter is not defined, then the entire %indo% is considered the search
area.
string_def &efines ho% the text search is performed. If no string3def
is specified, /L or A.-*, the default parameter0, the interpreter searches for
a complete %ord onl#. If ;, or TRU*, is specified, the search is not restricted
to a single, complete %ord.
c. (oving the pointer to that text string
i. win_mo!e_locator_te"t (window, string % ,search_area % ,string_def & & );
window The logical name of the %indo%.
string The text to locate. To specif# a literal, case sensitive string, enclose
the string in 2uotation mar$s. Alternativel#, #ou can specif# the name of a
string variable. The value of the string variable can include a regular
expression /the regular expression need not begin %ith an exclamation
mar$0.
search_area The region of the ob"ect to search, relative to the %indo%.
This area is defined as a pair of coordinates, %ith x;, #;, x+, #+ specif#ing
an# t%o diagonall# opposite corners of the rectangular search region. If this
parameter is not defined, then the entire %indo% specified is considered the
search area.
string_def &efines ho% the text search is performed. If no string3def
is specified, /L or A.-*, the default parameter0, the interpreter searches for
a complete %ord onl#. If ;, or TRU*, is specified, the search is not restricted
to a single, complete %ord.
d. 8omparing the text
i. compare_te"t (str9, str< %, chars9, chars<&);
str9, str< The t%o strings to be compared.
chars9 4ne or more characters in the first string.
chars< 4ne or more characters in the second string. These characters are
substituted for those in chars;.
22) W*at are t*e steps o( creating a data dri&en test?
a. The steps involved in data driven testing are,
i. 8reating a test
ii. 8onverting to a data1driven test and preparing a database
iii. Running the test
i&. Anal#!ing the test results.
23) Record a data dri&en test script using data dri&er wi.ard?
a. You can use the &ata&river Wi!ard to convert #our entire script or a part of #our
script into a data1driven test. or example, #our test script ma# include recorded
operations, chec$points, and other statements that do not need to be repeated for
multiple sets of data. You need to parameteri!e onl# the portion of #our test script
that #ou %ant to run in a loop %ith multiple sets of data.
$o create a data7dri&en test%
i. If #ou %ant to turn onl# part of #our test script into a data1driven test, first
select those lines in the test script.
ii. 8hoose Tools < &ata&river Wi!ard.
iii. If #ou %ant to turn onl# part of the test into a data1driven test, clic$
8ancel. -elect those lines in the test script and reopen the &ata&river
Wi!ard. If #ou %ant to turn the entire test into a data1driven test, clic$
=ext.
i&. The Use a new or existing Excel ta#le box displa#s the name of the *xcel
file that WinRunner creates, %hich stores the data for the data1driven test.
Accept the default data table for this test, enter a different name for the
data table, or use
&. The bro%se button to locate the path of an existing data table. 7# default,
the data table is stored in the test folder.
&i. In the Assign a name to the variable box, enter a variable name %ith %hich
to refer to the data table, or accept the default name, 5table.6
&ii. At the beginning of a data1driven test, the *xcel data table #ou selected is
assigned as the value of the table variable. Throughout the script, onl# the
table variable name is used. This ma$es it eas# for #ou to assign a
different data table
&iii. To the script at a later time %ithout ma$ing changes throughout the script.
ix. 8hoose from among the follo%ing options,
;. Add statements to create a data1driven test, Automaticall# adds
statements to run #our test in a loop, sets a variable name b# %hich
to refer to the data tableC adds braces /NandO0, a for statement, and
a ddt8get8row8count statement to #our test script selection to run
it in a loop %hile it reads from the data tableC adds ddt8open and
ddt8close statements
+. To #our test script to open and close the data table, %hich are
necessar# in order to iterate ro%s in the table. =ote that #ou can
also add these statements to #our test script manuall#.
9. If #ou do not choose this option, #ou %ill receive a %arning that
#our data1driven test must contain a loop and statements to open
and close #our datatable.
B. Import data from a database, Imports data from a database. This
option adds ddt8update8(ro+8d#, and ddt8sa&e statements to
#our test script after the ddt3open statement.
P. =ote that in order to import data from a database, either (icrosoft
Fuer# or &ata Aunction must be installed on #our machine. You
can install (icrosoft Fuer# from the custom installation of
(icrosoft 4ffice. =ote that &ata Aunction is not automaticall#
included in #our WinRunner pac$age. To purchase &ata Aunction,
contact #our (ercur# Interactive representative. or detailed
information on %or$ing %ith &ata Aunction, refer to the
documentation in the &ata Aunction pac$age.
Q. =ara+eteri.e t*e test, Replaces fixed values in selected
chec$points and in recorded statements %ith parameters, using the
ddt8&al function, and in the data table, adds columns %ith variable
values for the parameters. .ine b# line, 4pens a %i!ard screen for
each line of the selected test script, %hich enables #ou to decide
%hether to parameteri!e a particular line, and if so, %hether to add
a ne% column to the data table or use an existing column %hen
parameteri!ing data.
R. 6uto+atically, Replaces all data %ith ddt3val statements and adds
ne% columns to the data table. The first argument of the function is
the name of the column in the data table. The replaced data is
inserted into the table.
x. The Test script line to parameteri!e box displa#s the line of the test script
to parameteri!e. The highlighted value can be replaced b# a parameter.
The Argument to be replaced box displa#s the argument /value0 that #ou
can replace %ith a parameter. You can use the arro%s to select a different
argument to replace.
8hoose %hether and ho% to replace the selected data,
;. &o not replace this data, &oes not parameteri!e this data.
+. An existing column, If parameters alread# exist in the data table
for this test, select an existing parameter from the list.
9. A ne% column, 8reates a ne% column for this parameter in the data
table for this test. Adds the selected data to this column of the data
table. The default name for the ne% parameter is the logical name
of the ob"ect in the selected. T-. statement above. Accept this
name or assign a ne% name.
xi. The final screen of the %i!ard opens.
;. If #ou %ant the data table to open after #ou close the %i!ard, select
-ho% data table no%.
+. To perform the tas$s specified in previous screens and close the
%i!ard, clic$ inish.
9. To close the %i!ard %ithout ma$ing an# changes to the test script,
clic$ 8ancel.
34) W*at are t*e t*ree +odes o( running t*e scripts?
a. WinRunner provides three modes in %hich to run testsS'erif#, &ebug, and
Update. You use each mode during a different phase of the testing process.
i. 'eri(y
;. Use the 'erif# mode to chec$ #our application.
ii. "e#ug
;. Use the &ebug mode to help #ou identif# bugs in a test script.
iii. Update
;. Use the Update mode to update the expected results of a test or to
create a ne% expected results folder.
T;0 *xplain the follo%ing T-. functions,
a. &dt3open
i. 8reates or opens a datatable file so that WinRunner can access it.
5yntax% ddt_open ( data_table_name, mode );
data_table_name The name of the data table. The name ma# be the table
variable name, the (icrosoft *xcel file or a tabbed text file name, or the full path
and file name of the table. The first ro% in the file contains the names of the
parameters. This ro% is labeled ro% L.
mode The mode for opening the data table, &&T3(4&*3R*A& /read1onl#0 or
&&T3(4&*3R*A&WRIT* /read or %rite0.
#. &dt3save
i. -aves the information into a data file.
5yntax% dt_sa!e (data_table_name);
and file name of the table.
c. &dt3close
i. 8loses a data table file
5yntax% ddt_close ( data_table_name );
data_table_name The name of the data table. The data table is a (icrosoft
*xcel file or a tabbed text file. The first ro% in the file contains the names of the
parameters.
d. &dt3export
i. *xports the information of one data table file into a different data table
file.
5yntax% ddt_e"port (data_table_namename9, data_table_namename<);
data_table_namename9 The source data table filename.
data_table_namename< The destination data table filename.
e. &dt3sho%
i. -ho%s or hides the table editor of a specified data table.
5yntax% ddt_show (data_table_name %, show_flag&);
and file name of the table.
show_flag The value indicating %hether the editor should be sho%n
/defaultU;0 or hidden /L0.
(. &dt3get3ro%3count
i. Retrieves the no. of ro%s in a data tables
5yntax% ddt_get_row_count (data_table_name, out_rows_count);
parameters.
out_rows_count The output variable that stores the total number of ro%s in
the data table.
g. ddt3next3ro%
i. 8hanges the active ro% in a database to the next ro%
5yntax% ddt_ne"t_row (data_table_name);
parameters.
*. ddt3set3ro%
i. -ets the active ro% in a data table.
5yntax% ddt_set_row (data_table_name, row);
row The ne% active ro% in the data table.
i. ddt3set3val
i. -ets a value in the current ro% of the data table
5yntax% ddt_set_!al (data_table_name, parameter, !alue);
parameter The name of the column into %hich the value %ill be inserted.
!alue The value to be %ritten into the table.
j. ddt3set3val3b#3ro%
i. -ets a value in a specified ro% of the data table.
5yntax% ddt_set_!al_b_row (data_table_name, row, parameter, !alue);
row The ro% number in the table. It can be an# existing ro% or the current ro%
number plus ;, %hich %ill add a ne% ro% to the data table.
parameter The name of the column into %hich the value %ill be inserted.
!alue The value to be %ritten into the table.
:. ddt3get3current3ro%
i. Retrieves the active ro% of a data table.
5yntax% ddt_get_current_row ( data_table_name, out_row );
out_row The output variable that stores the active ro% in the data table.
l. ddt3is3parameter
i. Returns %hether a parameter in a datatable is valid
5yntax% ddt_is_parameter (data_table_name, parameter);
parameters.
parameter The parameter name to chec$ in the data table.
+. ddt3get3parameters
i. Returns a list of all parameters in a data table.
5yntax% ddt_get_parameters ( table, params_list, params_num );
table The pathname of the data table.
params_list This out parameter returns the list of all parameters in the data
table, separated b# tabs.
params_num This out parameter returns the number of parameters in
params3list.
n. ddt3val
i. Returns the value of a parameter in the active roe in a data table.
5yntax% ddt_!al (data_table_name, parameter);
parameters.
parameter The name of the parameter in the data table.
o. ddt3val3b#3ro%
i. Returns the value of a parameter in the specified ro% in a data table.
5yntax% ddt_!al_b_row ( data_table_name, row_number, parameter );
row_number The number of the ro% in the data table.
parameter The name of the parameter in the data table.
p. ddt3report3ro%
i. Reports the active ro% in a data table to the test results
5yntax% ddt_report_row (data_table_name);
<. ddt3update3from3db
i. imports data from a database into a data table. It is inserted into #our test
script %hen #ou select the Import data from a database option in the
&ata&river Wi!ard. When #ou run #our test, this function updates the data
table %ith data from the database.
32) How do you *andle unexpected e&ents and errors?
a. WinRunner uses exception handling to detect an unexpected event %hen it occurs
and act to recover the test run.
&efine *xception >andling
&efine *xception
&efine >andler
unction
Activate *xception >andling
WinRunner enables #ou to handle the follo%ing t#pes of exceptions,
=op7up exceptions% Instruct WinRunner to detect and handle the appearance of a
specific %indo%.
$5E exceptions% Instruct WinRunner to detect and handle T-. functions that return a
specific error code.
>#ject exceptions% Instruct WinRunner to detect and handle a change in a propert#
for a specific GUI ob"ect.
We# exceptions% When the WebTest add1in is loaded, #ou can instruct WinRunner to
handle unexpected events and errors that occur in #our Web site during a test run.
3)) How do you *andle pop7up exceptions?
a. A pop1up exception >andler handles the pop1up messages that come up during the
execution of the script in the AUT. T4 handle this t#pe of exception %e ma$e
WinRunner learn the %indo% and also specif# a handler to the exception. It could
be
i. "e(ault actions, WinRunner clic$s the 4@ or 8ancel button in the pop1up
%indo%, or presses *nter on the $e#board. To select a default handler,
clic$ the appropriate button in the dialog box.
ii. User7de(ined *andler, If #ou prefer, specif# the name of #our o%n
handler. 8lic$ User &efined unction =ame and t#pe in a name in the
User &efined unction =ame box.
3-) How do you *andle $5E exceptions?
a. A T-. exception enables #ou to detect and respond to a specific error code
returned during test execution.
#. -uppose #ou are running a batch test on an unstable version of #our application. If
#our application crashes, #ou %ant WinRunner to recover test execution. A T-.
exception can instruct WinRunner to recover test execution b# exiting the current
test, restarting the application, and continuing %ith the next test in the batch.
c. The handler function is responsible for recovering test execution. When
WinRunner detects a specific error code, it calls the handler function. You
implement this function to respond to the unexpected error in the %a# that meets
#our specific testing needs.
d. 4nce #ou have defined the exception, WinRunner activates handling and adds the
exception to the list of default T-. exceptions in the *xceptions dialog box.
&efault T-. exceptions are defined b# the HR3*H8:3T-. configuration
parameter in the %run.ini configuration file.
3/) How do you *andle o#ject exceptions?
a. &uring testing, unexpected changes can occur to GUI ob"ects in the application
#ou are testing. These changes are often subtle but the# can disrupt the test run
and distort results.
#. You could use exception handling to detect a change in propert# of the GUI ob"ect
during the test run, and to recover test execution b# calling a handler function and
continue %ith the test execution
30) How do you co++ent your script?
a. We comment a script or line of script b# inserting a IK) at the beginning of the
line.
31) W*at is a co+pile +odule?
a. A compiled module is a script containing a librar# of user1defined functions that
#ou %ant to call fre2uentl# from other tests. When #ou load a compiled module,
its functions are automaticall# compiled and remain in memor#. You can call them
directl# from %ithin an# test.
#. 8ompiled modules can improve the organi!ation and performance of #our tests.
-ince #ou debug compiled modules before using them, #our tests %ill re2uire less
error1chec$ing. In addition, calling a function that is alread# compiled is
significantl# faster than interpreting a function in a test script.
32) W*at is t*e di((erence #etween script and co+pile +odule?
a. Test script contains the executable file in WinRunner %hile 8ompiled (odule is
used to store reusable functions. 8omplied modules are not executable.
#. WinRunner performs a pre1compilation automaticall# %hen it saves a module
assigned a propert# value of 58ompiled (odule6.
c. 7# default, modules containing T-. code have a propert# value of DmainD. (ain
modules are called for execution from %ithin other modules. (ain modules are
d#namicall# compiled into machine code onl# %hen WinRunner recogni!es a
DcallD statement. *xample of a call for the Dapp3initD script,
call cso3init/0C
call/ D8,VV(#AppolderVVD W Dapp3initD 0C
d. 8ompiled modules are loaded into memor# to be referenced from T-. code in
an# module. *xample of a load statement,
reload /58,VV(#AppolderVVD W Dflt3libD0C
or
load /D8,VV(#AppolderVVD W Dflt3libD0C
33) Write and explain &arious loop co++and?
a. A for loop instructs WinRunner to execute one or more statements a specified
number of times.
It has the follo%ing syntax%
for ( % e"pression9 &; % e"pression< &; % e"pression= & )
statement
i. irst, expression; is executed. =ext, expression+ is evaluated. If
expression+ is true, statement is executed and expression9 is executed.
The c#cle is repeated as long as expression+ remains true. If expression+
is false, the for statement terminates and execution passes to the first
statement immediatel# follo%ing.
ii. or example, the for loop belo% selects the file UI3T*-T from the ile
=ame list
iii. in the 4pen %indo%. It selects this file five times and then stops.
set3%indo% /D4penD0
for /iULC iXPC iYY0
list3select3item/Dile3=ame,3;D,DUI3T*-TD0C KItem =umber+
#. A %hile loop executes a bloc$ of statements for as long as a specified condition is
true.
It has the follo%ing s#ntax,
while ( e"pression )
statement ;
i. While expression is true, the statement is executed. The
loop ends %hen the expression is false. or example, the
%hile statement belo% performs the same function as the
for loop above.
set3%indo% /D4penD0C
iULC
%hile /iXP0N
iYYC
list3select3item /Dile =ame,3;D, DUI3T*-TD0C K Item =umber +
O
c. A do?%hile loop executes a bloc$ of statements for as long as a specified
condition is true. Unli$e the for loop and %hile loop, a do?%hile loop tests the
conditions at the end of the loop, not at the beginning.
A do?%hile loop has the follo%ing s#ntax,
do
statement
while (e"pression);
i. The statement is executed and then the expression is
evaluated. If the expression is true, then the c#cle is
repeated. If the expression is false, the c#cle is not
repeated.
ii. or example, the do?%hile statement belo% opens and
closes the 4rder dialog box of light Reservation five
times.
set3%indo% /Dlight ReservationD0C
iULC
do
N
menu3select3item /DileC4pen 4rder...D0C
set3%indo% /D4pen 4rderD0C
button3press /D8ancelD0C
iYYC
O
%hile /iXP0C
144) Write and explain decision +a:ing co++and?
a. You can incorporate decision1ma$ing into #our test scripts using if?else or s%itch
statements.
i. An if?else statement executes a statement if a condition is trueC other%ise,
it executes another statement.
if / expression 0
statement;C
Z else
statement+C [
expression is evaluated. If expression is true, statement; is executed. If
expression; is false, statement+ is executed.
#. A s%itch statement enables WinRunner to ma$e a decision based on an expression
that can have more than t%o values.
s%itch /expression 0
N
case case3;, statements
case case3+, statements
case case3n, statements
default, statement/s0
O
The s%itch statement consecutivel# evaluates each case expression until one is
found that e2uals the initial expression. If no case is e2ual to the expression, then the
default statements are executed. The default statements are optional.
141) Write and explain switc* co++and?
a. A s%itch statement enables WinRunner to ma$e a decision based on an expression
that can have more than t%o values.
s%itch /expression 0
N
case case3;, statements
case case3+, statements
case case3n, statements
default, statement/s0
O
#. The s%itch statement consecutivel# evaluates each case expression until one is
found that e2uals the initial expression. If no case is e2ual to the expression, then
the default statements are executed. The default statements are optional.
142) How do you write +essages to t*e report?
a. To %rite message to a report %e use the report3msg statement
5yntax, report_msg (message);
14)) W*at is a co++and to in&o:e application?
a. Invo$e3application is the function used to invo$e an application.
5yntax% in!oke_application(file, command_option, working_dir, *412);
14-) W*at is t*e purpose o( tl8step co++and?
a. Used to determine %hether sections of a test pass or fail.
5yntax% tl_step(step_name, status, description);
14/) W*ic* $5E (unction you will use to co+pare two (iles?
a. We can compare + files in WinRunner using the file3compare function.
5yntax, file_compare (file9, file< %, sa!e file&);
140) W*at is t*e use o( (unction generator?
a. The unction Generator provides a 2uic$, error1free %a# to program scripts. You
can,
i. Add 8ontext -ensitive functions that perform operations on a GUI ob"ect
or get information from the application being tested.
ii. Add -tandard and Analog functions that perform non18ontext -ensitive
tas$s such as s#nchroni!ing test execution or sending user1defined
messages to a report.
iii. Add 8ustomi!ation functions that enable #ou to modif# WinRunner to suit
#our testing environment.
141) W*at is t*e use o( putting call and call8close state+ents in t*e test script?
a. You can use t%o t#pes of call statements to invo$e one test from another,
i. A call statement invo$es a test from %ithin another test.
ii. A call3close statement invo$es a test from %ithin a script and closes the
test %hen the test is completed.
iii. The call statement has the follo%ing s#ntax,
;. call test3name / Z parameter;, parameter+, ...parametern [ 0C
i&. The call3close statement has the follo%ing s#ntax,
;. call3close test3name / Z parameter;, parameter+, ... parametern [ 0C
&. The test3name is the name of the test to invo$e. The parameters are the
parameters defined for the called test.
&i. The parameters are optional. >o%ever, %hen one test calls another, the
call statement should designate a value for each parameter defined for the
called test. If no parameters are defined for the called test, the call
statement must contain an empt# set of parentheses.
142) W*at is t*e use o( treturn and texit state+ents in t*e test script?
a. The treturn and texit statements are used to stop execution of called tests.
i. The treturn statement stops the current test and returns control to the
calling test.
ii. The texit statement stops test execution entirel#, unless tests are being
called from a batch test. In this case, control is returned to the main batch
test.
#. 7oth functions provide a return value for the called test. If treturn or texit is not
used, or if no value is specified, then the return value of the call statement is L.
treturn
c. The treturn statement terminates execution of the called test and returns control to
the calling test.
The s#ntax is,
treturn Z/ expression 0[C
d. The optional expression is the value returned to the call statement used to invo$e
the test.
texit
e. When tests are run interactivel#, the texit statement discontinues test execution.
>o%ever, %hen tests are called from a batch test, texit ends execution of the
current test onl#C control is then returned to the calling batch test.
The s#ntax is,
texit Z/ expression 0[C
143) W*ere do you set up t*e searc* pat* (or a called test.
a. The search path determines the directories that WinRunner %ill search for a called
test.
#. To set the search path, choose -ettings < General 4ptions. The General 4ptions
dialog box opens. 8lic$ the olders tab and choose a search path in the -earch
:ath for 8alled Tests box. WinRunner searches the directories in the order in
%hich the# are listed in the box. =ote that the search paths #ou define remain
active in future testing sessions.
114) How you create user7de(ined (unctions and explain t*e syntax?
a. A user1defined function has the follo%ing structure,
Zclass[ function name /Zmode[ parameter...0
N
declarationsC
statementsC
O
#. The class of a function can be either static or public. A static function is available
onl# to the test or module %ithin %hich the function %as defined.
c.
d. :arameters need not be explicitl# declared. The# can be of mode in, out, or inout.
or all non1arra# parameters, the default mode is in. or arra# parameters, the
default is inout. The significance of each of these parameter t#pes is as follo%s,
in, A parameter that is assigned a value from outside the function.
out, A parameter that is assigned a value from inside the function.
inout, A parameter that can be assigned a value from outside or inside the
function.
111) W*at does static and pu#lic class o( a (unction +eans?
a. The class of a function can be either static or public.
#. A static function is available onl# to the test or module %ithin %hich the function
%as defined.
c. 4nce #ou execute a public function, it is available to all tests, for as long as the
test containing the function remains open. This is convenient %hen #ou %ant the
function to be accessible from called tests. >o%ever, if #ou %ant to create a
function that %ill be available to man# tests, #ou should place it in a compiled
module. The functions in a compiled module are available for the duration of the
testing session.
d. If no class is explicitl# declared, the function is assigned the default class, public.
112) W*at does in@ out and input para+eters +eans?
a. in, A parameter that is assigned a value from outside the function.
#. out, A parameter that is assigned a value from inside the function.
c. inout, A parameter that can be assigned a value from outside or inside the
function.
11)) W*at is t*e purpose o( return state+ent?
a. This statement passes control bac$ to the calling function or test. It also returns
the value of the evaluated expression to the calling function or test. If no
expression is assigned to the return statement, an empt# string is returned.
5yntax% return %( e"pression )&;
11-) W*at does auto@ static@ pu#lic and extern &aria#les +eans?
a. auto, An auto variable can be declared onl# %ithin a function and is local to that
function. It exists onl# for as long as the function is running. A ne% cop# of the
variable is created each time the function is called.
#. static, A static variable is local to the function, test, or compiled module in %hich
it is declared. The variable retains its value until the test is terminated b# an Abort
command. This variable is initiali!ed each time the definition of the function is
executed.
c. pu#lic, A public variable can be declared onl# %ithin a test or module, and is
available for all functions, tests, and compiled modules.
d. extern, An extern declaration indicates a reference to a public variable declared
outside of the current test or module.
11/) How do you declare constants?
a. The const specifier indicates that the declared value cannot be modified. The class
of a constant ma# be either public or static. If no class is explicitl# declared, the
constant is assigned the default class public. 4nce a constant is defined, it remains
in existence until #ou exit WinRunner.
#. The s#ntax of this declaration is,
%class& const name %5 e"pression&;
110) How do you declare arrays?
a. The follo%ing s#ntax is used to define the class and the initial expression of an
arra#. Arra# si!e need not be defined in T-..
b. class arra_name % & %5init_e"pression&
c. The arra# class ma# be an# of the classes used for variable declarations /auto,
static, public, extern0.
111) How do you load and unload a co+pile +odule?
a. In order to access the functions in a compiled module #ou need to load the
module. You can load it from %ithin an# test script using the load commandC all
tests %ill then be able to access the function until #ou 2uit WinRunner or unload
the compiled module.
#. You can load a module either as a s#stem module or as a user module. A s#stem
module is generall# a closed module that is 5invisible6 to the tester. It is not
displa#ed %hen it is loaded, cannot be stepped into, and is not stopped b# a pause
command. A s#stem module is not unloaded %hen #ou execute an unload
statement %ith no parameters /global unload0.
load (module_name %,9>?& %,9>?& );
The module_name is the name of an existing compiled module.
T%o additional, optional parameters indicate the t#pe of module. The first
parameter indicates %hether the function module is a s#stem module or a user
module, ; indicates a s#stem moduleC L indicates a user module.
/&efault U L0
The second optional parameter indicates %hether a user module %ill remain open
in the WinRunner %indo% or %ill close automaticall# after it is loaded, ;
indicates that the module %ill close automaticall#C L indicates that the module %ill
remain open.
/&efault U L0
c. The unload function removes a loaded module or selected functions from
memor#.
d. It has the follo%ing s#ntax,
unload ( % module_name > test_name % , 8function_name8 & & );
112) W*y you use reload (unction?
a. If #ou ma$e changes in a module, #ou should reload it. The reload function
removes a loaded module from memor# and reloads it /combining the functions
of unload and load0.
The s#ntax of the reload function is,
reload ( module_name % ,9>? & % ,9>? & );
The module3name is the name of an existing compiled module.
T%o additional optional parameters indicate the t#pe of module. The first
parameter indicates %hether the module is a s#stem module or a user module, ;
indicates a s#stem moduleC L indicates a user module.
/&efault U L0
The second optional parameter indicates %hether a user module %ill remain open
in the WinRunner %indo% or %ill close automaticall# after it is loaded. ; indicates
that the module %ill close automaticall#. L indicates that the module %ill remain
open.
/&efault U L0
113) Write and explain co+pile +odule?
a.
;+L0 >o% do #ou call a function from external libraries /dll0.
;+;0 What is the purpose of load3dllJ
;++0 >o% do #ou load and unload external librariesJ
;+90 >o% do #ou declare external functions in T-.J
;+B0 >o% do #ou call %indo%s A:Is, explain %ith an exampleJ
;+P0 Write T-. functions for the follo%ing interactive modes,
i. 8reating a dialog box %ith an# message #ou specif#, and an edit field.
ii. 8reate dialog box %ith list of items and message.
iii. 8reate dialog box %ith edit field, chec$ box, and execute button, and a
cancel button.
i&. 8reating a bro%se dialog box from %hich user selects a file.
&. 8reate a dialog box %ith t%o edit fields, one for login and another for
pass%ord input.
;+Q0 What is the purpose of step, step into, step out, step to cursor commands for debugging
#our scriptJ
;+R0 >o% do #ou update #our expected resultsJ
;+\0 >o% do #ou run #our script %ith multiple sets of expected resultsJ
;+T0 >o% do #ou vie% and evaluate test results for various chec$ pointsJ
;9L0 >o% do #ou vie% the results of file comparisonJ
;9;0 What is the purpose of Wdiff utilit#J
;9+0 What are batch tests and ho% do #ou create and run batch tests J
;990 >o% do #ou store and vie% batch test resultsJ
;9B0 >o% do #ou execute #our tests from %indo%s run commandJ
;9P0 *xplain different command line optionsJ
;9Q0 What T-. function #ou %ill use to pause #our scriptJ
;9R0 What is the purpose of setting a brea$ pointJ
;9\0 What is a %atch listJ
;9T0 &uring debugging ho% do #ou monitor the value of the variablesJ
If this is just phone screening, I would ask the following:
1. Where did you learn WinRunner and TestDirector?
If they say it was in a ercury class, ask if they can show you their
certi!cate of copletion. If they say no, let the know you will "erify it
with #ercury.
$. %a"e you e"er created a start&up script? If they answer 'yes', ask the
what was in it and how they got WR to e(ecute the start&up script when WR is
in"oked.
They should answer soething like this, 'In the start&up script, we loaded all
the gui aps for the application, any li)rary !les we needed, and any custo
gui o)ject apping we ha"e to do. We also loaded glo)al "aria)les and syste
"aria)les here. The startup script location is added to the WR .ini !le,
wrun.ini located under the windows or winnt directory as wrun.ini'
*. What is the di+erence )etween writing a function and writing a script?
They should ention soe of these things:
1. , function goes into a 'copiled odule', a script does not.
$. , function follows strict 'c' synta(. -or instance, you ha"e to declare
all "aria)les created and used in the function. In a script you do not.
.. What is the di+erence )etween 'set/window' and 'win/acti"ate'. When would
you use 'set/window' and when would you use 'win/acti"ate'?
win/acti"ate has the forat win/acti"ate0window12. The win/acti"ate function
akes the speci!ed window the acti"e window )y )ringing it into focus and
raising it to the top of the display. 0It is the e3ui"alent to clicking on the
window )anner1
4et/window has the following forat: set/window0window,5tie612
The set/window function directs input to the corret application window. This
directs the 78I ap to this window. It also sets the scope for o)ject
identi!cation in the 78I ap.
The ost iportant di+erence is that set/window has a tiing option.
WinRunner will wait a a(iu of the nu)er used in the function, 9:84 the
syste set tieout, to wait for the window to appear. Win/acti"ate assues the
window is already on the desktop and has no tiing option.

Win Runner Questions 123

Uploaded by

Document Information

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 Runner Questions 123

Uploaded by

Copyright:

Available Formats

1) How you used WinRunner in your project?

You might also like