Coverage Literature of software testing is primarily concerned with various notions of coverage Four basic kinds of coverage: Graph coverage Logic coverage.

Slides:



Advertisements
Similar presentations
1 Software Unit Test Coverage And Test Adequacy Hong Zhu, Patrick A. V. Hall, John H.R. May Presented By: Arpita Gandhi.
Advertisements

Predicate Complete Testing * Thomas Ball * Thomas Ball, A Theory of Predicate-Complete Test Coverage and Generation, Technical Report MSR-TR ,
Graph Coverage Criteria Structural Coverage Criteria : Defined on a graph just in terms of nodes and edges Data Flow Coverage Criteria : Requires a graph.
COVERAGE CRITERIA FOR TESTING 1. ill-defined terms in Testing  complete testing  exhaustive testing  full coverage Are poorly defined terms because.
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.
Topics in Testing We’ve Covered
Practical Approach to Teaching Software Testing Sashko Ristov 11th Workshop on “Software Engineering Education and Reverse Engineering” – August 22-27,
Unit Testing CSSE 376, Software Quality Assurance Rose-Hulman Institute of Technology March 27, 2007.
Software Testing Sudipto Ghosh CS 406 Fall 99 November 16, 1999.
1 Today Another approach to “coverage” Cover “everything” – within a well-defined, feasible limit Bounded Exhaustive Testing.
Basic Definitions: Testing
SOFTWARE TESTING WHITE BOX TESTING 1. GLASS BOX/WHITE BOX TESTING 2.
Topics in Software Dynamic White-box Testing: Data-flow Testing
A Complexity Measure THOMAS J. McCABE Presented by Sarochapol Rattanasopinswat.
Software Testing Sudipto Ghosh CS 406 Fall 99 November 9, 1999.
Topics in Software Dynamic White-box Testing Part 2: Data-flow Testing
Introduction to Software Testing Chapter 2.3 Graph Coverage for Source Code Paul Ammann & Jeff Offutt
Paul Ammann & Jeff Offutt
Class Specification Implementation Graph By: Njume Njinimbam Chi-Chang Sun.
CS4311 Spring 2011 Unit Testing Dr. Guoqiang Hu Department of Computer Science UTEP.
What is Software Testing? And Why is it So Hard J. Whittaker paper (IEEE Software – Jan/Feb 2000) Summarized by F. Tsui.
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.
Coverage – “Systematic” Testing Chapter 20. Dividing the input space for failure search Testing requires selecting inputs to try on the program, but how.
Introduction to Software Testing
Regression Testing. 2  So far  Unit testing  System testing  Test coverage  All of these are about the first round of testing  Testing is performed.
SWE 637: Test Criteria and Definitions Tao Xie Prepared based on Slides by ©Paul Ammann and Jeff Offutt Revised by Tao Xie.
Testing Testing Techniques to Design Tests. Testing:Example Problem: Find a mode and its frequency given an ordered list (array) of with one or more integer.
Test Coverage CS-300 Fall 2005 Supreeth Venkataraman.
637 – Introduction (Ch 1) Introduction to Software Testing Chapter 1 Jeff Offutt Information & Software Engineering SWE 437 Software Testing
White-box Testing.
White-Box Software Testing Methods Speaker: Jerry Gao Ph.D. San Jose State University URL:
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 Paul Ammann & Jeff Offutt Updated 24-August 2010.
Introduction to Software Testing. OUTLINE Introduction to Software Testing (Ch 1) 2 1.Spectacular Software Failures 2.Why Test? 3.What Do We Do When We.
1 Basic Definitions: Testing What is software testing? Running a program In order to find faults a.k.a. defects a.k.a. errors a.k.a. flaws a.k.a. faults.
CS412/413 Introduction to Compilers Radu Rugina Lecture 18: Control Flow Graphs 29 Feb 02.
1 Control Flow Graphs. 2 Optimizations Code transformations to improve program –Mainly: improve execution time –Also: reduce program size Can be done.
Static Techniques for V&V. Hierarchy of V&V techniques Static Analysis V&V Dynamic Techniques Model Checking Simulation Symbolic Execution Testing Informal.
1 Graph Coverage (3). Reading Assignment P. Ammann and J. Offutt “Introduction to Software Testing” ◦ Section 2.2 ◦ Section
1. Black Box Testing  Black box testing is also called functional testing  Black box testing ignores the internal mechanism of a system or component.
Workshop on Integrating Software Testing into Programming Courses (WISTPC14:2) Friday July 18, 2014 Introduction to Software Testing.
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;
White-Box Testing Techniques I Prepared by Stephen M. Thebaut, Ph.D. University of Florida Software Testing and Verification Lecture 7.
Software Testing and Maintenance Lecture 3 Graph Coverage for Source Code Paul Ammann & Jeff Offutt Instructor: Hossein Momeni Mazandaran.
Software Dynamic White-box Testing Part 2: Data-flow Testing Lecture 7 Prof. Mostafa Abdel Aziem Mostafa.
Chapter 2 : Graph Coverage (part 2)
CS223: Software Engineering Lecture 26: Software Testing.
1 Software Testing. 2 What is Software Testing ? Testing is a verification and validation activity that is performed by executing program code.
Introduction to Software Testing (2nd edition) Chapter 5 Criteria-Based Test Design Paul Ammann & Jeff Offutt
Software TestIng White box testing.
White-Box Testing Pfleeger, S. Software Engineering Theory and Practice 2nd Edition. Prentice Hall, Ghezzi, C. et al., Fundamentals of Software Engineering.
Software Testing and Maintenance 1
Graph Coverage Criteria CS 4501 / 6501 Software Testing
Paul Ammann & Jeff Offutt
Structural testing, Path Testing
White-Box Testing Techniques II
CHAPTER 4 Test Design Techniques
Dataflow Testing G. Rothermel.
White-Box Testing Techniques II
Sudipto Ghosh CS 406 Fall 99 November 16, 1999
Graph Coverage for Source Code
Graph Coverage Criteria CS 4501 / 6501 Software Testing
White-Box Testing Techniques I
White-Box Testing Techniques II
Whitebox Testing.
Paul Ammann & Jeff Offutt
Presentation transcript:

Coverage Literature of software testing is primarily concerned with various notions of coverage Four basic kinds of coverage: Graph coverage Logic coverage Input space partitioning Syntax-based coverage Two purposes: to know what we have & haven’t tested, and to know when we can “safely” stop testing

Need to Abstract Testing As we have seen, we can’t try all possible executions of a program How can we measure “how much testing” we have done and look for more things to test? Could talk about modules we have and have not tested, or use cases explored Could also talk structurally – what aspects of the source code have we tested?

Graph Coverage Cover all the nodes, edges, or paths of some graph related to the program Examples: Statement coverage Branch coverage Path coverage Data flow (def-use) coverage Model-based testing coverage Many more – most common kind of coverage, by far

Statement/Basic Block Coverage if (x < y) { y = 0; x = x + 1; } else x = y; Statement coverage: Cover every node of these graphs 4 1 2 3 x >= y x < y x = y y = 0 x = x + 1 3 1 2 x >= y x < y y = 0 x = x + 1 if (x < y) { y = 0; x = x + 1; } Treat as one node because if one statement executes the other must also execute (code is a basic block)

Branch Coverage if (x < y) { y = 0; x = x + 1; } else x = y; Branch coverage vs. statement coverage: Same for if-then-else 4 1 2 3 x >= y x < y x = y y = 0 x = x + 1 3 1 2 x >= y x < y y = 0 x = x + 1 if (x < y) { y = 0; x = x + 1; } But consider this if-then structure. For branch coverage can’t just cover all nodes, but must cover all edges – get to node 3 both after 2 and without executing 2!

Path Coverage How many paths through this code are there? Need one test case for each to get path coverage if (x < y) { y = 0; x = x + 1; } else x = y; 4 1 2 3 x >= y x < y x = y y = 0 x = x + 1 To get statement and branch coverage, we only need two test cases: 1 2 4 5 6 and 1 3 4 6 6 4 5 x >= y x < y y = 0 x = x + 1 Path coverage needs two more: 1 2 4 5 6 1 3 4 6 1 2 4 6 1 3 4 5 6 In general: exponential in the number of conditional branches!

Data Flow (Def-Use) Coverage 1 x = 3; y = 3; if (w) { x = y + 2; } if (z) { y = x – 2; n = x + y x = 3 Def(x) Annotate program with locations where variables are defined and used (very basic static analysis) 2 y = 3 Def(y) 5 3 4 !w w x = y + 2 Def-use pair coverage requires executing all possible pairs of nodes where a variable is first defined and then used, without any intervening re-definitions Def(x) Use(y) 7 4 6 !z z y = x - 2 Def means we write, Use means we use… E.g., this path covers the pair where x is defined at 1 and used at 7: 1 2 3 5 6 7 Def(y) Use(x) May be many pairs, some not actually executable But this path does NOT: 1 2 3 4 5 6 7 n = x + y Use(x) Use(y)

((a>b) || G)) && (x < y) ((a <= b) && !G) || (x >= y) Logic Coverage What if, instead of: if (x < y) { y = 0; x = x + 1; } 1 ((a>b) || G)) && (x < y) y = 0 x = x + 1 2 ((a <= b) && !G) || (x >= y) 3 we have: if (((a>b) || G)) && (x < y)) { y = 0; x = x + 1; } Now, branch coverage will guarantee that we cover all the edges, but does not guarantee we will do so for all the different logical reasons We want to test the logic of the guard of the if statement

Active Clause Coverage ( (a > b) or G ) and (x < y) 1 T F T T 2 F F T F With these values for G and (x<y), (a>b) determines the value of the predicate duplicate With these values for (a>b) and (x<y), G determines the value of the predicate 3 F T T T 4 F F T F With these values for (a>b) and G, (x<y) determines the value of the predicate 5 T T T T 6 T T F F 9

Input Domain Partitioning Partition scheme q of domain D The partition q defines a set of blocks, Bq = b1 , b2 , … bQ The partition must satisfy two properties: blocks must be pairwise disjoint (no overlap) together the blocks cover the domain D (complete) Coverage then means using at least one input from each of b1, b2, b3, . . . 10

Syntax-Based Coverage Usually known as mutant testing Bit different kind of creature than the other coverages we’ve looked at Idea: generate many syntactic mutants of the original program Coverage: how many mutants does a test suite kill (detect)? 11

Syntax-Based Coverage MUTANTS OF P Program P P 100% coverage means you kill all the mutants with your test suite 12