| We have discussed using life-cycle testing in Chapter 6, and we will continue the discussion in Chapter 9, as a technique that is applicable at various levels of development. We need to first determine what life cycle to use and then develop test cases based on it. For a distributed system, this life cycle may be measured by the lifetime of the infrastructure components instantiated to support the system. The test plan for the system should include a test run starting from nothing instantiated, followed by bringing the system up, executing a series of actions, and then bringing the system completely down. The following three important checks should be made to determine if this system test has succeeded: Did each of the actions carried out by the system complete successfully? Were all resources allocated by the system released after the system was terminated? Can the system successfully be restarted? (Or has the infrastructure stored a state that makes it impossible to restart?) | A life-cycle approach to testing implies that a series of test cases will be selected so that whatever is being tested is exercised from its creation to its destruction. Typically, there are many paths through the complete life cycle. The test plan should select representative paths to provide maximum coverage. For a class, life-cycle testing means choosing a series of tests that construct an instance of the class, use it through a series of messages, and then destroy the object. An effective life-cycle test should validate more than just correct answers. It should also validate that the item being tested interacts correctly with its environment. For a class, checking that after destruction all acquired resources have been released is a useful validation. Also checking that other elements with which the tested piece interacted are in correct states is a good idea. For example, when a server crashes, the "Naming Service" for a CORBA object request broker (ORB) might be corrupted and revert to a default setup. |
|