The fact   that testing and analysis tools are not yet widely used is most
likely due to the fact that most of them support rather clerical
tasks, e.g., "Capture and Play." Some compute rather fascinating
metrics such as, for example, the average length of the identifiers
used in the program (we're not making that up!), while offering no
real support in the most important task: Semantic analysis of, or
reasoning about, programs. In fact, clerical tasks constitute about 20%
of the development effort. Consequently, although it is nice to have
clerical things automated (as they are tedious and boring), the real
and interesting question: "Is the program working correctly or if it
is, typically, not the case, " Why is it not working?" is left up to the
programmer.

That situation should not be surprising: If reasoning about programs is
challenging to most humans then building a tool that provides a measure of
support is even a greater challenge. Having said that, due to the successful
research in the last two decades or so, some sophisticated
semantics-oriented tools have been built and their use seems to be more and
more accepted, particularly in safety-critical applications. Although those
tools come in a variety of forms, they usually fall into one or more of the
following three categories:

• Software Development Tools (SDT), which allow the software
  designer to specify and decompose (refine) the problem at hand and
  sometimes prove its properties
• Quality Assessment Tools (QAT), which pass (usually proscriptive)
  judgment on the existing code. An example: the detection of a use of
  uninitialized variables.
• Dependency Analysis Tools (DAT), which provide descriptive analysis
  of the program. An example: If an assignment to
  variable X in procedure P is changed, which are all the places in the
  program that are potentially affected by that change?

The following tools are available in the Lab
(observe the categories in the parentheses):

For more information click on one of the below: