S O F T WA R E T E S T I N G & Q U A L I T Y A S SU R A NC E
S ESS I ON 2
Input Space Partitioning
& Mutation Testing
Designing effective test cases through partitions, boundaries, and faults
Attendance is determined by an in-class quiz at the end of the session.
Take notes carefully to answer correctly.
◉ Equivalence Partitioning • Boundary Value Analysis • Base Choice Coverage
◉ Mutation Testing • Mutation Killing • BVA + Mutation Connection
◉ Hands-On Exercise with REQ-04: Borrow Book
Instructors:
Theory: Dr. Trần Trung Chuyên | chuyentt@[Link] | 0983.448.779 Lab: MSc. Kiều Quốc Việt
Software Testing & Quality Assurance | Session 2 | Input Space Partitioning & Mutation Testing
Why do we need Input Partitioning? ∞
Exhaustive testing – When comprehensive testing becomes impossible
“The input space is, to all practical purposes, infinite.” — Textbook Ch.2 §2.4
// A very basic function Each parameter is a 32-bit integer
232 = 4,294,967,296 values / parameter
int average(int a, int b, int c) {
return (a + b + c) / 3; 3 parameters → Total test cases
} (232)3 = 296 scenarios
// Only 3 lines of code... but how many tests?
If running 1 million tests/second
≈ 2.5 × 1015 years (millions of times the age of the universe)
The Input Space is INFINITE → Exhaustive testing = IMPOSSIBLE
→ We can't test everything. So how do we test smarter?
This is exactly why we need Input Space Partitioning.
Software Testing & Quality Assurance | Session 2 | Input Space Partitioning & Mutation Testing
From Theory to Practice: REQ-04 {}
Borrow Book – Where every business rule becomes a test partition
// REQ-04: Borrow Book A book borrowing limit requirement
Max 3 books / member
bool borrowBook(Member m, Book b) { borrowCount < 3 → valid | ≥ 3 → reject
if ([Link] == "suspended") throw Error;
if ([Link] == "expired") throw Error; Reason for rejection (must be as expected)
if (![Link]) throw Error; suspended ≠ expired ≠ unavailable ≠ limit
4 distinct error messages → 4 partitions to test
if ([Link] >= 3) throw Error;
return true;
Prerequisites
}
[Link] == true + 14-day loan
// 4 conditions → 4 rejection paths → How many partitions? available → borrow | not available → reject
Every condition is a partition. Every boundary hides a bug.
This is your SUT. Can you find ALL the partition?
Let’s apply Input Space Partitioning to a real requirement.
Software Testing & Quality Assurance | Session 2 | Input Space Partitioning & Mutation Testing
IDM – Input Domain Model ≡
The systematic framework for organizing test design
Requirement → Characteristic → Partition → Test Case
Example: Email Without IDM
Characteristic: Email input (formart, structure, content, length) → random testing
Partitions: valid / invalid / empty Test cases depend on experience, mood, who’s testing
Will 2 testers design the same tests?
So before we talk about Equivalence Partitioning or Boundary Value Analysis, we must agree on one thing:
IDM is not a test case. It’s a way of thinking.
Testing is a modeling activity.
“An input domain model (IDM) represents the input space of the system under test in an abstract way.” — Textbook Ch.6 §6.1
Software Testing & Quality Assurance | Session 2 | Input Space Partitioning & Mutation Testing
SPECIAL INSIGHT • USI NG AI EF FECT IV ELY
Working Smart with AI: Think → Ask → Refine
A simple framework to keep YOU in charge of the thinking — and let AI accelerate the work.
Today: apply it to Input Domain Modeling. Next time: same framework, new topic.
1 THINK 2 ASK 3 REFINE
Own the problem first Prompt with precision Verify and improve
• Define the real goal — what are • Give context: role, goal, • Read critically — check facts, logic,
you actually trying to solve? constraints, audience. code.
• List what you know vs. what you • Show examples of the output you • Test it on real inputs, edge cases
don’t. want. included.
• Sketch the approach in your own • Ask one thing at a time — small, • Iterate: refine the prompt, not just
words before typing a prompt. testable steps. the answer.
• Rule: No prompt until you can • Rule: A vague prompt gives a vague • Rule: You own the output. AI is the
explain the problem to a friend. answer. draft, you are the author.
AI is a force multiplier, not a substitute for your thinking.
If you use AI as an assistant → you save time.
If you use AI as a force multiplier → you outperform the rest.
Software Testing & Quality Assurance • Special Insight Slide
Equivalence Partitioning ≈
Group inputs that behave the same – test one from each group
Core Idea Example: borrowCount
Inputs in the same partition produce equivalent behavior <3 → valid
→ Only need ONE representative per partition ≥3 → invalid
How to apply EP
• Identify each input parameter
• Divide into valid & invalid partitions
• Pick ONE value from each partition
• Design test case with that representative
EP reduces test count dramatically – without losing coverage!
From 296 scenarios down to a handful of smart test cases.
Software Testing & Quality Assurance | Session 2 | Input Space Partitioning & Mutation Testing
SPECIAL INSIGHT • AP PL IE D TO IN P UT D OMA IN M OD EL I N G
Worked Example: Partitioning the email input
Watch the framework in motion — see how guessing partitions becomes designing them systematically.
1. THINK Characteristic: “Is the input a syntactically valid email address?”
First guess at partitions: valid | invalid | empty
Name the characteristic first
Prompt to AI:
2. ASK “Using IDM rules (disjoint, complete, one block per behavior), evaluate my partitions
Prompt with precision for the email input: valid / invalid / empty. Point out gaps and suggest sub-blocks.”
✔ Disjoint? Complete? One block = one behavior?
3. REFINE →AI spots the gap: “invalid” is too coarse — missing @, missing domain, and bad chars trigger different
validators.
Verify, then iterate
✔ Refined partitions: valid | no-@ | no-domain | bad-chars | empty
AI didn’t design the partitions — you did. AI just stress-tested them against IDM rules and helped you see what you missed.
Software Testing & Quality Assurance • Think → Ask → Refine, applied
REQ-04 Example: Applying EP ≡
Identifying equivalence partitions from borrowBook() requirements
IDM Table for REQ-04 EP Test Cases (1 representative per partition)
Characteristic 1: Member Status TC1: active + available + count=1 + 7 days
Partitions: active | suspended | expired → Expected: SUCCESS (all valid partitions)
Characteristic 2: Book Availability TC2: suspended + available + count=1 + 7 days
Partitions: available | not available → Expected: REJECT (suspended member)
TC3: active + not available + count=1 + 7 days
Characteristic 3: Borrow Count
→ Expected: REJECT (book unavailable)
Partitions: <3 (valid) | ≥3 (invalid)
TC4: active + available + count=5 + 7 days
Characteristic 4: Loan Period
→ Expected: REJECT (limit exceeded)
Partitions: ≤14 days (valid) | >14 days (invalid)
4 characteristics → 7 partitions → only 4 test cases needed with EP!
But wait – can EP alone catch the ≥ vs > bug at borrowCount = 3?
Software Testing & Quality Assurance | Session 2 | Input Space Partitioning & Mutation Testing
Boundary Value Analysis
Bugs love boundaries – so should your tests
“Boundaries: Values at or close to boundaries often cause problems. This is a form of stress testing.” — Textbook Ch.6 §6.1.4
Rule: Max 3 books (borrowCount ≤ 3)
Test value 2 → inside valid
Why boundaries?
Test value 3 → ON the boundary
Most bugs cluster at the edges of partitions
Off-by-one errors, wrong operators (> vs ≥), missing edge cases
Test value 4 → just outside
Is testing only value 2 enough?
If the code has > instead of ≥, value 2 passes but value 3 FAILS!
Boundaries are where bugs hide. BVA finds them.
Always test: boundary value, boundary-1, boundary+1
Software Testing & Quality Assurance | Session 2 | Input Space Partitioning & Mutation Testing
REQ-04 Example: Applying BVA
Testing at the boundary of borrowCount – where bugs hide
BVA Test Cases for borrowCount
Rule: Max 3 books (borrowCount ≤ 3)
borrowCount = 2 → valid (inside partition)
Boundary = 3
borrowCount = 3 → ON the boundary ★
BVA tests: boundary-1, boundary, boundary+1
borrowCount = 4 → invalid (just outside)
The Critical Question
If code has borrowCount > 3 instead of borrowCount ≥ 3
Test with count=2 passes both → BUG MISSED!
Test with count=3 shows different results → BUG FOUND!
BVA catches the bugs that EP misses – always test at the boundary!
Software Testing & Quality Assurance | Session 2 | Input Space Partitioning & Mutation Testing
EP vs BVA
Two complementary weapons in your testing arsenal
Equivalence Partitioning Boundary Value Analysis
• Goal: Reduce test count • Goal: Detect boundary bugs
• Strategy: Group → pick one representative • Strategy: Test at edges of partitions
• Example: test value 2 for valid partition • Example: test values 2, 3, 4
EP alone might miss boundary bugs (value 2 won’t catch > vs ≥)
BVA alone doesn’t reduce test count systematically
→ Use BOTH together for maximum effectiveness
EP reduces. BVA detects. Together they’re unstoppable.
Software Testing & Quality Assurance | Session 2 | Input Space Partitioning & Mutation Testing
EP & BVA – Mathematical Formulation ∑
Formal definitions applied to REQ-04: borrowBook()
“1. The partition must cover the entire domain (completeness) 2. The blocks must not overlap (disjoint)” — Textbook Ch.6 §6.1
Equivalence Partitioning (EP) Boundary Value Analysis (BVA)
Definition: Input domain D is partitioned into Definition: For boundary b between Pᵢ and Pⱼ:
D = P₁ ∪ P₂ ∪ ... ∪ Pₙ T(b) = { b − δ, b, b + δ }
Properties: Where:
• Pᵢ ∩ Pⱼ = ∅ (disjoint – không giao nhau) • b = boundary value (giá trị ranh giới)
• ∪ Pᵢ = D (complete – phủ toàn bộ) • δ = minimum increment (bước tăng nhỏ nhất)
• ∀x,y ∈ Pᵢ: f(x) ≡ f(y) (equivalent behavior) Goal: Detect f(b) ≠ f′(b)
Select: tᵢ ∈ Pᵢ (1 representative per partition) where f′ = mutant (code bị lỗi toán tử)
REQ-04 Example: borrowCount | Rule: max 3 books (borrowCount ≤ 3)
EP: D = P₁ ∪ P₂ where P₁ = {x | 0 ≤ x < 3} (valid) P₂ = {x | x ≥ 3} (invalid)
Select: t₁ = 1 ∈ P₁ t₂ = 5 ∈ P₂ → only 2 test values needed
BVA: b = 3, δ = 1 → T(3) = { 2, 3, 4 } → value 3 kills mutation (≥ → >) !
Software Testing & Quality Assurance | Session 2 | Input Space Partitioning & Mutation Testing
The Combination Problem ×
When multiple inputs meet – tests explode exponentially
“However, using all combinations will be impractical when more than two or three partitions are defined.” — Textbook Ch.6 §6.2
What if we have more inputs?
Multiple inputs = combinatorial explosion
5 inputs × 3 partitions each
email × password × role
35 = 243 test cases!
2 × 2 × 2 = 8 test cases
Still manageable... but grows FAST
Do we really need to test ALL combinations?
Most real bugs are triggered by interactions of 1–2 inputs, not all at once
We need a smarter strategy – enter Base Choice Coverage!
Next: How to pick the RIGHT combinations without testing everything.
Software Testing & Quality Assurance | Session 2 | Input Space Partitioning & Mutation Testing
Base Choice Coverage ◎
A practical strategy to tame the combination explosion
“The base choice can be the simplest, the smallest, the first in some ordering, or the most likely from an end -user point of view.” — Textbook Ch.6 §6.2
Example with REQ-04
The Strategy
Base: active + available + count=0
1. Fix a base case (most typical/common values)
Test 1: invalid email + rest at base
2. Change ONE input at a time
Test 2: suspended member + rest at base
3. Keep all others at base values
Test 3: unavailable book + rest at base
Why Base Choice?
• Dramatically fewer tests than all-combinations
• When a test fails → easy to isolate the cause
• Only ONE variable changed → simple debugging
Change one thing at a time. Simple. Systematic. Effective.
Software Testing & Quality Assurance | Session 2 | Input Space Partitioning & Mutation Testing
Mutation Testing
How do you know your tests are actually good?
“Mutation testing is used to help the user strengthen the quality of test data iteratively.” — Textbook Ch.9 §9.2.2
The Big Idea Example Mutation
Deliberately inject faults into the code Original: borrowCount >= 3
If your tests are good → they should DETECT the fault Mutant: borrowCount > 3
If they don’t → your tests have GAPS → ≥ becomes >
The Challenge
Which test case can detect this mutation?
If none of your tests catch it → your test suite has a blind spot!
Mutation testing doesn’t test your code. It tests your TESTS.
Software Testing & Quality Assurance | Session 2 | Input Space Partitioning & Mutation Testing
Mutation Killing ✓
Kill or survive – the verdict on your test quality
“t is said to kill m if and only if the output of t on P is different from the output of t on m.” — Textbook Ch.9 §9.2.2
KILLED ✓ SURVIVED ✗
Test detects the mutation Test misses the mutation
= Your test is EFFECTIVE = Your test has a GAP
Mutant: ≥ changed to > (boundary at borrowCount = 3)
The Lazy Test Suite The Smart Test Suite
count=0: 0≥3=F, 0>3=F → same → SURVIVE count=2: 2≥3=F, 2>3=F → same → SURVIVE
count=2: 2≥3=F, 2>3=F → same → SURVIVE count=3: 3≥3=T, 3>3=F → diff → KILLED!
count=5: 5≥3=T, 5>3=T → same → SURVIVE count=4: 4≥3=T, 4>3=T → same → SURVIVE
→ 3/3 SURVIVE! Mutation score = 0% → 1/3 KILLED! Mutation score = 33%
Lazy tests let mutants survive. Only boundary-aware tests KILL them.
Software Testing & Quality Assurance | Session 2 | Input Space Partitioning & Mutation Testing
REQ-04 Example: Applying Mutation Testing
Can your test suite kill the mutants hiding in borrowBook()?
Mutations applied to borrowBook() Which test kills which mutant?
M1: borrowCount ≥ 3 → borrowCount > 3 M1 (≥ → >): Test count=3 → KILLED ✓
M2: status == "suspended" → status != "suspended" Original rejects (3≥3=T), Mutant allows (3>3=F)
M3: ![Link] → [Link] (negate) M2 (== → !=): Test suspended → KILLED ✓
M3 (negate): Test unavailable → KILLED ✓
Mutation Score = 3/3 = 100% — Without BVA test (count=3), M1 would SURVIVE → score drops to 67%
EP + BVA + Mutation: the complete testing trinity for REQ-04!
Software Testing & Quality Assurance | Session 2 | Input Space Partitioning & Mutation Testing
BVA + Mutation Testing ∴
The powerful connection between boundaries and mutations
“Replace each occurrence of one of the relational operators (<, ≤, >, ≥, ==, ≠) by each of the other operators” — Textbook Ch.9 §9.2.2
Why they’re connected
Most mutations change boundary operators:
≥ → > | < → ≤ | == → !=
These mutations only reveal themselves AT the boundary!
Proof with borrowCount
Without BVA: test value 2 → mutation SURVIVES
With BVA: test value 3 (boundary) → mutation KILLED!
No boundary test = bug survives in production
BVA is not optional. It’s your mutation-killing weapon.
Skip boundary tests → mutations survive → bugs ship to production.
Software Testing & Quality Assurance | Session 2 | Input Space Partitioning & Mutation Testing
Hands-On Exercise ✎
Apply everything you’ve learned to REQ-04: Borrow Book
Task 1: Find ALL Partitions Task 2: Pick Boundary Values
• List every characteristic of borrowBook() • For borrowCount: test 2, 3, and 4
• Divide each into valid & invalid partitions • Justify WHY each value matters
Task 3: Design Test Cases
• Use Base Choice Coverage strategy
• How many test cases do you need?
• Can your tests KILL the ≥ → > mutation?
Expected output:
• IDM table with all characteristics & partitions
• Boundary values with justification
• Complete test case set using Base Choice
You have 10 minutes. Work in pairs. Present your solution!
Software Testing & Quality Assurance | Session 2 | Input Space Partitioning & Mutation Testing
Session 2 – Summary ∑
Key takeaways – What you should remember from today
“Thus asking whether a coverage criterion is black-box or white-box is the wrong question.” — Textbook Ch.2 §2.4
1. Input Space Partitioning 2. Boundary Value Analysis 3. Mutation Testing
EP – Equivalence Partitioning BVA – Test at boundaries Verify test quality
Group equivalent inputs, test only 1 Bugs hide at the boundaries between Deliberately inject faults to evaluate tests
representative per group partitions → Tests don’t test code, they test the TESTS
→ Reduce tests from millions down to dozens → Always test: boundary, boundary-1, boundary+1 themselves
4. Base Choice Coverage 5. Test Design Process
Pick base case → change ONE input at a time → easy IDM → EP → BVA → Base Choice → Mutation
debugging Each step builds on the previous one
EP reduces count. BVA detects bugs. Mutation verifies quality.
Q&A & Discussion – Any questions?
Next: Lab practice – Apply what you’ve learned!
Software Testing & Quality Assurance | Session 2 | Input Space Partitioning & Mutation Testing