Evaluating the “ Small Scope Hypothesis ”

The “small scope hypothesis” argues that a high proportion of bugs can be found by testing the program for all test inputs within some small scope. In object-oriented pro grams, a test input is constructed from objects of different classes; a test input is within a scope of s if at mosts objects of any given class appear in it. If the hypothesis holds , it follows that it is more effective to do systematic testing within a small scope than to generate fewer test inputs of a larger scope. This paper evaluates the hypothesis for several implementations of data structures, including some from the Java Collections Framework. We measure how statement coverage, branch coverage, and rate of mutant killing vary with scope. For systematic input generation and correctness checking of Java programs, we use the Korat framework. This paper also presents the Ferastrau framework that we have developed for mutation testing of Java programs. The experimental results show that exhaustive testing within small scopes can achieve complete coverage and kill most of the mutants, even for intricate methods that manipulate complex data structures. The results also show tha t Korat can be used effectively to generate inputs and check correctness for these scopes.

[1]  Richard J. Lipton,et al.  Hints on Test Data Selection: Help for the Practicing Programmer , 1978, Computer.

[2]  Barbara Liskov,et al.  Program Development in Java - Abstraction, Specification, and Object-Oriented Design , 1986 .

[3]  Kent L. Beck,et al.  Extreme programming explained - embrace change , 1990 .

[4]  K. N. King,et al.  A fortran language system for mutation‐based software testing , 1991, Softw. Pract. Exp..

[5]  Neil J. A. Sloane,et al.  The encyclopedia of integer sequences , 1995 .

[6]  A. Jefferson Offutt,et al.  Mutation Operators for Ada , 1996 .

[7]  Frank Yellin,et al.  The Java Virtual Machine Specification , 1996 .

[8]  Márcio Eduardo Delamaro,et al.  Proteum - A Tool for the Assessment of Test Adequacy for C Programs User's guide , 1996 .

[9]  R. K. Shyamasundar,et al.  Introduction to algorithms , 1996 .

[10]  Daniel Jackson,et al.  Elements of style: analyzing a software design feature with a counterexample detector , 1996, ISSTA '96.

[11]  John A. Clark,et al.  The Rigorous Generation of Java Mutation Operators Using HAZOP , 1999 .

[12]  Kevin J. Sullivan,et al.  COM revisited: tool-assisted modelling of an architectural framework , 2000, SIGSOFT '00/FSE-8.

[13]  Anders Møller,et al.  The Pointer Assertion Logic Engine , 2000 .

[14]  John A. Clark,et al.  Class Mutation : Mutation Testing for Object-Oriented Programs , 2000 .

[15]  Shmuel Sagiv,et al.  TVLA: A System for Implementing Static Analyses , 2000, SAS.

[16]  Stephan Merz,et al.  Model Checking , 2000 .

[17]  Daniel Jackson,et al.  Finding bugs with a constraint solver , 2000, ISSTA '00.

[18]  Sarfraz Khurshid,et al.  Exploring the design of an intentional naming scheme with an automatic constraint analyzer , 2000, Proceedings ASE 2000. Fifteenth IEEE International Conference on Automated Software Engineering.

[19]  Kent Beck,et al.  Test-infected: programmers love writing tests , 2000 .

[20]  William Adjie-Winoto,et al.  The design and implementation of an intentional naming system , 2000, OPSR.

[21]  Sarfraz Khurshid,et al.  TestEra: a novel framework for automated testing of Java programs , 2001, Proceedings 16th Annual International Conference on Automated Software Engineering (ASE 2001).

[22]  A. Jefferson Offutt,et al.  Mutation 2000: uniting the orthogonal , 2001 .

[23]  Sarfraz Khurshid,et al.  Korat: automated testing based on Java predicates , 2002, ISSTA '02.

[24]  K. Beck,et al.  Extreme Programming Explained , 2002 .

[25]  Gary T. Leavens,et al.  A Simple and Practical Approach to Unit Testing: The JML and JUnit Way , 2002, ECOOP.