Win Runner CheckPoints

Checkpoints allow user to compare the current behavior of the application being tested to its behavior in an earlier version. If any mismatches are found, WinRunner captures them as actual results. User can add four types of checkpoints to test scripts they are

GUI Checkpoints
Bitmap Checkpoints
Text checkpoints
Database checkpoints


All mouse operations, including those performed on the WinRunner window or WinRunner dialog boxes are recorded during an analog recording session. Therefore, don�t insert checkpoints and synchronization points, or select other WinRunner menu or toolbar options during an analog recording session. Note that even if user chooses to record only on selected applications, user can still create checkpoints and perform all other non-recording operations on all applications. Any checkpoints should not be a component of X & Y Co-ordinate dependant. In practical terms if there is a Check point that is defined on X, Y Parameters then the usability of the control point wouldn't make any sense for the application to test. User cannot insert objects from different windows into a single checkpoint. Don�t use Bitmap or GUI Checkpoints for dynamic verification. These checkpoints are purely for static verifications. There are of course, work-around, but mostly not worth the effort.

GUI checkpoints verify information about GUI objects. For example, user can check that a button is enabled or see which item is selected in a list. There are three types of GUI Check points they are
For Single Property
For Object/Window
For Multiple Objects

GUI checkpoint for single property:-user can check a single property of a GUI object. For example, user can check whether a button is enabled or disabled or whether an item in a list is selected.
GUI checkpoint for object/window:-user can create a GUI checkpoint to check a single object in the application being tested. User can either check the object with its default properties or user can specify multiple properties to check.
GUI checkpoint for multiple objects:-user can create a GUI checkpoint to check multiple objects in the application being tested. User can either check the object with its default properties or user can specify multiple properties of multiple objects to check.
Bitmap Checkpoint checks an object, a window, or an area of a screen in the application as a bitmap. While creating a test, user can indicate what user want to check. WinRunner captures the specified bitmap, stores it in the expected results folder (exp) of the test, and inserts a checkpoint in the test script. While running the test, WinRunner compares the bitmap currently displayed in the application being tested with the expected bitmap stored earlier. In the event of a mismatch, WinRunner captures the current actual bitmap and generates a difference bitmap. By comparing the three bitmaps (expected, actual, and difference), user can identify the nature of the discrepancy there are two types of bitmap check points they are
Bitmap Checkpoint for Object/Window: - user can capture a bitmap of any window or object in the application by pointing to it.
Bitmap Checkpointfor Screen Area:-user defines any rectangular area of the screen and captures it as a bitmap for comparison.

Text checkpoints read and check text in GUI objects and in areas of the screen. While creating a test user has to point to an object or a window containing text. WinRunner reads the text and writes a TSL statement to the test script. Later user can add simple programming elements to test scripts to verify the contents of the text. User should use a text checkpoint on a GUI object only when a GUI checkpoint cannot be used to check the text property. There are two types of Text checkpoints they are
From Object/Window
From Screen Area


Database checkpoints check the contents and the number of rows and columns of a result set, which is based on a query user, create on database. There are three types of database check points they are
Default Check:-used to check the entire contents of a result set, Default Check are useful when the expected results can be established before the test run.
Custom Check:-used to check the partial contents, the number of rows, and the number of columns of a result set.
Runtime Record Check:-user can create runtime database record checkpoints in order to compare the values displayed in the application during the test run with the corresponding values in the database.

How to Create a Test Using Winrunner (2)
GUI checkpoint
GUI checkpoint for single property
User can check a single property of a GUI object. For example, user 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:

button_check_info ()
scroll_check_info ()
edit_check_info ()
static_check_info ()
list_check_info ()
win_check_info ()
obj_check_info ()

Syntax:-Function_Name (name, property, property_value)
name: The Logical name of the object to be checked
property: The property to be checked
property_value: The expected property value


The Functions checks the current value of the specified property matches the expected property value.
To create a GUI checkpoint for a property value:
1. Choose Insert >GUI Checkpoint >For Single Property.
2. The mouse pointer becomes a pointing hand, and the Check Property dialog box opens and shows the default function for the selected object. WinRunner automatically assigns argument values to the function.
3. User can modify the arguments for the property check. To modify assigned argument values, choose a value from the Property list. The expected value is updated in the Expected text box. To choose a different object, click the pointing hand and then click the object to choose.

If the user clicks an object that is not compatible with the selected function, a message states that the current function cannot be applied to the selected object.


GUI checkpoint for object/window
This checkpoint is used to check the state or properties of a single object or window in an application. If a user single-click on a GUI object, the default checks for that object are included in the GUI checkpoint. If the user double-clicks on a GUI object, after WinRunner capturing GUI data, the Check GUI dialog box opens. User can choose which checks to include for that particular object. When using a GUI Checkpoint command, WinRunner inserts a checkpoint statement into the test script.

For a GUI object class, WinRunner inserts an obj_check_gui statement, which compares current GUI object data to expected data.

obj_check_gui (object, checklist, expected_results_file, time);

object The logical name or description of the GUI object. The object may belong to any class.
checklist The name of the checklist defining the GUI checks.
expected_results_file The name of the file that stores the expected GUI data.
time The interval in seconds. This interval is added to the timeout test option during the test run.
For a window, WinRunner inserts a win_check_gui statement, which compares current GUI data to expected GUI data for a window.

win_check_gui (window, checklist, expected_results_file, time);

WinRunner names the first checklist in the test as list1.ckl and the first expected results file gui1.

During test creation, the GUI data is captured and stored. When the user run the test, the current GUI data is compared to the data stored in the expected_results_file, according to the checklist. A file containing the actual results is also generated.

GUI checkpoint for multiple objects
The checkpoint statement inserted by the WinRunner in the case of GUI checkpoint for multiple objects and GUI checkpoint for object/window are the same.

To create a GUI checkpoint for two or more objects select GUI Checkpoint For Multiple Objects button on the User toolbar. The Create GUI Checkpoint dialog box opens.

To add an object, click the Add button once. If the user clicks a window title bar or menu bar, a window pops up asking "You are currently pointing at a window. What do you wish to check inside the window?" objects or menus. User can continue to choose objects by clicking the Add button.

Click the right mouse button to stop the selection process and to restore the mouse pointer to its original shape. The Create GUI Checkpoint dialog box reopens. The Objects pane contains the name of the window and objects included in the GUI checkpoint. To specify which objects to check, click an object name in the Objects pane. The Properties pane lists all the properties of the object. The default properties are selected.

The checklist file contains the expected values and it come under the exp folder. A GUI checklist includes only the objects and the properties to be checked. It does not include the expected results for the values of those properties. WinRunner has an edit checklist file option under the Insert menu. For modifying GUI checklist file select the Edit GUI Checklist. This brings up a dialog box that gives the 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.

Bitmap Checkpoint
Bitmap Checkpoint for Object/Window
To create a Bitmap Checkpoint for Object/Window
Choose Insert >Bitmap Checkpoint >For Object/Window.

The WinRunner window is minimized, the mouse pointer becomes a pointing hand.
Point to the object or window and click it.

WinRunner captures the bitmap and generates a TSL statement in the script.

The TSL statement generated for a window bitmap has the following syntax:

win_check_bitmap (window, bitmap, time);

The TSL statement generated for an object bitmap has the following syntax:
obj_check_bitmap (object, bitmap, time);

window or object The logical name or description of the window or object.
bitmap A string expression that identifies the captured bitmap.

time The interval marking the maximum delay between the previous input event and the capture of the current bitmap, in seconds. This interval is added to the timeout test option before the next statement is executed.

The win_check_bitmap function captures and compares bitmaps of a window or window area. During test creation, the specified window or area is captured and stored. During a test run, the current bitmap is compared to the one stored in the database. If they are different, the actual bitmap is captured. This function is generated during the recording of a test. Since the test is waiting for a result, the test should be run in update mode.

Bitmap Checkpoint for Screen Area

To create a Bitmap Checkpoint for Screen Area
Choose Insert>:Bitmap Checkpoint >:For Screen Area.

The WinRunner window is minimized, the mouse pointer becomes a crosshairs pointer Mark the area to be captured: press the left mouse button and drag the mouse pointer until a rectangle encloses the area; then release the mouse button.

Press the right mouse button to complete the operation.
WinRunner captures the area and generates a win_check_bitmap statement in the script.

The win_check_bitmap statement for an area of the screen has the following syntax:

win_check_bitmap (window, bitmap, time, x, y, width, height);

x, y For an area bitmap: the coordinates or the upper-left corner, relative to the window in which the selected area is located. width, height For an area bitmap: the size of the selected area, in pixels.

When area of the window is captured, the additional parameters i.e. x, y, width and height define the area's location and dimensions.

The analog version of win_check_bitmap is check_window. Syntax is as follows

check_window (time, bitmap, window, width, height, x, y [, relx1, rely1, relx2, rely2]);

time - Indicates the interval between the previous input event and the bitmap capture, in seconds. This interval is added to the timeout_msec testing option. The sum is the interval between the previous event and the bitmap capture, in seconds.
bitmap - A string identifying the captured bitmap. The string length is limited to 6 characters.
window - A string indicating the name in the window banner.
width, height - The size of the window, in pixels.

x, y - The position of the upper left corner of the window (relative to the screen). In the case of an MDI child window, the position is relative to the parent window.
relx1, rely1 For an area bitmap: the coordinates of the upper left corner of the rectangle, relative to the upper left corner of the client window (the x and y parameters).
relx2, rely2 For an area bitmap: the coordinates of the lower right corner of the rectangle, relative to the lower right corner of the client window (the x and y parameters).

The check_window function captures a bitmap of a window. During recording, the specified bitmap is captured and stored. During a test run, the current bitmap is compared to the bitmap stored in the database, and if it is different, the actual bitmap is captured.

Text checkpoints
Text checkpoints read text in GUI objects and in bitmaps and enable user to verify the contents. When creating a text check point for an object or a window containing text. WinRunner reads the text and writes a TSL statement to the test script. Using simple programming the user can use the text content.

User can use a text checkpoint to:
1. Read text from a GUI object or window in the application, using obj_get_text or win_get_text. The maximum number of characters that can be captured in one obj_get_text statement is 2048.

obj_get_text (object, out_text [, x1, y1, x2, y2]);

object The logical name or description of the GUI object. The object may belong to any class. out_text The name of the output variable that stores the captured text. x1,y1,x2,y2 An optional parameter that defines the location from which text will be read, relative to the specified object. The pairs of coordinates can designate any two diagonally opposite corners of a rectangle.

2. Search for text in an object or window, using obj_find_text or win_find_text returns the location of a string within an object.
obj_find_text (object, string, result_array [, search_area [, string_def]]);
object The logical name or description of the object. The object may belong to any class.

string A valid string expression or the name of a string variable, which can include a regular expression. The regular expression should not include an exclamation mark (!), however, which is treated as a literal character.
result_array The name of the four-element array that stores the location of the string. The elements are numbered 1 to 4. Elements 1 and 2 store the x- and y- coordinates of the upper left corner of the enclosing rectangle; elements 3 and 4 store the coordinates for the lower right corner.

search_area Indicates the area of the screen to search as coordinates that define any two diagonal corners of a rectangle, expressed as a pair of x,y coordinates. The coordinates are stored in result_array.

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. Any regular expression used in the string must not contain blank spaces, and only the default value of string_def, FALSE, is in effect.


3. Compares two strings using compare_text (str1, str2 [, chars1, chars2]);
str1, str2 the two strings to be compared.
chars1 One or more characters in the first string that should be considered equivalent to the character(s) specified in chars2.
chars2 One or more characters in the second string. that should be considered equivalent to the character(s) specified in chars1.

The compare_text function compares two strings, ignoring any differences specified. The two optional parameters are used to indicate characters that should be considered equivalent during the comparison. For instance, if the user specify "m" and "n", the words "any" and "amy" will be considered a match. The two optional parameters must be of the same length. Note that blank spaces are ignored.

WinRunner can read the visible text from the screen in most applications. If the Text Recognition mechanism is set to driver based recognition, this process is automatic. However, if the Text Recognition Mechanism is set to image-based recognition, WinRunner must first learn the fonts used by the application. When using the WinRunner text-recognition mechanism for Windows-based applications, keep in mind that it may occasionally retrieve unwanted text information (such as hidden text and shadowed text, which appears as multiple copies of the same string). The text recognition may behave differently in different run sessions depending on the operating system version, service packs, other installed toolkits, the APIs used, and so on. Therefore, when possible, it is highly recommended to retrieve or check text from application window by inserting a standard GUI checkpoint and selecting to check the object ’s value (or similar)property.

When reading text with a learned font, WinRunner reads a single line of text only. If the captured text exceeds one line, only the leftmost line is read. If two or more lines have the same left margin, then the bottom line is read.

Database Checkpoint

Default Check on a Database
To create default check on a database using ODBC or Microsoft Query:
Choose Insert >Database Checkpoint >Default Check
If Microsoft Query is installed and user is creating a new query, an instruction screen opens for creating a query. If Microsoft Query is not installed, the Database Checkpoint wizard opens to a screen where the user can define the ODBC query manually.
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. WinRunner captures the data specified by the query and stores it in the test’s exp folder. WinRunner creates the msqr*.sql query file and stores the query and the database checklist is stored in the test’s chklist folder.

A database checkpoint is inserted in the test script as a db_check statement.
Syntax:-
db_check (checklist, expected_results_file [, max_rows [, parameter_array]]);

checklist The name of the checklist specifying the checks to perform.
expected_results_file The name of the file storing the expected database data.
max_rows The maximum number of rows retrieved in a database. If no maximum is specified, then by default the number of rows is not limited.
parameter_array The array of parameters for the SQL statement.

The db_check function captures and compares information about a database. During a test run, WinRunner checks the query of the database with the checks specified in the checklist. WinRunner then checks the information obtained during the test run against the expected results contained in the expected_results_file.
Note:-when using Create > Database Checkpoint command to create a database checkpoint, only the first two (obligatory) parameters are included in the db_check statement (unless the user parameterize the SQL statement from within Microsoft Query). If the user changes this parameter in a db_check statement recorded in test script, user must run the test in Update mode before running it in Verify mode. SQL queries used with db_check are limited to 4Kb in length.
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.
Parameterize Standard Database Checkpoints

While creating a standard database checkpoint using ODBC (Microsoft Query), user can add parameters to an SQL statement to parameterize the checkpoint. 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 (?).

To execute a parameterized query, user must specify the values for the parameters.

To parameterize the SQL statement in the checkpoint, the db_check function has a fourth, optional, argument the parameter_array argument.

Syntax:-
db_check (checklist, expected_results_file [, max_rows [, parameter_array]]);

The parameter_array argument will contain the values to substitute for the parameters in the parameterized checkpoint. WinRunner cannot capture the expected result set while recording the test. Unlike regular database checkpoints, recording a parameterized checkpoint requires additional steps to capture the expected results set. Therefore, user must use array statements to add the values to substitute for the parameters. User must run the test in Update mode once to capture the expected results set before running the test in Verify mode.

TSL Functions for Working with ODBC (Microsoft Query)
When the user works with ODBC (Microsoft Query), user must perform the following steps in the following order:

Connect to the database.
Execute a query and create a result set based on an SQL statement.
Retrieve information from the database.
Disconnect from the database.

Connect to the database.
Syntax:-db_connect (session_name, connection_string [, timeout]);
session_name The logical name or description of the database session.
connection_string The connection parameters to the ODBC database.
timeout The number of seconds before the login attempt times out.


The db_connect function creates the new session_name database session and uses the connection_string to establish a connection to an ODBC database. User can use the Function Generator to open an ODBC dialog box, in which user can create the connection string. If user tries to use a session name that has already been used, WinRunner will delete the old session object and create a new one using the new connection string.

Execute a query and create a result set based on an SQL statement.
Syntax:-db_execute_query ( session_name, SQL, record_number );
SQL The SQL statement to be executed
record_number An out parameter returning the number of records in the result query.


The db_execute_query function executes the query based on the SQL statement and creates a record set. User must use a db connect statement to connect to the database before using this function.

Retrieve information from the database.
Syntax:-db_get_field_value (session_name, row_index, column);
row_index The index of the row written as a string: "# followed by the numeric index. (The first row is always numbered "#0".)
column name of the field in the column


The db_get_field_value function returns the value of a single field in the specified row_index and column in the session_name database session. In case of an error, an empty string will be returned. Before using this function user must use a db connect statement, connect to the database and db execute query statement, execute a query.

Syntax:-db_get_headers (session_name, header_count, header_content);
header_count The number of column headers in the query.
header_content The column headers concatenated and delimited by tabs. If this string exceeds 1024 characters, it is truncated.

The db_get_headers function returns the header_count and the text in the column headers in the session_name database session. Before using this function user must use a db connect statement, connect to the database and db execute query statement, execute a query.

Syntax:-db_get_row (session_name, row_index, row_content);
row_index The numeric index of the row. (The first row is always numbered "0".)
row_content The row content as a concatenation of the fields values, delimited by tabs.

The db_get_row function returns the row_content of the specified row_index, concatenated and delimited by tabs in the session_name database session. Before using this function user must use a db connect statement, connect to the database and dbexecute query statement, execute a query.



Syntax:-db_write_records (session_name, output_file [, headers [, record_limit]]);
output_file The name of the text file in which the record set is written.
headers An optional Boolean parameter that will include or exclude the column headers from the record set written into the text file. record_limit The maximum number of records in the record set to be written into the text file. A value of NO_LIMIT (the default value) indicates there is no maximum limit to the number of records in the record set.

The db_write_records writes the record set of the session_name into an output_file delimited by tabs. Before using this function user must use a db connect statement, connect to the database and db execute query statement, execute a query.

Syntax:-db_get_last_error ( session_name, error );
error The error message.

The db_get_last_error function returns the last error message of the last ODBC or Data Junction operation in the session_name database session. If there is no error message, an empty string will be returned. User must use a db connect statement to connect to the database before using this function.

Disconnect from the database.
Syntax:-db_disconnect ( session_name );

The db_disconnect function disconnects from the session_name database session. User must use a db connect statement to connect to the database before using this function.

Specifying the Verification Method
User can select the verification method to control how WinRunner identifies columns or rows within a result set. The verification method applies to the entire result set. Specifying the verification method is different for multiple-column and single-column result sets.

Specifying the Verification Method for a Multiple-Column Result Set
Column
Name (default setting)

WinRunner looks for the selection according to the column names. A shift in the position of the columns within the result set does not result in a mismatch.

Index WinRunner looks for the selection according to the index, or position, of the columns. A shift in the position of the columns within the result set results in a mismatch. Select this option if the result set contains multiple columns with the same name.
Row
Key WinRunner looks for the rows in the selection according to the key(s) specified in the Select key columns list box, which lists the names of all columns in the result set. A shift in the position of any of the rows does not result in a mismatch. If the key selection does not identify a unique row, only the first matching row will be checked.

Index (default setting) WinRunner looks for the selection according to the index, or position, of the rows. A shift in the position of any of the rows results in a mismatch.

Specifying the Verification Method for a Single-Column Result Set
By position WinRunner checks the selection according to the location of the items within the column.
By content WinRunner checks the selection according to the content of the items, ignoring their location in the column.


Specifying the Verification Type
WinRunner can verify the contents of a result set in several different ways. User can choose different verification types for different selections of cells.

Case Sensitive (the default)
WinRunner compares the text content of the selection. Any difference in case or text content between the expected and actual data results in a mismatch.

Case Sensitive Ignore Spaces
WinRunner checks the data in the field according to case and content, ignoring differences in spaces. WinRunner reports any differences in case or content as a mismatch.

Case Insensitive WinRunner compares the text content of the selection. Only differences in text content between the expected and actual data result in a mismatch.

Case Insensitive Ignore Spaces
WinRunner checks the content in the cell according to content, ignoring differences in case and spaces. WinRunner reports only differences in content as a mismatch.

Numeric Content WinRunner evaluates the selected data according to numeric values. WinRunner recognizes, for example, that “2” and “2.00” are the same number.

Numeric Range WinRunner compares the selected data against a numeric range. Both the minimum and maximum values are any real number that the user specifies. This comparison differs from text and numeric content verification in that the actual database data is compared against the range that user defined and not against the expected results.