Beruflich Dokumente
Kultur Dokumente
Outline
Testing Strategy V-Model and W-Model Unit testing Integration Testing System Testing Acceptance Testing
Testing Strategy
Testing Strategy outlines in broad terms how to use testing to assess the extent to which the goal for a product has been met.
Testing Strategy
Testing Strategy integrates software test case designing methods into a well planned series of steps that results in the successful development of a software.
Testing begins at component level and works towards the integration of the entire system. Different testing techniques at different points of time. Testing is conducted by the developer and ITG. Testing and debugging are different, but debugging is accommodated in any testing strategy.
Testing often takes more project effort than any other software engineering activity. If it is conducted haphazardly, time is wasted, unnecessary effort is expended, and even worse, errors sneak through undetected.
Software Criticality
V&V
Verification
Are we building the product right? A set of activities that ensure that software correctly implements a specific function. Are we building the right product? A set of activities that ensure that the software is traceable to customer requirements.
Validation
Outline
Testing Strategy V-Model and W-Model Unit testing Integration Testing System Testing Acceptance Testing
The V-Model
10
The V-Model
11
The V-Model
12
The V-Model
13
The W-Model
14
Outline
Testing Strategy V-Model and W-Model Unit testing Integration Testing System Testing Acceptance Testing
15
Unit Testing
Testing of the smallest unit of software design i.e.; a module or a component. It is white-box oriented as well as black-box. Unit Testing is normally done by the developer of the unit.
16
Unit Testing
module to be tested
software engineer
17
The developer cannot test the module, he/she is building independently. Module may interact with other modules that are not yet developed. So, programmer uses the dummy subprograms to test his module/ component and these are stubs or driver. Driver and stubs are overhead.
18
Driver
accepts test data, passes it to the component to be tested, and prints relevant results
19
It serves to replace modules that are subordinate (called by) the component to be tested.
It uses the subordinate modules interface, may do little data manipulation, prints verification of entry, and returns control to the module undergoing testing.
20
driver
interface local data structures
module
stub
21
Outline
Testing Strategy V-Model and W-Model Unit testing Integration Testing System Testing Acceptance Testing
22
Integration
Building a system or sub-system from unit-tested components is called integration. There are two approaches to integrate a system:
1. 2.
23
Integration
Big-bang Approach
Put all the components together at once, at the same time.
Incremental Approach
Add components one by one. Two approaches are:
1. 2.
24
Integration Testing
It is a systematic technique for constructing the program structure while at the same time conducting tests to uncover errors associated with interfacing. Integration testing should be black-box testing with tests derived from the specification.
25
Start with high-level system and integrate from the top-down replacing individual components by stubs where appropriate.
As Modules/ Components subordinate to the main control module are incorporated into the structure in either a depth-first or breadth-first manner.
26
27
2.
3.
4.
5.
The main control module is used as a test driver and stubs are substituted for all components directly subordinate to the main control module. Depending on the integration approach selected (depth-first or depth-first), subordinate modules are replaced one at a time with actual components. Tests are conducted as each component is integrated. On completion of each set of tests , another stub is replaced with the real component. Regression testing may be conducted to ensure that new errors have not been introduced
28
Major decision points are verified early in the test process. Using depth-first integration, a complete function of the software may be implemented. Stubs are required which are overhead. Problems occur when processing at low levels in the hierarchy is required to test upper levels. No significant data flow upward in the program structure until all the stubs are replaced by the actual components.
Cons
29
30
Low-level modules are combined into clusters that perform a specific software function. A driver is written to co-ordinate test case input and output. The cluster is tested. Drivers are removed and clusters are combined moving upwards in the program structure.
31
Bottom-up Integration
32
Pros
Processing required for components to a given level is always available. The need for stubs is eliminated. As integration moves upward, the need for separate test drivers lessens. The program as an entity does not exist until the last module is added.
Cons
33
Sandwich Testing
In practice, most integration involves a combination of bottom-up and top-down integration testing approaches, called Sandwich Testing. Top-down for upper levels. Bottom-up for lower levels.
34
A Final Picture
Bottom - Up Integration Time to get working program Drivers Stub Parallelism Test specification Product control seq. Early Late
Big Bang
Sandwich Early
Late
Early
Easy
Hard
Easy
Hard
35
Regression Testing
Each time a new module is added as part of integration testing, or a bug is fixed in the software, the software changes. These changes may introduce some new defects. Regression testing is the re-execution of some subset of tests that have already been conducted to ensure that changes have not generated unintended side effects.
36
Smoke Testing
37
Smoke Testing
Synchronize and Stabilize product is smoke tested daily. approach The integration approach may be top-down or bottom-up.
38
Integration risk is minimized. The quality of the end-product is improved. Error diagnosis and correction are simplified. Progress is easier to assess.
39
Outline
Testing Strategy V-Model and W-Model Unit testing Integration Testing System Testing Acceptance Testing
40
System Testing
A series of tests to verify that all system elements have been properly integrated. A series of different tests whose primary purpose is to fully exercise the computer-based system.
41
Recovery Testing Forces software to fail in a variety of ways and verifies that recovery is properly performed. Security Testing Attempts to verify the softwares protection mechanisms. The software designer tries to make penetration cost more than the value of information obtained by breaking in.
42
Stress Testing
Executes the system in a manner that demands resources in abnormal quantity, frequency or volume. Exercises the system beyond its maximum design load. Attempts to uncover data combination within valid input classes that may cause instability or improper processing.
Sensitivity Testing
43
Performance Testing
To test the run time performance of a system within the context of an integrated system. Occurs throughout all steps in testing process, means during unit testing and integration testing etc.
44
Outline
Testing Strategy V-Model and W-Model Unit testing Integration Testing System Testing Acceptance Testing
45
Acceptance Testing
It provides final assurance that software meets all functional, behavioral, and performance requirements. Whether the software under test functions in a manner that can reasonably be expected by the customer. Does it conforms to the specification?
46
Alpha Testing
Beta Testing
47
References
Sommerville, Ian Software Engineering 6th edition. Pressman, Roger Software Engineering, A Practitioners Approach6th edition. Mayer The Art of Software Testing 2nd edition.
48
Outline
Testing Strategy V-Model and W-Model Unit testing Integration Testing System Testing Acceptance Testing
49