1. Chapter 18 Testing Conventional Applications
Slide Set to accompany Software Engineering: A Practitioner’s Approach, 7/e
by Roger S. Pressman
Slides copyright © 1996, 2001, 2005, 2009 by Roger S. Pressman
For non-profit educational use only
May be reproduced ONLY for student use at the university level when used in conjunction with Software Engineering: A Practitioner's Approach, 7/e. Any other reproduction or use is prohibited without the express written permission of the author.
All copyright information MUST appear if these slides are posted on a website for student use.
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.

2. Introduction
The primary objective for test-case design is to derive a set of tests that have the highest likelihood for uncovering errors in software.
To accomplish this objective, two different categories of test-case design techniques are used: white-box testing and black-box testing.
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.

3. Software Testing white-box black-box methods methods Methods
Basis path testing
Condition testing
Data flow testing
Loop testing
Graph-Based Testing
Equivalence partitioning
Boundary value analysis
Orthogonal array testing
Model-based testing
white-box
methods
black-box
methods
Methods
Strategies
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.

4. White-box testing
White-box tests focus on the program control structure.
Test cases are derived to ensure that all statements in the program have been executed at least once during testing and all logical conditions have been exercised.
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.

5. Flow graph is generated from codes. You will see the example later.
The flow graph depicts logical control flow using the notation illustrated in next slide.
Flow graph is generated from codes. You will see the example later.

6. Flow graph notation
Sequence
UNTIL IF IF
CASE
WHILE

7. Flow graph
The arrows on the flow graph, called edges or links, represent flow of control and are analogous to flowchart arrows.
Area bounded by edges and nodes are called regions.
When counting regions, we include the area outside the graph as region.
Region 4
edges
Region 6
Region 5
Region 3
Region 1
Region 2
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.

8. Flow graph, independent paths, Cyclomatic Complexity and test cases
Step – 1: Construct the flow graph from the source code or flow charts.
Step – 2: Identify independent paths.
Step – 3: Calculate Cyclomatic Complexity, V(G).
Step – 4: Design the test cases.

9. Example 1 Step 1: Binary search flow graph
Predicate nodes
Predicate nodes
Predicate nodes R2 R1 R3 R4

10. Example 1 Step 2: Identify independent paths
Test cases should be derived so that all of these paths are executed
A dynamic program analyser may be used to check that paths have been executed

11. Example 1 Step 3: Calculate cyclomatic complexity, V(G)
Cyclomatic complexity can be used to count the number of independent paths.
A number of industry studies have indicated that the higher V(G), the higher the probability or errors.

12. Example 1 Step 3: Calculate cyclomatic complexity, V(G)
Calculation of V(G) by three methods:
Method 1
V(G) = e – n + 2 ( Where “e” are edges & “n” are nodes)
V(G) = 16 – = 4
Method 2
V(G) = P + 1 (Where P- predicate nodes with out-degree = 2)
V(G) = = 4 (The predicate nodes are labeled)
Method 3
V(G) = Number of regions = 4

13. Example 2 Step 1: Drawing flow graph from simple code
Predicate nodes 1 1
void foo (float y, float a *, int n) {
float x = sin (y) ;
if (x > 0.01)
z = tan (x) ;
else
z = cos (x) ;
for (int i = 0 ; i < x ; + + i) {
a[i] = a[i] * z ;
Cout < < a [i]; } } 2 R1 3 2 4 3
Predicate nodes R3 5 6 4 5 R2 6 6 6 7 7

14. Example 2 Step 2: Identify independent paths
There are 3 paths in this program which are independent paths and they form a basis-set.
These paths are described below
Path 1: 1 – 2 – 4 – 5 - 7
Path 2: 1 – 3 – 4 – 5 - 7
Path 3: 1 – 2 – 4 – 5 – 6 – 5 – 7
Path 4: 1 – 3 – 4 – 5 – 6 – 5 – 7
We must execute these paths at least once in order to test the program thoroughly.
Accordingly we can design the test cases (no of test cases => 3)

15. Example 2 Step 3: Calculate cyclomatic complexity, V(G)
Calculation of V(G) by three methods:
Method 1
V(G) = e – n + 2 ( Where “e” are edges & “n” are nodes)
V(G) = 8 – = 3
Method 2
V(G) = P + 1 (Where P- predicate nodes with out-degree = 2)
V(G) = = 3 (The predicate nodes are labeled)
Method 3
V(G) = Number of regions = 3

16. Example 3 Step 1: Flow graph2 3 8 4 5 6 7 9

17. Example 3 Step 2: Identify independent paths1 2 3 8 4 5 6 7
Path 1: 1-9
Path 2:
Path 3:
Path 4: 9

18. Example 3 Step 3: Calculate cyclomatic complexity, V(G)
V(G) = E - N + 2
V(G) = = 4
E= no. of edges,
N= no. of nodes 2 1 3 4
V(G) = P + 1
V(G) = = 4
P= no. of predicate nodes (conditions)
# Regions = 4

19. Example 4 Step 1: Flow chart2 3 4 5 6 7 8
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.

20. Example 4 Step 2: Identify independent paths1 2 3 4 5 6 7 8
Predicate nodes
Path 1: 1,2,3,6,7,8
Path 2: 1,2,3,5,7,8
Path 3: 1,2,4,7,8
Path 4: 1,2,4,7,2,4,...7,8 R1 R4 R2
Predicate nodes R3
edges
Predicate nodes
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.

21. Example 4 Step 3: Calculate cyclomatic complexity, V(G)
Calculation of V(G) by three methods:
Method 1
V(G) = e – n + 2 ( Where “e” are edges & “n” are nodes)
V(G) = 9 – = 4
Method 2
V(G) = P + 1 (Where P- predicate nodes with out-degree = 2)
V(G) = = 4 (The predicate nodes are labeled)
Method 3
V(G) = Number of regions = 4

22. Graph Matrices
A graph matrix is a square matrix whose size (i.e., number of rows and columns) is equal to the number of nodes on a flow graph
Each row and column corresponds to an identified node, and matrix entries correspond to connections (an edge) between nodes.
By adding a link weight to each matrix entry, the graph matrix can become a powerful tool for evaluating program control structure during testing
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.

23. Graph Matrices 1 3 5 4 2 a d b c f g e Connected to node Node 1 2 3 4
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.

24. Condition testing
Condition testing is a test-case design method that exercises the logical conditions contained in a program module.
In short, it tests relational operator like <, ≤, >, ≥, =, ≠ and Boolean operators like OR (|), AND (&), NOT(⌐) that exist in your program.
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.

25. Data flow testing
The data flow testing method selects test paths of a program according to the locations of definitions and uses of variables in the program.
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.

26. Loop testing
Loop testing is a white-box testing technique that focuses exclusively on the validity of loop constructs.
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.

27. Black-box testing
Black-box tests are designed to validate functional requirements without regard to the internal workings of a program.
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.

28. Black-box testing
Tests are designed to answer some of the following questions:
What classes of input will make good test cases?
Is the system particularly sensitive to certain input values?
How are system behavior and performance tested?
How is functional validity tested?
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.

29. Graph-based testing
Begins by creating a graph of important objects and their relationships and then devising a series of tests that will cover the graph so that each object and relationship is exercised and errors are uncovered.
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.

30. Equivalence partitioning
Equivalence partitioning divides the input domain into classes of data that are likely to exercise a specific software function.
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.

31. Equivalence partitioning
How do I define equivalence classes for testing?
Equivalence classes may be defined according to the following guidelines:
If an input condition specifies a range, one valid and two invalid equivalence classes are defined.
If an input condition requires a specific value, one valid and two invalid equivalence classes are defined.
If an input condition specifies a member of a set, one valid and one invalid equivalence classes are defined.
If an input condition is Boolean, one valid and one invalid equivalence classes are defined.
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.

32. Boundary Value Analysis
Boundary value analysis leads to a selection of test cases that exercise bounding values.
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.

33. Boundary Value Analysis
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.

34. Ritcher Scale Number (n)
Example:
Ritcher Scale Number (n)
Input Values
n<5.0
2.0
5.0 <= n < 5.5
5.0, 5.3
5.5 <= n < 6.5
5.5, 5.7
6.5 <= n < 7.5
6.5, 7.0
higher
7.5, 8.0

35. Orthogonal Array Testing
Used when the number of input parameters is small and the values that each of the parameters may take are clearly bounded
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.

36. Model-Based Testing
Uses information contained in the requirements model as the basis for the generation of test cases.
In many cases, the model-based testing technique uses UML state diagrams, an element of the behavioral model, as the basis for the design of test cases.
These slides are designed to accompany Software Engineering: A Practitioner’s Approach, 7/e (McGraw-Hill 2009). Slides copyright 2009 by Roger Pressman.