Testing Part-3

Introduction to Software Testing, Edition 2 (Ch 2) © Ammann & Offutt 1

 Fault & Failure Model (RIPR)
Four conditions necessary for a failure to be observed

1. Reachability: The location or locations in the program

that contain the fault must be reached
2. Infection: The state of the program must be incorrect
3. Propagation: The infected state must cause some
output or final state of the program to be incorrect
4. Reveal: The tester/oracle must observe part of the
incorrect portion of the program state

Introduction to Software Testing, Edition 2 (Ch 2) © Ammann & Offutt 2

 RIPR Model
Tests
Final Program State
Reaches
• Reachability Observed Final
Program State
• Infection Faults
Incorrect
Final
Infects
• Propagation State
Propagates
• Revealability Incorrect
Reveals
Program
States Test
Oracles
Introduction to Software Testing, Edition 2 (Ch 2) © Ammann & Offutt 3
int count = 0;
…
if (e.hasMoreElements()){ // should be while(e.hasMoreElements())
… e.nextElement();…
count++;
}

e = {1, 2, 3}
cout << count; // incorrect output
Reachability? yes
Infection? yes
Propagation? Yes
Revealability? Yes
Introduction to Software Testing (Ch 1), www.introsoftwaretesting.com © Ammann & Offutt 4
int count = 0;
…
if (e.hasMoreElements()){ // should be while(e.hasMoreElements())
… e.nextElement();…
count++;
}

e = {1}
cout << count; // incorrect output
Reachability? Yes
Infection? No
Propagation? No
Revealability? No
Introduction to Software Testing (Ch 1), www.introsoftwaretesting.com © Ammann & Offutt 5
int count = 0; boolean bNonZero = false;
…
if (e.hasMoreElements()){ // should be while(e.hasMoreElements())
… e.nextElement();…
count++;
} e = {1, 2, 3}
Reachability? yes
Infection? yes
Propagation? No
Revealability? No
if (count > 0) bNonZero = true; → nullified the propagation
cout << bNonZero; // correct output

Introduction to Software Testing (Ch 1), www.introsoftwaretesting.com © Ammann & Offutt 6

 Changing Notions of Testing

Old view of testing is of testing at specific

software development phases

– Unit, module, integration, system …

New view is in terms of coverage criteria

– Graphs, logical expressions, input space

Introduction to Software Testing (Ch 1), www.introsoftwaretesting.com © Ammann & Offutt 7

 Old: Testing based on phases

main Class P

Class A Class B

method mA1() method mB1()

method mA2() method mB2()

Unit testing: Test each

unit method individually
(testing the implementation)

Introduction to Software Testing (Ch 1), www.introsoftwaretesting.com © Ammann & Offutt 8

 Old: Testing based on phases

main Class P

Class A Class B

method mA1() method mB1()

method mA2() method mB2()

Module testing: Test
each class, file, module
or component (testing the
detailed design)

Introduction to Software Testing (Ch 1), www.introsoftwaretesting.com © Ammann & Offutt 9

 Old: Testing based on phases

main Class P

Class A Class B
Integration testing:
method mA1() method mB1() Test how modules
interact with each
other (testing the subsystem
method mA2() method mB2() design)

Introduction to Software Testing (Ch 1), www.introsoftwaretesting.com © Ammann & Offutt 10

 Old: Testing based on phases

main Class P

System testing: Test the

overall functionality of
the system (testing the
Class A Class B architectural design)

method mA1() method mB1()

method mA2() method mB2()

Introduction to Software Testing (Ch 1), www.introsoftwaretesting.com © Ammann & Offutt 11

 Old: Testing based on phases
Acceptance testing: Is
the software acceptable
to the user? Use real
main Class P data (testing the requirements,
validation testing)

Class A Class B

method mA1() method mB1()

method mA2() method mB2()

Introduction to Software Testing (Ch 1), www.introsoftwaretesting.com © Ammann & Offutt 12

 Old: Testing based on phases
Acceptance testing: Is
the software acceptable
to the user? Use real
main Class P data (testing the requirements,
validation testing)

System testing: Test the

overall functionality of
the system (testing the
Class A Class B architectural design)

Integration testing:
method mA1() method mB1() Test how modules
interact with each
other (testing the subsystem
method mA2() method mB2() design)
Module testing: Test
each class, file, module
or component (testing the
detailed design)

Unit testing: Test each

unit method individually
(testing the implementation)

Introduction to Software Testing (Ch 1), www.introsoftwaretesting.com © Ammann & Offutt 13

 New: Testing based on Coverage Criteria
• Since exhaustive testing is not feasible, coverage criteria
are used to decide when to stop testing

• The software testing community believes that the use of

coverage criteria makes it more likely that faults are
found and provides informal assurance of the reliability
of the software

• This is not a scientifically supported proposition, but it

is the best out there

Introduction to Software Testing (Ch 1), www.introsoftwaretesting.com © Ammann & Offutt 14

 New: Test Coverage Criteria
Define a model (abstraction) of the software, then find
ways to cover it

Test Requirements (TR):

A test requirement is a specific element of a software
artifact that a test case must cover.
Coverage Criterion:
A rule that imposes test requirements (set of all
statements, branches…) on a test set.

Introduction to Software Testing (Ch 1), www.introsoftwaretesting.com © Ammann & Offutt 15

 1. Graph Coverage – Structural

2 6

1 5 7

3 Node (Statement)
Cover every node
This graph may represent • 12567
• statements & branches 4
• 1343567
• methods & calls
• states and transitions

Introduction to Software Testing (Ch 1), www.introsoftwaretesting.com © Ammann & Offutt 16

 1. Graph Coverage – Structural

2 6

1 5 7

3 Node
Edge (Statement)
(Branch)
Cover
Coverevery
everynode
edge
This graph may represent •• 12567
12567
• statements & branches 4
•• 1343567
1343567
• methods & calls
• 1357
• states and transitions

Introduction to Software Testing (Ch 1), www.introsoftwaretesting.com © Ammann & Offutt 17

 1. Graph Coverage – Structural

2 6

1 5 7

3 Node
Path(Statement)
Edge (Branch)
Cover
Coverevery
Cover everynode
every edge
path
This graph may represent •••12567
12567
12567
• statements & branches 4
•••1343567
1343567
1257
• methods & calls
•• 1357
13567
• states and transitions
• 1357
• 1343567
Introduction to Software Testing (Ch 1), www.introsoftwaretesting.com © Ammann & Offutt
• 134357 … 18
 2. Logical Expressions

( (a > b) or G ) and (x < y)

Predicate Coverage: Each predicate must become true and false
– ( (a>b) or G ) and (x < y) = True, False

Clause Coverage: Each clause must become true and false

– (a > b) = True, False
– G = True, False
– (x < y) = True, False

Combinatorial Coverage: Various combinations of clauses (23)

Introduction to Software Testing (Ch 1), www.introsoftwaretesting.com © Ammann & Offutt 19

 3. Input Domain Characterization
Describe the input domain of the software

Unit level
– Parameters F (int X, int Y)
– Possible values X: { <0, 0, 1, 2, >2 }, Y : { 10, 20, 30 }
– Tests
• F (-5, 10), F (0, 20), F (1, 30), F (2, 10), F (5, 20)

Introduction to Software Testing (Ch 1), www.introsoftwaretesting.com © Ammann & Offutt 20