Win Runner Q & A Part 11

Win Runner Q & A Part 11

101. What are the steps of creating a data driven test?

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.

102. Record a data driven test script using data driver wizard?

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:

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 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 statement to your test script selection to run it in a loop while it reads from the data table; adds ddt_open and ddt_close 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, and ddt_save 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: Replaces fixed values in selected checkpoints and in recorded statements with parameters, using the ddt_val 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: 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.

103. What are the three modes of running the scripts?

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

1. Use the Verify mode to check your application.

ii. Debug

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

iii. Update

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

104. Explain the following TSL functions:

a) Ddt_open

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

Syntax: ddt_open ( data_table_name, mode );

data_table_name 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 The mode for opening the data table: DDT_MODE_READ (read-only) or DDT_MODE_READWRITE (read or write).

b) Ddt_save

Saves the information into a data file.

Syntax: dt_save (data_table_name);

data_table_name 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

Closes a data table file

Syntax: ddt_close ( data_table_name );

data_table_name 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

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

Syntax: ddt_export (data_table_namename1, data_table_namename2);

data_table_namename1 The source data table filename.

data_table_namename2 The destination data table filename.

e) Ddt_show

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

Syntax: ddt_show (data_table_name [, show_flag]);

data_table_name 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 The value indicating whether the editor should be shown (default=1) or hidden (0).

f) Ddt_get_row_count

Retrieves the no. of rows in a data tables

Syntax: ddt_get_row_count (data_table_name, out_rows_count);

out_rows_count The output variable that stores the total number of rows in the data table.

g) ddt_next_row

Changes the active row in a database to the next row

Syntax: ddt_next_row (data_table_name);

h) ddt_set_row

Sets the active row in a data table.

Syntax: ddt_set_row (data_table_name, row);

row The new active row in the data table.

i) ddt_set_val

Sets a value in the current row of the data table

Syntax: ddt_set_val (data_table_name, parameter, value);

parameter The name of the column into which the value will be inserted.

value The value to be written into the table.

j) ddt_set_val_by_row

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

Syntax: ddt_set_val_by_row (data_table_name, row, parameter, value);

row 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 The name of the column into which the value will be inserted.

value The value to be written into the table.

k) ddt_get_current_row

Retrieves the active row of a data table.

Syntax: ddt_get_current_row ( data_table_name, out_row );

out_row The output variable that stores the active row in the data table.

l) ddt_is_parameter

Returns whether a parameter in a datatable is valid

Syntax: ddt_is_parameter (data_table_name, parameter);

parameter The parameter name to check in the data table.

m) ddt_get_parameters

Returns a list of all parameters in a data table.

Syntax: 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 by tabs.

params_num This out parameter returns the number of parameters in params_list.

n) ddt_val

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

Syntax: ddt_val (data_table_name, parameter);

parameter The name of the parameter in the data table.

o) ddt_val_by_row

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

Syntax: ddt_val_by_row ( data_table_name, row_number, parameter );

row_number The number of the row in the data table.

parameter The name of the parameter in the data table.

p) ddt_report_row

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

Syntax: ddt_report_row (data_table_name);

q) ddt_update_from_db

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.

105. How do you handle unexpected events and errors?

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

Define Exception Handling

Define Exception

Define Handler Function

WinRunner enables you to handle the following types of exceptions:

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

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

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

Web exceptions: 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.

106. How do you handle pop-up exceptions?

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

107. How do you handle TSL exceptions?

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.

108. How do you handle object exceptions?

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

109. How do you comment your script?

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

110. What is a compile module?

a) A compiled module is a script containing a library of user-defined functions that you want to call frequently from other tests. When you load a compiled module, its functions are automatically compiled and remain in memory. You can call them directly from within any test.

b) Compiled modules can improve the organization and performance of your tests. Since you debug compiled modules before using them, your tests will require less error-checking. In addition, calling a function that is already compiled is significantly faster than interpreting a function in a test script.

Job Interview Questions - www.interviewhelper.org

Wednesday, March 19, 2008

Win Runner Q & A Part 11

No comments:

Some other interesting sites