Welcome to the QuickTest Tutorial
Welcome to the QuickTest tutorial. The tutorial is a self-paced guide that
teaches you the basics of testing your application with QuickTest, Mercury
Interactive’s powerful functional testing tool.
QuickTest enables you to test standard Web objects, ActiveX controls, and
Visual Basic controls.
This tutorial will familiarize you with the process of creating and running
automated tests and analyzing the test results.
Note: In addition to tests, QuickTest enables you to create business
components for use in business process tests, if you have Quality Center
with Business Process Testing support installed. The procedures described in
this tutorial are designed for creating tests, but you can also apply the
majority of these procedures to creating business components. For more
information on business components and Business Process Testing, refer to
the QuickTest Professional User’s Guide and the Business Process Testing User’s
Guide.
This introduction describes:
➤ Using This Tutorial
➤ Typographical Conventions
Using This Tutorial
The tutorial is divided into nine short lessons. In each lesson you will create
and run tests on the sample Mercury Tours Web site.
After completing the tutorial, you can apply the skills you have learned to
your own Web site.
Lesson 1, Introducing QuickTest compares automated and manual testing
methods. It introduces the QuickTest testing process and familiarizes you
with the QuickTest user interface and the sample Mercury Tours Web site.
Lesson 2, Recording Tests teaches you how to record a test and provides an
overview of the resulting Keyword View display.
Lesson 3, Running and Analyzing Tests shows you how to run a test and
view the test results.
Lesson 4, Creating Checkpoints explains how to add checkpoints to your
test to verify that information in your Web site is displayed as expected.
Lesson 5, Parameterizing Tests shows you how to parameterize your test so
that you can run it on multiple sets of data.
Lesson 6, Creating Output Values teaches you how to use output parameters
to retrieve data from your Web site.
Lesson 7, Using Regular Expressions teaches you how to create and run a
test using regular expressions.
Lesson 8, Dividing Tests into Multiple Actions explains how to divide your
test into actions so that you can design more efficient and modular tests.
Lesson 9, Where Do You Go from Here? shows you how to get started
testing your own Web site and tells you where you can find more
information about QuickTest.
Typographical Conventions
This book uses the following typographical conventions:
1, 2, 3 Bold numbers indicate steps in a procedure.
➤ Bullets indicate options and features.
> The greater than sign separates menu levels (for
example, File > Open).
Stone Sans The Stone Sans font indicates names of interface
elements (for example, the Run button) and other
items that require emphasis.
Bold Bold text indicates method or function names.
Italics Italic text indicates method or function arguments, file
names in syntax descriptions, and book titles.
<> Angle brackets enclose a part of a file path or URL
address that may vary from user to user (for example,
<MyProduct installation folder>\bin).
Arial The Arial font is used for examples and text that is to
be typed literally.
Arial bold The Arial bold font is used in syntax descriptions for
text that should be typed literally.
... In a line of syntax, an ellipsis indicates that more items
of the same format may be included. In a
programming example, an ellipsis is used to indicate
lines of a program that were intentionally omitted.
[ ] Square brackets enclose optional arguments.
| A vertical bar indicates that one of the options
separated by the bar should be selected.
1
Introducing QuickTest
In this lesson you will learn about the:
➤ Benefits of Automated Testing
➤ Testing Process
➤ QuickTest Window
➤ Mercury Tours Sample Web Site
Benefits of Automated Testing
If you have ever tested applications or Web sites manually, you are aware of
the drawbacks. Manual testing is time-consuming and tedious, requiring a
heavy investment in human resources. Worst of all, time constraints often
make it impossible to manually test every feature thoroughly before the
application is released. This leaves you wondering whether serious bugs
have gone undetected.
Automated testing with QuickTest addresses these problems by dramatically
speeding up the testing process. You can create tests that check all aspects of
your application or Web site, and then run these tests every time your site or
application changes.
As QuickTest runs tests, it simulates a human user by moving the mouse
cursor in a Web page or application window, clicking Graphical User
Interface (GUI) objects, and entering keyboard input; however, QuickTest
does this faster than any human user.
Testing Process
The QuickTest testing process consists of 7 main phases:
1 Preparing to record
Before you record a test, confirm that your application and QuickTest are set
to match the needs of your test.
Make sure your application displays elements on which you want to record,
such as a toolbar or a special window pane, for example, and that your
application options are set as you expect for the purposes of your test.
You should also view the settings in the Test Settings dialog box (Test >
Settings) and the Options dialog box (Tools > Options) to ensure that
QuickTest will record and store information appropriately. For example, you
should confirm that the test is set to use the appropriate object repository
mode.
Mercury Tours Sample Web Site
Mercury Tours is the sample Web application used throughout this tutorial.
It simulates a Web-based flight information and reservation service. You
should familiarize yourself with this application before starting the tutorial.
Optimizing Browser Settings for Your Test
If you are using Internet Explorer as your browser, you should clear the
option to use AutoComplete for user names and passwords for the purposes
of this tutorial. This will ensure that all of your operations are accurately
recorded while creating your tests.
To clear the AutoComplete option:
1 In your Internet Explorer’s menu bar, choose Tools > Internet Options >
Content tab.
2 Click AutoComplete in the Personal information area. The AutoComplete
Settings dialog box opens.
3 In the Use AutoComplete for area, clear the User names and passwords on
forms option.
4 Click OK to save your changes and close the AutoComplete Settings dialog
box, then click OK again to close the Internet Options dialog box.
Using the Mercury Tours Web Site for the First Time
Before you begin recording your tests on the Mercury Tours Web site, you
must register as a user.
To run Mercury Tours:
1 Launch the Mercury Tours application.
In your Web browser, type the following URL:
http://newtours.mercuryinteractive.com
The Mercury Tours home page opens.
2
Recording Tests
As you navigate through your Web site or application, QuickTest records
your steps. These operations are the basis of your test. When you stop
recording, you can see the steps of your newly-created test in a graphical
format in the Keyword View.
In this lesson you will learn about:
➤ Preparing to Record a Test
➤ Recording a Test
➤ Analyzing the Test in the Keyword View
Preparing to Record a Test
Before you begin recording a test, ensure that both your application or Web
site and QuickTest are set to match the needs of your test.
For the purposes of this tutorial, ensure that:
➤ You have registered as a user in the Mercury Tours Web site. For more
information, see “Using the Mercury Tours Web Site for the First Time” on
page 7.
➤ If you are using Internet Explorer as your browser, the AutoComplete option
is cleared for user names and passwords. For instructions, see “Optimizing
Browser Settings for Your Test” on page 7.
➤ All browsers are closed before you begin recording.
Recording a Test
In this section, you will record the process of making a reservation for a
flight from New York to San Francisco on the Mercury Tours Web site.
1 Start QuickTest and open a new test.
➤ If QuickTest is not currently open, choose Start > Programs > QuickTest
Professional > QuickTest Professional.
In the Add-in Manager, confirm that the Web Add-in is selected, and
clear all other add-ins. Click OK to close the Add-in Manager and open
QuickTest.
Note: While QuickTest loads your selected add-ins, the QuickTest splash
screen is displayed. This may take a few seconds.
If the Welcome window opens, click Blank Test.
Otherwise, choose File > New, or click the New button.
A blank test opens.
➤ If QuickTest is already open, check which add-ins are loaded by selecting
Help > About QuickTest Professional. If the Web Add-in is not loaded,
you must exit and restart QuickTest. When the Add-in Manager opens,
select the Web Add-in, and clear all other add-ins.
Choose File > New, or click the New button.
A blank test opens.
Note: If the Add-in Manager does not open when starting QuickTest,
choose Tools > Options. In the General tab, select Display Add-in
Manager on startup. When you exit and restart QuickTest, the Add-in
Manager opens.
Analyzing the Test in the Keyword View
As you recorded your test, QuickTest 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:
➤ Item—Displays the item for the step (test object, utility object, function call,
or statement) in a hierarchical icon-based tree.
➤ Operation—The operation to be performed on the item, for example, Click
or Select.
➤ Value—The argument values for the selected operation, for example, the
mouse button to use when clicking the image.
➤ Assignment—The assignment of a value to or from a variable so you can use
the value later in the test.
➤ Comment—Any textual information you want to add regarding the step, for
example, Return to page used in first step of the test.
➤ Documentation—Auto-documentation of what the step does, in an
easy-to-understand sentence, for example, Click the “findFlights” image.
Note: You can choose to hide or display individual columns as required, by
right-clicking the column heading in the Keyword View and selecting a
column name from the list.
In the Item column of the Keyword View, you can click the branch arrows to
expand or collapse the steps under each Web page. You can expand the
entire test by choosing View > Expand All.
3
Running and Analyzing Tests
When you run your test, QuickTest opens the appropriate application or
Web site and performs each step as it was originally recorded in the test.
When QuickTest finishes running the test, it displays the results of the run.
In this lesson you will learn about:
➤ Running a Test
➤ Analyzing Test Results
Running a Test
In this lesson, you will run the test you recorded in the previous lesson.
1 Start QuickTest and open the Recording test.
If QuickTest is not already open, choose Start > Programs > QuickTest
Professional > QuickTest Professional.
➤ If the Welcome window opens, click Open Existing.
➤ If QuickTest opens without displaying the Welcome window, choose
File > Open or click the Open button.
In the Open Test dialog box, locate and select the Recording test, then click
Open.
4
Creating Checkpoints
In the previous lessons, you created and ran a test checking that a series of
steps performed on the Mercury Tours Web site runs smoothly. A checkpoint
verifies that expected information is displayed in your application while the
test is running.
In this lesson you will learn about:
➤ Understanding Checkpoint Types
➤ Checking Objects
➤ Checking Pages
➤ Checking Text
➤ Checking Tables
➤ Running and Analyzing a Test with Checkpoints
Understanding Checkpoint Types
QuickTest Professional offers the following types of checkpoints:
Checkpoint
Type
Description Example of Use
Standard
Checkpoint
Checks values of an object’s
properties.
Check that a radio button is
selected.
Image
Checkpoint
Checks the property values of
an image.
Check that the image source file
is correct.
Table
Checkpoint
Checks information in a table. Check that the value in a table
cell is correct.
Page
Checkpoint
Checks the characteristics of a
Web page.
Check how long a Web page takes
to load or if a Web page contains
broken links.
Text /
Text Area
Checkpoint
Checks that a text string is
displayed in the appropriate
place in a Web page or
application window.
Check whether the expected text
string is displayed in the expected
location on a Web page or dialog
box.
Bitmap
Checkpoint
Checks an area of a Web page or
application after capturing it as
a bitmap
Check that a Web page (or any
portion of it) is displayed as
expected.
Database
Checkpoint
Checks the contents of
databases accessed by an
application or Web site
Check that the value in a
database query is correct.
Accessibility
Checkpoint
Identifies areas of a Web site to
check for Section 508
compliancy.
Check if the images on a Web
page include ALT properties,
required by the W3C Web
Content Accessibility Guidelines.
XML
Checkpoint
Checks the data content of
XML documents.
Note: XML file checkpoints are
used to check a specified XML
file; XML application checkpoints
are used to check an XML
document within a Web page.
You can add most checkpoints to your test either while recording or
afterward. The following sections explain how to create some of the
checkpoints described above on the test you created in “Recording Tests” on
page 9.
Note: When QuickTest creates a checkpoint, it assigns a name based on
information inside the checkpoint—the checked value, for example. The
checkpoint name remains unchanged, even if you subsequently modify the
information on which it was based. Keep this in mind when looking for
checkpoints displayed in the Keyword View. However, note that QuickTest
may shorten the name displayed in the Keyword View.
For more information on how to create checkpoints, refer to the QuickTest
Professional User’s Guide.
Checking Objects
In this section, you will add a standard checkpoint in the Book a Flight page.
This checkpoint will verify the value in the box containing the first name of
the passenger.
1 Start QuickTest and open the Recording test.
If QuickTest is not already open, choose Start > Programs > QuickTest
Professional > QuickTest Professional.
➤ If the Welcome window opens, click Open Existing.
➤ If QuickTest opens without displaying the Welcome window, choose
File > Open or click the Open button.
In the Open Test dialog box, locate and select the Recording test, then click
Open.
2 Save the test as Checkpoint.
Select File > Save As. Save the test as Checkpoint.
Checking Pages
In this section, you will add a page checkpoint to your test. The page
checkpoint checks that the number of links and images in the page when
you run your test is the same as when you recorded your test.
1 Locate the page where you want to add a page checkpoint.
In the Keyword View, expand (+) Action1 > Welcome: Mercury Tours.
Highlight the Book a Flight: Mercury row in the Keyword View. The page is
displayed in the Active Screen.
2 Create a page checkpoint.
Right-click anywhere in the Active Screen, and choose Insert Standard
Checkpoint. The Object Selection – Checkpoint Properties dialog box opens.
Note that this dialog box may include different elements, depending on
where you click in the Active Screen.
QuickTest adds the page checkpoint to your test. It is displayed in the
Keyword View as a checkpoint operation on the Book a Flight: Mercury
page.
3 Save the test.
Choose File > Save or click the Save button.
Checking Text
In this section, you will add a text checkpoint to your test to check whether
New York is displayed in the Flight Confirmation page.
1 Locate the page where you want to add a text checkpoint.
In the Keyword View, expand (+) Action1 > Welcome: Mercury Tours.
Highlight the Flight Confirmation: Mercury page in the Keyword View. The
page is displayed in the Active Screen.
2 Create a text checkpoint.
In the Active Screen, under “Departing,” highlight the text New York.
Checking Tables
In this section, you will add a table checkpoint to check the cost of the
outbound flight, as displayed in the Book a Flight: Mercury page.
1 Locate the page where you want to add a table checkpoint.
In the Keyword View, expand (+) Welcome: Mercury Tours >
Book a Flight: Mercury.
Highlight the passFirst0 step in the Keyword View. The page is displayed in
the Active Screen.
2 Create a table checkpoint.
In the Active Screen, right-click the price displayed for the first flight (New
York to San Francisco)—270—and choose Insert Standard Checkpoint.
The Object Selection – Checkpoint Properties dialog box opens.
Select WebTable: New York to San Fransisco.
Running and Analyzing a Test with Checkpoints
In this section, you will review your test with checkpoints, run the test, and
analyze the checkpoint results.
1 Expand the test and review your test.
Choose View > Expand All or use the * shortcut key on your number keypad.
5
Parameterizing Tests
When you test your applications, you may want to check how the
application performs the same operations with multiple sets of data. For
example, suppose you want to check how your Web site responds to ten
separate sets of data. You could record ten separate tests, each with its own
set of data. Alternatively, you can create Data Table parameters so that your
test runs ten times, each time using a different set of data.
In this lesson you will learn about:
➤ Defining a Data Table Parameter
➤ Adding Parameter Values to a Data Table
➤ Modifying Steps Affected by Parameterization
➤ Running and Analyzing a Parameterized Test
Defining a Data Table Parameter
In the previous lessons, you reserved a flight from New York to San
Francisco. New York is a constant value, which means that New York is the
departure city each time you run the test. In this exercise you will make the
departure city a parameter so that you can use a different departure city for
each test run.
Click OK to close the dialog box. QuickTest adds the departure parameter to
the Data Table as a new column and inserts New York in the first row under
it. New York will be the first of several departure cities that QuickTest will
use during test runs of the application.
Note the change in the step’s appearance in the Keyword View. Previously,
the step was displayed as fromPort Select New York. Now, the step is
displayed as fromPort Select DataTable(“departure”, DTGlobalSheet). When
you click the Value cell, the following information is displayed, indicating
that the value is parameterized using a Data Table parameter called
departure:
Adding Parameter Values to a Data Table
As you saw, QuickTest displays parameter values in the Data Table. In this
section, you will add two more departure cities to the Data Table, so that
QuickTest can test the application with this data.
1 Enter additional cities in the departure column.
Click row 2 in the departure column and type Portland.
Click row 3 and type Seattle.
Press Enter.
New column in
Data Table
2 Save the test.
Select File > Save or click the Save button.
Modifying Steps Affected by Parameterization
After parameterizing one step in a test, other test objects might be affected
when the value of the parameterized step changes. If so, you must modify
the expected values of those objects to match the value resulting from the
parameterized step. In this section, you will modify the text checkpoint so
that when running the test, QuickTest checks for the text that matches the
current departure city.
1 Locate the text checkpoint to modify.
In the Keyword View, expand (+) Welcome: Mercury Tours.
Right-click Flight Confirmation: Mercury and select Checkpoint Properties.
Running and Analyzing a Parameterized Test
You will now run the modified Parameter test. QuickTest will run the test
three times, once for each departure city in the Data Table. Each test run is
called an iteration.
1 Run the Parameter test.
Click Run on the Testing toolbar or choose Test > Run. The Run dialog box
opens.
Select New run results folder and accept the default results folder name.
Click OK. When the test run is completed, the Test Results window opens.
2 Examine the results summary.
The Test Results window shows that the second and third iterations of the
test failed, even though the text checkpoint passed in all three iterations.
See below for further information about why the iterations failed.
➤ Iteration 2:
In the results tree, expand (+) Parameter Iteration 2 > Action1 Summary
> Welcome Mercury Tours > Flight Confirmation: Mercury.
6
Creating Output Values
In the previous lesson, you created parameters that inserted different data
into each iteration of a test run. You can also retrieve data from your
application and output it to the Data Table, using output values. This data
can then be used at a later stage in the test. QuickTest displays the retrieved
data, following the test run, in the Runtime Data Table.
For example, you can use an output value to verify that the date or flight
number is correctly displayed in two different Web pages, by using the value
obtained in one page as the expected text that QuickTest checks for in the
other page.
In this lesson you will learn about:
➤ Creating an Output Value
➤ Running and Analyzing a Test with Output Values
Creating an Output Value
In the previous lesson, the second and third iterations of your test failed
because the ticket price changed when the departure city changed. The
checkpoint that checked the fare of the outbound flight in the Book a
Flight: Mercury page did not update its expected value as the fare changed.
In this lesson, you will create an output value that retrieves the outbound
fare from the Select a Flight: Mercury page in each test iteration. You will
then modify the table checkpoint you created, so that it checks that the
price displayed in the Book a Flight: Mercury page matches the price
captured in the Select a Flight: Mercury page.
Running and Analyzing a Test with Output Values
You will now run the test and examine the results.
1 Run the Output test.
Click the Run button or choose Test > Run. The Run dialog box opens.
Select New run results folder and accept the default results folder name.
Click OK. When the test run is completed, the Test Results window opens.
2 Examine the run-time data results.
In the Test Results window, select Run-Time Data from the results tree. The
output values used during the test run are displayed in a grid. Note that a
different price is shown in the depart_flight_price column for each
iteration.
3 Examine the checkpoint results.
Choose View > Expand All.
In Output Iteration 1 (Row 1), under the Book a Flight: Mercury page, click
Checkpoint "New York to San Francisco".
7
Using Regular Expressions
In Lesson 4, “Creating Checkpoints,” you created a text checkpoint that
searched for a specific text string. You can use regular expressions to increase
the flexibility and adaptability of your tests.
In this lesson you will learn about:
➤ Regular Expression Syntax
➤ Working with Regular Expressions
➤ Running and Analyzing a Test with Regular Expressions
Regular Expression Syntax
Regular expressions enable QuickTest 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.
A regular expression is a string that specifies a complex search phrase. By
using special characters such as a period (.), asterisk (*), caret (^), and
brackets ([ ]), you define the conditions of the search. For more information
on regular expression syntax, refer to the QuickTest Professional User’s Guide.
Working with Regular Expressions
In this tutorial, you will create a text checkpoint on a date text string that
changes according to the selected flight date. You can define the date as a
regular expression so that the checkpoint checks that the captured text
string matches the expected format, rather than checking the exact text.
To do this, you will create a text checkpoint with a regular expression that
will match any single character within a defined range.
1 Start QuickTest and open the Recording test.
If QuickTest is not already open, choose Start > Programs > QuickTest
Professional > QuickTest Professional.
➤ If the Welcome window opens, click Open Existing.
➤ If QuickTest opens without displaying the Welcome window, choose
File > Open or click the Open button.
In the Open Test dialog box, locate and select the Recording test, then click
Open.
2 Save the test as RegExpression.
Select File > Save As. Save the test as RegExpression.
3 Confirm that the Active Screen option is enabled.
If you do not see the Active Screen at the bottom of the QuickTest window,
click the Active Screen button, or choose View > Active Screen.
4 Select the text for which you will create the checkpoint.
In the Keyword View, expand (+) Welcome: Mercury: Tours and click the
Select a Flight: Mercury page. The page is displayed in the Active Screen.
In the Active Screen, scroll up and highlight the date for the outbound
flight, New York to San Francisco (12/29/2004). Right-click the highlighted
string and select Insert Text Checkpoint. The Text Checkpoint Properties
dialog box opens.
Running and Analyzing a Test with Regular Expressions
In this exercise you will run the test and examine the checkpoint results.
1 Run the RegExpression test.
Click the Run button or choose Test > Run. The Run dialog box opens.
Select New run results folder and accept the default results folder name.
Click OK. When the test run is completed, the Test Results window opens.
2 Examine the checkpoint results.
In the results tree, expand (+) Test RegExpression Summary >
RegExpression Iteration 1 (Row 1) > Action1 Summary >
Welcome: Mercury Tours > Select a Flight: Mercury
Select CheckPoint "[0-1][0-9]/[0-3][0-9]/200[0-9]".
8
Dividing Tests into Multiple Actions
Actions divide your test into logical sections. When you create a new test, it
contains a call to one action. By dividing your tests into calls to multiple
actions, you can design more modular and efficient tests.
In this lesson you will learn about:
➤ Working with Multiple Actions
➤ Creating New Actions
➤ Inserting Existing Actions
➤ Parameterizing an Action
➤ Running and Analyzing a Multi-action Test
Working with Multiple Actions
If you examine one of the tests you created in the previous lessons, you will
see that it can be divided into several distinct processes:
➤ You logged into the Mercury Tours site.
➤ You submitted a flight order.
➤ You logged out.
Assume that you wanted to run your test for five different flight orders. As
we saw in Lesson 5, “Parameterizing Tests”, you could parameterize your test
so that it would run the test five times using five different sets of data. You
can also organize your test so that only the second procedure runs five
times, simulating a single user logging in, ordering five flights, and logging
out. You do this by dividing your test into calls to different actions.
To divide your test into calls to different actions, you can insert a call to a
new action, split an existing action into calls to two actions, insert a call to a
copy of an existing action, or insert a call to an existing action.
You can insert calls to actions into your test during your recording session or
afterwards. Use one of the following menu options or toolbar buttons to add
actions to your test:
➤ Insert > Call to New Action or use the Insert Call to New Action button.
➤ Step > Split Action or use the Split Action button.
➤ Insert > Call to Copy of Action or right-click an action and choose Insert Call
to Copy of Action.
➤ Insert > Call to Existing Action or right-click an action and choose Insert Call
to Existing Action.
Creating New Actions
In this exercise you will create a test and divide it into three action calls.
Recording the Test
1 Start QuickTest and open a new test.
For more information, see step 1 of “Recording a Test” on page 10.
2 Start recording on the Mercury Tours Web site.
In the coming steps, you will record a test similar to the one recorded in the
“Recording Tests” lesson. However, this test is designed slightly differently
to optimize the test for a multi-action test.
Confirm that all Web browsers are closed.
Inserting Existing Actions
When you plan a suite of tests, you may realize that each test requires one or
more identical activities, such as signing in. Once you have created the
action and stored it with one test, you can insert either a call to a copy of
the existing action, or a call to the existing action, into other tests.
When you insert a call to copy of an existing action, you can make changes
to the copied action, and your changes will neither affect, nor be affected
by, any other test. Calls to existing actions, however, are read-only in the
calling test. They can be modified only in the test with which they were
stored. Calls to existing actions enable you to call the same action from
several tests and make it easy to maintain tests, because when your
application changes you only have to update the existing action stored with
the original test.
In the following exercises you will create a new test that is similar to the
ActionA test, except that the Sign_in and ReturnHome actions are external
actions (calls to existing actions stored with other tests) and the FlightOrder
action is slightly modified.
Inserting Calls to Actions
First, you will insert calls to the reusable Sign_in and ReturnHome actions
from ActionA into ActionB.
1 Open a new test.
For more information, see step 1 of “Recording a Test,” on page 10.
2 Insert a call to the Sign_in action.
7 Confirm that the original FlightOrder action was not modified.
Choose File > Open. Browse to ActionA, and click Open.
Expand FlightOrder > Welcome: Mercury Tours > Find a Flight: Mercury.
Note that the change of departure city you made in the ActionB test did not
affect the original action in ActionA (New York is still the departure city in
ActionA).
Parameterizing an Action
If you look at the Data Table at the bottom of the QuickTest window in the
ActionB test, you will see four tabs: Global, Copy of FlightOrder,
Sign_in [ActionA], and ReturnHome [ActionA].
Note: If the Data Table is not displayed, choose View > Data Table to display
it.
The Global tab is a data sheet whose data is used for the entire test. If five
rows of data are displayed in the Global table, the test will run five times. In
addition, you can create data sets for each action, using the relevant action
sheet. If you parameterize a step using an action parameter and enter five
rows of data in the corresponding sheet, then that action will run five times
within each test iteration.
Note: The Sign_in [ActionA] and ReturnHome [ActionA] data sheets are
displayed in gray and cannot be edited because each of these data sheets
belong to the corresponding called action and can be edited from only the
called action’s original test.
Running and Analyzing a Multi-action Test
You will now run the ActionB test. The entire test will run only once, but the
FlightOrder action will run twice; one time for each set of data in the Copy
of FlightOrder data sheet.
1 Run the ActionB test.
Confirm that all Web browsers are closed.
Click Run or choose Test > Run. The Run dialog box opens.
Select New run results folder and accept the default results folder name.
Click OK. When the test run is completed, the Test Results window opens.
2 Examine the test results.
Examine the Results Summary. The test is marked as Done. This indicates
that the test ran without any failures (there were no checkpoints to “pass”).
9
Where Do You Go from Here?
Now that you have completed the exercises in this tutorial, you are ready to
apply the QuickTest concepts and the skills you learned to testing your own
application.
In this lesson you will learn about:
➤ Testing Your Own Application—Getting Started
➤ Getting Additional Information
➤ Documentation Updates
Testing Your Own Application—Getting Started
In this tutorial, you learned about the basic tools needed for testing
applications and Web sites.
We suggest that you follow the procedure outlined below when testing your
own application.
1 Plan your test.
Decide how to organize your test. Consider what users will want to
accomplish when deciding which operations to record. Confirm that your
application and QuickTest are set to match the needs of your test.
No comments:
Post a Comment