At the beginning of this book, we stressed the fact that software is only one el- ement of a larger computer-based system. Ultimately, software is incorporated with other system elements (e.¢,, hardware, people, information), and a series of system integration and validation tests are conducted. These tests fall out- side the scope of the software process and are not conducted solely by software engineers. However, steps taken during software design and testing can greatly improve the probability of successful software integration in the larger system.22.8.1 Recovery Testing Many computer-based systems must recover from faults and resume processing with little or no downtime. In some cases, a system must be Faull tolerant; that is, processing faults must not cause overall system function to cease, In other cases, a system failure must be corrected within a specified period of time or severe economic damage will occur. Recovery testing is a system test that forces the software to fail in a variety of ways and verifics thal recovery is properly performed. If recovery is automatic (performed by the system itself), reinilializalion, checkpointing mechanisms, data recovery, and restart are evaluated for correctness. If recovery requires. human intervention, the mean-time-to-repair (MTTR) is evaluated to determine whether it is within acceptable limits.22.8.2 Security Testing Any computer-based system thal manages sensitive information or causes actions thal can improperly harm (or benefit) individuals is a target for improper or illegal penetration. Penetration spans 4 broad range of activities: hackers who attempt to penetrate systems for sport, disgruntled employees who attempt to penetrate for revenge, dishonest individuals who attempt to penatrate for i it personal gain. Security testing attompts to verify that protection mechanisms built into a sys- tem will, in fact, protect it from improper penciration. To quote Beizer [Beital: “The system’s security must, of course, be tested for invulnerability from frontal attack—but must also be tested for invulnerability from flank or rear attack.”22.8.3 Stress Testing Earlier sofiware testing steps result in thorough evaluation of normal program functions and performance, Stress tests are designed to confront programs with abnormal situations, In essence, the tester who performs stress testing asks: “How high can we crank this up before it fails?" Stress testing oxecutes a systom in a manner that demands resources in abnor- mal quantity, frequency, or volume. For example, (1) special tests may be dosignod that generale 10 interrupts per second, when one or two is the average rate, (2) input data rates may be increased by an order of magnitude to determine how input functions will respond, (3) test cases that require maximum memory or other re- sources are executed, (4) test cases that may cause thrashing in a virtual operating system are designed, (5) test cases that may cause excessive hunting for disk-resi- dent data are created. Essentially, (he tester altempts to break the program.22.8.4 Performance Testing For real-time and embedded systems, software that provides required function but does not conform to performance requirements is unacceptable. Performance testing is designed to test the run-time performance of software within the context of an integrated system. Performance testing occurs throughout all steps in the twsling process, Even al the unil level, the performance of an individual module may be assessed as (ests are conducted, However, it is not until all system elements are fully integrated that the true performance of a system can be ascertained.22.8.5 Deployment Testing In many cases, software must execute on a variety of platforms and under more than ono operating systom onvironment. Deployment testing, somotimes callod configuration testing, cxercises the software in each environment in which il is to operate. In addition, deployment testing examines all installation procedures and PART THREE QUALITY MANAGEMENT specialized installation software (e.g., “installers”) that will be used by customers, and all documentation that will bo used to introduce tho software to end users.