Testing and Debugging - PowerPoint PPT Presentation

1 / 6
About This Presentation
Title:

Testing and Debugging

Description:

likes to break things! a good tester is one who. likes to fix things! ... method based on the contract (look at the requires/ensures clauses, respectively) ... – PowerPoint PPT presentation

Number of Views:18
Avg rating:3.0/5.0
Slides: 7
Provided by: brucew5
Category:

less

Transcript and Presenter's Notes

Title: Testing and Debugging


1
Testing and Debugging
a good tester is one who likes to break things!
a good tester is one who likes to fix things!
  • Testing is the process of trying to force
    software to exhibit its defects (violations of
    contracts)
  • Debugging is the process of identifying and
    fixing such defects

2
Testing a Class Step 1
this is normally an entire class, not just a
single method
a good way to present a test case is with a
tracing table
  • Create a test plan, i.e., a set of test cases,
    each of which has
  • A set of input values to a method of the unit
    under test (UUT)
  • A set of expected output values, based on the
    methods contract

3
Testing a Class Step 2
this can be tricky
  • Carry out the test plan, i.e., write a test
    driver program that for each test case
  • Constructs the test case input values of the test
    case
  • Executes the method
  • Compares the actual output values of the method
    to the expected output values of the test case

this can be tricky
this is often just main in the UUT!
4
Test Case Selection
sometimes called black-box testing
sometimes called white-box testing or clear-box
testing
  • Test cases can be
  • Specification-based, i.e., selected based on the
    interface contract the UUT is supposed to
    implement
  • Code-based, i.e., selected based on the code of
    the UUT
  • What are some pros and cons of both?

5
Test Coverage Black Box
  • Partition the input space and output space for
    each method based on the contract (look at the
    requires/ensures clauses, respectively)
  • Include at least one test case from each partition

one good way to partition is to identify extreme
cases in the specification
6
Test Coverage White Box
if (condition) branch1 else branch2
if (conditionA) branch1 else
branch2 if (conditionB) branch3 else
branch4
each of these is stronger than the one before it
  • Statement coverage
  • Make sure each statement is executed at least
    once
  • Branch coverage
  • Make sure each branch is executed at least once
  • Path coverage
  • Make sure each path is executed at least once
Write a Comment
User Comments (0)
About PowerShow.com