1 / 9

CS527: Advanced Topics in Software Engineering (Software Testing and Analysis)

CS527: Advanced Topics in Software Engineering (Software Testing and Analysis). Darko Marinov September 11, 2008. Schedule. Aug 26 & 28: Intro, reading/writing papers Sep 2: Random testing Sep 4: Refactoring (Jeff Overbey) Sep 9: Testing refactoring engines

kelly-shelton
Download Presentation

CS527: Advanced Topics in Software Engineering (Software Testing and Analysis)

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. CS527: Advanced Topics in Software Engineering(Software Testing and Analysis) Darko Marinov September 11, 2008

  2. Schedule • Aug 26 & 28: Intro, reading/writing papers • Sep 2: Random testing • Sep 4: Refactoring (Jeff Overbey) • Sep 9: Testing refactoring engines • TODAY: Sep 11: Static analysis (more votes) • Sep 16: Model checking (fewer votes) • Sep 18 (and on): Testing (most votes)

  3. Paper Reports • Continue with four items for a while: • One good point • One bad point • One potential project • Goal: help you identify your projects • One question for discussion • If sent early, may be discussed in class • Looking for depth • No need to make reports (too) long

  4. Paper Today • Checking System Rules Using System-Specific, Programmer-Written Compiler Extensionsby Dawson Engler, Benjamin Chelf, Andy Chou, Seth Hallem (OSDI 2000) • One in a series of papers on meta-level compilation • Slides from Dawson Engler’s web page

  5. Brief Summary • Motivation • Use system-specific rules to check for bugs • Approach • Allow the programmer to specify the rules succinctly using a new language (metal) • Later work: infer rules automatically from the code • Automatically check the specified rules • Results (this paper) • 500+ correctness errors in four real systems • Some optimization improvements for FLASH

  6. Some Terms • No need to remember details; the point: there’re many approaches to static analysis • Abstract Interpretation • Dataflow Analysis • Flow-sensitive vs. flow-insensitive • Intra-procedural vs. inter-procedural • Context-sensitive vs. context-insensitive • “Data flow analysis is model checking of abstract interpretations” by David Schmidt(PLDI 1998)

  7. Your Questions (1) • What are we expected to get from this paper? • How to detect/prevent false positives? • Could code inspection or other practices (better) find these bugs? • How did they make the rules for different languages? • What are the limitations of this checking? • What time it takes to check typical software? • How to know if compiler works correctly? [PP]

  8. Your Questions (2) • Can static analysis be used… • …for commercial programs with unusual or highly specific business rules? [YYL] • …in other field (say refactoring engine)? [DY] • …during the software design process to improve quality and minimize errors? [DH] • …for other potential uses (of the metal SMs)? • Is the proposed approach really better than automatic testing? [ST] • How are static analysis and testing used in practice? [WX]

  9. More Questions • How the flow graph was generated to find the blocking routines in Linux (Section 6.1)? • How hard is it to write the checkers? • Can MC go across function boundary? • Catches only 1 double lock and 1 double unlock bug in Linux? • Why syntactical and not semantical? • Large number of false positives?

More Related