Software Engineering: A Practitioner’s Approach, 6/e
Chapter 14 Software Testing Techniques copyright © 1996, 1996 2001, 2001 2005
R.S. Pressman & Associates, Inc. For University Use Only May y be reproduced p ONLY for student use at the university y level when used in conjunction with Software Engineering: A Practitioner's Approach. Any other reproduction or use is expressly prohibited.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
1
Testability: estab ty: how o eas easily y a so software t a e ca can be tested
Operability— the better it works, the more efficiently it can Operability— be tested. tested - It operates cleanly Observability— Observability —What you see is what you test. The results of each test case are readily observed (clear and visible variables and states, states incorrect output, output …)) Controllability— Controllability —the degree to which testing can be automated and optimized Decomposability— Decomposability b l —testing can be b targeted d to independent d d modules Simplicity— Simplicity —reduce complex architecture and logic to simplify tests Stability— Stability —few changes are requested during testing Understandability— Understandability y—of the design g
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
2
What is a “Good” Good Test?
A good test has a high probability of finding an error A good test is not redundant. A good test should be “best of breed” (best between those with similar intent) A good test should be neither too simple nor too complex l
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
3
Test Case Design "Bugs lurk in corners and congregate at boundaries ..." Boris Beizer OBJECTIVE
to uncover errors
CRITERIA
in a complete manner
CONSTRAINT with a minimum of effort and time These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
4
Exhaustive Testing
loop < 20 X
14
There are 10 possible paths! If we execute one test per millisecond, it would take 3,170 years to test this program!! These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
5
Selective Se ect ve Testing est g Selected path Selected
loop < 20 X
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
6
Software Testing g black-box methods
white-box methods
Methods Strategies
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
7
WhiteWhite te-Box o Testing est g
... our g goal is to ensure that all statements and conditions have been executed at least once ... These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
8
Why Cover? logic errors and incorrect assumptions are iinversely l proportional ti l to t a path's th' execution probability we oftenbelieve believethat that a path is not likely to be executed; in fact, reality is often counter intuitive typographical errors are random; it's likely that untested paths will contain some
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
9
Basic Path Testing
Define a basic set of execution paths Guarantee that every statement is executed at least once Using a logical complexity measure of a procedural design and use it as a guide for defining a basic set of execution path
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
10
Flow Graph Notation
A representation for control flow of program Each structured construct -> a flow graph symbol
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
11
Independent program path
Any path through the program that introduces at least one new set of processing statements or a new condition. An independent p p path must move along g at least one edge g that has not been traversed before the path is defined. The basic set is not unique. How do we know how many paths to look for?
Cyclomatic complexity
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
12
Basis Path Testing: g Cyclomatic y Complexity y First, we compute the cyclomatic First complexity: number of simple decisions + 1 (simple decisions: predicate node) or number of enclosed areas + 1 or E-N+2 (E number of edges, N number of nodes) In this case, V(G) = 4
13
Cyclomatic Complexity A number of industry studies have indicated that the higher V(G), the higher the probability or errors. errors
mod les modules
V(G) modules in this range are more error prone
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
14
Basis Path Testing Next, we derive the independent paths: 1
Since V(G) = 4, there are four paths
2 3
4 5
7
8
6
Path 1: Path 2: Path 3: Path 4:
1,2,3,6,7,8 1,2,3,5,7,8 1,2,4,7,8 1,2,4,7,2,4,... ,...7 7,8
Finally, Finally we derive test cases to exercise these paths.
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
15
Basis Path Testing Notes you don't don t need a flow chart chart, but the picture will help when you trace program paths count each simple logical test, compound tests count as 2 or more basis p path testing g should be applied to critical modules
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
16
Deriving test cases
Using the design or code, draw a flow diagram Determine the cyclomatic complexity of the flow graph Determine a basis set of independent paths Prepare test cases to force the execution of each path
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
17
Graph Matrices
A tabular representation of a flow graph 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 p to connections ((an edge) g ) 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 courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
18
Link weights can be
The probability of execution of that edge The processing time for execution that edge The memory required The resource required
Help to design test cases
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
19
Other Control Structure Testing
Condition testing — a test case design method that exercises the logical conditions contained in a program module Data flow testing — selects test paths of a program according to the locations of definitions (D) and uses (U) off variables i bl in i the th program ((every DU chain h i b be covered d at least once) Loop testing – focus on validity of loop constructs
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
20
Loop Testing f four diff differentt classes l off lloop
Simple loop Nested Loops Concatenated Loops
Unstructured U s uc u ed Loops
These courseware materials are to be used in conjunction with Software Engineering: A Practitioner’s Approach, 6/e and are provided with permission by R.S. Pressman & Associates, Inc., copyright © 1996, 2001, 2005
21
Loop p Testing: g Simple p Loops p Minimum conditions— conditions—Simple p Loops p 1. skip the loop entirely 2. only one pass through the loop 3. two passes through the loop 4. m p passes through g the loop p m
