Equivalence Partitioning

software-engineering testing

Definition

Equivalence Partitioning

Equivalence Partitioning is a specification-based testing technique that divides the input data of a software unit into partitions of equivalent data from which test cases can be derived.
The fundamental premise is that if one test case in a partition detects a defect, other cases in the same partition would likely detect the same defect.

Identification

A systematic way to identify partitions is to look at:

1. Input Variables: Explore types and ranges of individual inputs (unidimensional partitioning).
2. Interactions: How inputs depend on or constrain each other (multidimensional partitioning).
3. Outputs: Identify all possible types of outputs and work backwards to find inputs that trigger them.

Common Partition Categories

Standard partitions often include:

• Numerical: Ranges (e.g., $<0$, $0$, $>0$).
• Collections/Strings:
  • $P_{null}$: Input is null.
  • $P_{empty}$: Input is empty ($length=0$).
  • $P_{pop}$: Input is populated ($length\ge 1$).
• Objects: Valid vs. Invalid state.

Partition Types

To ensure complete coverage, partitions are categorised into two types:

1. Valid Partitions: Values that should be accepted by the component (represent normal operation).
2. Invalid Partitions: Values that should be rejected by the component (represent error handling/exceptions).

Example

Example: alternateMerge

int[] alternateMerge(int[] arr1, int[] arr2) { /* ... */ }

Specification: Combines two integer arrays by interleaving their elements in alternating order. If one array runs out, the remaining elements of the other are appended. If either array is null, it is treated as empty. Returns a new, non-null array.

• arr1: first integer array, may be null.
• arr2: second integer array, may be null.

1. Input Partitions (Individual Variables): We identify partitions for each array independently:

• $P_{null}$: Input is null.
• $P_{empty}$: Input is [].
• $P_{pop}$: Input is populated ($length\ge 1$).

2. Input Partitions (Interactions): We analyse how the two inputs relate to each other (specifically length, as “running out” is key behaviour):

• $L_1=L_2$: Lengths are equal.
• $L_1>L_2$: First array is longer (append $arr1$ tail).
• $L_1<L_2$: Second array is longer (append $arr2$ tail).
• Validity: Combinations of Null/Empty/Populated (e.g., $P_{null}$ vs $P_{pop}$).

3. Test Cases (Derived): We select representatives that cover the identified partitions and interactions:

ID	arr1	arr2	Partition / Rationale	Expected
T1	null	null	$P_{null}\times P_{null}$ (Both null treated as empty)	[]
T2	[]	[]	$P_{empty}\times P_{empty}$	[]
T3	[1, 2]	[3, 4]	$P_{pop}$, $L_1=L_2$ (Standard Interleave)	[1, 3, 2, 4]
T4	[1, 2, 3]	[4, 5]	$P_{pop}$, $L_1>L_2$ (Append arr1)	[1, 4, 2, 5, 3]
T5	[1, 2]	[3, 4, 5]	$P_{pop}$, $L_1<L_2$ (Append arr2)	[1, 3, 2, 4, 5]
T6	null	[1]	$P_{null}\times P_{pop}$ (Treat null as empty)	[1]

Example: passwordStrength

String passwordStrength(String pwd) { /* ... */ }

Specification: Evaluates password strength based on length and composition. Returns “Weak”, “Medium”, or “Strong”.

• Exceptions: Raises IllegalArgumentException if null or empty.
• Rules:
  • Length < 6: “Weak”.
  • Length >= 6: Check for Digit AND Uppercase.
    • Both: “Strong”.
    • One missing: “Medium”.
    • Both missing: “Weak”.

1. Input Partitions: We break down the input domain based on the specification rules:

• Validity (Pre-condition):
  • $P_{null}$: Input is null.
  • $P_{empty}$: Input is empty string "".
  • $P_{valid}$: Input is a non-empty string.
• Length (if Valid):
  • $P_{short}$: Length < 6.
  • $P_{long}$: Length >= 6.
• Content (if Valid & Long):
  • $C_{none}$: No Digit, No Upper.
  • $C_{digit}$: Digit, No Upper.
  • $C_{upper}$: No Digit, Upper.
  • $C_{both}$: Digit AND Upper.

2. Test Cases (Derived):

ID	Input pwd	Partition / Rationale	Expected Result
T1	null	$P_{null}$	IllegalArgumentException
T2	""	$P_{empty}$	IllegalArgumentException
T3	"abc"	$P_{valid}\cap P_{short}$	"Weak"
T4	"abcdef"	$P_{valid}\cap P_{long}\cap C_{none}$	"Weak"
T5	"1bcdef"	$P_{valid}\cap P_{long}\cap C_{digit}$	"Medium"
T6	"Abcdef"	$P_{valid}\cap P_{long}\cap C_{upper}$	"Medium"
T7	"A1cdef"	$P_{valid}\cap P_{long}\cap C_{both}$	"Strong"

Example: shippingCost

double shippingCost(int weight, String speed) { /* ... */ }

Specification: Computes cost from weight and speed. Throws exception for invalid inputs.

• Weights: $(0,5]\to 5$, $(5,20]\to 10$, $(20,\infty )\to 20$.
• Speed: “standard” ($\times 1$), “express” ($\times 1.5$). case-insensitive.

1. Input Partitions:

• Weight:
  • $P_{inv\_neg}$: $w\le 0$ (invalid)
  • $P_{low}$: $0<w\le 5$ (base 5)
  • $P_{mid}$: $5<w\le 20$ (base 10)
  • $P_{high}$: $w>20$ (base 20)
• Speed:
  • $P_{inv\_speed}$: Invalid (null, empty, unknown).
  • $P_{std}$: “standard” (case-insensitive).
  • $P_{exp}$: “express” (case-insensitive).

2. Test Cases (Derived):

ID	Weight	Speed	Partition / Rationale	Expected Outcome
T1	0	"standard"	$P_{inv\_neg}$ (invalid weight)	IllegalArgumentException
T2	10	null	$P_{inv\_speed}$ (null speed)	IllegalArgumentException
T3	10	"fast"	$P_{inv\_speed}$ (unknown speed)	IllegalArgumentException
T4	2	"standard"	$P_{low}\times P_{std}$	5.0
T5	5	"express"	$P_{low}\times P_{exp}$	7.5
T6	10	"STANDARD"	$P_{mid}\times P_{std}$ (case-insensitive)	10.0
T7	21	"Express"	$P_{high}\times P_{exp}$	30.0