Static tests and analyses (such as reviews) can generally be performed on documents with any kind of structure, but tool-based static analysis relies on documents having as formal a structure as possible. For source code, the structure is prescribed by the syntax of the programming language, while formal specifications or models are governed by the syntax of the modeling language you use (UML, for example).
There are also tools designed to investigate informal documents written in natural language, which can, for example, check spelling, grammar, or readability. These, too, are classed as static analysis tools.
What all these tools have in common is that they do not analyze executable code. Static testing tools can therefore help to identify faults and inconsistencies at an early stage in a project (see the left-hand branch of the V-model in figure 3-2) or during early iterations in the development cycle. Identifying faults immediately or at least early on prevents the occurrence of follow-on defects and thus saves time and money overall.
Review support tools
Reviews are structured, manual checks performed according to the buddy principle (“two pairs of eyes are better than one”). Review support tools aid the planning, execution, and evaluation of reviews. They are used to manage information related to planned and past review meetings, participants, findings, and results. Verification aids such as checklists can be managed and provided online. Information collected during reviews can be evaluated and compared to estimate the overall effort involved and to plan subsequent reviews. Comparing review results also helps to bring weaknesses in the development process into the open, where they can be more effectively combated.
Review support tools are especially useful in projects being developed by multiple teams located in different countries or time zones. In such cases, online reviews are not only useful, but may also be the only really practicable solution.
Static analysis
Static analysis tools provide figures relating to various aspects of the code—for example, cyclomatic complexity3 or other code metrics. This kind of data can be used to identify particularly complex, error-prone (i.e., risky) blocks of code that can then be reviewed in more detail separately and manually.
Such tools can also be used to check that coding guidelines are adhered to (for example guidelines that support code security or code portability aspects). Checking HTML code for broken or invalid links is also a form of static analysis.
Our Tip Increase analytical detail step by step
- Static analysis tools list all “suspicious” places in the code, and such lists of findings can quickly become very long indeed. Most tools offer functionality for defining the scope and detail of the analysis. We recommend using a setting that keeps the number of findings small for an initial analysis, and you can always refine your settings later. These kinds of tools are only accepted if they are set up specifically to suit the project at hand.
Side Note: Analyzing data use
Data flow analysis is a good example of a static analytical technique. The aim of the process is to analyze data usage along its path(s) through the program code. Findings detected by this kind of tool are called “data flow anomalies” (or just “anomalies”). An anomaly is an inconsistency that can but doesn’t necessarily cause a failure. Anomalies need to be flagged as risks.
Examples for data flow anomalies are when a variable is referred to although it hasn’t been initialized or a reference to a variable without a value. The following three states of a variable need to be distinguished here:
- defined (d): the variable is assigned a value
- referenced (r): the variable’s value is referenced
- undefined (u): the variable has no defined value
Data flow anomalies
Three types of data flow anomalies can be distinguished:
- ur anomaly
An undefined variable value (u) is read on a path (r) - du anomaly
The variable has a value (d) that becomes invalid (u) without having been used in the meantime - dd anomaly
The variable receives a second value (d) on a program path without having used the first value (d)
Example of anomalies
The following examples illustrate data flow anomalies using a C++ code fragment. The function in question is designed to swap the integer parameters Max and Min using the variable Help if the value of Min is greater than that of Max:
void Swap (int& Min, int& Max) {
int Help;
if (Min > Max) {
Max = Help;
Max = Min;
Help = Min;
}
}Analyzing the variables’ usage reveals the following anomalies:
- ur anomaly for the variable HelpThe variable is only valid within the function and is first used on the right-hand side of an assignment. At this point it is referenced although its value has not been defined. The variable wasn’t initialized when it was declared (this kind of anomaly can be identified by most compilers if you set an appropriately high warning level).
- dd anomaly for the variable Max
The variable is used twice consecutively on the left-hand side of an assignment, and is thus assigned two values. Either the first assignment can be ignored or use of the first value (before the second assignment) has been overlooked. - du anomaly for the variable Help
The final statement assigns a value to the variable Help that cannot be used because the variable is only valid within the function.
Data flow anomalies are not usually obvious
The anomalies in our examples are obvious. However, don’t forget that—in “real-life code”—any number of other assignments using other variables could take place between the ones shown above, making the anomalies much more difficult to identify and easy to overlook during a review. Using a data flow analysis tool will give you a better chance of discovering anomalies like these.
Not every anomaly causes a failure. For example, a du anomaly won’t always have a direct effect, and the program can continue to run. Nevertheless, we need to ask why the assignment occurs at this point before the variable’s validity ends. It is always worth taking a closer look at the parts of a program that show anomalies, and you will usually find further inconsistencies if you do.
Model checkers
Like source code, specifications can be analyzed for certain attributes too, provided that they are written using some kind of formal modeling language or notation. Tools that do this job are called “model checkers”. They “read” the structure of a model while checking static attributes such as missing states, missing state transitions, and other inconsistencies. The specification-based test generators discussed in are often addons to static model checkers. This type of tool is particularly useful for developer-side test case generation.
Leave a Reply