Introduction to Object Oriented Testing Methods

Object oriented testing begins in the small with a series of tests designed to exercise class operations and check whether errors exist as one class collaborates with other classes. Use based testing along with fault based testing is applied to integrated classes. In the end, use cases are used to uncover errors at software validation level.

Encapsulation can create a minor problem when testing because testing reports on concrete and abstract state of an object. Multiple inheritance complicates testing by increasing number of contexts for which testing is required. Black box testing methods are appropriate for object oriented systems as they are for systems developed using conventional software engineering methods.

The strategy for fault based testing is to hypothesize a set of possible faults and then derive the tests to prove each of that hypothesis. The effectiveness of these techniques depends on how testers see a plausible fault.

Inheritance complicates the testing process. even though the base class has been properly tested, there is a need to test all classes derived from it.

Scenario based testing will uncover errors that occur when any actor interacts with the software. It concentrates on what the user does and not what the product does. This type of testing uncovers interaction errors.

Surface structure is an externally observable structure of object oriented program. Testing surface structure is similar to black box testing. Deep structure refers to the internal technical details of object oriented program. It exercises dependencies, behaviors and communication mechanisms. It is similar to white box testing.

Object Oriented Testing Methods - Fault Based Testing

Object oriented system testing begins at different levels to uncover errors that may occur as classes collaborate with one another and subsystems communicate across architectural layers.
Actual object oriented testing begins with a series of tests designed to exercise class operations and check whether errors exists when a class collaborates with other classes.
Attributes and operations are encapsulated, testing operations outside of the class is unproductive. Encapsulation, an essential design concept, creates a minor obstacle during testing. Inheritance also leads to additional challenges for the test case designer. Multiple inheritance complicates testing further by increasing the number of contexts for which testing is required.
White box testing methods like basis path, loop testing or data flow techniques can help to ensure that every statement in an operation has been tested. Black box testing methods are also appropriate for object oriented systems as they are for systems developed using conventional software engineering methods.

FAULT BASED TESTING

The strategy for fault based testing is to hypothesize a set of plausible faults and then derive tests to prove each hypothesis. The objective of fault based testing within an object oriented system is to design tests that have a higher possibility of uncovering plausible errors. Test cases are designed to exercise the design or code and to determine whether faults exist. This approach is really no better than any random testing technique if faults in object oriented systems are implausible.

Three types of faults are encountered when integration testing looks for plausible faults in operation calls or message connections. These faults are:
- unexpected result.
- wrong operation/message used.
- incorrect invocation.
Integration testing applies to attributes as well as operations. Integration testing attempts to find errors in the client side and not the server.