From Failures to Faults

• Finding failure-inducing essence

• Minimization with Delta Debugging

• Algorithm: C={▲1 ,…, ▲n } with ▲i pairwise disjoint

  1. Test each ▲i plus its complement ▼i=C - ▲i

  2. If testing any ▲i fails: Split ▲i in n=2 halves and recurse. Classical divide and conquer.

  3. Otherwise, if testing any ▼i fails: Split ▼i in n-1 blocks and recurse Why n-1? Testing results of earlier invocation can be re-used!

  4. Otherwise, if no test failed, increase granularity – try again with 2*n subsets If 2*n larger than original test T, use |T|

  5. Repeat until granularity cannot be increased. Then, we have tried to remove any single element of a test.

• Fault localization with program / hit spectra

  • Check how often each block of the program is visited by passing and failing test cases.

  • Use similarity metrics to create a ranked list of similar blocks. (hard to choose metric)

• Fault localization based on code metrics

  • Do certain code properties affect software failures? (e.g., code complexity, problem domain, past history, or process quality)

  • Case study reveals significant correlation between complexity metrics and post-release defects.

  • But, different metrics correlate for each project.

• Fault localization based on code churn

  • Is the amount of change in a module an indicator for its error-proneness?

  • Promising results for single projects, but further research needs to be done.

• Reduce failure analysis time by clustering the failures

• Cluster encompasses failures caused by same fault

• investigate only one representative of the clusters

  
  

independent part of the program is associated with a program failure

-> Tackling the issue: take dynamic calls and explicit data-dependency graphs of failing tests into account