Download presentation
Presentation is loading. Please wait.
Published byRodney Phelps Modified over 9 years ago
1
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 1 Defect testing l Testing programs to establish the presence of system defects
2
©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
3
©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
4
©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, 10001 Equivalence partitioning
5
©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
6
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 6 White-box testing
7
Binary search (Java)
8
©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
9
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 9 Binary search equiv. partitions
10
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 10 Binary search - test cases
11
©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
12
©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
13
SequenceIf-Then-ElseWhile-DoDo-Until Case Basic Control Constructs
14
©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
15
Binary search flow graph
16
©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
17
©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
18
©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 – 9 + 2 = 4 ----------------------------------------------- V(G) = Nr predicate nodes + 1 = 3 + 1(nodes 2, 3 & 4) = 4
19
©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
20
Binary search flow graph 123 4
21
©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
22
©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
23
©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
Similar presentations
© 2024 SlidePlayer.com. Inc.
All rights reserved.