Page 287 - DCAP305_PRINCIPLES_OF_SOFTWARE_ENGINEERING

Unit 14: Flow Based Testing Process

2. Conduct a series of tests that simulate bad data or other potential errors at the software Notes
interface,

3. Record the results of tests to use as “evidence” if finger-pointing does occur, and
4. Participate in planning and design of system tests to ensure that software is adequately
tested.
System testing is actually a series of different tests whose primary purpose is to fully exercise
the computer-based system. Although each test has a different purpose, all work to verify that
system elements have been properly integrated and perform allocated functions. In the sections
that follow, we discuss the types of system tests that are worthwhile for software-based systems.
Recovery Testing
Many computer based systems must get better from faults and resume processing within a pre-
specified time. In some cases, a system must be fault 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
verifies that recovery is properly performed. If recovery is automatic (performed by the system
itself), re-initialization, check pointing 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.
Security Testing
Any computer-based system that manages sensitive information or causes proceedings that can
improperly harm (or benefit) individuals is a target for improper or illegal diffusion. Penetration
spans a 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 penetrate
for illicit personal increase.
Security testing attempts to verify that protection mechanisms built into a system will, in
fact, protect it from indecent penetration. 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.”
During security testing, the tester plays the role(s) of the individual who desires to penetrate the
system. Anything goes? The tester may attempt to acquire passwords through external clerical
means; may attack the system with custom software designed to breakdown any defenses that
have been constructed; may overwhelm the thereby denying service to others; may purposely
cause system errors, hoping to penetrate during recovery; may browse through insecure data,
hoping to find the system entry.
Stress Testing
During earlier software testing steps, white-box and black-box techniques resulted in thorough
evaluation of normal program functions and performance. Stresses are designed to confront
programs with abnormal situations. In essence, the taster who performs stress testing asks: How
high can we crank this up before it fails.
Stress testing executes a system in a manner that demands resources in abnormal quantity,
frequency, or volume.
For example:
1. special tests may be designed that generate ten interrupts per second, when one or two
is the average rate,
2. Function data rates may be increased by an order of magnitude to determine how function
will respond,

LOVELY PROFESSIONAL UNIVERSITY 281