[Spoorthi]

39) How do you filter the objects in the GUI map?[/b]


a. GUI Map Editor has a Filter option. This
provides for filtering with 3 different types of options.


i. Logical name displays only objects with the
specified logical name.


ii.
Physical description displays only objects matching the specified physical
description. Use any substring belonging to the physical description.


iii.
Class displays only objects of the specified class, such as all the push
buttons.





40) How do you configure GUI map?[/b]


a. When WinRunner learns the description of a
GUI object, it does not learn all its properties. Instead, it learns the
minimum number of properties to provide a unique identification of the object.


b. Many applications also contain custom GUI
objects. A custom object is any object
not belonging to one of the standard classes used by WinRunner. These objects
are therefore assigned to the generic “object” class. When WinRunner records an
operation on a custom object, it generates obj_mouse_[/b]
statements in the test script.


c. If a custom object is similar to a standard
object, you can map it to one of the standard classes. You can also configure
the properties WinRunner uses to identify a custom object during Context
Sensitive testing. The mapping and the configuration you set are valid only for
the current WinRunner session. To make the mapping and the configuration
permanent, you must add configuration statements to your startup test script.




continues tomarow

[Spoorthi]

41) What is the purpose of GUI map configuration?[/b]


a. GUI Map configuration is used to map a
custom object to a standard object.





42) How do you make the configuration and mappings permanent?[/b]


a. The mapping and the configuration you set are
valid only for the current WinRunner session. To make the mapping and the
configuration permanent, you must add configuration statements to your startup
test script.

[Spoorthi]

43) What is the purpose of GUI spy?[/b]


a. Using the GUI Spy, you can view the
properties of any GUI object on your desktop. You use the Spy pointer to point
to an object, and the GUI Spy displays the properties and their values in the
GUI Spy dialog box. You can choose to view all the properties of an object, or
only the selected set of properties that WinRunner learns.





44) What is the purpose of obligatory and optional properties of the
objects?[/b]


a. For each class, WinRunner learns a set of
default properties. Each default property is classified “obligatory[/b]” or “optional[/b]”.



i. An obligatory[/b]
property is always learned (if it exists).


ii.
An optional[/b] property is used only if
the obligatory properties do not provide unique identification of an object.
These optional properties are stored in a list. WinRunner selects the minimum
number of properties from this list that are necessary to identify the object.
It begins with the first property in the list, and continues, if necessary, to
add properties to the description until it obtains unique identification for
the object.


[/b]

[Spoorthi]

45) When the optional properties are learned?[/b]


a. An optional property is used only if the
obligatory properties do not provide unique identification of an object.





46) What is the purpose of location indicator and index indicator in GUI
map configuration?[/b]


a. In cases where the obligatory and optional
properties do not uniquely identify an object, WinRunner uses a selector to
differentiate between them. Two types of selectors are available:


i. A Location
Selector [/b]uses the spatial position of objects.


1. The location selector uses the spatial order of
objects within the window, from the top left to the bottom right corners, to
differentiate among objects with the same description.


ii.
An Index Selector[/b] uses a unique
number to identify the object in a window.


1. The index selector uses numbers assigned at the
time of creation of objects to identify the object in a window. Use this
selector if the location of objects with the same description may change within
a window.


[/b]

[Spoorthi]

47) How do you handle custom objects?[/b]


a. A custom object is any GUI object not
belonging to one of the standard classes used by WinRunner. WinRunner learns
such objects under the generic “object” class. WinRunner records operations on
custom objects using obj_mouse_[/b]
statements.


b. If a
custom object is similar to a standard object, you can map it to one of the
standard classes. You can also configure the properties WinRunner uses to
identify a custom object during Context Sensitive testing.





48) What is the name of custom class in WinRunner and what methods it
applies on the custom objects?[/b]


a. WinRunner learns custom class objects
under the generic “object” class. WinRunner records operations on custom
objects using obj_[/b] statements.

[Spoorthi]

49) In a situation when obligatory and optional both the properties
cannot uniquely identify an object what method WinRunner applies?[/b]


a. In cases where the obligatory and optional
properties do not uniquely identify an object, WinRunner uses a selector to
differentiate between them. Two types of selectors are available:


i. A location
selector [/b]uses the spatial position of objects.


ii.
An index selector[/b] uses a unique
number to identify the object in a window.

[Spoorthi]

50) What is the purpose of different record methods 1) Record 2) Pass up
3) As Object 4) Ignore.[/b]


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


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


c. As Object [/b]instructs WinRunner to record all operations performed on a GUI object
as though its class were “object” class. [/b]


d. Ignore[/b] instructs WinRunner to disregard all operations performed on the
class.[/b]

[Spoorthi]

51) How do you find out which is the start up file in WinRunner?[/b]


a. The test script name in the Startup Test box
in the Environment tab in the General Options dialog box is the start up file
in WinRunner.

[Spoorthi]

52) What are the virtual objects and how do you learn them?[/b]


a. Applications may contain bitmaps that look
and behave like GUI objects. WinRunner records operations on these bitmaps
using win_mouse_click statements. By defining a bitmap as a virtual object, you
can instruct WinRunner to treat it like a GUI object such as a push button,
when you record and run tests.


b. Using the Virtual Object wizard, you can
assign a bitmap to a standard object class, define the coordinates of that
object, and assign it a logical name.


To define a virtual object using the Virtual Object wizard:[/b]


i. Choose Tools > Virtual Object Wizard. The
Virtual Object wizard opens. Click Next.


ii. In the Class list, select a class for the new
virtual object. If rows that are displayed in the window. For a table class,
select the number of visible rows and columns. Click Next.


iii. Click Mark Object. Use the crosshairs pointer
to select the area of the virtual object. You can use the arrow keys to make
precise adjustments to the area you define with the crosshairs. Press Enter or
click the right mouse button to display the virtual object’s coordinates in the
wizard. If the object marked is visible on the screen, you can click the
Highlight button to view it. Click Next.


iv. Assign a logical name to the virtual object.
This is the name that appears in the test script when you record on the virtual
object. If the object contains text that WinRunner can read, the wizard
suggests using this text for the logical name. Otherwise, WinRunner suggests virtual_object[/b], virtual_push_button[/b], virtual_list[/b],
etc.


v. You can accept the wizard’s suggestion or type
in a different name. WinRunner checks that there are no other objects in the
GUI map with the same name before confirming your choice. Click Next.

[Spoorthi]

53) How you created you test scripts 1) by recording or 2) programming?[/b]


a. Programming. I have done complete
programming only, absolutely no recording.





54) What are the two modes of recording?[/b]


a. There are 2 modes of recording in
WinRunner


i. Context
Sensitive recording [/b]records the operations you perform on your application
by identifying Graphical User Interface (GUI) objects.


ii.
Analog recording[/b] records keyboard
input, mouse clicks, and the precise x- and y-coordinates traveled by the mouse
pointer across the screen.

[Spoorthi]

55) What is a checkpoint and what are different types of checkpoints?[/b]


a. Checkpoints allow you to compare the
current behavior of the application being tested to its behavior in an earlier
version. You can add four types of checkpoints to your test scripts:










i. GUI
checkpoints [/b]verify information about GUI objects. For example, you can
check that a button is enabled or see which item is selected in a list.


ii.
Bitmap checkpoints[/b] take a “snapshot”
of a window or area of your application and compare this to an image captured
in an earlier version.


iii.
Text checkpoints[/b] read text in GUI
objects and in bitmaps and enable you to verify their contents.


iv.
Database checkpoints[/b] check the
contents and the number of rows and columns of a result set, which is based on
a query you create on your database.

[Spoorthi]

56) What are data driven tests?[/b]


a. When you test your application, you may
want to check how it performs the same operations with multiple sets of data.
You can create a data-driven test with a loop that runs ten times: each time
the loop runs, it is driven by a different set of data. In order for WinRunner
to use data to drive the test, you must link the data to the test script which
it drives. This is called parameterizing your test. The data is stored in a
data table. You can perform these operations manually, or you can use the
DataDriver Wizard to parameterize your test and store the data in a data table.





57) What are the synchronization points?[/b]


a. Synchronization points enable you to solve
anticipated timing problems between the test and your application. For example,
if you create a test that opens a database application, you can add a
synchronization point that causes the test to wait until the database records
are loaded on the screen.


b. For Analog testing, you can also use a
synchronization point to ensure that WinRunner repositions a window at a
specific location. When you run a test, the mouse cursor travels along exact
coordinates. Repositioning the window enables the mouse pointer to make contact
with the correct elements in the window.

[Spoorthi]

58) What is parameterizing?[/b]


a. In order for WinRunner to use data to drive
the test, you must link the data to the test script which it drives. This is
called parameterizing your test. The data is stored in a data table.


[/b]


59) How do you maintain the document information of the test scripts?[/b]


a. Before
creating a test, you can document information about the test in the General and
Description tabs of the Test Properties dialog box. You can enter the name of
the test author, the type of functionality tested, a detailed description of
the test, and a reference to the relevant functional specifications document.

[Spoorthi]

60) What do you verify with the GUI checkpoint for single property and
what command it generates, explain syntax?[/b]


a. You can check a single property of a GUI
object. For example, you can check whether a button is enabled or disabled or
whether an item in a list is selected. To create a GUI checkpoint for a
property value, use the Check Property dialog box to add one of the following
functions to the test script:


i. button_check_info


ii. scroll_check_info


iii. edit_check_info


iv. static_check_info


v. list_check_info


vi. win_check_info


vii. obj_check_info





Syntax: [/b]button_check_info
(button, property, property_value );[/i]


edit_check_info ( edit, property, property_value );[/i]






continues tomarow

[/i]

[Spoorthi]

61) What do you verify with the GUI checkpoint for object/window and
what command it generates, explain syntax?[/b]


a. You can create a GUI checkpoint to check a
single object in the application being tested. You can either check the object
with its default properties or you can specify which properties to check.


b. [/b]
Creating a GUI Checkpoint using the
Default Checks[/b]


i. You can create a GUI checkpoint that performs a
default check on the property recommended by WinRunner. For example, if you
create a GUI checkpoint that checks a push button, the default check verifies
that the push button is enabled.


ii. To create a GUI checkpoint using default checks:


1. Choose Create > GUI Checkpoint > For
Object/Window, or click the GUI Checkpoint for Object/Window button on the User
toolbar. If you are recording in Analog mode, press the CHECK GUI FOR
OBJECT/WINDOW softkey in order to avoid extraneous mouse movements. Note that
you can press the CHECK GUI FOR OBJECT/WINDOW softkey in Context Sensitive mode
as well. The WinRunner window is minimized, the mouse pointer becomes a
pointing hand, and a help window opens on the screen.


2. Click an object.


3. WinRunner captures the current value of the
property of the GUI object being checked and stores it in the test’s expected
results folder. The WinRunner window is restored and a GUI checkpoint is
inserted in the test script as an obj_check_gui statement





Syntax[/b]:
win_check_gui ( window, checklist,
expected_results_file, time );[/i]






c. Creating
a GUI Checkpoint by Specifying which Properties to Check[/b]


d. You
can specify which properties to check for an object. For example, if you create
a checkpoint that checks a push button, you can choose to verify that it is in
focus, instead of enabled.





e. To
create a GUI checkpoint by specifying which properties to check:[/b]





i. Choose Create > GUI Checkpoint > For
Object/Window, or click the GUI Checkpoint for Object/Window button on the User
toolbar. If you are recording in Analog mode, press the CHECK GUI FOR
OBJECT/WINDOW softkey in order to avoid extraneous mouse movements. Note that
you can press the CHECK GUI FOR OBJECT/WINDOW softkey in Context Sensitive mode
as well. The WinRunner window is minimized, the mouse pointer becomes a
pointing hand, and a help window opens on the screen.


ii. Double-click the object or window. The Check
GUI dialog box opens.


iii. Click an object name in the Objects pane. The
Properties pane lists all the properties for the selected object.


iv. Select the properties you want to check.


1. To edit the expected value of a property,
first select it. Next, either click the Edit Expected Value button, or
double-click the value in the Expected Value column to edit it.


2. To add a check in which you specify arguments,
first select the property for which you want to specify arguments. Next, either
click the Specify Arguments button, or double-click in the Arguments column.
Note that if an ellipsis (three dots) appears in the Arguments column, then you
must specify arguments for a check on this property. (You do not need to
specify arguments if a default argument is specified.) When checking standard
objects, you only specify arguments for certain properties of edit and static
text objects. You also specify arguments for checks on certain properties of
nonstandard objects.


3. To change the viewing options for the
properties of an object, use the Show Properties buttons.


4. Click OK to close the Check GUI dialog box.
WinRunner captures the GUI information and stores it in the test’s expected
results folder. The WinRunner window is restored and a GUI checkpoint is
inserted in the test script as an obj_check_gui or a win_check_gui statement.


[/b]


Syntax[/b]:
win_check_gui ( window, checklist,
expected_results_file, time );[/i]


[/b]obj_check_gui ( object,
checklist, expected results file, time );[/i]