Path Testing + Coverage Chapter 9 Assigned reading from Binder.

Slides:



Advertisements
Similar presentations
Chapter 14 Software Testing Techniques - Testing fundamentals - White-box testing - Black-box testing - Object-oriented testing methods (Source: Pressman,
Advertisements

Chapter 14 Testing Tactics
Chapter 6 Path Testing Software Testing
1 ECE 453 – CS 447 – SE 465 Software Testing & Quality Assurance Lecture 11 Instructor Paulo Alencar.
SOFTWARE TESTING. INTRODUCTION  Software Testing is the process of executing a program or system with the intent of finding errors.  It involves any.
White Box Testing Techniques Dynamic Testing. White box testing(1) Source code is known and used for test design While executing the test cases, the internal.
Chapter 8: Path Testing Csci 565.
Testing an individual module
SOFTWARE TESTING WHITE BOX TESTING 1. GLASS BOX/WHITE BOX TESTING 2.
Software Testing and QA Theory and Practice (Chapter 4: Control Flow Testing) © Naik & Tripathy 1 Software Testing and Quality Assurance Theory and Practice.
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 methodology.
Fundamentals of Python: From First Programs Through Data Structures
Software Testing Sudipto Ghosh CS 406 Fall 99 November 9, 1999.
Software Systems Verification and Validation Laboratory Assignment 3
1 ECE 453 – CS 447 – SE 465 Software Testing & Quality Assurance Lecture 9 Instructor Paulo Alencar.
Fundamentals of Python: First Programs
1 ECE 453 – CS 447 – SE 465 Software Testing & Quality Assurance Instructor Kostas Kontogiannis.
Topics in Software Dynamic White-box Testing Part 2: Data-flow Testing
CS4311 Spring 2011 Unit Testing Dr. Guoqiang Hu Department of Computer Science UTEP.
©Ian Sommerville 2000 Software Engineering, 6th edition. Chapter 20 Slide 1 Defect testing l Testing programs to establish the presence of system defects.
CS4311 Spring 2011 Unit Testing Dr. Guoqiang Hu Department of Computer Science UTEP.
Reference Paulo Alencar, University of Waterloo Frank Tsui, Southern Polytechnic State University.
Agenda Introduction Overview of White-box testing Basis path testing
1 Software Testing. 2 Path Testing 3 Structural Testing Also known as glass box, structural, clear box and white box testing. A software testing technique.
1 Software Testing & Quality Assurance Lecture 14 Created by: Paulo Alencar Modified by: Frank Xu.
Test Coverage CS-300 Fall 2005 Supreeth Venkataraman.
White-box Testing.
Coverage Estimating the quality of a test suite. 2 Code Coverage A code coverage model calls out the parts of an implementation that must be exercised.
1 Program Testing (Lecture 14) Prof. R. Mall Dept. of CSE, IIT, Kharagpur.
BASIS PATH TESTING.
Control Structures - Selections - Repetitions/iterations (part 2) 1 -Based on slides from Deitel & Associates, Inc. - Revised by T. A. Yang.
Chapter 8 Path Testing. Path testing Path testing is a “design structural testing” in that it is based on detailed design & the source code of the program.
Overview Structural Testing Introduction – General Concepts
Theory and Practice of Software Testing
SOFTWARE TESTING. Introduction Software Testing is the process of executing a program or system with the intent of finding errors. It involves any activity.
Structural Testing Review Chapter Measuring Gaps and Redundancy We have seen that functional testing methods may produce test suites with serious.
1 Test Coverage Coverage can be based on: –source code –object code –model –control flow graph –(extended) finite state machines –data flow graph –requirements.
1 ECE 453 – CS 447 – SE 465 Software Testing & Quality Assurance Instructor Kostas Kontogiannis.
Cyclomatic Complexity Philippe CHARMAN Last update:
Structural (White-Box) Testing Software Testing Module Dr. Samer Hanna.
Dynamic White-Box Testing What is code coverage? What are the different types of code coverage? How to derive test cases from control flows?
SOFTWARE TESTING LECTURE 9. OBSERVATIONS ABOUT TESTING “ Testing is the process of executing a program with the intention of finding errors. ” – Myers.
CS223: Software Engineering Lecture 26: Software Testing.
Software TestIng White box testing.
BASIS PATH TESTING.
Software 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.
Control Flow Testing Handouts
Handouts Software Testing and Quality Assurance Theory and Practice Chapter 4 Control Flow Testing
Software Engineering (CSI 321)
Software Testing and Maintenance 1
CompSci 230 Software Construction
Paul Ammann & Jeff Offutt
Outline of the Chapter Basic Idea Outline of Control Flow Testing
Structural testing, Path Testing
White-Box Testing Techniques
Java Programming: Guided Learning with Early Objects
White-Box Testing.
Paul Ammann & Jeff Offutt
Chapter 9 Path Testing–Part 1
UNIT-4 BLACKBOX AND WHITEBOX TESTING
Software Testing (Lecture 11-a)
White-Box Testing.
Paul Ammann & Jeff Offutt
Whitebox Testing.
Whitebox Testing.
UNIT-4 BLACKBOX AND WHITEBOX TESTING
Software Testing.
Unit III – Chapter 3 Path Testing.
Presentation transcript:

Path Testing + Coverage Chapter 9 Assigned reading from Binder

2 Structural Testing Also known as glass/white/open box testing A software testing technique whereby explicit knowledge of the internal workings of the item being tested are used to select the test data Functional Testing uses program specification Structural Testing is based on specific knowledge of the source code to define the test cases and to examine outputs.

3 Structural Testing Structural testing methods are very amenable to: Rigorous definitions Control flow, data flow, coverage criteria Mathematical analysis Graphs, path analysis Precise measurement Metrics, coverage analysis

4 Program Graph - Definition Given a program written in an imperative programming language, its program graph is a directed graph in which nodes are statement fragments, and edges represent flow of control A complete statement is also considered a statement fragment

5 Program Graph - Example

6 DD-Path A decision-to-decision path (DD-Path) is a chain in a program graph such that: Case1: it consists of a single node with indeg=0 Case2: it consists of a single node with outdeg=0 Case3: it consists of a single node with indeg ≥ 2 or outdeg ≥ 2 Case4: it consists of a single node with indeg =1, and outdeg = 1 Case5: it is a maximal chain of length ≥ 1 DD-Paths are also known as segments

7 DD-Path Graph Given a program written in an imperative language, its DD-Path graph is a directed graph, in which nodes are DD-Paths of its program graph, and edges represent control flow between successor DD-Paths. Also known as Control Flow Graph

8 Control Flow Graph Derivation Straightforward process Some judgement is required The last statement in a segment must be a predicate, a loop control, a break, or a method exit Let’s try an example…

public int displayLastMsg(int nToPrint) { np = 0; if ((msgCounter > 0) && (nToPrint > 0)) { for (int j = lastMsg; (( j != 0) && (np < nToPrint)); --j) { System.out.println(messageBuffer[j]); ++np; } if (np < nToPrint) { for (int j = SIZE; ((j != 0) && (np < nToPrint)); --j) { System.out.println(messageBuffer[j]); ++np; } return np; }

10 Control flow graph for previous slide

11 Control flow graphs Depict which program segments may be followed by others A segment is a node in the CFG A conditional transfer of control is a branch represented by an edge An entry node (no inbound edges) represents the entry point to a method An exit node (no outbound edges) represents an exit point of a method

12 Control flow graphs An entry-exit path is a path from the entry node to the exit node Path expressions represent paths as sequences of nodes Loops are represented as segments within parentheses followed by an asterisk There are 22 different path expressions in our example

13 Example path expressions AL ABL ABCDGL ABCDEGL ABC(DEF)*DGL ABC(DEF)*DEGL ABCDGHIL ABCDGHIJL ABCDGH(IJK)*IL ABC(DEF)*DEGH(IJK)*IJL Full list of path expressions in the reading

14 Code coverage models Statement Coverage Segment Coverage Branch Coverage Multiple-Condition Coverage

15 Statement coverage Achieved when all statements in a method have been executed at least once A test case that will follow the path expression below will achieve statement coverage in our example One test case is enough to achieve statement coverage! ABC(DEF)*DGH(IJK)*IL

16 Segment coverage Segment coverage counts segments rather than statements May produce drastically different numbers Assume two segments P and Q P has one statement, Q has nine Exercising only one of the segments will give 10% or 90% statement coverage Segment coverage will be 50% in both cases

17 Statement coverage problems Predicate may be tested for only one value (misses many bugs) Loop bodies may only be iterated once Statement coverage can be achieved without branch coverage. Important cases may be missed String s = null; if (x != y) s = “Hi”; String s2 = s.substring(1);

18 Branch coverage Achieved when every path from a node is executed at least once At least one true and one false evaluation for each predicate Can be achieved with D+1 paths in a control flow graph with D 2-way branching nodes and no loops Even less if there are loops

19 Branch coverage problems Short-circuit evaluation means that many predicates might not be evaluated A compound predicate is treated as a single statement. If n clauses, 2 n combinations, but only 2 are tested Only a subset of all entry-exit paths is tested if (a == b) x++; if (c == d) x--;

20 Multiple-condition coverage All true-false combinations of simple conditions in compound predicates are considered at least once A truth table may be necessary Not necessarily achievable due to lazy evaluation or mutually exclusive conditions if ((x > 0) && (x < 5)) …

21 Dealing with Loops Loops are highly fault-prone, so they need to be tested carefully Simple view: Every loop involves a decision to traverse the loop or not A bit better: Boundary value analysis on the index variable Nested loops have to be tested separately starting with the innermost

22 Coverage usefulness 100% coverage is never a guarantee of bug-free software Coverage reports can point out inadequate test suites suggest the presence of surprises, such as blind spots in the test design Help identify parts of the implementation that require structural testing

23 Coverage example TEX and AWK are widely used programs with comprehensive test suites Coverage analysis showed SystemSegmentBranchP-useC-use TEX AWK

24 Is 100% coverage possible? Short-circuit evaluation Mutually exclusive conditions (x > 2) || (x < 10) Redundant predicates if (x == 0) do1; else do2; if (x != 0) do3; else do4; Dead code “This should never happen”

25 How to measure coverage? The source code is instrumented Depending on the code coverage model, code that writes to a trace file is inserted in every branch, statement etc. Most commercial tools measure segment and branch coverage

26 FAQ about Coverage Is 100% coverage the same as exhaustive testing? Are branch and path coverage the same? Can path coverage be achieved? Is every path in a control flow graph testable? Is less than 100% coverage acceptable? Can I trust a test suite without measuring coverage? When can I stop testing?

27 Some answers… When you run out of time When continued testing reveals no new faults When you cannot think of any new test cases When you reach a point of diminishing returns When mandated coverage has been attained When all faults have been removed

28 A coverage counter-example void Depository::give_change(int price) { int n_100, n_25, n_10, n_5; if (deposit <= price) { change_due = 0; } else { change_due = deposit-price; n_100 = change_due / 100; change_due = change_due – n_100*100; n_25 = change_due / 25; change_due = change_due – n_25*25; n_10 = change_due / 10; change_due = change_due – n_10*10; n_5 = change_due / 10; // A cut-and paste bug }