In the Text/Text Area Checkpoint
Properties dialog box, you can specify the text to be checked as well as which
text is displayed before and after the checked text. These configuration
options are particularly helpful when the text string you want to check appears
several times or when it could change in a predictable way during run sessions.
In Windows-based environments, if there is more than one line of text selected, the Checkpoint Summary pane displays [complex value] instead of the selected text string. You can then click Configure to view and manipulate the actual selected text for the checkpoint.
QTP automatically displays the Checked Text in red and the text before and after the Checked Text in blue. For text area checkpoints, only the text string captured from the defined area is displayed (Text Before and Text After are not displayed). To designate parts of the captured string as Checked Text and other parts as Text Before and Text After, click the Configure button. The Configure Text Selection dialog box opens
Checking XML :
XML (Extensible Markup Language) is a meta-markup language for text documents that is endorsed as a standard by the W3C. XML makes the complex data structures portable between different computer environments/operating systems and programming languages, facilitating the sharing of data.
XML files contain text with simple tags that describe the data within an XML document. These tags describe the data content, but not the presentation of the data. Applications that display an XML document or file use either Cascading Style Sheets (CSS) or XSL Formatting Objects (XSL-FO) to present the data.
In Windows-based environments, if there is more than one line of text selected, the Checkpoint Summary pane displays [complex value] instead of the selected text string. You can then click Configure to view and manipulate the actual selected text for the checkpoint.
QTP automatically displays the Checked Text in red and the text before and after the Checked Text in blue. For text area checkpoints, only the text string captured from the defined area is displayed (Text Before and Text After are not displayed). To designate parts of the captured string as Checked Text and other parts as Text Before and Text After, click the Configure button. The Configure Text Selection dialog box opens
Checking XML :
XML (Extensible Markup Language) is a meta-markup language for text documents that is endorsed as a standard by the W3C. XML makes the complex data structures portable between different computer environments/operating systems and programming languages, facilitating the sharing of data.
XML files contain text with simple tags that describe the data within an XML document. These tags describe the data content, but not the presentation of the data. Applications that display an XML document or file use either Cascading Style Sheets (CSS) or XSL Formatting Objects (XSL-FO) to present the data.
You can verify the data content of
XML files by inserting XML checkpoints. A few common uses of XML checkpoints
are described below: An XML file can be a static data file that is accessed in
order to retrieve commonly used data for which a quick response time is needed—for
example,
country names, zip codes, or area codes. Although this data can change over time, it is normally quite static. You can use an XML file checkpoint to validate that the data has not changed from one application release to another.
An XML file can consist of elements with attributes and values (character data). There is a parent and child relationship between the elements, and elements can have attributes associated with them. If any part of this structure (including data) changes, your application's ability to process the XML file may be affected. Using an XML checkpoint, you can check the content of an element to make sure that its tags, attributes, and values have not changed.
XML files are often an intermediary that retrieves dynamically changing data from one system. The data is then accessed by another system using Document Type Definitions (DTD), enabling the accessing system to read and display the information in the file. You can use an XML checkpoint and parameterize the captured data values in order to check an XML document or file whose data changes in a predictable way.
XML documents and files often need a well-defined structure in order to be portable across platforms and development systems. One way to accomplish this is by developing an XML schema, which describes the structure of the XML elements and data types. You can use schema validation to check that each item of content in an XML file adheres to the schema description of the element in which the content is to be placed.
country names, zip codes, or area codes. Although this data can change over time, it is normally quite static. You can use an XML file checkpoint to validate that the data has not changed from one application release to another.
An XML file can consist of elements with attributes and values (character data). There is a parent and child relationship between the elements, and elements can have attributes associated with them. If any part of this structure (including data) changes, your application's ability to process the XML file may be affected. Using an XML checkpoint, you can check the content of an element to make sure that its tags, attributes, and values have not changed.
XML files are often an intermediary that retrieves dynamically changing data from one system. The data is then accessed by another system using Document Type Definitions (DTD), enabling the accessing system to read and display the information in the file. You can use an XML checkpoint and parameterize the captured data values in order to check an XML document or file whose data changes in a predictable way.
XML documents and files often need a well-defined structure in order to be portable across platforms and development systems. One way to accomplish this is by developing an XML schema, which describes the structure of the XML elements and data types. You can use schema validation to check that each item of content in an XML file adheres to the schema description of the element in which the content is to be placed.
1) Key word driven testing
2) Suitable for both client server and web based application
3) VB script as the script language
4) Better error-handling mechanism
5) Excellent data driven testing features
6) Operates stand-alone, or integrated into HP Business Process Testing and HP Quality Center.
It introduces next-generation zero-configuration Keyword Driven testing technology in QTP allowing for fast test creation, easier maintenance, and more powerful data-driving capability.
It identifies objects with Unique Smart Object Recognition, even if they change from build to build, enabling reliable unattended script execution.
It collapses test documentation and test creation to a single step with Auto-documentation technology.
It enables thorough validation of applications through a full complement of checkpoints.
2) Suitable for both client server and web based application
3) VB script as the script language
4) Better error-handling mechanism
5) Excellent data driven testing features
6) Operates stand-alone, or integrated into HP Business Process Testing and HP Quality Center.
It introduces next-generation zero-configuration Keyword Driven testing technology in QTP allowing for fast test creation, easier maintenance, and more powerful data-driving capability.
It identifies objects with Unique Smart Object Recognition, even if they change from build to build, enabling reliable unattended script execution.
It collapses test documentation and test creation to a single step with Auto-documentation technology.
It enables thorough validation of applications through a full complement of checkpoints.
How
to handle the exceptions using recovery scenario manager in QTP?
You can instruct QTP to recover
unexpected events or errors that occurred in your testing environment during
test run. Recovery scenario manager provides a wizard that guides you through
the defining recovery scenario.
Recovery scenario has three steps
1) Triggered Events
2) Recovery steps
3) Post Recovery Test-Run
Recovery scenario has three steps
1) Triggered Events
2) Recovery steps
3) Post Recovery Test-Run
What
information does the columns in the Keyword View provide for each step?
As you recorded your test, QTP
generated steps in the Keyword View representing each operation you performed
in the Web browser.
The columns in the Keyword View show different information for each step, as follows:
1) Item: Displays the item for the step (test object, utility object, function call, or statement) in a hierarchical icon-based tree.
2) Operation: The operation to be performed on the item, for example, Click or Select.
3) Value: The argument values for the selected operation, for example, the mouse button to use when clicking the image.
4) Assignment: The assignment of a value to or from a variable so you can use the value later in the test.
5) Comment: Any textual information you want to add regarding the step, for example, Return to page used in first step of the test.
6) Documentation: Auto-documentation of what the step does, in an easy-to-understand sentence, for example, Click the "findFlights" image.
The columns in the Keyword View show different information for each step, as follows:
1) Item: Displays the item for the step (test object, utility object, function call, or statement) in a hierarchical icon-based tree.
2) Operation: The operation to be performed on the item, for example, Click or Select.
3) Value: The argument values for the selected operation, for example, the mouse button to use when clicking the image.
4) Assignment: The assignment of a value to or from a variable so you can use the value later in the test.
5) Comment: Any textual information you want to add regarding the step, for example, Return to page used in first step of the test.
6) Documentation: Auto-documentation of what the step does, in an easy-to-understand sentence, for example, Click the "findFlights" image.
Why
do we use Regular Expressions?
We create a text checkpoint for
searching a specific text string. We can use regular expressions to increase
the flexibility and adaptability of your tests. Regular expressions enable QTP
to identify objects and text strings with varying values.
You can use regular expressions when defining the properties of an object, the methods of an argument, when parameterizing a step, and when creating checkpoints with varying values.
You can use regular expressions when defining the properties of an object, the methods of an argument, when parameterizing a step, and when creating checkpoints with varying values.
The QTP testing process consists of6 main phases: 1) Create your test plan: Prior
to automating there should be a detailed description of the test including the
exact steps to follow, data to be input, and all items to be verified by the
test. The verification information should include both data validations and
existence or state verifications of objects in the application.
2) Recording a session on your application: As you navigate through your application, QTP graphically displays each step you perform in the form of a collapsible icon-based test tree. A step is any user action that causes or makes a change in your site, such as clicking a link or image, or entering data in a form.
3) Enhancing your test:
Inserting checkpoints into your test lets you search for a specific value of a page, object or text string, which helps you identify whether or not your application is functioning correctly.
Checkpoints can be added to a test as you record it or after the fact via the Active Screen. It is much easier and faster to add the checkpoints during the recording process.
Broadening the scope of your test by replacing fixed values with parameters lets you check how your application performs the same operations with multiple sets of data.
Adding logic and conditional statements to your test enables you to add sophisticated checks to your test.
4) Debugging your test: If changes were made to the script, you need to debug it to check that it operates smoothly and without interruption.
5) Running your test on a new version of your application: You run a test to check the behavior of your application. While running, QTP connects to your application and performs each step in your test.
6) Analyzing the test results: You examine the test results to pinpoint defects in your application.
7) Reporting defects: As you encounter failures in the application when analyzing test results, you will create defect reports in Defect Reporting Tool.
2) Recording a session on your application: As you navigate through your application, QTP graphically displays each step you perform in the form of a collapsible icon-based test tree. A step is any user action that causes or makes a change in your site, such as clicking a link or image, or entering data in a form.
3) Enhancing your test:
Inserting checkpoints into your test lets you search for a specific value of a page, object or text string, which helps you identify whether or not your application is functioning correctly.
Checkpoints can be added to a test as you record it or after the fact via the Active Screen. It is much easier and faster to add the checkpoints during the recording process.
Broadening the scope of your test by replacing fixed values with parameters lets you check how your application performs the same operations with multiple sets of data.
Adding logic and conditional statements to your test enables you to add sophisticated checks to your test.
4) Debugging your test: If changes were made to the script, you need to debug it to check that it operates smoothly and without interruption.
5) Running your test on a new version of your application: You run a test to check the behavior of your application. While running, QTP connects to your application and performs each step in your test.
6) Analyzing the test results: You examine the test results to pinpoint defects in your application.
7) Reporting defects: As you encounter failures in the application when analyzing test results, you will create defect reports in Defect Reporting Tool.
What
is parameterizing of Tests?
When you test your application, you
may want to check how it performs the same operations with multiple sets of
data.
For example, you want to check how your application responds to ten separate sets of data. You could record ten separate tests, each with its own set of data.
Alternatively, you can create a parameterized test that runs ten times: each time the test runs, it uses a different set of data.
For example, you want to check how your application responds to ten separate sets of data. You could record ten separate tests, each with its own set of data.
Alternatively, you can create a parameterized test that runs ten times: each time the test runs, it uses a different set of data.
How
to analyze the test results using QTP?
When QTP finishes running the test,
the Test Results window opens. Initially, the Test Results window contains two
panes for displaying the key elements of your test run. # The left pane
displays the results tree, an icon-based view of the steps that were performed
while the test was running. The results tree is organized according to the Web
pages visited during the test run and can be expanded (+) to view each step.
The steps performed during the test run are represented by icons in the tree.
You can instruct QTP to run a test or action more than once using different
sets of data in each run. Each test run is called iteration, and each iteration
is numbered. (The test you ran had only one iteration.) # The right pane
displays the test results details. The iteration summary table indicates which
iterations passed and which failed. The status summary table indicates the
number of checkpoints or reports that passed, failed, and raised warnings
during the test. View the test results for a specific step. In the results
tree, expand (+) Test Recording Summary > Recording Iteration 1 (Row 1) >
Action1 Summary > your application > your test name.
When QTP finishes running the test,
the Test Results window opens. Initially, the Test Results window contains two
panes for displaying the key elements of your test run.
The left pane displays the results tree, an icon-based view of the steps that were performed while the test was running. The results tree is organized according to the Web pages visited during the test run and can be expanded (+) to view each step. The steps performed during the test run are represented by icons in the tree. You can instruct QTP to run a test or action more than once using different sets of data in each run. Each test run is called iteration, and each iteration is numbered. (The test you ran had only one iteration.)
The right pane displays the test results details. The iteration summary table indicates which iterations passed and which failed. The status summary table indicates the number of checkpoints or reports that passed, failed, and raised warnings during the test. View the test results for a specific step. In the results tree, expand (+) Test Recording Summary > Recording Iteration 1 (Row 1) > Action1 Summary > your application > your test name.
The Test Results window now contains three panes, displaying
The results tree, with one step highlighted
The test results details of the highlighted step
The Active Screen, showing a screen capture of the Web page on which the step was performed. When you click a page in the results tree, QTP displays the corresponding page in the application view. When you click a step (an operation performed on an object) in the results tree, the corresponding object is highlighted in the application view. In this case, the Departing From text box is highlighted.
The left pane displays the results tree, an icon-based view of the steps that were performed while the test was running. The results tree is organized according to the Web pages visited during the test run and can be expanded (+) to view each step. The steps performed during the test run are represented by icons in the tree. You can instruct QTP to run a test or action more than once using different sets of data in each run. Each test run is called iteration, and each iteration is numbered. (The test you ran had only one iteration.)
The right pane displays the test results details. The iteration summary table indicates which iterations passed and which failed. The status summary table indicates the number of checkpoints or reports that passed, failed, and raised warnings during the test. View the test results for a specific step. In the results tree, expand (+) Test Recording Summary > Recording Iteration 1 (Row 1) > Action1 Summary > your application > your test name.
The Test Results window now contains three panes, displaying
The results tree, with one step highlighted
The test results details of the highlighted step
The Active Screen, showing a screen capture of the Web page on which the step was performed. When you click a page in the results tree, QTP displays the corresponding page in the application view. When you click a step (an operation performed on an object) in the results tree, the corresponding object is highlighted in the application view. In this case, the Departing From text box is highlighted.
Briefly
tell me about the checkpoints in QTP?
A checkpoint verifies that expected
information is displayed in an application while the test is running. You can
add eight types of checkpoints to your test for standard web objects using QTP.
1) A page checkpoint checks the characteristics of an application
2) A text checkpoint checks that a text string is displayed in the appropriate place on an application
3) An object checkpoint (Standard) checks the values of an object on an application
4) An image checkpoint checks the values of an image on an application
5) A table checkpoint checks information within a table on an application
6) An Accessibility checkpoint checks the web page for statutory compliance.
7) An XML checkpoint checks the contents of individual XML data files or XML documents that are part of your Web application.
8) A database checkpoint checks the contents of databases accessed by your web site
1) A page checkpoint checks the characteristics of an application
2) A text checkpoint checks that a text string is displayed in the appropriate place on an application
3) An object checkpoint (Standard) checks the values of an object on an application
4) An image checkpoint checks the values of an image on an application
5) A table checkpoint checks information within a table on an application
6) An Accessibility checkpoint checks the web page for statutory compliance.
7) An XML checkpoint checks the contents of individual XML data files or XML documents that are part of your Web application.
8) A database checkpoint checks the contents of databases accessed by your web site
In
how many ways we can add checkpoints to an application using QTP?
We can add checkpoints while
recording the application or we can add after recording is completed using
Active screen To perform the second one The Active screen must be enabled while
recording
Explain
the Automation Object Model of QTP in brief?
Essentially all configuration and
run functionality provided via the QTP interface is in some way represented in
the QTP automation object model via objects, methods, and properties. Although
a one-on-one comparison cannot always be made, most dialog boxes in QTP have a
corresponding automation object, most options in dialog boxes can be set and/or
retrieved using the corresponding object property, and most menu commands and
other operations have corresponding automation methods. You can use the
objects, methods, and properties exposed by the QTP automation object model,
along with standard programming elements such as loops and conditional
statements to design your program.
Briefly
explain the QTP Environment.
QTP environment uses the graphical
interface and ActiveScreen technologies - A testing process for creating test
scripts, relating manual test requirements to automated verification features -
Data driving to use several sets of data using one test script.
During recording QTP looks at the
object and stores it as test object. For each test object QTP learns a set of
default properties called mandatory properties, and look at the rest of the
objects to check whether this properties are enough to uniquely identify the
object. During test run, QTP searches for the run time objects that matches
with the test object it learned while recording
No comments:
Post a Comment