Testing Strategies
Strategy is a general approach rather than a
method of devising particular systems for component tests.
Different strategies may be adopted depending on the type of system to be tested and the development process used. The testing strategies are
Top-Down Testing
Bottom - Up Testing
Thread Testing
Stress Testing
Back- to Back Testing
1. Top-down testing
Where testing starts with the most abstract component and works downwards.
2. Bottom-up testing
Where testing starts with the fundamental components and works upwards.
3. Thread testing
Which is used for systems with multiple processes where the processing of a transaction threads its way through these processes.
4. Stress testing
Which relies on stressing the system by going beyond its specified limits and hence testing how well the system can cope with over-load situations.
5. Back-to-back testing
Which is used when versions of a system are available. The systems are tested together and their outputs are compared.
Different strategies may be adopted depending on the type of system to be tested and the development process used. The testing strategies are
Top-Down Testing
Bottom - Up Testing
Thread Testing
Stress Testing
Back- to Back Testing
1. Top-down testing
Where testing starts with the most abstract component and works downwards.
2. Bottom-up testing
Where testing starts with the fundamental components and works upwards.
3. Thread testing
Which is used for systems with multiple processes where the processing of a transaction threads its way through these processes.
4. Stress testing
Which relies on stressing the system by going beyond its specified limits and hence testing how well the system can cope with over-load situations.
5. Back-to-back testing
Which is used when versions of a system are available. The systems are tested together and their outputs are compared.
6. Performance testing.
This is used to test the run-time performance of software.
7. Security testing.
This attempts to verify that protection mechanisms built into system will protect it from improper penetration.
8. Recovery testing.
This forces software to fail in a variety ways and verifies that recovery is properly performed.
Large systems are usually tested using a mixture of these strategies rather than any single approach. Different strategies may be needed for different parts of the system and at different stages in the testing process.
Whatever testing strategy is adopted, it is always sensible to adopt an incremental approach to sub-system and system testing. Rather than integrate all components into a system and then start testing, the system should be tested incrementally. Each increment should be tested before the next increment is added to the system. This process should continue until all modules have been incorporated into the system.
When a module is introduced at some stage in this process, tests, which were previously unsuccessful, may now, detect defects. These defects are probably due to interactions with the new module. The source of the problem is localized to some extent, thus simplifying defect location and repai
Debugging
Brute force, backtracking, cause elimination.
This is used to test the run-time performance of software.
7. Security testing.
This attempts to verify that protection mechanisms built into system will protect it from improper penetration.
8. Recovery testing.
This forces software to fail in a variety ways and verifies that recovery is properly performed.
Large systems are usually tested using a mixture of these strategies rather than any single approach. Different strategies may be needed for different parts of the system and at different stages in the testing process.
Whatever testing strategy is adopted, it is always sensible to adopt an incremental approach to sub-system and system testing. Rather than integrate all components into a system and then start testing, the system should be tested incrementally. Each increment should be tested before the next increment is added to the system. This process should continue until all modules have been incorporated into the system.
When a module is introduced at some stage in this process, tests, which were previously unsuccessful, may now, detect defects. These defects are probably due to interactions with the new module. The source of the problem is localized to some extent, thus simplifying defect location and repai
Debugging
Brute force, backtracking, cause elimination.
|
Unit Testing
|
Coding
|
Focuses on each module and whether
it works properly. Makes heavy use of white box testing
|
|
Integration Testing
|
Design
|
Centered on making sure that each
module works with another module.
Comprised of two kinds: Top-down and Bottom-up integration. Or focuses on the design and construction of the software architecture. Makes heavy use of Black Box testing.(Either answer is acceptable) |
|
Validation Testing
|
Analysis
|
Ensuring conformity with
requirements
|
|
Systems Testing
|
Systems Engineering
|
Making sure that the software
product works with the external environment, e.g., computer system, other
software products.
|
Driver and Stubs
Driver: dummy main program
Stub: dummy sub-program
This is because the modules are not yet stand-alone programs therefore drive and or stubs have to be developed to test each unit.
Driver: dummy main program
Stub: dummy sub-program
This is because the modules are not yet stand-alone programs therefore drive and or stubs have to be developed to test each unit.
Some different types of tests, and
their level:
·
Unit Tests to test individual
classes or objects (default)
·
Acceptance tests / Functional tests
(everything)
·
Performance Tests: how fast it is
(extensive)
·
Load Tests: how it performs under a
large load (extensive)
·
Smoke Tests: fast tests for the key
functionality (mandatory)
·
Integration Tests: how the pieces
work together (default)
·
Mock Client Tests: tests from the
client's point of view (default)
