Section 11.6
System Development
11.6 Testing
11.6.1 Acceptance Testing
The tasks the finished system must perform in order to be accepted (by the user)
can be used as the basis for different tests.
11.6.2 Program Testing Strategies
Bottom-Up Testing
The individual modules are tested in a stand-alone fashion. The individual
modules are combined and tested. Finally, a system test is performed.
Top-Down Testing
The whole system (or at least a skeleton of it) is tested. Individual modules,
yet to be completed, are replaced by 'stubs'. Stubs often display a message on
screen to show that the module has been called.
11.6.3 The Test Plan
A test plan should be developed which will go through as many paths as possible
in the system.
For each test the following points should be included:
- the test's purposes.
- the test's location.
- a description of the test.
- testing procedure.
Test data should test the program to its limits.
It should include:
- data in the extremes
- invalid data
- commonly entered data
11.6.4 Objectives Of Testing
We need to ask:
Does the logic work properly?
- does it work as intended?
- any runtime errors?
Is all the logic present?
- any functions or sub-programs missing?
11.6.5 White And Black Box Testing
White Box Testing (or Logical Testing)
We test the program by examining the code and trying to test each possible path
in the program at least once.
Black Box Testing (or Functional Testing)
In Black Box we are not concerned with the program code. The progarm
specification is used as the basis for producing a set of test data that covers
all the inputs, outputs and program functions
11.6.6 Other Types Of Testing
Performance Testing
The system is tested to see if it can handle the volume of data anticipated
in the user environment.
Recovery Testing
Here we need to ensure that the system can recover from various types of
failure.
Such tests can be performed by simulating hardware or power failures.
