Structured Testing - McCabe and Associates

eing used during the testing process. It may have little or no connection to the likelihood of
errors manifesting once the system is delivered or to the total number of errors present in the
software.
Another common approach to testing is based on requirements analysis. A requirements specification
is converted into test cases, which are then executed so that testing verifies system behavior
for at least one test case within the scope of each requirement. Although this approach is an
important part of a comprehensive testing effort, it is certainly not a complete solution. Even
setting aside the fact that requirements documents are notoriously error-prone, requirements are
written at a much higher level of abstraction than code. This means that there is much more
detail in the code than the requirement, so a test case developed from a requirement tends to
exercise only a small fraction of the software that implements that requirement. Testing only at
the requirements level may miss many sources of error in the software itself.
The structured testing methodology falls into another category, the white box (or code-based, or
glass box) testing approach. In white box testing, the software implementation itself is used to
guide testing. A common white box testing criterion is to execute every executable statement
during testing, and verify that the output is correct for all tests. In the more rigorous branch coverage
approach, every decision outcome must be executed during testing. Structured testing is
still more rigorous, requiring that each decision outcome be tested independently. A fundamental
strength that all white box testing strategies share is that the entire software implementation
is taken into account during testing, which facilitates error detection even when the software
specification is vague or incomplete. A corresponding weakness is that if the software does not
implement one or more requirements, white box testing may not detect the resultant errors of
omission. Therefore, both white box and requirements-based testing are important to an effective
testing process. The rest of this document deals exclusively with white box testing, concentrating
on the structured testing methodology.
1.2 Software complexity measurement
Software complexity is one branch of software metrics that is focused on direct measurement of
software attributes, as opposed to indirect software measures such as project milestone status
and reported system failures. There are hundreds of software complexity measures [ZUSE],
ranging from the simple, such as source lines of code, to the esoteric, such as the number of
variable definition/usage associations.
An important criterion for metrics selection is uniformity of application, also known as “open
reengineering.” The reason “open systems” are so popular for commercial software applications
is that the user is guaranteed a certain level of interoperability—the applications work
together in a common framework, and applications can be ported across hardware platforms
with minimal impact. The open reengineering concept is similar in that the abstract models
2