When you create database checkpoints, you define a query on your database, and your database checkpoint checks the values contained in the result set. The result set is a set of values retrieved from the results of the query.
There are several ways to define the query that will be used in your database checkpoints:
About Runtime Database Record Checkpoints
You can create runtime database record checkpoints in order to compare the values displayed in your application during the test run with the corresponding values in the database. If the comparison does not meet the success criteria you specify for the checkpoint, the checkpoint fails. You can define a successful runtime database record checkpoint as one where one or more matching records were found, exactly one matching record was found, or where no matching records are found. Your can include your databasecheckpoint in a loop. If you run your database checkpoint in a loop, the results for each iteration of the checkpoint are displayed in the test results as separate entries. The results of the checkpoint can be viewed in the Test Results window.
Runtime record checkpoints are useful when the information in the database changes from one run to the other. Runtime record checkpoints enable you to verify that the information displayed in your application was correctly inserted to the database or conversely, that information from the database is successfully retrieved and displayed on the screen.
Note that when you create a runtime database record checkpoint, the data in the application and in the database are generally in the same format. If the data is in different formats, you can follow the instructions in “Comparing Data in Different Formats” to create a runtime database record checkpoint. Note that this feature is for advanced WinRunner users only.
About Standard Database Checkpoints
You can create standard database checkpoints to compare the current values of the properties of the result set during the test run to the expected values captured during recording or otherwise set before the test run. If the expected results and the current results do not match, the database checkpoint fails.
Standard database checkpoints are useful when the expected results can be established before the test run. There are two types of standard database checkpoints: Default and Custom.
You can use a default check to check the entire contents of a result set, or you can use a custom check to check the partial contents, the number of rows, and the number of columns of a result set. Information about which result set properties to check is saved in a checklist. WinRunner captures the current information about the database and saves this information as expected results. A database checkpoint is automatically inserted into the test script. This checkpoint appears in your test script as a db_check statement.
For example, when you check the database of an application for the first time in a test script, the following statement is generated:
where list1.cdl is the name of the checklist containing information about the database and the properties to check, and dbvf1 is the name of the expected results file. The checklist is stored in the test’s chklist folder.If you are working with Microsoft Query or ODBC, it references a *.sqlquery file, which contains information about the database and the SQL statement. If you are working with Data Junction, it references a *.djs conversion file, which contains information about the database and the conversion. When you define a query, WinRunner creates a checklist and stores it in the test’s chklist folder. The expected results file is stored in the test’s exp folder.
When you run the test, the database checkpoint compares the current state of the database in the application being tested to the expected results. If the expected results and the current results do not match, the database checkpoint fails. Your can include your database checkpoint in a loop. If you run your database checkpoint in a loop, the results for each iteration of the checkpoint are displayed in the test results as separate entries. The results of the checkpoint can be viewed in the Test Results window.
You can modify the expected results of an existing standard database checkpoint before or after you run your test. You can also make changes to the query in an existing database checkpoint. This is useful if you move the database to a new location on the network.
When you create a database checkpoint using ODBC/Microsoft Query, you can add parameters to an SQL statement to parameterize your checkpoint. This is useful if you want to create a database checkpoint on a query in which the SQL statement defining your query changes.
Setting Options for Failed Database Checkpoints
You can instruct WinRunner to send an e-mail to selected recipients each time a database checkpoint fails and you can instruct WinRunner to capture a bitmap of your window or screen when any checkpoint fails. You set these options in the General Options dialog box.
To instruct WinRunner to send an e-mail message when a database checkpoint fails:
The e-mail contains summary details about the test and checkpoint and details about the connection string and SQL query used for the checkpoint.
To instruct WinRunner to capture a bitmap when a checkpoint fails:
When you run your test, the captured bitmaps are saved in your test results folder.
WinRunner Related Interview Questions
|SILK TEST Interview Questions||LoadRunner Interview Questions|
|WinRunner Interview Questions||HTML Interview Questions|
|QTP Interview Questions||Manual Testing Interview Questions|
|OpenStack Interview Questions||Automation Testing Interview Questions|
|API testing Interview Questions||Rational robot Interview Questions|
|Selenium IDE Interview Questions||Performance Testing Interview Questions|
|Test Director Interview Questions|
Winrunner At A Glance
Understanding How Winrunner Identifies Gui Objects
Understanding Basic Gui Map Concepts
Working In The Global Gui Map File Mode
Editing The Gui Map
Merging Gui Map Files
Configuring The Gui Map
Learning Virtual Objects
Checking Gui Objects
Working In The Gui Map File Per Test Mode
Working With Web Objects
Working With Activex And Visual Basic Controls
Checking Powerbuilder Applications
Checking Table Contents
Creating Data-driven Tests
Synchronizing The Test Run
Defining And Using Recovery Scenarios
Handling Web Exceptions
Using Regular Expressions
Enhancing Your Test Scripts With Programming
Creating User-defined Functions
Creating Compiled Modules
Calling Functions From External Libraries
Creating Dialog Boxes For Interactive Input
Understanding Test Runs
Analyzing Test Results
Running Batch Tests
Running Tests From The Command Line
Controlling Your Test Run
Setting Properties For A Single Test
Setting Global Testing Options
Customizing The Test Script Editor
Customizing The Winrunner User Interface
Setting Testing Options From A Test Script
Customizing The Function Generator
Initializing Special Configurations
Integrating With Quicktest Professional
Managing The Testing Process
Testing Systems Under Load
All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.