1.01k likes | 2.63k Views
White-Box Testing. Pfleeger, S. Software Engineering Theory and Practice 2 nd Edition. Prentice Hall, 2001. Ghezzi, C. et al., Fundamentals of Software Engineering. Prentice Hall, 2002. Pressman, R., Software Engineering A Practitioner’s Approach, Mc Graw Hill, 2005. 1209.
E N D
White-Box Testing Pfleeger, S. Software Engineering Theory and Practice 2nd Edition. Prentice Hall, 2001. Ghezzi, C. et al., Fundamentals of Software Engineering. Prentice Hall, 2002. Pressman, R., Software Engineering A Practitioner’s Approach, Mc Graw Hill, 2005. 1209
White Box Testing • Also known as: • Glass box testing • Structural testing • Test set is derived from structure of code • Code structure represented as a Control Flow Graph • Goal is to cover the CFG
Control Flow Graphs • Programs are made of three kinds of statements:
Control Flow Graph (CFG) Sequence If-then-else Iterative If-then
Example 1: CFG 1. read (result); 2. read (x,k) 3.while result < 0 then { 4. ptr false 5. if x > k then 6. ptr true 7. x x + 1 8. result result + 1 } 9. print result
Write a CFG • Example 2 • 1.if (a < b) then • 2. while (a < n) • 3. a a + 1; • 4. else • 5. while (b < n) • 6. b b + 1;
Answers • Example 3 • 1.read (a,b); • 2.if (a 0 && b 0) then { • 3. c a + b; • 4. if c > 10 then • 5. c max • else c min } • 7. else print ‘Done’
Answers • Example 4 • 1.read (a,b); • 2.if (a 0 || b 0) then { • 3. c a + b • 4.while( c < 100) • 5. c a + b; } • 6. c a * b
Cyclomatic Complexity • Software metric for the logical complexity of a program. • Defines the number of independent paths in the basis set of a program • Provides the upper bound for the number of tests that must be conducted to ensure that all statements been have executed at least once • For Edges (E) and Nodes (N) V(G) = E – N + 2
Complexity of CFGs 3,4 3,4 1 1 5 5 6 2 Join Join 3
Example 1 2,3 6 4,5 8 7 9 10 11
Example 1: CFG 1,2 3 9 4,5 6 Join 7,8
1 2 5 3 6 Join Example 2
1,2 3,4 7 5 6 Join Join Answers
1, 2 3 4 Join 5 6 Answers
Criteria • Statement coverage • Branch coverage • Condition coverage • (lots of others …)
1,2 3 9 4,5 6 Join 7,8 Branch Coverage • Each edge of a program’s CFG is traversed at least once in some test. • Independent paths: • 1, 2, 3, 9 • 1, 2, 3, 4, 5, 6, 7, 8, 3, …, 9 • 1, 2, 3, 4, 5, 7, 8, 3, …, 9 Example 1
Criteria • Statement coverage • Branch coverage • Condition coverage • Every complex condition is made true and false by every possible combination • E.G., (x and y) • x = true, y = true • x=false, y=true • x = true, y= false • x =false, y = false
AND Condition 1, 2A 2B 4 3 Join
OR Condition 1,2A 3 2B 4 5 Join
Path Coverage-1 1,2,3 • Every distinct path through code is executed at least once • Basis set does not yield minimal test set • Example 1. read (x) 2. read (z) 3. if x 0 thenbegin 4. y x * z; 5. x z end 6. else print ‘Invalid’ 7.if y > 1 then 8. print y 9. else print ‘Invalid’ • Test Paths: 1, 2, 3, 4, 5, J1, 7, 8, J2 1, 2, 3, 4, 5, J1, 7, 9, J2 1, 2, 3, 6, J1, 7, 8, J2, 1, 2, 3, 6, J1, 7, 9, J2 4,5 6 Join1 7 8 9 Join2
Def-Use Coverage Def: x, z Use: x 1,2,3 • Def-use coverage: every path from every definition of every variable to every use of that definition is exercised in some test. • Example 1. read (x) 2. read (z) 3. if x 0 thenbegin 4. y x * z; 5. x z end 6. else print ‘Invalid’ 7.if y > 1 then 8. print y 9. else print ‘Invalid’ 4,5 Def: y, x Use: x, z 6 Use: none Join 7 Use: y 8 Use: none 9 Use: y • Test Path: 1, 2, 3, 4, 5, 7, 8, J Join
What paths don’t tell you • Timing errors • Unanticipated error conditions • User interface inconsistency (or anything else) • Configuration errors • Capacity errors