White-Box Testing Techniques II
|
|
|
- Donna Prudence Warren
- 5 years ago
- Views:
Transcription
1 White-Box Testing Techniques II Software Testing and Verification Lecture 8 Prepared by Stephen M. Thebaut, Ph.D. University of Florida
2 White-Box Testing Topics Logic coverage (lecture I) Dataflow coverage (lecture II) Path conditions and symbolic evaluation (lecture III) Other white-box testing strategies (e.g., fault-based testing ) (lecture IV)
3 Dataflow Coverage Based on the idea that program paths along which variables are defined and then used should be covered. Families of path selection criteria have been defined based on somewhat different models/definitions. The different criteria reflect different degrees of coverage. The model/definitions we consider are representative. CASE tool support is very desirable.
4 Variable Definitions and Uses A program variable is DEFINED when it appears: on the left hand side of an assignment statement (e.g., Y := 7) in an input statement (e.g., input(y)) as an OUT parameter in a subroutine call (e.g., DOIT(X:IN,Y:OUT)) (cont d)
5 Variable Definitions and Uses (cont d) A program variable is USED when it appears: on the right hand side of an assignment statement (e.g., Y := X+7) as an IN parameter in a subroutine or function call (e.g., Y := SQRT(X)) in the predicate of a branch statement (e.g., if X>0 then...) (cont d)
6 Variable Definitions and Uses (cont d) Use of a variable in the predicate of a branch statement is called a predicateuse ( p-use ). Any other use is called a computation-use ( c-use ). For example, in the program statement: If (X>0) then print(y) end_if_then there is a p-use of X and a c-use of Y. (cont d)
7 Variable Definitions and Uses (cont d) A variable can also be used and then redefined in a single statement when it appears: on both sides of an assignment statement (e.g., Y := Y+X) as an IN/OUT parameter in a subroutine call (e.g., INCREMENT(Y:IN/OUT))
8 Other Dataflow Terms and (Informal) Definitions A path is definition clear ( def-clear ) with respect to a variable v if there is no re-definition of v within the path. A complete path is a path whose initial node is a/the start node and whose final node is a/the exit node. (cont d)
9 Other Dataflow Terms and (Informal) Definitions (cont d) A definition-use pair ( du-pair ) with respect to a variable v is a double (d,u) such that d is a node in the program s flow graph at which v is defined, u is a node or edge at which v is used, and there is a def-clear path with respect to v from d to u. (Note that the definition of a du-pair does not require the existence of a feasible defclear path from d to u.)
10 Example. input(a,b) if (B>) then. A := A+7 end_if. if (A>0) then. B := A+B end_if. output(a,b) B A 0 input(a,b) B> A>0 output(a,b) A := A+7 B := A+B
11 Identifying DU-Pairs Variable A (,) <,> (,) <,,> (,) <,,,> <,,> (,<,>) <,,> (,<,>) <,,> (,) <,,> (,) <,,,> <,,> (,<,>) <,,> (,<,>) <,,> B A 0 input(a,b) B> A>0 output(a,b) A := A+7 B := A+B
12 Identifying DU-Pairs Variable A (,) <,> (,) <,,> (,) <,,,> <,,> (,<,>) <,,> (,<,>) <,,> (,) <,,> (,) <,,,> <,,> (,<,>) <,,> (,<,>) <,,> B A 0 input(a,b) B> A>0 output(a,b) A := A+7 B := A+B
13 Identifying DU-Pairs Variable A (,) <,> (,) <,,> (,) <,,,> <,,> (,<,>) <,,> (,<,>) <,,> (,) <,,> (,) <,,,> <,,> (,<,>) <,,> (,<,>) <,,> B A 0 input(a,b) B> A>0 output(a,b) A := A+7 B := A+B
14 Identifying DU-Pairs Variable A (,) <,> (,) <,,> (,) <,,,> <,,> (,<,>) <,,> (,<,>) <,,> (,) <,,> (,) <,,,> <,,> (,<,>) <,,> (,<,>) <,,> B A 0 input(a,b) B> A>0 output(a,b) A := A+7 B := A+B
15 Identifying DU-Pairs Variable A (,) <,> (,) <,,> (,) <,,,> <,,> (,<,>) <,,> (,<,>) <,,> (,) <,,> (,) <,,,> <,,> (,<,>) <,,> (,<,>) <,,> B A 0 input(a,b) B> A>0 output(a,b) A := A+7 B := A+B
16 Identifying DU-Pairs Variable A (,) <,> (,) <,,> (,) <,,,> <,,> (,<,>) <,,> (,<,>) <,,> (,) <,,> (,) <,,,> <,,> (,<,>) <,,> (,<,>) <,,> B A 0 input(a,b) B> A>0 output(a,b) A := A+7 B := A+B
17 Identifying DU-Pairs Variable A (,) <,> (,) <,,> (,) <,,,> <,,> (,<,>) <,,> (,<,>) <,,> (,) <,,> (,) <,,,> <,,> (,<,>) <,,> (,<,>) <,,> B A 0 input(a,b) B> A>0 output(a,b) A := A+7 B := A+B
18 Identifying DU-Pairs Variable A (,) <,> (,) <,,> (,) <,,,> <,,> (,<,>) <,,> (,<,>) <,,> (,) <,,> (,) <,,,> <,,> (,<,>) <,,> (,<,>) <,,> B A 0 input(a,b) B> A>0 output(a,b) A := A+7 B := A+B
19 Identifying DU-Pairs Variable A (,) <,> (,) <,,> (,) <,,,> <,,> (,<,>) <,,> (,<,>) <,,> (,) <,,> (,) <,,,> <,,> (,<,>) <,,> (,<,>) <,,> B A 0 input(a,b) B> A>0 output(a,b) A := A+7 B := A+B
20 Identifying DU-Pairs Variable A (,) <,> (,) <,,> (,) <,,,> <,,> (,<,>) <,,> (,<,>) <,,> (,) <,,> (,) <,,,> <,,> (,<,>) <,,> (,<,>) <,,> B A 0 input(a,b) B> A>0 output(a,b) A := A+7 B := A+B
21 Identifying DU-Pairs Variable A (,) <,> (,) <,,> (,) <,,,> <,,> (,<,>) <,,> (,<,>) <,,> (,) <,,> (,) <,,,> <,,> (,<,>) <,,> (,<,>) <,,> B A 0 input(a,b) B> A>0 output(a,b) A := A+7 B := A+B
22 Identifying DU-Pairs Variable A (,) <,> (,) <,,> (,) <,,,> <,,> (,<,>) <,,> (,<,>) <,,> (,) <,,> (,) <,,,> <,,> (,<,>) <,,> (,<,>) <,,> B A 0 input(a,b) B> A>0 output(a,b) A := A+7 B := A+B
23 Identifying DU-Pairs Variable B du-pair path(s) (,) <,,,> <,,> (,) <,,,> <,,> (,<,>) <,> (,<,>) <,> (,) <,> B A 0 input(a,b) B> A>0 output(a,b) A := A+7 B := A+B (Verification of du-pairs/paths(s) left as an exercise...)
24 Dataflow Test Coverage Criteria All-Defs: for every program variable v, at least one def-clear path from every definition of v to at least one c-use or one p-use of v must be covered. (cont d)
25 Dataflow Test Coverage Criteria (cont d) Consider a test case executing path:. <,,,,> Identify all def-clear paths covered (i.e., subsumed) by this path for each variable. Are all definitions for each variable associated with at least one of the subsumed def-clear paths?
26 Def-Clear Paths Subsumed by <,,,,> for Variable A (,) <,> (,) <,,> (,) <,,,> <,,> (,<,>) <,,> (,<,>) <,,> (,) <,,> (,) <,,,> <,,> (,<,>) <,,> (,<,>) <,,> B A 0 input(a,b) B> A>0 output(a,b) A := A+7 B := A+B
27 Def-Clear Paths Subsumed by <,,,,> for Variable B du-pair path(s) (,) <,,,> <,,> (,) <,,,> <,,> (,<,>) <,> (,<,>) <,> (,) <,> B A 0 input(a,b) B> A>0 output(a,b) A := A+7 B := A+B
28 Dataflow Test Coverage Criteria (cont d) Since <,,,,> covers at least one defclear path from each of the two definitions of A/B to at least one c-use or p-use of A/B, All-Defs coverage is achieved. (cont d)
29 Dataflow Test Coverage Criteria (cont d) All-Uses: for every program variable v, at least one def-clear path from every definition of v to every c-use and every p-use of v must be covered. Consider additional test cases executing paths:. <,,,>. <,,,> Do all three test cases provide All-Uses coverage?
30 Def-Clear Paths Subsumed by <,,,> for Variable A du-pair path(s) (,) <,> (,) <,,> (,) <,,,> <,,> (,<,>) <,,> (,<,>) <,,> (,) <,,> (,) <,,,> <,,> (,<,>) <,,> (,<,>) <,,> B A 0 input(a,b) B> A>0 output(a,b) A := A+7 B := A+B
31 Def-Clear Paths Subsumed by <,,,> for Variable B du-pair path(s) (,) <,,,> <,,> (,) <,,,> <,,> (,<,>) <,> (,<,>) <,> (,) <,> B A 0 input(a,b) B> A>0 output(a,b) A := A+7 B := A+B
32 Def-Clear Paths Subsumed by <,,,> for Variable A du-pair path(s) (,) <,> (,) <,,> (,) <,,,> <,,> (,<,>) <,,> (,<,>) <,,> (,) <,,> (,) <,,,> <,,> (,<,>) <,,> (,<,>) <,,> B A 0 input(a,b) B> A>0 output(a,b) A := A+7 B := A+B
33 Def-Clear Paths Subsumed by <,,,> for Variable B du-pair path(s) (,) <,,,> <,,> (,) <,,,> <,,> (,<,>) <,> (,<,>) <,> (,) <,> B A 0 input(a,b) B> A>0 output(a,b) A := A+7 B := A+B
34 Dataflow Test Coverage Criteria (cont d) Since none of the three test cases covers the du-pair (,<,>) for variable A, All- Uses Coverage is not achieved. Exercise: Did the three test cases considered provide Branch coverage? Basis Paths coverage? Path coverage?
35 What would be even stronger than All-Uses? We have considered the All-Defs and the All-Uses criteria so far. How could the definition of All-Uses be modified to make it even stronger? Recall: All-Uses: for every program variable v, at least one def-clear path from every definition of v to every c-use and every p-use of v must be covered.
36 Example. input(x,y). while () do. if (X>0) then. Y := Y-X else. input(x) end_if_then_else 6. end_while 7. output(x,y) input(x) 7 input(x,y)) X 0 6 X>0 output(x,y) Y := Y-X
37 Example. input(x,y). while () do. if (X>0) then. Y := Y-X else. input(x) end_if_then_else 6. end_while 7. output(x,y) input(x) 7 input(x,y)) X 0 6 X>0 output(x,y) Y := Y-X Note edges <6,7> and <6,>.
38 Logic Coverage Control Flow Graph input(a) while a do if b then s else s end_if_then_else end_while output(a)
39 Dataflow Coverage Control Flow Graph input(a) while a do if b then s else s end_if_then_else end_while output(a)
40 Identifying DU-Pairs Variable X (,) <,,,> <,,,,(6,,)*> (,7) <,,7> <,,,,6,7> <,,,,6,(,,6)*,7> (,<,>) <,,,> <,,,,(6,,)*> (,<,>) <,,,> (,) <,6,,> <,6,,,(6,,)*> input(x) 7 input(x,y)) X 0 6 X>0 output(x,y) Y := Y-X
41 Identifying DU-Pairs Variable X (,) <,,,> <,,,,(6,,)*> (,7) <,,7> <,,,,6,7> <,,,,6,(,,6)*,7> (,<,>) <,,,> <,,,,(6,,)*> (,<,>) <,,,> (,) <,6,,> <,6,,,(6,,)*> input(x) 7 input(x,y)) X 0 6 X>0 output(x,y) Y := Y-X
42 Identifying DU-Pairs Variable X (,) <,,,> <,,,,(6,,)*> (,7) <,,7> <,,,,6,7> <,,,,6,(,,6)*,7> (,<,>) <,,,> <,,,,(6,,)*> (,<,>) <,,,> (,) <,6,,> <,6,,,(6,,)*> input(x) 7 input(x,y)) X 0 6 X>0 output(x,y) Y := Y-X
43 Identifying DU-Pairs Variable X (,) <,,,> <,,,,(6,,)*> (,7) <,,7> <,,,,6,7> <,,,,6,(,,6)*,7> (,<,>) <,,,> <,,,,(6,,)*> (,<,>) <,,,> (,) <,6,,> <,6,,,(6,,)*> input(x) 7 input(x,y)) X 0 6 X>0 output(x,y) Y := Y-X
44 Identifying DU-Pairs Variable X (,) <,,,> <,,,,(6,,)*> (,7) <,,7> <,,,,6,7> <,,,,6,(,,6)*,7> (,<,>) <,,,> <,,,,(6,,)*> (,<,>) <,,,> (,) <,6,,> <,6,,,(6,,)*> input(x) 7 input(x,y)) X 0 6 X>0 output(x,y) Y := Y-X
45 Identifying DU-Pairs Variable X (,) <,,,> <,,,,(6,,)*> (,7) <,,7> <,,,,6,7> <,,,,6,(,,6)*,7> (,<,>) <,,,> <,,,,(6,,)*> (,<,>) <,,,> (,) <,6,,> <,6,,,(6,,)*> input(x) 7 input(x,y)) X 0 6 X>0 output(x,y) Y := Y-X
46 Identifying DU-Pairs Variable X (,) <,,,> <,,,,(6,,)*> (,7) <,,7> <,,,,6,7> <,,,,6,(,,6)*,7> (,<,>) <,,,> <,,,,(6,,)*> (,<,>) <,,,> (,) <,6,,> <,6,,,(6,,)*> input(x) 7 input(x,y)) X 0 6 X>0 output(x,y) Y := Y-X
47 Identifying DU-Pairs Variable X (,) <,,,> <,,,,(6,,)*> (,7) <,,7> <,,,,6,7> <,,,,6,(,,6)*,7> (,<,>) <,,,> <,,,,(6,,)*> (,<,>) <,,,> (,) <,6,,> <,6,,,(6,,)*> input(x) 7 input(x,y)) X 0 6 X>0 output(x,y) Y := Y-X
48 Identifying DU-Pairs Variable X (,) <,,,> <,,,,(6,,)*> (,7) <,,7> <,,,,6,7> <,,,,6,(,,6)*,7> (,<,>) <,,,> <,,,,(6,,)*> (,<,>) <,,,> (,) <,6,,> <,6,,,(6,,)*> input(x) 7 input(x,y)) X 0 6 X>0 output(x,y) Y := Y-X
49 Identifying DU-Pairs Variable X (,) <,,,> <,,,,(6,,)*> (,7) <,,7> <,,,,6,7> <,,,,6,(,,6)*,7> (,<,>) <,,,> <,,,,(6,,)*> (,<,>) <,,,> (,) <,6,,> <,6,,,(6,,)*> input(x) 7 input(x,y)) X 0 6 X>0 output(x,y) Y := Y-X
50 Identifying DU-Pairs Variable X (,) <,,,> <,,,,(6,,)*> (,7) <,,7> <,,,,6,7> <,,,,6,(,,6)*,7> (,<,>) <,,,> <,,,,(6,,)*> (,<,>) <,,,> (,) <,6,,> <,6,,,(6,,)*> input(x) 7 input(x,y)) X 0 6 X>0 output(x,y) Y := Y-X
51 Identifying DU-Pairs Variable X (,) <,,,> <,,,,(6,,)*> (,7) <,,7> <,,,,6,7> <,,,,6,(,,6)*,7> (,<,>) <,,,> <,,,,(6,,)*> (,<,>) <,,,> (,) <,6,,> <,6,,,(6,,)*> input(x) 7 input(x,y)) X 0 6 X>0 output(x,y) Y := Y-X
52 Identifying DU-Pairs Variable X (,) <,,,> <,,,,(6,,)*> (,7) <,,7> <,,,,6,7> <,,,,6,(,,6)*,7> (,<,>) <,,,> <,,,,(6,,)*> (,<,>) <,,,> (,) <,6,,> <,6,,,(6,,)*> input(x) 7 input(x,y)) X 0 6 X>0 output(x,y) Y := Y-X
53 Identifying DU-Pairs Variable X (,) <,,,> <,,,,(6,,)*> (,7) <,,7> <,,,,6,7> <,,,,6,(,,6)*,7> (,<,>) <,,,> <,,,,(6,,)*> (,<,>) <,,,> (,) <,6,,> <,6,,,(6,,)*> input(x) 7 input(x,y)) X 0 6 X>0 output(x,y) Y := Y-X
54 Identifying DU-Pairs Variable X (,) <,,,> <,,,,(6,,)*> (,7) <,,7> <,,,,6,7> <,,,,6,(,,6)*,7> (,<,>) <,,,> <,,,,(6,,)*> (,<,>) <,,,> (,) <,6,,> <,6,,,(6,,)*> input(x) 7 input(x,y)) X 0 6 X>0 output(x,y) Y := Y-X
55 Identifying DU-Pairs Variable X (,) <,,,> <,,,,(6,,)*> (,7) <,,7> <,,,,6,7> <,,,,6,(,,6)*,7> (,<,>) <,,,> <,,,,(6,,)*> (,<,>) <,,,> (,) <,6,,> <,6,,,(6,,)*> input(x) 7 input(x,y)) X 0 6 X>0 output(x,y) Y := Y-X
56 Identifying DU-Pairs Variable X (,7) <,6,7> <,6,,,6,7> <,6,,,6,(,,6)*,7> (,<,>) <,6,,> <,6,,,(6,,)*> (,<,>) <,6,,> <,6,,,6,,> <,6,,,6,(,,6)*,,> input(x) 7 input(x,y)) X 0 6 X>0 output(x,y) Y := Y-X
57 Identifying DU-Pairs Variable X (,7) <,6,7> <,6,,,6,7> <,6,,,6,(,,6)*,7> (,<,>) <,6,,> <,6,,,(6,,)*> (,<,>) <,6,,> <,6,,,6,,> <,6,,,6,(,,6)*,,> infeasible input(x) 7 input(x,y)) X 0 6 X>0 output(x,y) Y := Y-X
58 Identifying DU-Pairs Variable X (,7) <,6,7> <,6,,,6,7> <,6,,,6,(,,6)*,7> (,<,>) <,6,,> <,6,,,(6,,)*> (,<,>) <,6,,> <,6,,,6,,> <,6,,,6,(,,6)*,,> infeasible input(x) 7 input(x,y)) X 0 6 X>0 output(x,y) Y := Y-X
59 Identifying DU-Pairs Variable X (,7) <,6,7> <,6,,,6,7> <,6,,,6,(,,6)*,7> (,<,>) <,6,,> <,6,,,(6,,)*> (,<,>) <,6,,> <,6,,,6,,> input(x) input(x,y)) X 0 X>0 Y := Y-X infeasible <,6,,,6,(,,6)*,,> 7 6 output(x,y)
60 Identifying DU-Pairs Variable X (,7) <,6,7> <,6,,,6,7> <,6,,,6,(,,6)*,7> (,<,>) <,6,,> <,6,,,(6,,)*> (,<,>) <,6,,> <,6,,,6,,> <,6,,,6,(,,6)*,,> infeasible input(x) 7 input(x,y)) X 0 6 X>0 output(x,y) Y := Y-X
61 Identifying DU-Pairs Variable X (,7) <,6,7> <,6,,,6,7> <,6,,,6,(,,6)*,7> (,<,>) <,6,,> <,6,,,(6,,)*> (,<,>) <,6,,> <,6,,,6,,> <,6,,,6,(,,6)*,,> infeasible input(x) 7 input(x,y)) X 0 6 X>0 output(x,y) Y := Y-X
62 Identifying DU-Pairs Variable X (,7) <,6,7> <,6,,,6,7> <,6,,,6,(,,6)*,7> (,<,>) <,6,,> <,6,,,(6,,)*> (,<,>) <,6,,> <,6,,,6,,> <,6,,,6,(,,6)*,,> infeasible input(x) 7 input(x,y)) X 0 6 X>0 output(x,y) Y := Y-X
63 Identifying DU-Pairs Variable X (,7) <,6,7> <,6,,,6,7> <,6,,,6,(,,6)*7> (,<,>) <,6,,> <,6,,,(6,,)*> (,<,>) <,6,,> <,6,,,6,,> <,6,,,6,(,,6)*,,> infeasible input(x) 7 input(x,y)) X 0 6 X>0 output(x,y) Y := Y-X
64 Identifying DU-Pairs Variable X (,7) <,6,7> <,6,,,6,7> <,6,,,6,(,,6)*7> (,<,>) <,6,,> <,6,,,(6,,)*> (,<,>) <,6,,> <,6,,,6,,> <,6,,,6,(,,6)*,,> infeasible input(x) 7 input(x,y)) X 0 6 X>0 output(x,y) Y := Y-X
65 Identifying DU-Pairs Variable X (,7) <,6,7> <,6,,,6,7> <,6,,,6,(,,6)*7> (,<,>) <,6,,> <,6,,,(6,,)*> (,<,>) <,6,,> <,6,,,6,,> <,6,,,6,(,,6)*,,> infeasible input(x) 7 input(x,y)) X 0 6 X>0 output(x,y) Y := Y-X
66 Identifying DU-Pairs Variable X (,7) <,6,7> <,6,,,6,7> <,6,,,6,(,,6)*7> (,<,>) <,6,,> <,6,,,(6,,)*> (,<,>) <,6,,> <,6,,,6,,> <,6,,,6,(,,6)*,,> infeasible input(x) 7 input(x,y)) X 0 6 X>0 output(x,y) Y := Y-X
67 More Dataflow Terms and Definitions A path (either partial or complete) is simple if all edges within the path are distinct (i.e., different). A path is loop-free if all nodes within the path are distinct (i.e., different).
68 Simple and Loop-Free Paths path Simple? Loop-free? <,,,> <,,,> <,,,,> <,,,,>
69 Simple and Loop-Free Paths (cont d) Which is stronger, simple or loop-free?
70 More Dataflow Terms and Definitions (cont d) A path <n,n,...,n j,n k > is a du-path with respect to a variable v if v is defined at node n and either:. there is a c-use of v at node n k and <n,n,...,n j,n k > is a def-clear simple path, or. there is a p-use of v at edge <n j,n k > and <n,n,...n j > is a def-clear loopfree path.
71 More Dataflow Terms and Definitions (cont d) A path <n,n,...,n j,n k > is a du-path with respect to a variable v if v is defined at node n and either:. there is a c-use of v at node n k and <n,n,...,n j,n k > is a def-clear simple path, or. there is a p-use of v at edge <n j,n k > and <n,n,...n j > is a def-clear loopfree path. NOTE!
72 Identifying du-paths du-path? X: (,7) <,6,7> <,6,,,6,7> <,6,,,6,(,,6)*,7> X: (,<,>) <,6,,> <,6,,,(6,,)*> X: (,<,>) <,6,,> <,6,,,6,,> <,6,,,6,(,,6)*,,> infeasible
73 Another Dataflow Test Coverage Criterion All-DU-Paths: for every program variable v, every du-path from every definition of v to every c-use and every p-use of v must be covered.
74 Exercise Identify all c-uses and p-uses for variable Y in Example. For each c-use or p-use, identify (using the * notation) all def-clear paths. Identify whether or not each def-clear path is feasible, and whether or not it is a du-path.
75 Summary of White-Box Coverage Relationships Path Compound Condition All dupaths Branch / Condition Basis Paths All-Uses Loop Condition Branch * Statement All-Defs - nominal cases *
76 White-Box Testing Techniques II Software Testing and Verification Lecture 8 Prepared by Stephen M. Thebaut, Ph.D. University of Florida
White-Box Testing Techniques III
White-Box Testing Techniques III Software Testing and Verification Lecture 9 Prepared by Stephen M. Thebaut, Ph.D. University of Florida White-Box Testing Topics Logic coverage (lecture I) Dataflow coverage
Course Wrap-Up. Software Testing and Verification. Stephen M. Thebaut, Ph.D. Prepared by. University of Florida
Course Wrap-Up Software Testing and Verification Prepared by Stephen M. Thebaut, Ph.D. University of Florida A few loose ends Final Exam + solution notes will be posted (under Practice Exams ) ASAP probably
Using the code to measure test adequacy (and derive test cases) Structural Testing
Using the code to measure test adequacy (and derive test cases) Structural Testing Objectives To describe a second approach to testing which is geared to find program defects To explain the use of program
Dataflow-based Coverage Criteria
Dataflow-based Coverage Criteria W. Eric Wong Department of Computer Science The University of Texas at Dallas ewong@utdallas.edu http://www.utdallas.edu/~ewong Dataflow-based Coverage Criteria ( 2012
Testing: Dataflow Coverage
Testing: Dataflow Coverage Testing, Quality Assurance, and Maintenance Winter 2018 Arie Gurfinkel based on slides by Thibaud Lutellier, Marsha Chechik and Prof. Lin Tan Non-looping Path Selection Problem
Testing Methods: White Box Testing II
Testing Methods: White Box Testing II Outline Today we continue our look at white box testing with more code coverage methods, and a data coverage method We ll look at : - code coverage testing - decision
Program Structure. Simple Statements. Program consists of blocks Block. Can be represented by a flow graph. Sequence of statements
An Applicable Family of Data Flow Testing Criteria Assumptions about the program No goto statements with variant records Functions having var parameters By reference Procedural or functional parameters
Program Structure. Simple Statements. Program consists of blocks Block. Can be represented by a flow graph. Sequence of statements
An Applicable Family of Data Flow Testing Criteria Assumptions about the program No goto statements with variant records Functions having var parameters By reference Procedural or functional parameters
MTAT : Software Testing
MTAT.03.159: Software Testing Lecture 03: White-Box Testing (Textbook Ch. 5) Dietmar Pfahl Spring 2017 email: dietmar.pfahl@ut.ee Lecture Chapter 5 White-box testing techniques (Lab 3) Structure of Lecture
MTAT : Software Testing
MTAT.03.159: Software Testing Lecture 03: White-Box Testing (Textbook Ch. 5) Dietmar Pfahl Spring 2016 email: dietmar.pfahl@ut.ee Lecture Chapter 5 White-box testing techniques (Lab 3) Structure of Lecture
Data Flow Coverage 1. Stuart Anderson. Stuart Anderson Data Flow Coverage 1 c 2011
Data Flow Coverage 1 Stuart Anderson Why Consider Data Flow? 1 Control Flow: Statement and branch coverage criteria are weak. Condition coverage and path coverage are more costly and can become infeasible.
MTAT : Software Testing
MTAT.03.159: Software Testing Lecture 04: White-Box Testing (advanced) Part1 Dietmar Pfahl Spring 2018 email: dietmar.pfahl@ut.ee White-Box Testing Techniques Control-Flow Testing Data-Flow Testing Mutation
Requirements and Specifications
Requirements and Specifications Software Testing and Verification Lecture 3 Prepared by Stephen M. Thebaut, Ph.D. University of Florida What are Requirements and Specifications? Requirement: something
INTRODUCTION TO SOFTWARE ENGINEERING
INTRODUCTION TO SOFTWARE ENGINEERING Structural Testing d_sinnig@cs.concordia.ca Department for Computer Science and Software Engineering Introduction Testing is simple all a tester needs to do is find
6. Test-Adequacy. Assessment Using Control Flow and Data Flow. Andrea Polini
6. Test-Adequacy Assessment Using Control Flow and Data Flow Andrea Polini Software Engineering II Software Testing MSc in Computer Science University of Camerino (Software Engineering II Software Testing)
Software Quality Engineering Exercises
Software Quality Engineering Exercises Exercise 1 The following program computes the greatest common divisor of two natural numbers by Euclid s algorithm. Begin input(x,y); While(x>0 and y>0) Do If (x>y)
MTAT : Software Testing
MTAT.03.159: Software Testing Lecture 03: White-Box Testing (Textbook Ch. 5) Spring 2013 Dietmar Pfahl email: dietmar.pfahl@ut.ee Lecture Chapter 5 White-box testing techniques (Lab 3) Structure of Lecture
Subject Software Testing Structural Testing
Subject Software Testing Structural Testing Objective: 1. Understand Concept of structural testing 2. How structural (code-based or glass-box) testing complements functional (black-box) testing 3. Recognize
Testing Role in Unified Approach Coverage: Structural/Coverage Model Based Test Generation from Model Checking (project) Interaction of
Testing Role in Unified Approach Coverage: Structural/Coverage Model Based Test Generation from Model Checking (project) Interaction of Coverage/Model Based Testing Will Not Cover Statistical Methods Partition
Path Testing + Coverage. Chapter 8
Path Testing + Coverage Chapter 8 Structural Testing n Also known as glass/white/open box testing n A software testing technique whereby explicit knowledge of the internal workings of the item being tested
Overview Graph Coverage Criteria
Overview Graph Coverage Criteria Graph Coverage Four Structures for Modeling Software Graphs Logic Input Space Syntax Applied to Applied to Source FSMs Applied to Specs DNF Source Specs Source Models Design
Software Testing. Testing: Our Experiences
Software Testing Testing: Our Experiences Test Case Software to be tested Output 1 Test Case Generation When to Stop? Test Case Software to be tested Verification Output No Enough? Test Coverage Yes A
NAME (from your UF ID): UF ID#: (Please PRINT) Quiz 1 -- Spring 2017
NAME (from your UF ID): UF ID#: (Please PRINT) -------------------- CEN 4072/6070 Software Testing & Verification ------------------ Quiz 1 -- Spring 2017 You have 30 minutes to work on this exam. It is
White-Box Testing Techniques
T-76.5613 Software Testing and Quality Assurance Lecture 3, 18.9.2006 White-Box Testing Techniques SoberIT Content What are white-box testing techniques Control flow testing Statement coverage Branch coverage
Data Flow Testing. Mohammad Mousavi. Testing and Verification, February 2 nd, University of Leicester, UK and GU/Chalmers, Sweden
Data Flow Testing Mohammad Mousavi University of Leicester, UK and GU/Chalmers, Sweden Testing and Verification, February 2 nd, 2018 Outline From Paths to DU-Paths Path Testing: Pros and Cons Pros: Abstract
CMPSCI 521/621 Homework 2 Solutions
CMPSCI 521/621 Homework 2 Solutions Problem 1 Direct data dependencies: 3 is directly data dependent on 1 and 5 5 is directly data dependent on 1,3, and 5 7 is directly data dependent on 1,3, and 5 Note,
Introduction to Software Testing Chapter 2.3 Graph Coverage for Source Code. Paul Ammann & Jeff Offutt
Introduction to Software Testing Chapter 2.3 Graph Coverage for Source Code Paul Ammann & Jeff Offutt Overview The most common application of graph criteria is to program source Graph : Usually the control
Testing Tools. Software Testing and Verification. Lecture 14. Stephen M. Thebaut, Ph.D. Prepared by. University of Florida
Testing Tools Software Testing and Verification Lecture 14 Prepared by Stephen M. Thebaut, Ph.D. University of Florida Overview of Topics Why is test automation desirable? Types of test automation test
Introduction to Software Engineering
Introduction to Software Engineering (CS350) Lecture 17 Jongmoon Baik Testing Conventional Applications 2 Testability Operability it operates cleanly Observability the results of each test case are readily
LECTURE 11 TEST DESIGN TECHNIQUES IV
Code Coverage Testing 1. Statement coverage testing 2. Branch coverage testing 3. Conditional coverage testing LECTURE 11 TEST DESIGN TECHNIQUES IV Code Complexity Testing 1. Cyclomatic Complexity s V
Test Case Specifications and Test adequacy. Research Methods - Barbara Russo SwSE - Software and Systems Engineering
Test Case Specifications and Test adequacy Research Methods - Barbara Russo SwSE - Software and Systems Engineering 1 Test Case Selection How do we create tests? Test are defined in terms of their adequacy
Lecture 18: Structure-based Testing
Test Case First Strategy White box testing: Statement Coverage Branch Coverage Condition Coverage Data Path Coverage Lecture 18: Structure-based Testing Testing with good and bad data Testing Object Oriented
Introduction to Software Testing Chapter 2, Sections: 2.1 & 2.2 Overview Graph Coverage Criteria
Introduction to Software Testing Chapter 2, Sections: 2.1 & 2.2 Overview Graph Coverage Criteria Paul Ammann & Jeff Offutt http://www.cs.gmu.edu/~offutt/softwa retest/ Ch. 2 : Graph Coverage Four Structures
STRUCTURAL TESTING. AKA White Box Testing. Thanks go to Andreas Zeller for allowing incorporation of his materials. F. Tip and M.
F. Tip and M. Weintraub STRUCTURAL TESTING AKA White Box Testing Thanks go to Andreas Zeller for allowing incorporation of his materials STRUCTURAL TESTING Testing based on the structure of the code Test
Introduction to Software Testing Chapter 2.1, 2.2 Overview Graph Coverage Criteria Paul Ammann & Jeff Offutt
Introduction to Software Testing Chapter 2.1, 2.2 Overview Graph Coverage Criteria Paul Ammann & Jeff Offutt www.introsoftwaretesting.com Ch. 2 : Graph Coverage Four Structures for Modeling Software Graphs
Program Testing and Analysis: Manual Testing Prof. Dr. Michael Pradel Software Lab, TU Darmstadt
Program Testing and Analysis: Manual Testing Prof. Dr. Michael Pradel Software Lab, TU Darmstadt Partly based on slides from Peter Müller, ETH Zurich 1 Warm-up Quiz What does the following code print?
STRUCTURAL TESTING. AKA White Box Testing. Thanks go to Andreas Zeller for allowing incorporation of his materials. F. Tip and M.
F. Tip and M. Weintraub STRUCTURAL TESTING AKA White Box Testing Thanks go to Andreas Zeller for allowing incorporation of his materials STRUCTURAL TESTING Testing based on the structure of the code Test
7. Testing and Debugging Concurrent Programs
7. Testing and Debugging Concurrent Programs The purpose of testing is to find program failures => A successful test is a test that causes a program to fail. Ideally, tests are designed before the program
CSCE 747 Software Testing and Quality Assurance
CSCE 747 Software Testing and Quality Assurance Lecture 07 Dataflow Testing 1 Lec 07 Dataflow Testing 1 9/1/2013 CSCE 747 Fall 2013 Last Time Lecture 06 Slides 1 19 covered last time Case Study Question
Structural Testing. Testing Tactics. Why Structural? Structural white box. Functional black box. Structural white box. Functional black box
From Pressman, Software Engineering a practitioner s approach, Chapter 14 and Pezze + Young, Software Testing and Analysis, Chapters 12-13 Structural Testing Software Engineering Andreas Zeller Saarland
CS 520 Theory and Practice of Software Engineering Fall 2018
Today CS 52 Theory and Practice of Software Engineering Fall 218 Software testing October 11, 218 Introduction to software testing Blackbox vs. whitebox testing Unit testing (vs. integration vs. system
Software Verification and Validation. Prof. Lionel Briand Ph.D., IEEE Fellow
Software Verification and Validation Prof. Lionel Briand Ph.D., IEEE Fellow 1 White-Box Testing 2 White-Box vs. Black-BoxTesting: Reminder Software Representation (Model) Associated Criteria Test cases
Test s in i g n III Week 16
Testing III Week 16 Agenda (Lecture) White box testing Condition coverage Loop coverage Path coverage Agenda (Lab) Implementation Review of SRS/SDD documents Submit a weekly project progress report at
Agenda. Predicate Testing. CSE 5321/4321, Ali Sharifara, UTA
Agenda Predicate Testing CSE 5321/4321, Ali Sharifara, UTA 1 Predicate Testing Introduction Basic Concepts Predicate Coverage Summary CSE 5321/4321, Ali Sharifara, UTA 2 Motivation Predicates are expressions
SE 3S03. Zahra Ali. Week of Feb 22, 2016
SE 3S03 Department of Computing and Software McMaster University Week of Feb 22, 2016 Coverage Coverage 1/34 Outline Coverage Coverage Coverage Coverage 2/34 Recall that means using the information about
Dataflow Testing. Dataflow Testing. Dataflow Analysis. Definitions. Definitions 2. Definitions 3
Dataflow Testing Dataflow Testing Testing All-Nodes and All-Edges in a control flow graph may miss significant test cases Testing All-Paths in a control flow graph is often too timeconsuming Chapter 9
Dataflow Testing. Definitions 2
Dataflow Testing Dataflow Analysis Can reveal interesting bugs Dataflow Testing Chapter 9 Testing All-Nodes and All-Edges in a control flow graph may miss significant test cases Testing All-Paths in a
Integrating the classification tree method with combinatorial testing: test selection strategy
Integrating the classification tree method with combinatorial testing: test selection strategy Eduardo Miranda, PhD. CMU/MSE MSE/NIST Seminar June 7th, 2011 Pittsburgh, PA The Classification Tree Method
Structural Testing. (c) 2007 Mauro Pezzè & Michal Young Ch 12, slide 1
Structural Testing (c) 2007 Mauro Pezzè & Michal Young Ch 12, slide 1 Learning objectives Understand rationale for structural testing How structural (code-based or glass-box) testing complements functional
Introduction to Dynamic Analysis
Introduction to Dynamic Analysis Reading assignment Gary T. Leavens, Yoonsik Cheon, "Design by Contract with JML," draft paper, http://www.eecs.ucf.edu/~leavens/jml//jmldbc.pdf G. Kudrjavets, N. Nagappan,
Advanced Test Coverage Criteria: Specify and Measure, Cover and Unmask
Advanced Test Coverage Criteria: Specify and Measure, Cover and Unmask Sébastien Bardin & Nikolai Kosmatov joint work with Omar Chebaro, Robin David, Mickaël Delahaye, Michaël Marcozzi, Mike Papadakis,
Symbolic Evaluation/Execution
Symbolic Evaluation/Execution Reading Assignment *R.W. Floyd, "Assigning Meaning to Programs, Symposium on Applied Mathematics, 1967, pp. 19-32 (Appeared as volume 19 of Mathematical Aspects of Computer
SE 3S03 - Tutorial 10. Helen Brown. Week of Mar 23, 2015
SE 3S03 - Tutorial 10 Department of Computing and Software McMaster University Week of Mar 23, 2015 : Acknowledgments: The material of these slides is based on [1] 1/34 Outline Edge : Path : 2/34 Recall
Dataflow Testing. Chapter 9!
Dataflow Testing Chapter 9! Dataflow Testing Testing All-Nodes and All-Edges in a control flow graph may miss significant test cases! Testing All-Paths in a control flow graph is often too timeconsuming!
What is Structural Testing?
Structural Testing What is Structural Testing? Based on Source Code Examine the internal structure of the program Test cases are derived from an examination of program s logic Do not pay any attention
MSc Software Testing MSc Prófun hugbúnaðar
MSc Software Testing MSc Prófun hugbúnaðar Fyrirlestrar 7 & 8 Structural Testing White-box tests. 29/8/27 Dr Andy Brooks 1 Case Study Dæmisaga Reference Structural Testing of Programs, A Survey, A A Omar
Cleanroom Software Engineering
Cleanroom Software Engineering Software Testing and Verification Lecture 25 Prepared by Stephen M. Thebaut, Ph.D. University of Florida Required Reading and Additional Reference Required Reading: Linger,
Structural Testing. White Box Testing & Control Flow Analysis
Structural Testing White Box Testing & Control Flow Analysis Functional vs. Structural Functional Have I built the right product? Tests derived from the program specification Internal Structure ignored
Structural Testing. Testing Tactics. Why Structural? Structural white box. Functional black box. Structural white box. Functional black box
From Pressman, Software Engineering a practitioner s approach, Chapter 14 and Pezze + Young, Software Testing and Analysis, Chapters 12-13 Structural Testing Software Engineering Andreas Zeller Saarland
Aerospace Software Engineering
16.35 Aerospace Software Engineering Verification & Validation Prof. Kristina Lundqvist Dept. of Aero/Astro, MIT Would You...... trust a completely-automated nuclear power plant?... trust a completely-automated
In this Lecture you will Learn: Testing in Software Development Process. What is Software Testing. Static Testing vs.
In this Lecture you will Learn: Testing in Software Development Process Examine the verification and validation activities in software development process stage by stage Introduce some basic concepts of
Program Analysis. Program Analysis
Program Analysis Class #4 Program Analysis Dynamic Analysis 1 Static VS Dynamic Analysis Static analysis operates on a model of the SW (without executing it) If successful, produces definitive information
Software Quality Assurance Dynamic Test
Software Quality Assurance Dynamic Test Contents Properties and goals Structural testing Control flow testing Data flow testing Functional test Diversified test 2 Properties and Goals Properties of dynamic
Software Testing. 1. Testing is the process of demonstrating that errors are not present.
What is Testing? Software Testing Many people understand many definitions of testing :. Testing is the process of demonstrating that errors are not present.. The purpose of testing is to show that a program
Testing: Coverage and Structural Coverage
Testing: Coverage and Structural Coverage Testing, Quality Assurance, and Maintenance Winter 2017 Prof. Arie Gurfinkel based on slides by Prof. Marsha Chechik and Prof. Lin Tan How would you test this
Dataflow Testing. Chapter 10!
Dataflow Testing Chapter 10! Dataflow Testing Testing All-Nodes and All-Edges in a control flow graph may miss significant test cases! Testing All-Paths in a control flow graph is often too timeconsuming!
1 Black Box Test Data Generation Techniques
1 Black Box Test Data Generation Techniques 1.1 Equivalence Partitioning Introduction Equivalence partitioning is based on the premise that the inputs and outputs of a component can be partitioned into
Facts About Testing. Cost/benefit. Reveal faults. Bottom-up. Testing takes more than 50% of the total cost of software development
Reveal faults Goals of testing Correctness Reliability Usability Robustness Performance Top-down/Bottom-up Bottom-up Lowest level modules tested first Don t depend on any other modules Driver Auxiliary
Reading Assignment. Symbolic Evaluation/Execution. Move from Dynamic Analysis to Static Analysis. Move from Dynamic Analysis to Static Analysis
Reading Assignment Symbolic Evaluation/Execution *R.W. Floyd, "Assigning Meaning to Programs, Symposium on Applied Mathematics, 1967, pp. 19-32 (Appeared as volume 19 of Mathematical Aspects of Computer
Cleanroom Software Engineering
Cleanroom Software Engineering Software Testing and Verification Lecture 25 Prepared by Stephen M. Thebaut, Ph.D. University of Florida Required Reading and Additional Reference Required Reading: Linger,
Data Flow Testing. CSCE Lecture 10-02/09/2017
Data Flow Testing CSCE 747 - Lecture 10-02/09/2017 Control Flow Capture dependencies in terms of how control passes between parts of a program. We care about the effect of a statement when it affects the
SFWR ENG 3S03: Software Testing
(Slide 1 of 52) Dr. Ridha Khedri Department of Computing and Software, McMaster University Canada L8S 4L7, Hamilton, Ontario Acknowledgments: Material based on [?] Techniques (Slide 2 of 52) 1 2 3 4 Empirical
Testing Tactics. Structural Testing. Why Structural? Why Structural? Functional black box. Structural white box. Functional black box
ing Tactics Structural ing Functional black box Structural white box Software Engineering Andreas Zeller Saarland University s based on spec covers as much specified behavior as possible s based on code
Test Suite Reduction with Selective Redundancy
Test Suite Reduction with Selective Redundancy Dennis Jeffrey Department of Computer Science The University of Arizona Tucson, AZ 85721 jeffreyd@cs.arizona.edu Neelam Gupta Department of Computer Science
What s Next INF 117 Project in Software Engineering
What s Next IN 117 Project in Software Engineering Lecture Notes - Spring Quarter, 2008 Michele Rousseau Set 8 - esting Set 8 - esting 2 Announcements k Drop Boxes We will use drop boxes for the remainder
Part I: Preliminaries 24
Contents Preface......................................... 15 Acknowledgements................................... 22 Part I: Preliminaries 24 1. Basics of Software Testing 25 1.1. Humans, errors, and testing.............................
Software Testing TEST CASE SELECTION AND ADEQUECY TEST EXECUTION
Software Testing TEST CASE SELECTION AND ADEQUECY TEST EXECUTION Overview, Test specification and cases, Adequacy criteria, comparing criteria, Overview of test execution, From test case specification
An Introduction to Systematic Software Testing. Robert France CSU
An Introduction to Systematic Software Testing Robert France CSU Why do we need to systematically test software? Poor quality products can Inconvenience direct and indirect users Result in severe financial
Iterative Statements. Iterative Statements: Examples. Counter-Controlled Loops. ICOM 4036 Programming Languages Statement-Level Control Structure
ICOM 4036 Programming Languages Statement-Level Control Structure Selection Statement Iterative Statements Unconditional Branching Guarded Commands This lecture covers review questions 8-16 This lecture
MTAT : Software Testing
MTAT.03.159: Software Testing Lecture 02: Basic Black-Box and White-Box Testing Techniques (Textbook Ch. 4 & 5) Spring 2018 Dietmar Pfahl email: dietmar.pfahl@ut.ee Structure of Lecture 2 Black-Box vs.
Overview. State-of-the-Art. Relative cost of error correction. CS 619 Introduction to OO Design and Development. Testing.
Overview CS 619 Introduction to OO Design and Development ing! Preliminaries! All sorts of test techniques! Comparison of test techniques! Software reliability Fall 2012! Main issues: There are a great
Chapter 14 Testing Tactics
Chapter 14 Testing Tactics Moonzoo Kim CS Division of EECS Dept. KAIST moonzoo@cs.kaist.ac.kr http://pswlab.kaist.ac.kr/courses/cs550-07 Spring 2007 1 Overview of Ch14. Testing Tactics 14.1 Software Testing
Class 8 ALGORITHMS AND FLOWCHARTS. The City School
Class 8 ALGORITHMS AND FLOWCHARTS ALGORITHMS AND FLOWCHARTS A typical programming task can be divided into two phases: Problem solving phase produce an ordered sequence of steps that describe solution
MTAT : Software Testing
MTAT.03.159: Software Testing Lecture 02: Basic Black-Box and White-Box Testing Techniques (Textbook Ch. 4 & 5) Spring 2018 Dietmar Pfahl email: dietmar.pfahl@ut.ee Structure of Lecture 2 Black-Box vs.
Compiler Design. Fall Data-Flow Analysis. Sample Exercises and Solutions. Prof. Pedro C. Diniz
Compiler Design Fall 2015 Data-Flow Analysis Sample Exercises and Solutions Prof. Pedro C. Diniz USC / Information Sciences Institute 4676 Admiralty Way, Suite 1001 Marina del Rey, California 90292 pedro@isi.edu
MSc Software Testing and Maintenance MSc Prófun og viðhald hugbúnaðar
MSc Software Testing and Maintenance MSc Prófun og viðhald hugbúnaðar Fyrirlestrar 31 & 32 Structural Testing White-box tests. 27/1/25 Dr Andy Brooks 1 Case Study Dæmisaga Reference Structural Testing
Testing: (A Little) Logic Coverage
Testing: (A Little) Logic Coverage Testing, Quality Assurance, and Maintenance Winter 2018 Prof. Arie Gurfinkel Why Logic Coverage? MC/DC (Modified condition/decision coverage) MC/DC is required by the
Software Testing part II (white box) Lecturer: Giuseppe Santucci
Software Testing part II (white box) Lecturer: Giuseppe Santucci 4. White box testing White-box (or Glass-box) testing: general characteristics Statement coverage Decision coverage Condition coverage Decision
Unit-Level Test Adequacy Criteria for Visual Dataflow Languages and a Testing Methodology
1 Unit-Level Test Adequacy Criteria for Visual Dataflow Languages and a Testing Methodology MARCEL R. KARAM American University of Beirut TREVOR J. SMEDLEY Dalhousie University and SERGIU M. DASCALU University
CSE Section 10 - Dataflow and Single Static Assignment - Solutions
CSE 401 - Section 10 - Dataflow and Single Static Assignment - Solutions 1. Dataflow Review For each of the following optimizations, list the dataflow analysis that would be most directly applicable. You
Testing: Coverage and Structural Coverage
Testing: Coverage and Structural Coverage Testing, Quality Assurance, and Maintenance Winter 2018 Prof. Arie Gurfinkel based on slides by Prof. Marsha Chechik and Prof. Lin Tan How would you test this
Compiler Design. Fall Control-Flow Analysis. Prof. Pedro C. Diniz
Compiler Design Fall 2015 Control-Flow Analysis Sample Exercises and Solutions Prof. Pedro C. Diniz USC / Information Sciences Institute 4676 Admiralty Way, Suite 1001 Marina del Rey, California 90292
Programming Embedded Systems
Programming Embedded Systems Lecture 8 Overview of software testing Wednesday Feb 8, 2012 Philipp Rümmer Uppsala University Philipp.Ruemmer@it.uu.se 1/53 Lecture outline Testing in general Unit testing
15.083J Integer Programming and Combinatorial Optimization Fall Enumerative Methods
5.8J Integer Programming and Combinatorial Optimization Fall 9 A knapsack problem Enumerative Methods Let s focus on maximization integer linear programs with only binary variables For example: a knapsack
Wednesday, February 15, 2017
Wednesday, February 15, 2017 Topics for today Before and after assembly: Macros, Linkers Overview of Chapter 6 Branching Unconditional Status bits and branching If statements While statements The V and
Test Path Selection Based on Effective Domains*
Abstract Test Path Selection Based on Effective Domains* In this papec a method is proposed to produce test paths that check both dataflow and controlflow for a protocol specijied in the Extended Finite
c. Typically results in an intractably large set of test cases even for small programs
Multiple-Choice Questions: 1. True or false? Generally, in practice, developers exhaustively test software. a. True b. False 2. True or false? All real software contains bugs. a. True b. False 3. Which
Logic Coverage for Source Code
Logic Coverage for Source Code CS 4501 / 6501 Software Testing [Ammann and Offutt, Introduction to Software Testing, Ch. 8] 1 Structural Logic Coverage for Source Code Aim: to identify test requirements
CS 4387/5387 SOFTWARE V&V LECTURE 4 BLACK-BOX TESTING
1 CS 4387/5387 SOFTWARE V&V LECTURE 4 BLACK-BOX TESTING Outline 2 Quiz Black-Box Testing Equivalence Class Testing (Equivalence Partitioning) Boundary value analysis Decision Table Testing 1 3 Quiz - 1
Testing & Continuous Integration. Kenneth M. Anderson University of Colorado, Boulder CSCI 5828 Lecture 20 03/19/2010
esting & Continuous Integration Kenneth M. Anderson University of Colorado, Boulder CSCI 5828 Lecture 20 03/1/20 University of Colorado, 20 1 Goals 2 Review material from Chapter of Pilone & Miles esting