Interview Questions

How to Create a Test Using Winrunner (4)

Introduction To WinRunner Basics


(Continued from previous question...)

How to Create a Test Using Winrunner (4)

Custom Check on a Database

When the user wants to create a custom check on a database, user creates a standard database checkpoint in which user can specify which properties to check on a result set. User can create a custom check on a database using ODBC, Microsoft Query or Data Junction. User can create a custom check on a database in order to:

Check the contents of part or the entire result set
Edit the expected results of the contents of the result set
Count the rows in the result set
Count the columns in the result set

To create a custom check on a database:
Choose Insert >Database Checkpoint >Custom Check

The Database Checkpoint wizard opens. Use ODBC or Microsoft Query to define a query, copy a query, or specify an SQL statement. WinRunner takes several seconds to capture the database query and restore the WinRunner window.
If the user wants 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. WinRunner captures the current property values and stores them in the test’s exp folder. WinRunner stores the database query in the test’s chklist folder. A database checkpoint is inserted in the test script as a db_check statement. If the user is using Microsoft Query and the user want to be able to parameterize the SQL statement in the db_check statement, then in the last wizard screen in Microsoft Query, click View data or edit query in Microsoft Query

The default check for a multiple-column query on a database is a case sensitive check on the entire result set by column name and row index. The default check for a single-column query on a database is a case sensitive check on the entire result set by row position. If the result set contains multiple columns with the same name, WinRunner disregards the duplicate columns and does not perform checks on them. Therefore, user should create a custom check on the database and select the column index option.

Modifying a Standard Database Checkpoint
User can make the following changes to an existing standard database checkpoint:
Make a checklist available to other users by saving it in a shared folder
User can edit an existing database checklist.
User can modify a query in an existing checklist


To save a database checklist in a shared folder:
Choose Insert >Edit Database Checklist.

The Open Checklist dialog box opens.
Select a database checklist and click OK .
Under Scope, click Shared .Type in a name for the shared checklist.

*.sql files are not saved in shared database checklist folders. Checklists have the .cdl extension, while GUI checklists have the .ckl extension. The Objects pane contains “Database check”and the name of the *.sql query file or *.djs conversion file that will be included in the database checkpoint. The Properties pane lists the different types of checks that can be performed on databases. A check mark indicates that the item is selected and is included in the checkpoint. In the Properties pane, user can edit the database checklist to include or exclude the following types of checks:

ColumnsCount: Counts the number of columns in the result set.
Content : Checks the content of the result set
RowsCount: Counts the number of rows in the result set.

To modify a query in an existing checklist, highlight the name of the query file or the conversion file, and click Modify.
The Modify ODBC Query dialog box opens and the user can make modification to connection string and/or the SQL statement.
After making the modifications user must run all tests that use this checklist in Update mode before running them in Verify mode.

Runtime record checkpoints
Runtime record checkpoints are useful when the information in the database changes from one run to the other. Runtime record checkpoints enable user to verify that the information displayed in the application was correctly inserted to the database or conversely, that information from the database is successfully retrieved and displayed on the screen. If the comparison does not meet the success criteria user specify for the checkpoint, the checkpoint fails.

To add a runtime database record checkpoints
Select Insert >Database Checkpoint >Runtime Record Check .

The Define Query screen pops up which enables user to select a database and define a query for the checkpoint. User can create a new query from database using Microsoft Query, or manually define an SQL statement.

The Next screen is the Match Database Field screen which enables user to identify the application control or text in application that matches the displayed database field.

The Next screen is the Matching Record Criteria screen which enables user to specify the number of matching database records required for a successful checkpoint.

db_record_check statement is inserted into the script. db_record_check () function compares information that appears in the application under test during a test run with the current values in the corresponding record(s) in database.

Syntax of db_record_check ():-
db_record_check (ChecklistFileName, SuccessConditions, RecordNumber [, Timeout]);


ChecklistFileName A file created by WinRunner and saved in the test's checklist 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 Checkpoint wizard.

SuccessConditions Contains one of the following values:

DVR_ONE_OR_MORE_MATCH -
The checkpoint passes if one or more matching database records are found.
DVR_ONE_MATCH -
The checkpoint passes if exactly one matching database record is found.
DVR_NO_MATCH - The checkpoint passes if no matching database records are found.
RecordNumber Parameter that returns the number of records the database.
Timeout The number of seconds before the query attempt times out.


User cannot use an SQL statement of the type "SELECT * from ..." with the db_record_check function. Instead, user must supply the tables and field names. The reason for this is that WinRunner needs to know which database fields should be matched to which variables in the WinRunner script. The expected SQL format is:

SELECT table_name1.field_name1, table_name2.field_name2, ……FROM table_name1, table_name2, ... [WHERE ...]

Editing a Runtime Database Record Checklist
User can make changes to a checklist created for a runtime database record checkpoint. A checklist includes the connection string to the database, the SQL statement or a query, the database fields in the data source, the controls in the application, and the mapping between them. It does not include the success conditions of a runtime database record Checkpoint so the user can’t edit the success conditions. User can change the success condition of the checkpoint by modifying the second parameter in the db_record_check statement in the test script.

To edit an existing runtime database record checklist:

Choose Insert >Edit Runtime Record Checklist.
Select the checklist name from the Runtime Record Checkpoint wizard by default, runtime database record checklists are named sequentially in each test, starting with list1.cvr.

The next screen is the Specify SQL statement screen where the user can modify the Connection String and SQL statement. If the user modified the SQL statement or query in Microsoft Query so that it now references an additional database field in the data source, the checklist will now include a new database field.

User must match this database field to an application control. Use the pointing hand in the next screen to identify the control or text that matches the displayed field name. New database fields are marked with a “New” icon

If user wants several db_record_check statements, each with different success conditions then user can manually enter a db_record_check statement that references an existing checklist and specify the success conditions user want. User does not need to rerun the Runtime Record Checkpoint wizard for each new checkpoint.

(Continued on next question...)

Other Interview Questions