Steps in Top Down Integration Testing

Top-down testing is a type of incremental integration testing approach in which testing is done by integrating or joining two or more modules by moving down from top to bottom through control flow of architecture structure. In these, high-level modules are tested first, and then low-level modules are tested. Then, finally, integration is done to ensure that system is working properly. Stubs and drivers are used to carry out this project. This technique is used to increase or stimulate behavior of Modules that are not integrated into a lower level.

Processing :
Following are the steps that are needed to be followed during processing :

1. Test driver represents main control module also known as a high-level module and stubs are generally used for all low-level modules that directly subordinate (present or rank below another) to high-level modules.
2. In this, testing takes place from to bottom. So, too or high-level modules are tested first in isolation.
3. After this, low-level modules or subordinated modules or stubs replace high-level module one by one at a time. This can be done using methods like depth-first or breadth search.
4. The process is repeated until each module is integrated and tested.
5. Another stub replaces present real or control module after completion of each set of tests. These stubs act as s temporary replacement for a called module (stubs) and give same result or output as actual product gives.
6. To check if there is any defect or any error occurred or present, regression testing is done and it’s important to reduce any side effect that might be caused due to errors occurred.

Shortcomings :
Following are some of logical problems that might arise in top-down integration testing :

1. Upper models or high levels modules should be tested properly to maintain quality and for processing lower-level modules or stubs of top-down testing.
2. As we know that in this type of pf testing, stubs temporarily replace a lower-level module, but data do not move upwards with this replacement. Due to this, testing cannot be done on time which results in delays in testing.
3. Due to replacement, stubs might become more and more complex after each replacement.
4. Losing control over correspondence between specific tests and specific modules is main problem that might arises during process.
5. Sometimes, modules at lower levels are tested inadequately (unsatisfactory that lacks quality).

Example –
In the top-down integration testing, if depth-first approach is adopted then we will start integration from module M1. Then we will integrate M2, then M3, M4, M5, M6, and at last M7.

In the top-down integration testing, if breadth-first approach is adopted, then we will integrate module M1 first, then M2, M6. Then we will integrate module M3, M4, M5, and at last M7.

Advantages :

• There is no need to write drivers.
• Interface errors are identified at an early stage and fault localization is also easier.
• Low-level utilities that are not important are not tested well and high-level testers are tested well in an appropriate manner.
• Representation of test cases is easier and simple once Input-Output functions are added.

Disadvantages :

• It requires a lot of stubs and mock objects.
• Representation of test cases in stubs can be not easy and might be difficult before Input-Output functions are added.
• Low-level utilities that are important are also not tested well.

My Personal Notes arrow_drop_up

Save