1

Department of Master of Computer Applications

LAB MANUAL

SOFTWARE TESTING


TY MCA Sem V

Year: 2013 - 2014









Subject In-charge: Sandesh Patil

2
SUBJECT: Software Testing (ST)
PEOs:
1. Understand role of testing in SDLC
2. Impart knowledge of testing phases in various SDLC models
3. Analyze static testing and dynamic testing
4. Develop skills for understanding, formulating, analyzing and
solving a variety of test case generating techniques
5. Provide knowledge about test organization, planning and
strategies
6. Demonstrate various testing tools
7. Introduce Object Oriented testing techniques

Program Outcomes:
a) Student will have understood role and importance of testing in
SDLC. (1)
b) Acquire knowledge of psychology, general principles, and metrics
of testing. (1)
c) Shall be able to understand the phase of testing in various SDLC
models. (2)
d) Shall be able to identify advantages and limitations of static and
dynamic testing. (3)(4)
e) Shall be able to apply static and dynamic testing techniques on a
given scenario. (4)
f) Shall understand the ways of managing the testing process. (5)
g) Shall acquire ability to solve problems using test scripts. (4)
h) Shall be able to solve problems of testing using testing tools. (6)
i) Shall have knowledge of object Oriented testing techniques. (7)

3
List of Experiments


Sr. No. Name of Experiment
1 Test Case Preparation (Manual)
2 Test Case Preparation (Using JUnit)
3 White Box Testing using Statement
Coverage Method
4 White Box Testing using Branch Coverage
Method
5 White Box Testing using Path Coverage
Method
6 Black Box Testing using Equivalence Class
Partitioning and Boundary Value Analysis
7 Black Box Testing using State Transition
Diagram
8 Introduction to QTP
9 Recording Tests using QTP
10 Running and Analysing Tests
11 Creating Checkpoints
12 Parameterising Tests


4
Practical no.: 1
Title:
Test Case Preparation (Manual)
Aim:
To perform unit testing for a simple calculator program
Description:
Unit/Component test verifies whether each software component performs correctly according to its
specification.
Within the first test level (unit testing), the software units that had been implemented just prior to the
programming phase are tested systematically for the first time. The main attribute of unit testing is the
following: the software components are tested individually and isolated from all other software
components of the system. The isolation is necessary to prevent external influences on components.
If testing detects a problem, it is definitely a problem originating from the component under test itself.
The most important task of component testing is to guarantee that the particular test object executes
its entire functionality correctly and completely, as required by the specification. Here functionality
means the input/output behaviour of the test object. In order to check the correctness and
completeness of the implementation, the component is tested with a series of test cases, where each
test case covers a particular input/output combination.
Test cases:

Sr.
No.
Test
ID
Test Case Test Description Input
Data
Expected Result Actual
Result
1 1.1

2 1.2



8 4

9 5




Term Explanation
Test ID a unique ID for the test case
Test Case name of the test case
Test Description brief description of the test
Input Data data required for the execution of the test case
Expected Result the result that is expected, according to the specification, after execution
of the test case
Actual Result the actual result after the test case execution


Write a simple calculator program in Java to perform the following operations:
1. Addition
2. Subtraction
3. Multiplication
4. Division
5. Integer Modulo Division


5
Practical No.: 2
Title:
Test Case Preparation (Using JUnit)
Aim:
To perform unit testing for a simple calculator program using JUnit
Description:
JUnit is a unit testing framework for the Java programming language. JUnit has been important in the
development of test-driven development, and is one of a family of unit testing frameworks collectively
known as xUnit that originated with SUnit. JUnit is linked as a JAR at compile-time; the framework
resides under packages junit.framework for JUnit 3.8 and earlier and under org.junit for JUnit
4 and later.
Writing a test case:
Each test method will correspond to one test case. Test methods must be annotated by the @Test
annotation.
For example:
import org.junit.*;
public class Tester
{

@Test
public void test() {
assertTrue(true);
}

}

Compiling and Running:
Compile:
prompt> javac -cp .;"<Complete path to JUnit .jar file>"
<file_name>.java
Execute:
prompt> java -cp .;"<Complete path to JUnit .jar file>"
org.junit.runner.JUnitCore <file_name>

Write JUnit test cases for the Simple Calculator program developed in Practical #1.

6
Practical No.: 3
Title:
White Box Testing using Statement Coverage Method
Aim:
To perform White Box testing of given programs using statement coverage method
Description:
Statement coverage focuses on each statement of the test object. The test cases shall execute a
predefined minimum quota or even all statements of the test object. The first step is to translate the
source code into a control flow graph. The graph makes it easier to specify in detail the control
elements that must be covered. In the graph, the statements are represented as nodes and the
control flow between the statements are represented as edges (connections). If sequences of
unconditional statements appear in the program fragment, then they are illustrated as one single
node, because execution of the first statement of the sequence guarantees that all following
statements will be executed. Conditional statements (IF, CASE) and loops (WHILE, FOR) have more
than one edge going out from them.
After execution of the test cases it must be verified which of the statements have been executed.
When the previously defined coverage level has been achieved, the test is considered to be sufficient
and will therefore be terminated.
Example:
Consider the control flow graph given below:

In the example, all statements (all nodes) can be reached by a single test case. In this test case the
edges of the graph must be traversed in the following order:
a, b, f, g, h, d, e
7
One test case is enough.
After traversing the edges in this way, all statements have been executed once. Other combinations
of edges of the graph can also achieve complete coverage. But, the cost of testing should always be
minimized, which means reaching the goal with the least possible number of test cases.


Apply Statement Coverage Method on the following programs:
1. calculate_price(double baseprice, double specialprice, double
extraprice, int extras, double discount)
{
double addon_discount, result;
if(extras >= 3) addon_discount = 10;
else if(extras >= 5) addon_discount = 15;
else addon_discount = 0;
if(discount > addon_discount)
addon_discount = discount;
result = baseprice / 100.0 * (100 - discount)
+ specialprice +
extraprice / 100.0 * (100 - addon_discount);
return result;
}


2. begin
int a, b, c, n;
a = 1;
b = 1;
input(n);
if(n < 0)
n = -n;
output(a);
output(b);
while(n > 0) {
c = a + b;
output(c);
a = b;
b = c;
n--;
}
end


3. begin
int num, product, power;
bool done;
product = 1;
input(done);
while(!done) {
input(num);
product = product * num;
input(done);
}
output(product);
end


8
Practical No.: 4
Title
White Box Testing using Branch Coverage Method
Aim:
To perform White Box testing of given programs using branch coverage method
Description:
A more advanced criterion for white box testing is branch coverage of the control flow graph; for
example, the edges in the graph are the center of attention. The execution of each statement is not
considered, but rather the execution of decisions. The result of the decision determines which
statement is executed next. Testing should make sure every decision is executed with both possible
outcomes (TRUE and FALSE decision coverage is another name for this criterion). Empty ELSE-
parts are considered.
Thus, contrary to statement coverage, for branch coverage it is not interesting if, for instance, an IF-
statement has no ELSE-part. It must be executed anyway. Branch coverage requires the test of every
decision outcome: both THEN and ELSE in the IF-statement; all possibilities for the CASE-statement
and the fall-through case; for loops, both execution of the loop body, i.e., and the bypassing of the
loop body and a return to the beginning of the loop.
Example:
Consider the control flow graph given below:


9
The possible paths are:
1. a, b, c, d, e
2. a, b, f, g, i, g, h, d, e
3. a, k, e
These test cases result in a complete coverage of the edges of the control flow graph. With that, all
possible branches of the control flow in the source code of the test object have been tested.
Some edges have been executed more than once. This seems to be redundant, however, it cannot
always be avoided. In the example, the edges a and e are executed in every test case because there
is no alternative to these edges.

Apply Branch Coverage Method on the following programs:
1. calculate_price(double baseprice, double specialprice, double
extraprice, int extras, double discount)
{
double addon_discount, result;
if(extras >= 3) addon_discount = 10;
else if(extras >= 5) addon_discount = 15;
else addon_discount = 0;
if(discount > addon_discount)
addon_discount = discount;
result = baseprice / 100.0 * (100 - discount)
+ specialprice +
extraprice / 100.0 * (100 - addon_discount);
return result;
}


2. begin
int a, b, c, n;
a = 1;
b = 1;
input(n);
if(n < 0)
n = -n;
output(a);
output(b);
while(n > 0) {
c = a + b;
output(c);
a = b;
b = c;
n--;
}
end


3. begin
int num, product, power;
bool done;
product = 1;
input(done);
while(!done) {
input(num);
product = product * num;
input(done);
}
output(product);
end

10
Practical No.: 5
Title:
White Box Testing using Path Coverage Method
Aim:
To perform White Box testing of given programs using path coverage method
Description:
Path coverage requires the execution of all different paths through the test object. A path describes
the possible order of single program parts in a program fragment. Contrary to this, branches are
viewed independently, each for itself. The paths consider dependencies between the branches, as
with loops for example, at which one branch leads back to the beginning of another branch.
If there are loops in the source code, then every possible number of repetitions is counted as one
possible path through the program fragment. 100% path coverage is not feasible in a program
containing loops. Thus only a limited number of looping possibilities are considered during testing.
Example:
Consider the control flow graph given above:
The possible paths are:
1. a, k, e
2. a, b, c, d, e
3. a, b, f, g, h, d, e
4. a, b, f, g, i, g, h, d, e
5. a, b, f, g, i, g, i, g, h, d, e
6. a, b, f, g, i, g, i, g, i, g, h, d, e
7. a, b, f, g, i, g, i, g, i, g, i, g, h, d, e
8. etc.
11
Thus there is an indefinite number of paths in the control flow graph.

Apply Path Coverage Method on the following programs:
1. calculate_price(double baseprice, double specialprice, double
extraprice, int extras, double discount)
{
double addon_discount, result;
if(extras >= 3) addon_discount = 10;
else if(extras >= 5) addon_discount = 15;
else addon_discount = 0;
if(discount > addon_discount)
addon_discount = discount;
result = baseprice / 100.0 * (100 - discount)
+ specialprice +
extraprice / 100.0 * (100 - addon_discount);
return result;
}


2. begin
int a, b, c, n;
a = 1;
b = 1;
input(n);
if(n < 0)
n = -n;
output(a);
output(b);
while(n > 0) {
c = a + b;
output(c);
a = b;
b = c;
n--;
}
end


3. begin
int num, product, power;
bool done;
product = 1;
input(done);
while(!done) {
input(num);
product = product * num;
input(done);
}
output(product);
end


12
Practical No.: 6
Title:
Black Box Testing using Equivalence Class Partitioning and Boundary Value Analysis
Aim:
To perform Black Box Testing of given programs using Equivalence Class Partitioning and Boundary
Value Analysis
Description:
Equivalence Class Partitioning
The domain of possible input data element is divided into equivalence classes. An equivalence class
is a group of data values where tester assumes that the test object processes them in the same way.
The test of one representative of the equivalence class is seen as sufficient because it is assumed
that for any other input value of the same equivalence class the test object will not show a different
reaction or behavior. Besides equivalence classes for correct input, those for incorrect input values
must be tested as well.
Systematic derivation of the test cases
For every input data element that should be tested the domain of all possible inputs should be
determined. This domain is then partitioned into equivalence classes. First, the subdomain of correct
inputs is found. The test object should process these values according to the specification. The values
outside of this domain are seen as equivalence classes with incorrect input values. For these values
as well, it must be tested how the test object behaves.
Further partitioning of the equivalence classes
If the test object's specification tells that some elements of equivalence classes are processed
differently, they should be assigned to a new (sub)equivalence class. The equivalence classes should
be divided until each different requirement corresponds to an equivalence class. For every single
equivalence class, a representative value should be chosen for testing.
Boundary Value Analysis
Faults often appear at the boundaries of equivalence classes. This happens because boundaries are
often not defined clearly or programmers misunderstand them. A test with boundary values usually
discovers failures. The technique can only be applied if the set of data, which is in one equivalence
class, has identifiable boundaries.
On every border, the exact boundary value and both nearest adjacent values (inside and outside the
equivalence class) are tested. Thereby the minimal possible increment in both directions should be
used. For floating point data this can be the defined tolerance. Therefore, three test cases result from
every boundary. If the upper boundary of one equivalence class equals the lower boundary of the
adjacent equivalence class, then the respective test cases coincide as well.
In many cases there does not exist a real boundary value because the boundary value belongs to
another equivalence class. In such cases it can be sufficient to test the boundary with two values: one
value, which is just inside of an equivalence class, and another value, that is just outside an
equivalence class.
Apply Equivalence Class Partitioning and Boundary Value Analysis on the following program.
Write a program that takes as input name, age, and weight of a person.
String name;
int age;
double weight;


13
The name should not be more 20 characters long.

Age will be classified as follows
If 0 <= age < 13 output: Child
If 13 <= age < 20 output: Teenager
If 20 <= age < 60 output: Adult
If 60 <= age <= 120 output: Senior Citizen

Weight will be classified as follows
If 0 <= weight < 50 output: Light weight
If 50 <= weight < 75 output: Medium
If 75 <= weight output: Heavy Weight

The program will print the name; child, teenager, adult, or senior citizen according to age; and light
weight, medium, or heavy weight according to weight.


14
Practical No.: 7
Title:
Black Box Testing using State Transition Diagram
Aim:
To perform Black Box Testing of Stack program using State Transition Diagram
Description:
In many cases, not only the current input, but also the history of execution or events or inputs,
influences the outputs and how the test object will behave. To illustrate the dependence on history,
state diagrams are used. They are the basis for designing the test (state transition testing).
The system or test object starts from an initial state and can then come into different states. Events
trigger state transitions where an event normally is a function invocation. State transitions can involve
actions. Besides the initial state, the other special state is the end-state. Finite state machines, state
diagrams, or state transition tables model this behavior.
In state transition testing the test object can be a complete system with different system states, as
well as a class in an object-oriented system with different states. Whenever the history leads to
differing behavior, a state transition test must be applied.
Test criteria
A state transition test should execute all specified functions of a certain state at least once. The
compliance between the specified and the actual behavior of the test object can thus be checked.
In order to identify the necessary test cases, the finite state machine is transformed into a transition
tree, which includes certain sequences of transitions. The cyclic state transition diagram with
potentially infinite sequences of states changes to a transition tree, which corresponds to a
representative number of states without cycles. In doing this translation, all states must be reached
and all transitions of the transition diagram must appear.
The transition tree is built from a transition diagram in the following way:
1. The initial or start state is the root of the tree.
2. For every possible transition from the initial state to a following state in the state transition
diagram, the transition tree receives a branch from its root to a node, representing this next
state.
3. The process for step 2 is repeated for every leaf in the tree (every newly added node) until
one of the following two end-conditions is fulfilled:
o The corresponding state is already included in the tree on the way from the root to the
node. This end condition corresponds to one pass of a cycle in the transition diagram.
o The corresponding state is a final state, and therefore has no further transitions to be
considered.
Wrong usage of the functions
The reaction of the state machine for wrong usage must be also be checked, which means that
functions are called in states in which they are not supposed to be called. This is a test of robustness
to verify how the test object reacts upon incorrect use. Thus, it is tested whether unexpected
transitions may appear.
The transition tree should be extended by including a branch for every function from every node. This
means that from every state, all the functions should be executed or at least attempted to be
executed.


15
Apply State Transition Testing on a stack program. The stack can adopt three different states: an
empty stack, a filled stack, and a full stack.
The stack is "empty" after initializing where the maximum height (Max) is defined (current height = 0).
By adding an element to the stack (call of the function push), the state changes to "filled" and the
current height is incremented. In this state further elements can be added (push, increment height), as
well as withdrawn (call of the function pop, decrement height). The uppermost element can also be
displayed (call of the function top, height unchanged). Displaying does not alter the stack itself and
therefore does not remove any element. If the current height is one less than the maximum (height =
Max 1) and one element is added to the stack (push), then the state of the stack changes from
"filled" to "full". No further element can be added. If one element is removed (pop) while the stack is in
the state "full", the state is changed back from "full" to "filled". A state transition from filled to empty
happens only if the stack consists of just one element which is removed (pop). The stack can only be
deleted in the state "empty".


Figure: State diagram of a stack



16
Practical No.: 8
Title:
Introducing QuickTest
Aim:
To study Mercury QuickTest Professional tool
Description:
Benefits of Automated Testing
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.
Benefits of Automated Testing
Fast QuickTest runs tests significantly faster
than human users.
Reliable Tests perform precisely the same
operations each time they are run, thereby
eliminating human error.
Repeatable You can test how the Web site or
application reacts after repeated execution
of the same operations.
Programmable You can program sophisticated tests that
bring out hidden information.
Comprehensive You can build a suite of tests that covers
every feature in your Web site or
application.
Reusable You can reuse tests on different versions
of a Web site or application, even if the
user interfaces changes.
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.
2. Recording a session on your application
As you navigate through your application or Web site, QuickTest graphically displays each step
you perform as a row in the Keyword View. A step is any user action that causes or makes a
change in your application, 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 determine whether your application or site is
functioning correctly.
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.
17
Adding logic and conditional or loop statements enables you to add sophisticated
checks to your test.
4. Debugging your test
You debug a test to ensure that it operates smoothly and without interruption
5. Running your test
You run a test to check the behavior of your application or Web site. While running, QuickTest
opens the application, or connects to the Web site, 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
If you have Quality Center installed, you can report the defects you discover to a database. Quality
Center is Mercury Interactives software test management tool.
QuickTest Window
The image below shows a QuickTest window as it would appear after you record a test, with all
toolbars and panes (except the Debug Viewer pane) displayed:


18
Practical No.: 9
Title:
Recording Tests using QTP
Aim:
To record tests using QTP
Description:
Recording Tests using QTP
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
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. If the Welcome window opens,
click Blank Test. Otherwise, choose File > New, or click the New button. A blank test opens.
2. Start recording on the Mercury Tours Web site
Choose Test > Record or click the Record button. The Record and Run Settings dialog box
opens.

Set the options as shown in the above figure and click OK.
3. Log in to the Mercury Tours Web site
In the User Name and Password boxes, type tutorial for both name and password, and click
on Sign-In. The Flight Finder page opens.
4. Enter flight details
Change the following selections:
Departing From: New York
On: Dec 29
Arriving In: San Francisco
Returning: Dec 31
Service Class: Business class
Click CONTINUE to accept the other default selections. The Select Flight page opens.
19
5. Select a flight
Click CONTINUE to accept the default flight selections. The Book a Flight page opens.
6. Enter required passenger and purchase information
Enter the required information (fields with red text labels) in the Passengers and Credit Card
sections. (You may enter fictitious information.)
In the Billing Address section, select Ticketless Travel. At the bottom of the page, click
SECURE PURCHASE. The Flight Confirmation page opens.
7. Review and complete your booking
Click BACK TO HOME. The Mercury Tours home page opens.
8. Stop recording
In QuickTest, click Stop on the Testing toolbar to stop the recording process.
You have now reserved an imaginary business class ticket from New York to San Francisco.
QuickTest recorded your Web browser operations from the time you clicked the Record
button until you clicked the Stop button.
9. Save your test
Select File > Save or click the Save button. The Save dialog box opens to the Tests folder.
Create a folder named Tutorial, select it, and click Open. Type Recording in the File name
field.
Confirm that Save Active Screen files is selected.
Click Save. The test name (Recording) is displayed in the title bar of the main QuickTest
window.


20
Practical No.: 10
Title:
Running and Analysing Tests
Aim:
To run and analyse tests using QTP
Description:
Running a Test
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. Confirm that all images are saved to the test results
QuickTest allows you to determine when to save images to the test results. In this lesson, all
images should be saved to the test results.
Choose Tools > Options and select the Run tab. In the Save step screen capture to test
results option, select Always.
Click OK to close the Options dialog box.
3. Start running your test
Click Run or choose Test > Run. The Run dialog box opens.
Select New run results folder. Accept the default results folder name. Click OK to close the
Run dialog box.
Analyzing Test Results
When QuickTest 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 QuickTest to run a test or
action more than once using different sets of data in each run. Each test run is called an
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.
Your test run succeeded because QuickTest was able to navigate the Mercury Tours site just as the
test was originally recorded. In this section, you will inspect the steps QuickTest performed when
running your test, and how the application window appeared when a step was performed.



21
Practical No.: 11
Title:
Creating Checkpoints
Aim:
To create checkpoint using QTP
Description:
Understanding Checkpoint Types
QuickTest Professional offers the following types of checkpoints:
Checkpoint
Type
Description Example of Use
Standard
Checkpoint
Checks values of an objects
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.

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.
2. Save the test as Checkpoint
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.
22
4. Locate the page where you want to add a standard checkpoint
5. Create a standard checkpoint
In the Active Screen, right-click the First Name box and choose Insert Standard Checkpoint.
The Object Selection Checkpoint Properties dialog box opens.

Confirm that WebEdit: passFirst0 is highlighted, and click OK.
The Checkpoint Properties dialog box opens.

The first name is entered in the First Name box when the passFirst0 Set... step is performed.
Therefore, in the Insert statement area of the Checkpoint Properties dialog box, select After
current step. This inserts the checkpoint after the passFirst0 Set... step in which the first name
is entered.
Accept the rest of the settings as default and click OK. QuickTest adds a standard checkpoint
step to your test below the selected step.




23
6. Save the test
In a similar manner, create the following checkpoints:
Page
Text
Table
Running and Analyzing a Test with Checkpoints
1. Expand the test and review your test
Choose View > Expand All or use the * shortcut key on your number keypad. The Keyword
View displayed is similar to the following:


2. Start running your test
3. View the test results
When QuickTest finishes running the test, the Test Results window opens. The test result
should be Passed, indicating that all checkpoints passed. If one or more checkpoints had
failed, the test result would be Failed.
4. View the results of the page checkpoint
In the results tree, expand (+) Checkpoint Iteration 1 (Row 1) > Action1 Summary > Welcome:
Mercury Tours > Book a Flight: Mercury.
Highlight Checkpoint Book a Flight: Mercury.
In the Details pane, you can review the details of the page checkpoint, which lists the items
checked.
24
The checkpoint passed because the actual values of the checked properties match the
expected values.

5. View the results of the table checkpoint
6. View the results of the standard checkpoint
7. View the results of the text checkpoint
8. Close the Test Results window


25
Practical No.: 12
Title:
Parameterising Tests
Aim:
To parameterise tests using QTP
Description:
Defining a Data Table Parameter
1. Start QuickTest and open the Checkpoint test
2. Save the test as Parameter
3. Confirm that the Active Screen option is enabled
4. Confirm that the Data Table option is enabled
If you do not see the Data Table at the bottom of the QuickTest window, click the Data Table
button, or choose View > Data Table.
5. Select the text to parameterize
In the Keyword View, expand (+) Action1 > Welcome: Mercury Tours > Find a Flight: Mercury.
In the fromPort row in the Keyword View, click in the Value cell and then click the
parameterization icon . The Value Configuration Options dialog box opens.

6. Set the parameterization properties
Select the Parameter radio button. This lets you replace the constant value (New York) with a
parameter.
Confirm that the DataTable option is selected. This means that the value of the parameter will
be taken from the QuickTest Data Table.
The Name box is enabled and displays p_Item. Change this to departure.
26

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.

Adding Parameter Values to a Data Table
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.
2. Save the test
Modifying Steps Affected by Parameterization
1. Locate the text checkpoint to modify
In the Keyword View, expand (+) Welcome: Mercury Tours.
Right-click Flight Confirmation: Mercury and select Checkpoint Properties. The Text
Checkpoint Properties dialog box opens.
27

2. Parameterize the text checkpoint
In the Checked Text area, New York is displayed in the Constant box. New York is the
expected value for the checkpoint for every iteration.
Select Parameter and click the Parameter Options button. The Parameter Options dialog box
opens.

In the Name box, select departure. This instructs the checkpoint to use the departure
parameter values in the Data Table for the expected results.
Click OK to close the Parameter Options dialog box, and then click OK again to close the Text
Checkpoint Properties dialog box. The checkpoint is now parameterized.
3. Save the test
28
Running and Analyzing a Parameterized Test
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
3. Close the Test Results window