- Basic Terminology
- Defects and Faults that Lead to Failure
- Defect Removal Versus Defect Survival
- Deriving New Exception Classes
- Protecting the Exception Classes from Exceptions
- Conclusion
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Defects and Faults that Lead to Failure
Failures occur at runtime during software operation. Failures are the result of a defect in hardware, software, or human operation. If the software isn’t running, it cannot encounter defects. Although this is an obvious statement, it’s important in understanding some of the distinctions between the responsibilities and activities of the testing phase versus those of the exception handler. Ideally, defects in the software are removed during the testing stages. The same would be true for hardware. As for defects in human operation, we would like to remove those defects through training and experience, but this is easier said than done. To keep matters simple, we’ll focus our discussion on defects in software. Table 2 describes the eight basic types of testing that should be performed on a piece of software prior to putting it into operation.
Table 2 Basic types of testing used during the software development process.
|
Type of Testing |
Description |
|
Validation testing |
A type of testing that provides evidence as to whether the software and its products satisfy the requirements of the user’s needs and intended use. |
|
Verification testing |
A type of testing that provides objective evidence as to whether the software conforms to requirements and satisfies the standards, practices, conventions, and criteria of the software development lifecycle processes. |
|
Black box testing |
A type of testing in which input to the system can be manipulated and the output is observed, but source code, internal data, and design documentation describing the system are not observed. |
|
Glass box testing |
A type of testing in which the tester examines design documents and code and observes during runtime the internal data and the steps taken by the algorithms. |
|
Stress testing |
A type of testing designed to push a component or a system up to and sometimes beyond its limits. Stress testing includes testing boundary conditions that help in determining what happens at the boundaries of the software. |
|
Integration testing |
A type of testing used to assemble components. The components are combined into logical groups, and each group is tested as a unit. The group can be subjected to the same type of tests to which units are subjected. As each component is added to the assembly, the number of elements that must be tested grows combinatorially. |
|
Regression testing |
A type of testing used to retest modules that have changed. Regression tests ensure that the changes to the component don’t cause it to lose functionality. |
|
Functional testing |
A type of testing in which every function of a module is identified and then tested separately. |