Computing Reviews
Today's Issue Hot Topics Search Browse Recommended My Account Log In
Review Help
Search
DSD-Crasher: a hybrid analysis tool for bug finding
Csallner C., Smaragdakis Y.  Software testing and analysis (Proceedings of the 2006 International Symposium on Software Testing and Analysis, Portland, Maine, Jul 17-20, 2006)245-254.2006.Type:Proceedings
Date Reviewed: Feb 2 2007

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.

Reviewer:  Josep Silva Review #: CR133876 (0803-0279)
1) Nimmer, J.W.; Ernst, M.D. Automatic generation of program specifications. In Proc. 2002 ACM SIGSOFT International Symposium on Software Testing and Analysis (July, 2002), ACM, 2002, 229–239.
Bookmark and Share
  Reviewer Selected
 
 
Formal Methods (D.2.4 ... )
 
 
Program Verification (I.2.2 ... )
 
 
Reliability (D.2.4 ... )
 
 
Testing Tools (D.2.5 ... )
 
 
Software/ Program Verification (D.2.4 )
 
 
Testing And Debugging (D.2.5 )
 
Would you recommend this review?
yes
no
Other reviews under "Formal Methods": Date
On a method of multiprogramming
Feijen W., van Gasteren A., Springer-Verlag New York, Inc., New York, NY, 1999. Type: Book (9780387988702)
May 1 2000
Computer-Aided reasoning: ACL2 case studies
Kaufmann M. (ed), Manolios P. (ed), Moore J. Kluwer Academic Publishers, Norwell, MA,2000. Type: Divisible Book
Jul 2 2002
Architecting families of software systems with process algebras
Bernardo M., Ciancarini P., Donatiello L. ACM Transactions on Software Engineering and Methodology 11(4): 386-426, 2002. Type: Article
Mar 10 2003
more...

E-Mail This Printer-Friendly
Send Your Comments
Contact Us
Reproduction in whole or in part without permission is prohibited.   Copyright 1999-2024 ThinkLoud®
Terms of Use
| Privacy Policy