Testcover.com Testcover.com
Tutorial - Equivalence Partitioning -
HTML Form Example

Home
Existing User Login
Brochure
Sign up for Risk-Free Trial
About Testcover.com
Frequently Asked Questions
Tutorial with Examples
->Equivalence Partitioning
--->HTML Form Example
--->Functional Dependence
----->Temperature Example
----->Calendar Example
----->Fixed Values Procedure
--->Shopping Cart Example
----->Seq. Unit Replay Design
->UML State Machines
--->Shopping Cart Example
--->Thermostat Example
->Definitions of Terms
Performance
WSDL Interface
Background
Partners
Registrations
Contact Information

Most of the examples in this tutorial make use of equivalence partitioning, a technique for separating test factor values into classes for equivalent expected results. For example, test inputs for a program that converts Celsius temperatures to Fahrenheit has two partitions, one for valid input temperatures, like 100 oC, and an invalid partition for inputs below absolute zero, like -300 oC. Inputs from the first partition are converted to Fahrenheit temperatures according to the formula [oF] = [oC] • 9/5 + 32. Inputs from the second partition are required to give an exception result (and not use the formula). The partitions divide the inputs according to their different classes of results. And all inputs from the same partition are expected to give equivalent results.

Organizing test factor values into into equivalence classes provides a framework for test planning, which can help to avoid omissions and to identify test cases at the boundaries between partitions. In pairwise testing it is important not to mix test cases from different partitions together. If test cases from different classes of results are combined into one partition, some classes may not be covered by all pairs of test values. The following example illustrates this point. It also illustrates two common characteristics of complex systems: (1) Partitions with multiple test factors are multidimensional, and (2) there can be several different classes of normal results.

The design-your-burger application uses inputs from an HTML form so that a user can order a burger just the way he wants it prepared. The form looks like this:

The objective is to test the action of the form (ordering a burger) with all pairs of input values. There are several inputs as follows. (In this table none means no input value is provided.)

Input NameInput TypeInput Values
Burgermenu beef turkey veggie
Cookedradio none rare medium well
Cheesecheckbox no yes
Lettucecheckbox no yes
Tomatocheckbox no yes
Onioncheckbox no yes
Ketchupcheckbox no yes
Mustardcheckbox no yes
Mayocheckbox no yes
Secret saucecheckbox no yes
Resetreset none reset
Submitsubmit none submit
Nutrition factslink none click
About the cheflink none click
To start, the tester associates each input from the form with a test factor. Most of the inputs specify data about the burger, and the submit button is the trigger to start processing. However some of these inputs lead to results which are not equivalent: They do not order a burger. The reset button clears the form, and the links go to other pages.

The tester wants to verify that the submit button and resulting processing work correctly in this partition. Inputs from the reset button and the links should not be included because they do not lead to the intended result. If all the inputs are placed into the same partition, some of the input value pairs might not test the action of the form. Instead they will be reset, or they will be lost going to other pages. The reset button and links can be tested of course, but their inputs belong in different partitions because their expected results are not equivalent to ordering a burger.

There are 10 test factors with values as follows.

Test FactorNumber of ValuesTest Factor Values
1.Burger3 beef turkey veggie
2.Cooked4 none rare medium well
3.Cheese2 no yes
4.Lettuce2 no yes
5.Tomato2 no yes
6.Onion2 no yes
7.Ketchup2 no yes
8.Mustard2 no yes
9.Mayo2 no yes
10.Secret sauce2 no yes
The reset button and link inputs are not used in this partition, but the submit button input is required in every test case. It triggers the action of the form after all the other input values are set. There is only one value (submit) that leads to the expected result, so the submit input is a single-value factor. Including single-value factors in generator requests is optional. A factor with one value can always be appended to the results, and it will be paired with all the other values in the test cases. Thus, the choice to include a single-value factor is one of convenience or clarity. In this example, clicking the submit button is implied.

The test case generator request is given below.
Design-your-burger form inputs
Burger
Cooked
Cheese
Lettuce
Tomato
Onion
Ketchup
Mustard
Mayo
Secret sauce
#
beef turkey veggie
none rare medium well
no yes
no yes
no yes
no yes
no yes
no yes
no yes
no yes

The results table follows.

#1.
Test
Case ID
Burger Cooked Cheese Lettuce Tomato Onion Ketchup Mustard Mayo Secret sauce Combo
Countdown
3 Values4 Values2 Values2 Values2 Values2 Values2 Values2 Values2 Values2 Values236
1turkeywellyesyesnoyesnononoyes191
2veggienoneyesnoyesnoyesyesyesno146
3beefrarenoyesnoyesyesnoyesno110
4turkeymediumnonoyesyesyesyesyesyes83
5beefnonenononononononoyes59
6veggierareyesnoyesnonoyesnoyes43
7veggiemediumyesyesnonononoyesno29
8beefwellnonoyesnoyesyesyesyes19
9turkeyrarenoyesyesnoyesnonono12
10turkeynoneyesyesnoyesnoyesnono7
11veggiewellnoyesnoyesyesnoyesno3
12beefmediumyesyesyesyesnononoyes0

<Database Table Example Temperature Conversion Example>

Copyright © 2003-2017 Testcover.com, LLC. All rights reserved.