©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 1 Defect testing l Testing programs to establish the presence of system defects

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 2 l Test data Inputs which have been devised to test the system l Test cases Inputs to test the system and the predicted outputs from these inputs if the system operates according to its specification Test data and test cases

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 3 Equivalence partitioning l Input data and output results often fall into different classes where all members of a class are related l Each of these classes is an equivalence partition where the program behaves in an equivalent way for each class member l Test cases should be chosen from each partition

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 4 l Partition system inputs and outputs into ‘equivalence sets’ If input is a 5-digit integer between 10,000 and 99,999, equivalence partitions are 10, 000 l Choose test cases at the boundary of these sets 00000, 09999, 10000, 99999, Equivalence partitioning

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 5 l Sometime called white-box testing l Derivation of test cases according to program structure. Knowledge of the program is used to identify additional test cases l Objective is to exercise all program statements (not all path combinations) Structural testing

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 6 White-box testing

Binary search (Java)

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 8 l Pre-conditions satisfied, key element in array l Pre-conditions satisfied, key element not in array l Pre-conditions unsatisfied, key element in array l Pre-conditions unsatisfied, key element not in array l Input array has a single value l Input array has an even number of values l Input array has an odd number of values Binary search - equiv. partitions

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 9 Binary search equiv. partitions

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 10 Binary search - test cases

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 11 Path testing l The objective of path testing is to ensure that the set of test cases is such that each path through the program is executed at least once l The starting point for path testing is a program flow graph that shows nodes representing program decisions and arcs representing the flow of control l Statements with conditions are therefore nodes in the flow graph

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 12 l Describes the program control flow. Each branch is shown as a separate path and loops are shown by arrows looping back to the loop condition node l Used as a basis for computing the cyclomatic complexity – a function of the number of distinct paths of execution within a module l Use graph theory to suggest a basis set of test Program flow graphs

SequenceIf-Then-ElseWhile-DoDo-Until Case Basic Control Constructs

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 14 l The number of tests to test all control statements equals the cyclomatic complexity l Cyclomatic complexity equals number of conditions in a program l Useful if used with care. Does not imply adequacy of testing. l Although all paths are executed, all combinations of paths are not executed Cyclomatic complexity

Binary search flow graph

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 16 l 1, 2, 3, 8, 9 l 1, 2, 3, 4, 6, 7, 2 l 1, 2, 3, 4, 5, 7, 2 l 1, 2, 3, 4, 6, 7, 2, 8, 9 l Test cases should be derived so that all of these paths are executed l A dynamic program analyser may be used to check that paths have been executed Independent paths

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 17 Graph Theory l The cyclomatic complexity, V(G) of a graph, G, with N vertices and E edges is V(G) = N – E + 2 l A predicate node is a node at which the path splits. If P is the number of predicate nodes, then V(G) = P + 1

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 18 V(G) for Binary Search V(G) – the cyclomatic complexity for Binary Search = Nr Edges – Nr Nodes + 2 = 11 – = V(G) = Nr predicate nodes + 1 = 3 + 1(nodes 2, 3 & 4) = 4

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 19 More Graph Theory Euler’s Formula: If G is a connected plane graph (no edges crossing) with N vertices, E edges and R regions, then: N – E + R = 2, or equivalently R = E – N + 2 Since V(G) = E – N + 2, and R = E – N + 2, it follows that V(G) = R I.e. The cyclomatic complexity = the number of regions in the graph

Binary search flow graph 123 4

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 21 Application to Testing l Associate a module with a graph with unique entry and exit nodes l Each node corresponds to a block of sequential code l Edges represent the program’s branches l Assumes each node can be reached from the entry node and each node can reach the exit node

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 22 Application to Testing (cont’d) l The maximum number of independent paths in G is V(G). l V(G) represents the maximum number of test; not all of these tests may be possible

©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 23 General Notes l Cyclomatic Complexity has no direct relationship to the number of lines of code in a module So, trying to limit complexity by limiting the number of lines of code is meaningless l Except when case statements are used, the cyclomatic complexity of a module should not exceed 10 l Studies show 50% of the run time is spent in 4% of the code For complexity < 5, conventional testing result in full coverage