Information Technology Reference
In-Depth Information
Propagation, infection, and execution (PIE) provides a behavioral set of measures that
assess how the structure and semantics of the software interact with its environment
(Voas, 1992). The code complexity metrics must be a function of the software's
semantics and environment in a robustness study. If they are, then they will be useful
for creating a more universally applicable robustness theory.
It is possible to use the three algorithms of the PIE model (Voas,
1996)—propagation analysis, infection analysis, and execution analysis in a robust-
ness study. Execution analysis provides a quantitative assessment of how frequently
a piece of code actually is executed with respect to the environment. For example,
a deeply nested piece of code, if viewed only statically, seems hard to reach. This
assumption could be false. If the environment contains many test vectors that toggle
branch outcomes in ways that reach the nested code, then executing this code will not
be difficult. Similarly, infection analysis and propagation analysis also quantitatively
assess the software semantics in the context of the internal states that are created at
runtime (Whittaker & Voas, 2000).
Software does not execute in isolation; it resides on hardware. Operating systems
are the lowest level software programs we can deal with, and they operate with
privileged access to hardware memory. Application software cannot touch memory
without going through the operating system kernel. Device drivers are the next
highest level. Although they must access hardware memory through an operating
system kernel, device drivers can interact directly with other types of hardware, such
as modems and keyboards.
Application software communicates with either device drivers or an operating sys-
tem. In other words, most software does not interact directly with humans; instead, all
inputs come from an operating system, and all outputs go to an operating system. Too
often, developers perceive humans as the only user of software. This misconception
fools testers into defining operational profiles based on how human users interact with
software. In reality, humans interact only with the drivers that control input devices.
The current practice for specifying an operational profile is to enumerate input
only from human users and lump all other input under abstractions called environment
variables. For example, you might submit inputs in a normal environment and then
apply the same inputs in an overloaded environment. Such abstractions greatly over-
simplify the complex and diverse environment in which the software operates. The
industry must recognize not only that humans are not the primary users of software
but also that they often are not users at all. Most software receives input only from
other software. Recognizing this fact and testing accordingly will ease debugging and
make operational profiles more accurate and meaningful. Operational profiles must
encompass every external resource and the entire domain of inputs available to the
software being tested. One pragmatic problem is that current software testing tools
are equipped to handle only human-induced noise (Whittaker & Voas, 2000).
Sophisticated and easy-to-use tools to manipulate graphical user interface (GUIs)
and type keystrokes are abundant. Tools capable of intercepting and manipulating
software-to-software communication fall into the realm of hard-to-use system-level
debuggers. It is difficult to stage an overloaded system in all its many variations, but
it is important to understand the realistic failure situations that may result.
Search WWH ::
Custom Search