WinRunner question 3

1. • DVR_NO_MATCH - The checkpoint passes if no matching database records are found. - RecordNumber An out parameter returning the number of records in the database.
2. • How do you handle dynamically changing area of the window in the bitmap checkpoints? - a) The difference between bitmaps option in the Run Tab of the general options defines the minimum number of pixels that constitute a bitmap mismatch
3. • What do you verify with the database check point custom and what command it generates, explain syntax? - a) When you create a custom check on a database, you create a standard database checkpoint in which you can specify which properties to check on a result set.
b) You can create a custom check on a database in order to:
i. check the contents of part or the entire result set
ii. edit the expected results of the contents of the result set
iii. count the rows in the result set
iv. count the columns in the result set
c) You can create a custom check on a database using ODBC, Microsoft Query or Data Junction.
4. • What do you verify with the sync point for object/window property and what command it generates, explain syntax? - a) Synchronization compensates for inconsistencies in the performance of your application during a test run. By inserting a synchronization point in your test script, you can instruct WinRunner to suspend the test run and wait for a cue before continuing the test.
b) You can a synchronization point that instructs WinRunner to wait for a specified object or window to appear. For example, you can tell WinRunner to wait for a window to open before performing an operation within that window, or you may want WinRunner to wait for an object to appear in order to perform an operation on that object.
c) You use the obj_exists function to create an object synchronization point, and you use the win_exists function to create a window synchronization point. These functions have the following syntax:
Syntax:
obj_exists ( object [, time ] );
win_exists ( window [, time ] );
5. • What do you verify with the sync point for object/window bitmap and what command it generates, explain syntax? - a) You can create a bitmap synchronization point that waits for the bitmap of an object or a window to appear in the application being tested.
b) During a test run, WinRunner suspends test execution until the specified bitmap is redrawn, and then compares the current bitmap with the expected one captured earlier. If the bitmaps match, then WinRunner continues the test.
Syntax:
obj_wait_bitmap ( object, image, time );
win_wait_bitmap ( window, image, time );
6. • What do you verify with the sync point for screen area and what command it generates, explain syntax? - a) For screen area verification we actually capture the screen area into a bitmap and verify the application screen area with the bitmap file during execution
Syntax: obj_wait_bitmap(object, image, time, x, y, width, height);
7. • How do you edit checklist file and when do you need to edit the checklist file? - a) WinRunner has an edit checklist file option under the create menu. Select the “Edit GUI Checklist” to modify GUI checklist file and “Edit Database Checklist” to edit database checklist file. This brings up a dialog box that gives you option to select the checklist file to modify. There is also an option to select the scope of the checklist file, whether it is Test specific or a shared one. Select the checklist file, click OK which opens up the window to edit the properties of the objects.
8. • How do you edit the expected value of an object? - a) We can modify the expected value of the object by executing the script in the Update mode. We can also manually edit the gui*.chk file which contains the expected values which come under the exp folder to change the values.
9. • How do you modify the expected results of a GUI checkpoint? - a) We can modify the expected results of a GUI checkpoint be running the script containing the checkpoint in the update mode.
10. • How do you handle ActiveX and Visual basic objects? - a) WinRunner provides with add-ins for ActiveX and Visual basic objects. When loading WinRunner, select those add-ins and these add-ins provide with a set of functions to work on ActiveX and VB objects.
11. • How do you create ODBC query? - a) We can create ODBC query using the database checkpoint wizard. It provides with option to create an SQL file that uses an ODBC DSN to connect to the database. The SQL File will contain the connection string and the SQL statement.
12. • How do you record a data driven test? - a) We can create a data-driven testing using data from a flat file, data table or a database.
i. Using Flat File: we actually store the data to be used in a required format in the file. We access the file using the File manipulation commands, reads data from the file and assign the variables with data.
ii. Data Table: It is an excel file. We can store test data in these files and manipulate them. We use the ‘ddt_*’ functions to manipulate data in the data table.
iii.Database: we store test data in the database and access these data using ‘db_*’ functions.
13. • How do you convert a database file to a text file? - a) You can use Data Junction to create a conversion file which converts a database to a target text file.
14. • How do you parameterize database check points? - a) When you create a standard database checkpoint using ODBC (Microsoft Query), you can add parameters to an SQL statement to parameterize the checkpoint. This is useful if you want to create a database checkpoint with a query in which the SQL statement defining your query changes.
15. • How do you create parameterize SQL commands? - 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:
16. SELECT Flights.Departure, Flights.Flight_Number, Flights.Day_Of_Week FROM Flights Flights WHERE (Flights.Departure=?) AND (Flights.Day_Of_Week=?)
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 function has a fourth, optional, argument: the parameter_array argument. A statement similar to the following is inserted into your test script:
db_check(”list1.cdl”, “dbvf1?, NO_LIMIT, dbvf1_params);
The parameter_array argument will contain the values to substitute for the parameters in the parameterized checkpoint.
17. • Explain the following commands: - a) db_connect
to connect to a database
db_connect(, );
b) db_execute_query
to execute a query
db_execute_query ( session_name, SQL, record_number );
record_number is the out value.
c) db_get_field_value
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 );
d) db_get_headers
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 );
e) db_get_row
returns the content of the row, concatenated and delimited by tabs.
db_get_row ( session_name, row_index, row_content );
f) db_write_records
writes the record set into a text file delimited by tabs.
db_write_records ( session_name, output_file [ , headers [ , record_limit ] ] );
g) db_get_last_error
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 );
h) db_disconnect
disconnects from the database and ends the database session.
db_disconnect ( session_name );
i) db_dj_convert
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 ] ] ] );
18. • What check points you will use to read and check text on the GUI and explain its syntax? - 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 and win_get_text
ii.Search for text in an object or window, using win_find_text and obj_find_text
iii. Move the mouse pointer to text in an object or window, using obj_move_locator_text and win_move_locator_text
iv. Click on text in an object or window, using obj_click_on_text and win_click_on_text
19. • Explain Get Text checkpoint from object/window with syntax? - a) We use obj_get_text (, ) function to get the text from an object
b) We use win_get_text (window, out_text [, x1, y1, x2, y2]) function to get the text from a window.
20. • Explain Get Text checkpoint from screen area with syntax? - a) We use win_get_text (window, out_text [, x1, y1, x2, y2]) function to get the text from a window.
21. • Explain Get Text checkpoint from selection (web only) with syntax? - a) Returns a text string from an object.
web_obj_get_text (object, table_row, table_column, out_text [, text_before, text_after, index]);
i. object The logical name of the object.
ii. table_row 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 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 The output variable that stores the text string.
v. text_before Defines the start of the search area for a particular text string.
vi. text_after Defines the end of the search area for a particular text string.
vii. index The occurrence number to locate. (The default parameter number is numbered 1).
22. • Explain Get Text checkpoint web text checkpoint with syntax? - a) We use web_obj_text_exists function for web text checkpoints.
web_obj_text_exists ( object, table_row, table_column, text_to_find [, text_before, text_after] );
a. object The logical name of the object to search.
b. table_row If the object is a table, it specifies the location of the row within a table. The string is preceded by the character #.
c. table_column If the object is a table, it specifies the location of the column within a table. The string is preceded by the character #.
d. text_to_find The string that is searched for.
e. text_before Defines the start of the search area for a particular text string.
f. text_after Defines the end of the search area for a particular text string.
23. • Which TSL functions you will use for - a) Searching text on the window
i. find_text ( string, out_coord_array, 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 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 The name of the array that stores the screen coordinates of the text (see explanation below).
search_area 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 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 ] ] );
window The logical name of the window to search.
string 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 The name of the output variable that stores the location of the string as a four-element array.
search_area 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 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 ] ] );
window The logical name of the window.
string 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 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 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]);
str1, str2 The two strings to be compared.
chars1 One or more characters in the first string.
chars2 One or more characters in the second string. These characters are substituted for those in chars1.
24. • 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.
25. • 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.”
26. 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:
27. • 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 -
28. • 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. -
29. • 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. -
30. • 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. -
31. • 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. -
32. • 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. -
33. • 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:
34. • Do not replace this data: Does not parameterize this data. -
35. • An existing column: If parameters already exist in the data table for this test, select an existing parameter from the list. -
36. • 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.
37. • If you want the data table to open after you close the wizard, select Show data table now. -
38. • To perform the tasks specified in previous screens and close the wizard, click Finish. -
39. • To close the wizard without making any changes to the test script, click Cancel. -
40. • 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
41. • Use the Verify mode to check your application. - ii. Debug
42. • Use the Debug mode to help you identify bugs in a test script. - iii. Update