Graph Coverage for Design Elements CS 4501 / 6501 Software Testing

Slides:



Advertisements
Similar presentations
Graph Coverage for Design Elements 1.  Use of data abstraction and object oriented software has increased importance on modularity and reuse.  Therefore.
Advertisements

Paul Ammann & Jeff Offutt
Graph Coverage (2).
Introduction to Software Testing Chapter 9.2 Challenges in Testing Software – Software Testability Paul Ammann & Jeff Offutt
Introduction to Software Testing Chapter 2.1, 2.2 Overview Graph Coverage Criteria Paul Ammann & Jeff Offutt
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.
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
Introduction to Software Testing Chapter 7.1 Engineering Criteria for Technologies Paul Ammann & Jeff Offutt
Overview Graph Coverage Criteria ( Introduction to Software Testing Chapter 2.1, 2.2) Paul Ammann & Jeff Offutt.
Software Testing and Maintenance Lecture 4 Graph Coverage for Design Element Paul Ammann & Jeff Offutt Instructor: Hossein Momeni Mazandaran.
Cohesion and Coupling CS 4311
1 Graph Coverage (4). Reading Assignment P. Ammann and J. Offutt “Introduction to Software Testing” ◦ Section
1 Introduction to Software Testing. Reading Assignment P. Ammann and J. Offutt “Introduction to Software Testing” ◦ Chapter 1 2.
Software Verification Graph Model 2. 2 Graph Coverage Four Structures for Modeling Software Graphs Logic Input Space Syntax Use cases Specs Design Source.
Introduction to Software Testing Chapter 2.3 Graph Coverage for Source Code Paul Ammann & Jeff Offutt
Paul Ammann & Jeff Offutt
Introduction to Software Testing (2nd edition) Chapter 7.4 Graph Coverage for Design Elements Paul Ammann & Jeff Offutt
Software Testing and Maintenance Lecture 2.1 Overview Graph Coverage
Introduction to Software Testing Chapter 7.1 Engineering Criteria for Technologies Paul Ammann & Jeff Offutt
Graph Coverage for Design Elements 1.  Use of data abstraction and object oriented software has increased importance on modularity and reuse.  Therefore.
1 Graph Coverage (3). Reading Assignment P. Ammann and J. Offutt “Introduction to Software Testing” ◦ Section 2.2 ◦ Section
Introduction to Functions CSIS 1595: Fundamentals of Programming and Problem Solving 1.
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;
Coupling-based Criteria for Integration Testing Journal of Software Testing, Verification, and Analysis, 8(3): , September 1998, Jenny Jin and Jeff.
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)
Introduction to Software Testing (2nd edition) Chapter 5 Criteria-Based Test Design Paul Ammann & Jeff Offutt
Paul Ammann & Jeff Offutt
Paul Ammann & Jeff Offutt
Visit for more Learning Resources
Testing Object-Oriented Software Test Coverage Criteria
Paul Ammann & Jeff Offutt
Software Testing and Maintenance 1
Paul Ammann & Jeff Offutt
Paul Ammann & Jeff Offutt
Input Space Partition Testing CS 4501 / 6501 Software Testing
Graph Coverage for Specifications CS 4501 / 6501 Software Testing
Paul Ammann & Jeff Offutt
Graph Coverage for Design Elements CS 4501 / 6501 Software Testing
White-Box Testing Techniques II
Paul Ammann & Jeff Offutt
Dataflow Testing G. Rothermel.
Paul Ammann & Jeff Offutt
Program Slicing Baishakhi Ray University of Virginia
Paul Ammann & Jeff Offutt
Paul Ammann & Jeff Offutt
Paul Ammann & Jeff Offutt
White-Box Testing Techniques II
Introduction to Software Testing Chapter 3, Sec# 3.5
Paul Ammann & Jeff Offutt
Introduction to Software Testing Chapter 3.5 Logic Coverage for FSMs
Graph: Data Flow Coverage Criteria CS 4501 / 6501 Software Testing
Graph Coverage for Specifications CS 4501 / 6501 Software Testing
Sudipto Ghosh CS 406 Fall 99 November 16, 1999
Graph Coverage for Source Code
Paul Ammann & Jeff Offutt
Graph Coverage Criteria CS 4501 / 6501 Software Testing
Graph Coverage Criteria
UNIT V Run Time Environments.
White-Box Testing Techniques II
Graph Coverage Criteria
Paul Ammann & Jeff Offutt
Paul Ammann & Jeff Offutt
Paul Ammann & Jeff Offutt
Paul Ammann & Jeff Offutt
Software Testing and QA Theory and Practice (Chapter 5: Data Flow Testing) © Naik & Tripathy 1 Software Testing and Quality Assurance Theory and Practice.
Presentation transcript:

Graph Coverage for Design Elements CS 4501 / 6501 Software Testing [Ammann and Offutt, “Introduction to Software Testing,” Ch. 7.4]

Overview Use of data abstraction and OO software Emphasis on modularity and reuse Complexity in design Testing design of software becomes more important than in the past Graphs for the design are based on couplings between software components. Couplings are dependency relations between components Faults in one component (unit) may affect the coupled component (unit) Most test criteria for design require that connections among components be visited

Call Graph The most common graph for structural design testing Nodes represent methods (or units) Edges represent method calls Node coverage (method coverage) Call every method at least once B C D A F E Edge coverage (call coverage) Execute every call at least once Node F must be called at least twice, once from C and once from D Node and edge coverage of class call graphs often do not work well because individual methods might not all call each other

Data Flow for Design Elements Control connections among design elements are not effective at finding faults Data flow coverage can be applied to call graphs Data flow couplings are often more complex than control flow couplings When values are passed, they change names Many different ways to share data Analysis of defs and uses can be difficult Which uses a def can reach When software gets complicated, that indicates a source of faults

The primary issue is where the defs and uses occur Call Site Example The primary issue is where the defs and uses occur Caller Unit that invokes another unit A  B (x)  end A B (Y)  end B Statement or node where the call appears Call site Call interface Actual parameter Variable in the caller Callee Unit that is called Mapping of actual to formal parameters Formal parameter Variable in the callee The criteria require execution from definitions of actual parameters through calls to uses of formal parameters

Data Flow Couplings for Call Sites Types of couplings between caller and callee units: Parameter coupling Defined by parameter passing from caller to callee Return value coupling Defined by return value passing from callee to caller Shared data coupling Defined by shared variables between caller and callee External device coupling Defined by shared use of a device by caller and callee (e.g., a file)

Inter-Procedural DU Pairs To achieve confidence in the interfaces between integrated program units, variables defined in caller unit must be appropriately used in callee For a variable x that expresses a coupling between caller and callee Last-def of x Set of locations (or nodes) that last define x (def-clear) in one of the units (caller or callee) First-use Set of locations (or nodes) that first use x in the other unit (def-clear and use-clear path from the call site to the nodes)

Inter-Procedural DU Pairs Example Parameter coupling last-def of x: set of locations in caller that last define a call parameter x just before the call site first-use of x: set of locations in callee that first use a parameter a after the entry point Caller F x = 14  y = G(x)  print(y) last-def call site DU pair first-use Callee Return value coupling last-def of b: set of locations in callee that last define return result first-use of b: set of locations in caller that first use the result of the call after the call site G(a) print(a)  b = 42  return(b) first-use DU pair last-def last-defs and first-uses define coupling du-pairs

Inter-Procedural DU Pairs Example B(x) x = 3 2 1 4 3 Caller A B(int y) T = y Z = y Print(y) 10 11 12 13 Callee B Last Defs 2, 3 First Uses 11, 12 Coupling DU Pairs (A, x, 2)—(B, y, 11) (A, x, 2)—(B, y, 12) (A, x, 3)—(B, y, 11) (A, x, 3)—(B, y, 12) coupling du-path = path from a last-def to a first-use

Coupling DU-Paths and Coverage Criteria A coupling du-path for x is a path from a last-def of x to a first-use of x Data flow coverage criteria for coupling du-paths: All-Coupling-Defs Coverage (~All-Defs Coverage) For each last-def of x, cover at least one first-use All-Coupling-Uses Coverage (~All-Uses Coverage) For each last-def of x, cover every first-uses All-Coupling-DU-Paths Coverage (~All-DU-Paths Coverage) For each last-def of x, cover all paths to every first-uses

Example Quadratic Shared variables last-def Call site first-use

Example: Quadratic Coupling DU-Pairs Pairs of locations: method name, variable name, statement (main(), X, 12) – (Root(), A, 36) (main(), Y, 13) – (Root(), B, 36) (main(), Z, 14) – (Root(), C, 36) (main(), X, 19) – (Root(), A, 36) (main(), Y, 20) – (Root(), B, 36) (main(), Z, 21) – (Root(), C, 36) (Root(), Root1, 42) – (main(), Root1, 26) (Root(), Root2, 43) – (main(), Root2, 26) (Root(), Result, 39) – (main(), ok, 24) (Root(), Result, 44) – (main(), ok, 24)

Summary Call graphs are common and very useful ways to design integration tests Inter-procedural data flow is relatively easy to compute and results in effective integration tests The ideas of coupling data flow for OO software and web applications are preliminary and have not been used much in practice

Extra Slides If you may be interested in graph coverage for inheritance (will not be tested)

Inheritance and Polymorphism The most obvious graph for testing these OO features is the inheritance hierarchy Classes are not executable  the graph is not directly testable. To test the inheritance hierarchy graph, we need to instantiate objects for the classes A B C D A B C D a b d c Ideas of graph coverage for inheritance and polymorphism are preliminary and have not been widely used [noted by Offutt and Ammann]

Coverage on Inheritance Graph Node coverage: create at least one object for each class Weak because there is no execution Thus, we create an object for each class and then apply call coverage (execute every call at least once) A B C D OO call coverage Cover each node in the call graph of an object instantiated for each class in the inheritance hierarchy graph a b d2 d1 c All object call coverage Cover each node in the call graph of every object instantiated for each class in the inheritance hierarchy graph