Static Analysis

Subscribe to Static Analysis: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get Static Analysis: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

Static Analysis Authors: AppDynamics Blog, Jason Bloomberg, RealWire News Distribution, Skytap Blog, Jayaram Krishnaswamy

Related Topics: SOA & WOA Magazine, Java Developer Magazine, Static Analysis

SOA & WOA: Article

Flow Analysis: Static Analysis on Steroids

How and why to add flow analysis to your existing testing strategies

There are three main types of software bugs:
Poorly implemented requirements - The software doesn't operate as expected because the functionality defined in the requirements was implemented incorrectly.
Missing or incomplete requirements - The software doesn't perform necessary operations or handle feasible scenarios because the stakeholders/designers didn't anticipate the need for such functionality and didn't specify requirements for it, or because the developers failed to implement a specified requirement.
Confused user - The software was designed in a way that lets confused users take unexpected paths.

Building a robust regression suite is the best way to identify poorly implemented requirements, and performing negative testing is the best way to identify confused user errors. However, finding missing requirements is difficult because it's not clear what you're looking for. Flow analysis, which basically analyzes paths through the code without executing it, is the only known automated testing technique that leads you to such problems. For instance, assume that flow analysis identified a NullPointerException in a Java application. If you examine the path that led to the exception, then consider the conditions under which the program might end up going down this path, you might find a missing requirement - for instance, the exception could be caused by a certain situation that's feasible but was never anticipated during the design/planning phase. Such problems wouldn't be noticed if testing focused solely on writing tests that verify requirements.

Besides pointing to missing requirements, flow analysis also can expose construction problems and logical flaws in an application. It's designed to be used as part of a comprehensive regression test suite that also includes pattern-matching static analysis, JUnit tests, Cactus tests, HttpUnit tests, and any other tests you use to verify the software. Running the complete regression test suite - including flow analysis and all the other tests - automatically and regularly is the most effective way to determine if code modifications/additions introduced new problems, broke existing functionality, or caused unexpected side effects.

This article examines why and how to add flow analysis to your existing testing strategies. After introducing the general concept and benefits of flow analysis, it demonstrates how flow analysis helps you find critical runtime bugs without executing code.

Static Code Flow Analysis - Background
The term static code analysis means different things to different people in the software industry. There seems to be two main static analysis approaches: (1) program execution or flow-based analysis and (2) pattern-based analysis.

For program execution adherents, static analysis means trying to logically execute the program - sometimes symbolically - to uncover code problems such as memory corruption, leaks, and exceptions. This type of testing largely focuses on identifying code problems without creating test cases. It provides developers with the "instant feedback" they need to address defects and security vulnerabilities quickly on the desktop - while they're still working on the code and it's fresh in their minds - and it prevents defects and vulnerabilities from making their way further downstream in the software development process, which is where they're much more expensive to identify and remediate.

Flow analysis can be done using automated technologies that determine whether the application's execution paths match "suspicious behavior" profiles. For each defect found, a hierarchical flow path details the complete execution path that leads to the identified defect, ending with the exact line of code where the bug manifests itself. In some cases, the analysis configurations can be customized to make the analysis process more flexible and tailored to your unique project needs. As a result, flow analysis can even be used to detect violations bound to the use of very specific APIs.

Using flow analysis, development teams gain the following key benefits:
Perform more comprehensive testing with existing resources: Flow analysis complements other testing techniques by letting you find problems that would otherwise require the development, execution, and maintenance of complex test cases. The defects exposed by flow analysis would be very difficult and time-consuming to find through manual testing or inspections, and would be exponentially more costly to fix if they weren't detected until runtime. Flow analysis lets developers quickly find, diagnose, and fix classes of software errors that can evade pattern-based static analysis and/or unit testing. Exposing these defects early in the software development lifecycle saves hours of diagnosis and potential rework.
Automatically identify defects that pass through multiple classes: Most developers have done thorough testing on a class, corrected all the apparent problems, integrated the code then later encountered problems, such as NullPointerExceptions, that took days to diagnose because they resulted from an obscure or complex execution path that passed through multiple methods or even multiple packages. Using flow analysis, the same problem can be identified in seconds.
Focus on actual defects and misuses: Flow analysis results typically indicate actual misuse (as opposed to the possible/hypothetical misuse that might be reported during unit testing). For example, flow analysis shouldn't report a violation for the following code unless there was a method in the source code calling strlen and passing it a null value, but unit testing could report a problem regardless by passing null to the strlen method in the test:

       public int strlen(String str)
       return str.length();

More Stories By Nada daVeiga

Nada daVeiga is the Product Manager of Java Solutions at Parasoft, where she has been a senior member of Professional Services team for two years. Nada's background includes development of service-oriented architecture for integration of rich media applications such as Artesia Teams, IBM Content Manager, Stellent Content Server and Virage Video Logger. Nada developed J2EE enterprise applications and specialized in content transport frameworks using XML, JMS, SOAP, and JWSDP technologies. As a presales engineer, Nada worked with clients such as Cisco, Fidelity, HBO and Time Warner. Nada holds a bachelors degree in computer science from the University of California, Los Angeles (UCLA).

Comments (1)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.