Data Flow Coverage Criteria

Slides:



Advertisements
Similar presentations
Whitebox Testing Fra: CS Fall Whitebox Testing AKA Structural, Basis Path Test Normally used at unit level Assumes errors at unit level are.
Advertisements

Graph Coverage for Design Elements 1.  Use of data abstraction and object oriented software has increased importance on modularity and reuse.  Therefore.
Paul Ammann & Jeff Offutt
Graph Coverage (2).
CITS5501 Software Quality and Testing Logic and Path Coverage From Introduction to Software Testing, 2 nd ed, Ammann & Offutt.
Graph Coverage Criteria Structural Coverage Criteria : Defined on a graph just in terms of nodes and edges Data Flow Coverage Criteria : Requires a graph.
Introduction to Software Testing Chapter 2.1, 2.2 Overview Graph Coverage Criteria Paul Ammann & Jeff Offutt
Lecture 2 White-box Testing and Structural Coverage.
The Application of Graph Criteria: Source Code  It is usually defined with the control flow graph (CFG)  Node coverage is used to execute every statement.
Handouts Software Testing and Quality Assurance Theory and Practice Chapter 5 Data Flow Testing
Software Testing Mistake in coding is called error ,
Introduction to Software Testing Chapter 1 Introduction Paul Ammann & Jeff Offutt
Introduction to Software Testing Chapter 2.3 Graph Coverage for Source Code Paul Ammann & Jeff Offutt
Paul Ammann & Jeff Offutt
Introduction to Software Testing Chapter 2.4 Graph Coverage for Design Elements Paul Ammann & Jeff Offutt
Software testing techniques Testing criteria based on data flow
Presented By Dr. Shazzad Hosain Asst. Prof., EECS, NSU
Data Flow Testing Chapter Data Flow Testing Testing All-Nodes and All-Edges in a control flow graph may miss significant test cases Testing All-Paths.
1 ECE 453 – CS 447 – SE 465 Software Testing & Quality Assurance Instructor Kostas Kontogiannis.
Course Outline Traditional Static Program Analysis –Theory –Classic analysis and applications Points-to analysis, CHA, RTA –The Soot analysis framework.
White-Box Testing Techniques II Originals prepared by Stephen M. Thebaut, Ph.D. University of Florida Dataflow Testing.
Overview Graph Coverage Criteria ( Introduction to Software Testing Chapter 2.1, 2.2) Paul Ammann & Jeff Offutt.
Final Review  Different tests  Boundary Value Testing  Equivalence Class Testing  Decision Table Based Testing  Path Testing  Data Flow & P-Slice.
Software Testing and Maintenance Lecture 4 Graph Coverage for Design Element Paul Ammann & Jeff Offutt Instructor: Hossein Momeni Mazandaran.
1 Graph Coverage (4). Reading Assignment P. Ammann and J. Offutt “Introduction to Software Testing” ◦ Section
Introduction to Software Testing Chapters 1-5 Coverage Summary Paul Ammann & Jeff Offutt
Introduction to Software Testing Chapter 2.3 Graph Coverage for Source Code Paul Ammann & Jeff Offutt
Software Verification Graph Model. 2 Graph Coverage Four Structures for Modeling Software Graphs Logic Input Space Syntax Use cases Specs Design Source.
Paul Ammann & Jeff Offutt
Introduction to Software Testing (2nd edition) Chapter 7.4 Graph Coverage for Design Elements Paul Ammann & Jeff Offutt
Introduction to Software Testing Chapter 2.3 Graph Coverage for Source Code Paul Ammann & Jeff Offutt.
Software Testing and Maintenance Lecture 2.1 Overview Graph Coverage
Overview Structural Testing Introduction – General Concepts
1 Graph Coverage (3). Reading Assignment P. Ammann and J. Offutt “Introduction to Software Testing” ◦ Section 2.2 ◦ Section
Control Flow Graphs : The if Statement 1 if (x < y) { y = 0; x = x + 1; } else { x = y; } x >= yx < y x = y y = 0 x = x + 1 if (x < y) { y = 0;
Paul Ammann & Jeff Offutt
Software Testing and Maintenance Lecture 3 Graph Coverage for Source Code Paul Ammann & Jeff Offutt Instructor: Hossein Momeni Mazandaran.
Data Flow Testing. Introduction to Software Testing (Ch 2) © Ammann & Offutt 2 Definition of a Graph A set N of nodes, N is not empty A set N 0 of initial.
Chapter 2 : Graph Coverage (part 2)
Software Testing and QA Theory and Practice (Chapter 5: Data Flow Testing) © Naik & Tripathy 1 Software Testing and Quality Assurance Theory and Practice.
Paul Ammann & Jeff Offutt
Paul Ammann & Jeff Offutt
Paul Ammann & Jeff Offutt
Software Testing and Maintenance 1
Paul Ammann & Jeff Offutt
Introduction to Software Testing Syntactic Logic Coverage Criteria
Graph Coverage Criteria CS 4501 / 6501 Software Testing
Paul Ammann & Jeff Offutt
Software Verification
Graph: Data Flow Criteria CS 4501 / 6501 Software Testing
Paul Ammann & Jeff Offutt
Path testing Path testing is a “design structural testing” in that it is based on detailed design & the source code of the program to be tested. The.
Graph Coverage for Design Elements CS 4501 / 6501 Software Testing
Paul Ammann & Jeff Offutt
Paul Ammann & Jeff Offutt
Paul Ammann & Jeff Offutt
Paul Ammann & Jeff Offutt
Paul Ammann & Jeff Offutt
Graph Coverage for Design Elements CS 4501 / 6501 Software Testing
Graph: Data Flow Coverage Criteria CS 4501 / 6501 Software Testing
Graph Coverage for Source Code
Paul Ammann & Jeff Offutt
Graph Coverage Criteria CS 4501 / 6501 Software Testing
Graph Coverage Criteria
Graph Coverage Criteria
Paul Ammann & Jeff Offutt
George Mason University
Paul Ammann & Jeff Offutt
Paul Ammann & Jeff Offutt
Presentation transcript:

Data Flow Coverage Criteria All-Defs Coverage (ADC): For each def-path set S = du(n, v), TR contains at least one path d in S. All-Uses Coverage (AUC): For each def-pair set S = du(ni , nj , v), TR contains at least one path d in S. All-du-Paths Coverage (ADUPC): For each def-pair set S = du(ni , nj, v), TR contains every path d in S.

Data Flow Coverage Criteria All-Defs Coverage requires that each def reaches at least one use, All-Uses Coverage requires that each def reaches all possible uses All-du-Paths Coverage requires that each def reaches all possible uses through all possible du-paths. The formal definitions of the criteria are simply appropriate selections from the appropriate set.

Differences Among the three Data Flow Coverage Criteria The graph has one def, so only one path is needed to satisfy all-defs. The def has two uses, so two paths are needed to satisfy all-uses. Since two paths go from the def to each use, four paths are needed to satisfy all-du-paths.

Annotated Control Graph Nodes 4 and 6 are final nodes, corresponding to the return statements. Node 2 is introduced to capture the for loop; it has no executable statements. DU (def-use) pairs are shown as a variable name followed by the def node, then the use node. use(3)= def (5) = { i } use (5) = { i } Def -Use Pairs = { (1, 1,x), (1,3,x), (1,3,y), (1, 2,i), (1, 3,i), (1,5,i), (1,6,i), (5, 2,i), (5, 3,i), ( 5, 6,i), (5, 5,i)}

example of a graph annotated with defs and uses

System.out.println ("length: " + length); public static void computeStats (int [ ] numbers) { int length = numbers.length; double med, var, sd, mean, sum, varsum; sum = 0; for (int i = 0; i < length; i++) sum += numbers [ i ]; } med = numbers [ length / 2]; mean = sum / (double) length; varsum = 0; varsum = varsum + ((numbers [ I ] - mean) * (numbers [ I ] - mean)); var = varsum / ( length - 1.0 ); sd = Math.sqrt ( var ); System.out.println ("length: " + length); System.out.println ("mean: " + mean); System.out.println ("median: " + med); System.out.println ("variance: " + var); System.out.println ("standard deviation: " + sd); } 1 2 i = 0 3 4 5 6 i = 0 7 8 i >= length i < length i++

CFG for ComputeStats – With Defs & Uses 8 1 2 4 3 5 6 7 def (1) = { numbers, sum, length } def (2) = { i } use (3, 5) = { i, length } use (3, 4) = { i, length } def (5) = { med, mean, varsum, i } use (5) = { numbers, length, sum } def (4) = { sum, i } use (4) = { sum, numbers, i } use (6, 8) = { i, length } use (6, 7) = { i, length } def (8) = { var, sd } use (8) = { varsum, length, mean, med, var, sd } def (7) = { varsum, i } use (7) = { varsum, numbers, i, mean }

Defs and Uses Tables for ComputeStat Node Def Use 1 { numbers, sum, length } { numbers } 2 { i } 3 4 { sum, i } { numbers, i, sum } 5 { med, mean, varsum, i } { numbers, length, sum } 6 7 { varsum, i } { varsum, numbers, i, mean } 8 { var, sd } { varsum, length, var, mean, med, var, sd } Edge Use (1, 2) (2, 3) (3, 4) { i, length } (4, 3) (3, 5) (5, 6) (6, 7) (7, 6) (6, 8)

DU Pairs for ComputeStat Defs come before uses, do not count as DU pairs variable DU Pairs numbers (1, 4) (1, 5) (1, 7) length (1, 5) (1, 8) (1, (3,4)) (1, (3,5)) (1, (6,7)) (1, (6,8)) med (5, 8) var (8, 8) sd mean (5, 7) (5, 8) sum (1, 4) (1, 5) (4, 4) (4, 5) varsum (5, 7) (5, 8) (7, 7) (7, 8) i (2, 4) (2, (3,4)) (2, (3,5)) (2, 7) (2, (6,7)) (2, (6,8)) (4, 4) (4, (3,4)) (4, (3,5)) (4, 7) (4, (6,7)) (4, (6,8)) (5, 7) (5, (6,7)) (5, (6,8)) (7, 7) (7, (6,7)) (7, (6,8)) defs after use in loop, these are valid DU pairs No def-clear path … different scope for i No path through graph from nodes 5 and 7 to 4 or 3

DU Paths for Stats variable DU Pairs DU Paths numbers (1, 4) (1, 5) (1, 7) [ 1, 2, 3, 4 ] [ 1, 2, 3, 5 ] [ 1, 2, 3, 5, 6, 7 ] length (1, 8) (1, (3,4)) (1, (3,5)) (1, (6,7)) (1, (6,8)) [ 1, 2, 3, 5, 6, 8 ] med (5, 8) [ 5, 6, 8 ] var (8, 8) No path needed sd sum (4, 4) (4, 5) [ 4, 3, 4 ] [ 4, 3, 5 ] variable DU Pairs DU Paths mean (5, 7) (5, 8) [ 5, 6, 7 ] [ 5, 6, 8 ] varsum (7, 7) (7, 8) [ 7, 6, 7 ] [ 7, 6, 8 ] i (2, 4) (2, (3,4)) (2, (3,5)) (4, 4) (4, (3,4)) (4, (3,5)) (5, (6,7)) (5, (6,8)) (7, (6,7)) (7, (6,8)) [ 2, 3, 4 ] [ 2, 3, 5 ] [ 4, 3, 4 ] [ 4, 3, 5 ]