Nimmer and Ernst [1] propose a bug-finding tool that follows a two-step approach to program analysis. The first step dynamically detects invariants to produce an input domain. For this purpose, the Daikon tool is used to track, at runtime, a testee’s variables and generalize their behavior to invariants. The second step statically analyzes the program within the restricted input domain. In this case, the ESC/Java tool is used. ESC/Java is able to derive abstract conditions under which the execution of a method being tested may terminate abnormally.
The authors extend this approach with a third step: the automatic generation of test cases to verify the results of the previous static analysis. The implementation of this step has been performed by using the bug-finding tool CnC, which combines ESC/Java and the JCrasher random testing tool. In essence, CnC takes error conditions inferred by ESC/Java, and produces test cases that are executed by JCrasher.
The paper also described how this new approach—called DSD-Crasher—has been implemented and tested. In particular, the authors remark that the new schema cannot be evaluated with the metrics used in Nimmer and Ernst’s work [1]. Consequently, they use another metric (end-to-end efficiency) to measure and compare their implementation.
The comparative study performed suggests that DSD-Crasher significantly reduces the number of false positives when finding bugs, making this method an improvement over previous approaches. The paper is clear and well written, and both the advantages and disadvantages of the method are described. However, for a nonexpert reader, the structure of the paper can be a bit confusing, due to the description of several debugging tools that are posteriorly needed to introduce DSD-Crasher. For this reason, I would suggest reading section 3.1 (the motivation) first, and then the rest of the paper.