[Spoorthi]

80) How do you create parameterize SQL commands?[/b]


a. A parameterized query is a query in which at
least one of the fields of the WHERE clause is parameterized, i.e., the value
of the field is specified by a question mark symbol ( ? ). For example, the
following SQL statement is based on a query on the database in the sample
Flight Reservation application:





i. SELECT Flights.Departure, Flights.Flight_Number, Flights.Day_Of_Week
FROM Flights Flights WHERE (Flights.Departure=?) AND (Flights.Day_Of_Week=?) [/i]


[/i]



SELECT defines the columns to include in
the query.



FROM specifies the path of the database.


WHERE (optional) specifies the conditions, or filters to use in
the query.


Departure is the parameter that represents the departure point of
a flight.


Day_Of_Week is the parameter that represents
the day of the week of a flight.





b. When creating a database checkpoint, you
insert a db_check statement into your test script. When you parameterize the
SQL statement in your checkpoint, the db_check[/b]
function has a fourth, optional, argument: the parameter_array[/b] argument. A statement similar to the following is
inserted into your test script:





db_check("list1.cdl", "dbvf1",
NO_LIMIT, dbvf1_params);[/i]





The parameter_array[/b] argument will contain
the values to substitute for the parameters in the parameterized checkpoint.

[Spoorthi]

81) Explain the following commands:[/b]


a. db_connect


i. to connect to a database


db_connect(<session_name>, <connection_string>);[/i]





b. db_execute_query


i. to execute a query


db_execute_query ( session_name, SQL, record_number );[/i]


[/i]


record_number [/i]is the out value.





c. db_get_field_value


i. returns the value of a single field in the
specified row_index and column in the session_name database session.





db_get_field_value ( session_name, row_index, column );[/i]





d. db_get_headers


i. returns the number of column headers in a query
and the content of the column headers, concatenated and delimited by tabs.





db_get_headers ( session_name, header_count, header_content );[/i]





e. db_get_row


i. returns the content of the row, concatenated
and delimited by tabs.





db_get_row ( session_name, row_index, row_content );[/i]


[/i]


f. db_write_records


i. writes the record set into a text file
delimited by tabs.





db_write_records
( session_name, output_file [ , headers [ , record_limit ] ] );[/i]


[/i]


g. db_get_last_error


i. returns the last error message of the last ODBC
or Data Junction operation in the session_name database session.





db_get_last_error ( session_name, error );[/i]


[/i]


h. db_disconnect


i. disconnects from the database and ends the
database session.


db_disconnect ( session_name );[/i]


i. db_dj_convert


i. runs the djs_file Data Junction export file.
When you run this file, the Data Junction Engine converts data from one spoke
(source) to another (target). The optional parameters enable you to override
the settings in the Data Junction export file.





db_dj_convert ( djs_file [ , output_file [ , headers
[ , record_limit ] ] ] );[/i]


[/i]

[Spoorthi]

82) What check points you will use to read and check text on the GUI and
explain its syntax?[/b]


a. You can use text checkpoints in your test
scripts to read and check text in GUI objects and in areas of the screen. While
creating a test you point to an object or a window containing text. WinRunner
reads the text and writes a TSL statement to the test script. You may then add
simple programming elements to your test scripts to verify the contents of the
text.





b. You
can use a text checkpoint to:


i. Read text from a GUI object or window in your
application, using obj_get_text[/b] and win_get_text[/b]


ii. Search for text in an object or window, using win_find_text[/b] and obj_find_text[/b]


iii. Move the mouse pointer to text in an object or
window, using obj_move_locator_text[/b]
and win_move_locator_text[/b]


iv. Click on text in an object or window, using obj_click_on_text[/b] and win_click_on_text[/b]


[/b]

[Spoorthi]

83) Explain Get Text checkpoint from object/window with syntax?[/b]


a. We use obj_get_text
(<logical_name>, <out_text>)[/i] function to get the text from an
object


b. [/i]We
use win_get_text (window, out_text [, x1,
y1, x2, y2]) [/i]function to get the text from a window.[/i]





84) Explain Get Text checkpoint from screen area with syntax?[/b]


a. [/i]We
use win_get_text (window, out_text [, x1,
y1, x2, y2]) [/i]function to get the text from a window.[/i]

[Spoorthi]

85) Explain Get Text checkpoint from selection (web only) with syntax?[/b]


a. Returns a text string from an object.


[/i]


web_obj_get_text (object, table_row, table_column,
out_text [, text_before, text_after, index]);[/i]





i. object[/i] The
logical name of the object.


ii.
table_row[/i] If the object is a table, it
specifies the location of the row within a table. The string is preceded by the
# character.


iii.
table_column[/i] If the object is a table, it specifies the location of the column
within a table. The string is preceded by the # character.


iv.
out_text[/i] The output variable that
stores the text string.


v.
text_before [/i]Defines the start of the search area for a particular text
string.


vi.
text_after [/i] Defines the end of the
search area for a particular text
string.


vii.
index [/i]The
occurrence number to locate. (The default parameter number is numbered 1).

[Spoorthi]

86) Explain Get Text checkpoint web text checkpoint with syntax?[/b]


a. We use web_obj_text_exists
[/i]function for web text checkpoints.





web_obj_text_exists ( object, table_row, table_column, text_to_find [,
text_before, text_after] );[/i]


[/i]


i. object[/i] The logical name of the object to search.


ii. table_row[/i] If the object is a table, it specifies the
location of the row within a table. The
string is preceded by the character #.


iii. table_column[/i] If the object is a table, it specifies the
location of the column within a table. The string is preceded by the character #.


iv. text_to_find[/i] The string that is searched for.


v. text_before[/i]
Defines the start of the search area
for a particular text string.


vi. text_after[/i] Defines the end of the search area
for a particular text string.

[Spoorthi]

87) Which TSL functions you will use for [/b]


a. Searching text on the window


i. find_text ( string, out_coord_array, search_area [, string_def ] );[/i]


[/i]


string [/i]The string that is searched
for. The string must be complete, contain no spaces, and it must be preceded
and followed by a space outside the quotation marks. To specify a literal,
case-sensitive string, enclose the string in quotation marks. Alternatively,
you can specify the name of a string variable. In this case, the string
variable can include a regular expression.





out_coord_array [/i]The name of the array that
stores the screen coordinates of the text (see explanation below).





search_area [/i]The area to search,
specified as coordinates x1,y1,x2,y2. These define any two diagonal corners of
a rectangle. The interpreter searches for the text in the area defined by the
rectangle.





string_def [/i]Defines the type of search
to perform. If no value is specified, (0 or FALSE, the default), the search is
for a single complete word only. When 1, or TRUE, is specified, the search is
not restricted to a single, complete word.





b. getting the location of the text string


i. win_find_text ( window, string, result_array [, search_area [,
string_def ] ] );[/i]





window[/i] The
logical name of the window to search.





string[/i] The text to locate. To specify a literal, case
sensitive string, enclose the string in quotation marks. Alternatively, you can
specify 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 mark (!), however, which is treated as a literal character. For
more information regarding Regular Expressions, refer to the "Using
Regular Expressions" chapter in your User's Guide.





result_array[/i] The name of the output variable
that stores the location of the string as a four-element array.





search_area[/i] The region of the object to
search, relative to the window. This area is defined as a pair of coordinates,
with x1,y1,x2,y2 specifying any two diagonally opposite corners of the
rectangular search region. If this parameter is not defined, then the entire
window is considered the search area.





string_def[/i] Defines how the text search is
performed. If no string_def is specified, (0 or FALSE, the default parameter),
the interpreter searches for a complete word only. If 1, or TRUE, is specified,
the search is not restricted to a single, complete word.





c. Moving the pointer to that text string


i. win_move_locator_text (window, string [ ,search_area [ ,string_def ] ] ); [/i]


[/i]


window[/i] The logical name of the window.





string[/i] The text to locate. To specify a literal, case
sensitive string, enclose the string in quotation marks. Alternatively, you can
specify the name of a string variable. The value of the string variable can
include a regular expression (the regular expression need not begin with an
exclamation mark).





search_area[/i] The region of the object to
search, relative to the window. This area is defined as a pair of coordinates,
with x1, y1, x2, y2 specifying any two diagonally opposite corners of the
rectangular search region. If this parameter is not defined, then the entire
window specified is considered the search area.


string_def[/i] Defines how the text search is
performed. If no string_def is specified, (0 or FALSE, the default parameter),
the interpreter searches for a complete word only. If 1, or TRUE, is specified,
the search is not restricted to a single, complete word.





d. Comparing the text


i. compare_text (str1, str2 [, chars1, chars2]);[/i]





str1, str2[/i] The two strings to be
compared.





chars1[/i] One or more characters in the first
string.





chars2[/i] One or more characters in the second
string. These characters are substituted for those in chars1.

[Spoorthi]

88) What are the steps of creating a data driven test?[/b]


a. The steps involved in data driven testing
are:


i. Creating
a test


ii. Converting to a data-driven test and preparing
a database


iii. Running the test


iv. Analyzing the test results.

[Spoorthi]

89) Record a data driven test script using data driver wizard?[/b]


a. You can use the DataDriver Wizard to
convert your entire script or a part of your script into a data-driven test.
For example, your test script may include recorded operations, checkpoints, and
other statements that do not need to be repeated for multiple sets of data. You
need to parameterize only the portion of your test script that you want to run
in a loop with multiple sets of data.





To create a data-driven test:[/b]


i. If you
want to turn only part of your test script into a data-driven test, first
select those lines in the test script.


ii. Choose Tools > DataDriver Wizard.


iii. If you want to turn only part of the test into
a data-driven test, click Cancel. Select those lines in the test script and
reopen the DataDriver Wizard. If you want to turn the entire test into a
data-driven test, click Next.


iv. The Use
a new or existing Excel table[/b] box displays the name of the Excel file that
WinRunner creates, which stores the data for the data-driven test. Accept the
default data table for this test, enter a different name for the data table, or
use


v. The browse button to locate the path of an
existing data table. By default, the data table is stored in the test folder.


vi. In the Assign a name to the variable box, enter
a variable name with which to refer to the data table, or accept the default
name, “table.”


vii. At the beginning of a data-driven test, the
Excel data table you selected is assigned as the value of the table variable.
Throughout the script, only the table variable name is used. This makes it easy
for you to assign a different data table


viii. To the script at a later time without making
changes throughout the script.


ix. Choose from among the following options:


1. Add statements to create a data-driven test:
Automatically adds statements to run your test in a loop: sets a variable name
by which to refer to the data table; adds braces ({and}), a for statement, and
a ddt_get_row_count[/b] statement to
your test script selection to run it in a loop while it reads from the data
table; adds ddt_open[/b] and ddt_close [/b]statements


2. To your test script to open and close the data
table, which are necessary in order to iterate rows in the table. Note that you
can also add these statements to your test script manually.


3. If you do not choose this option, you will
receive a warning that your data-driven test must contain a loop and statements
to open and close your datatable.


4. Import data from a database: Imports data from
a database. This option adds ddt_update_from_db[/b],
and ddt_save[/b] statements to your test
script after the ddt_open statement.


5. Note that in order to import data from a
database, either Microsoft Query or Data Junction must be installed on your
machine. You can install Microsoft Query from the custom installation of
Microsoft Office. Note that Data Junction is not automatically included in your
WinRunner package. To purchase Data Junction, contact your Mercury Interactive
representative. For detailed information on working with Data Junction, refer
to the documentation in the Data Junction package.


6. Parameterize
the test[/b]: Replaces fixed values in selected checkpoints and in recorded
statements with parameters, using the ddt_val[/b]
function, and in the data table, adds columns with variable values for the
parameters. Line by line: Opens a wizard screen for each line of the selected
test script, which enables you to decide whether to parameterize a particular
line, and if so, whether to add a new column to the data table or use an
existing column when parameterizing data.


7. Automatically[/b]:
Replaces all data with ddt_val statements and adds new 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 parameterize box
displays the line of the test script to parameterize. The highlighted value can
be replaced by a parameter. The Argument to be replaced box displays the
argument (value) that you can replace with a parameter. You can use the arrows
to select a different argument to replace.





Choose whether and how to
replace the selected data:


1. Do not replace this data: Does not parameterize
this data.


2. An existing column: If parameters already exist
in the data table for this test, select an existing parameter from the list.


3. A new column: Creates a new 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 new parameter is the logical
name of the object in the selected. TSL statement above. Accept this name or
assign a new name.





xi. The final screen of the wizard opens.


1. If you want the data table to open after you
close the wizard, select Show data table now.


2. To perform the tasks specified in previous
screens and close the wizard, click Finish.


3. To close the wizard without making any changes
to the test script, click Cancel.

[Spoorthi]

90) What are the three modes of running the scripts?[/b]


a. WinRunner provides three modes in which to
run tests-Verify, Debug, and Update. You use each mode during a different phase
of the testing process.


i. Verify[/b]


1. Use the Verify mode to check your application.


ii. Debug[/b]


1. Use the Debug mode to help you identify bugs in
a test script.


iii. Update[/b]


1. Use the Update mode to update the expected
results of a test or to create a new expected results folder.

[Spoorthi]

91) Explain the following TSL functions:[/b]


a. Ddt_open


i. Creates or opens a datatable file so that
WinRunner can access it.


Syntax: [/b]ddt_open ( data_table_name,
mode );[/i]





data_table_name[/i] The name of the data table.
The name may be the table variable name, the Microsoft Excel file or a tabbed
text file name, or the full path and file name of the table. The first row in
the file contains the names of the parameters. This row is labeled row 0.





mode[/i] The mode for opening the data table:
DDT_MODE_READ (read-only) or DDT_MODE_READWRITE (read or write).





b. Ddt_save


i. Saves the information into a data file.


Syntax: [/b]dt_save (data_table_name);[/i]





data_table_name[/i] The name of the data table.
The name may be the table variable name, the Microsoft Excel file or a tabbed
text file name, or the full path and file name of the table.





c. Ddt_close


i. Closes a data table file


Syntax: [/b]ddt_close ( data_table_name
);[/i]





data_table_name[/i] The name of the data table.
The data table is a Microsoft Excel file or a tabbed text file. The first row
in the file contains the names of the parameters.





d. Ddt_export


i. Exports the information of one data table file
into a different data table file.


Syntax:[/b] ddt_export
(data_table_namename1, data_table_namename2);[/i]





data_table_namename1[/i] The source
data table filename.


data_table_namename2 [/i]The destination data table filename.





e. Ddt_show


i. Shows or hides the table editor of a specified
data table.


Syntax:[/b] ddt_show (data_table_name [,
show_flag]);[/i]





data_table_name[/i] The name of the data table.
The name may be the table variable name, the Microsoft Excel file or a tabbed
text file name, or the full path and file name of the table.





show_flag[/i] The value indicating whether
the editor should be shown (default=1) or hidden (0).





f. Ddt_get_row_count


i. Retrieves the no. of rows in a data tables


Syntax:[/b] ddt_get_row_count
(data_table_name, out_rows_count);[/i]





data_table_name[/i] The name of the data table.
The name may be the table variable name, the Microsoft Excel file or a tabbed
text file name, or the full path and file name of the table. The first row in
the file contains the names of the parameters.





out_rows_count [/i]The output variable that
stores the total number of rows in the data table.





g. ddt_next_row


i. Changes the active row in a database to the
next row


Syntax: [/b]ddt_next_row
(data_table_name);[/i]





data_table_name[/i] The name of the data table.
The name may be the table variable name, the Microsoft Excel file or a tabbed
text file name, or the full path and file name of the table. The first row in
the file contains the names of the parameters.


h. ddt_set_row


i. Sets the active row in a data table.


Syntax: [/b]ddt_set_row (data_table_name, row);[/i]


[/b]


data_table_name[/i] The name of the data table.
The name may be the table variable name, the Microsoft Excel file or a tabbed
text file name, or the full path and file name of the table. The first row in
the file contains the names of the parameters. This row is labeled row 0.





row[/i] The new active row in the data table.


[/b]


i. ddt_set_val


i. Sets a value in the current row of the data
table


Syntax: [/b]ddt_set_val (data_table_name,
parameter, value);[/i]





data_table_name[/i] The name of the data table.
The name may be the table variable name, the Microsoft Excel file or a tabbed
text file name, or the full path and file name of the table. The first row in
the file contains the names of the parameters. This row is labeled row 0.


parameter[/i] The name of the column into
which the value will be inserted.


value[/i] The value to be written into the table.





j. ddt_set_val_by_row


i. Sets a value in a specified row of the data
table.


Syntax: [/b]ddt_set_val_by_row
(data_table_name, row, parameter, value);[/i]





data_table_name[/i] The name of the data table.
The name may be the table variable name, the Microsoft Excel file or a tabbed
text file name, or the full path and file name of the table. The first row in
the file contains the names of the parameters. This row is labeled row 0.





row[/i] The row number in the table. It can be any
existing row or the current row number plus 1, which will add a new row to the
data table.





parameter[/i] The name of the column into
which the value will be inserted.





value [/i]The value to be written into
the table.





k. ddt_get_current_row


i. Retrieves the active row of a data table.


Syntax:[/b] ddt_get_current_row (
data_table_name, out_row );[/i]





data_table_name[/i] The name of the data table.
The name may be the table variable name, the Microsoft Excel file or a tabbed
text file name, or the full path and file name of the table. The first row in
the file contains the names of the parameters. This row is labeled row 0.





out_row[/i] The output variable that stores
the active row in the data table.





l. ddt_is_parameter


i. Returns whether a parameter in a datatable is
valid


Syntax: [/b]ddt_is_parameter
(data_table_name, parameter);[/i]





data_table_name[/i] The name of the data table.
The name may be the table variable name, the Microsoft Excel file or a tabbed
text file name, or the full path and file name of the table. The first row in
the file contains the names of the parameters.





parameter[/i] The parameter name to check
in the data table.





m. ddt_get_parameters


i. Returns a list of all parameters in a data
table.


Syntax: [/b]ddt_get_parameters ( table,
params_list, params_num );[/i]





table[/i] The pathname of the data table.


params_list[/i] This out parameter returns
the list of all parameters in the data table, separated by tabs.


params_num[/i] This out parameter returns
the number of parameters in params_list.





n. ddt_val


i. Returns the value of a parameter in the active
roe in a data table.


Syntax: [/b]ddt_val (data_table_name,
parameter);[/i]





data_table_name[/i] The name of the data table.
The name may be the table variable name, the Microsoft Excel file or a tabbed
text file name, or the full path and file name of the table. The first row in
the file contains the names of the parameters.





parameter[/i] The name of the parameter in
the data table. [/b]





o. ddt_val_by_row


i. Returns the value of a parameter in the
specified row in a data table.


Syntax:[/b] ddt_val_by_row (
data_table_name, row_number, parameter );[/i]





data_table_name[/i] The name of the data table.
The name may be the table variable name, the Microsoft Excel file or a tabbed
text file name, or the full path and file name of the table. The first row in
the file contains the names of the parameters. This row is labeled row 0.





row_number[/i] The number of the row in the
data table.





parameter[/i] The name of the parameter in
the data table.





p. ddt_report_row


i. Reports the active row in a data table to the
test results


Syntax:[/b] ddt_report_row
(data_table_name);[/i]





data_table_name[/i] The name of the data table.
The name may be the table variable name, the Microsoft Excel file or a tabbed
text file name, or the full path and file name of the table. The first row in
the file contains the names of the parameters. This row is labeled row 0.





q. ddt_update_from_db


i. imports data from a database into a data table. It is inserted
into your test script when you select the Import data from a database option in
the DataDriver Wizard. When you run your test, this function updates the data
table with data from the database.

[Spoorthi]

92) How do you handle unexpected events and errors?[/b]


a. WinRunner uses exception handling to
detect an unexpected event when it occurs and act to recover the test run.





WinRunner enables you to
handle the following types of exceptions:





Pop-up exceptions:[/b] Instruct WinRunner to detect and handle the appearance of a specific
window.





TSL exceptions:[/b] Instruct WinRunner to detect and handle TSL functions that return a
specific error code.





Object exceptions:[/b] Instruct WinRunner to detect and handle a change in a property for a
specific GUI object.





Web exceptions:[/b] When the WebTest add-in is loaded, you can instruct WinRunner to
handle unexpected events and errors that occur in your Web site during a test
run.

[Spoorthi]

93) How do you handle pop-up exceptions? [/b]


a.
A pop-up exception Handler handles the pop-up messages that come up during the
execution of the script in the AUT. TO handle this type of exception we make
WinRunner learn the window and also specify a handler to the exception. It
could be


i. Default
actions[/b]: WinRunner clicks the OK or Cancel button in the pop-up window, or
presses Enter on the keyboard. To select a default handler, click the
appropriate button in the dialog box.


ii.
User-defined handler[/b]: If you prefer,
specify the name of your own handler. Click User Defined Function Name and type
in a name in the User Defined Function Name box.

[Spoorthi]

94) How do you handle TSL exceptions?[/b]


a. A TSL exception enables you to detect and
respond to a specific error code returned during test execution.


b. Suppose you are running a batch test on an
unstable version of your application. If your application crashes, you want
WinRunner to recover test execution. A TSL exception can instruct WinRunner to
recover test execution by exiting the current test, restarting the application,
and continuing with 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 way that meets your specific testing needs.


d. Once you have defined the exception,
WinRunner activates handling and adds the exception to the list of default TSL
exceptions in the Exceptions dialog box. Default TSL exceptions are defined by
the XR_EXCP_TSL configuration parameter in the wrun.ini configuration file.

[Spoorthi]

95) How do you handle object exceptions?[/b]


a. During testing, unexpected changes can
occur to GUI objects in the application you are testing. These changes are
often subtle but they can disrupt the test run and distort results.


b. You could use exception handling to detect
a change in property of the GUI object during the test run, and to recover test
execution by calling a handler function and continue with the test execution





96) How do you comment your script?[/b]


a. We comment a script or line of script by
inserting a ‘#’ at the beginning of the line.