Computational Models

Sequential processing of program statements is the "default" model of computation. In this section we will discuss some other models and briefly talk about the testing implications of each.

Concurrent

The concurrent model of computation introduces a logical notion of multiple things happening at the same time. Physically it may or may not be possible for two things to happen at the exact same time, but a design must be constructed to assume that things are happening at the same time. The introduction of light-weight threads into recent operating systems have made this model easy to realize.

Testing for concurrency defects should focus on those points at which two threads interact. Methods should receive the typical testing described in Chapter 5 before being exercised in an interaction setting. The interaction tests, which we began talking about in Chapter 6, should provide opportunity for two or more clients to request the same service. But more about this later in the chapter (see Path Testing in Distributed Systems, on page 275).

Parallel

The parallel model of computation uses a set of physical processors to achieve true physically concurrent computing. As many computations as processors may proceed at exactly the same time. There are various definitions of this term but a "parallel computer" is usually taken to be one in which these multiple processors share a common high-speed data bus and are thought to be in the same "box." The National Oceanic and Atmospheric Administration (NOAA) uses a computer with over two thousand processors to compute forecasts from vast quantities of measurements from around the world. We will not discuss the issues associated with this model.

Networked

In this model, physical concurrency is achieved by linking together separate boxes with communication devices that operate at a slower speed than the internal data bus. This is a model we will consider because it is applicable to such heavily used systems as the Internet. One of the testing problems associated with networked computing is the difficulty in synchronizing the many independent machines that comprise a networked system. This can make it difficult to determine how thoroughly an implementation has been tested because the times at which events occurred are measured in terms of each local clock. Without getting into the details of networking and Web communication, we will discuss some techniques for testing systems that incorporate a Web component.

Distributed

Distributed systems use multiple processes to support a flexible architecture in which the number of participating objects can change. Although the objects of a system can be distributed across multiple processes on the same machine, they are usually distributed across multiple physical computers. These distributed components must be able to locate the other components with which they must interact. An object variously named the "Naming Service" or registry or some other name is known to all the components. In some cases a configuration file lists the machines that are authorized to participate in the system. These and other pieces constitute what we will refer to as the infrastructure of the distributed system. This infrastructure may be standardized and reusable across a number of systems with little or no modification. We will consider a number of issues related to testing these distributed components and systems.