Top-Down Approach:

Top down integration is basically an approach where modules are developed and tested starting at the top level of the programming hierarchy and continuing with the lower levels.

It is an incremental approach because we proceed one level at a time. It can be done in either "Depth first" or "Breadth first" manner.

Depth first means we proceed from the top level all the way down to the lowest level.
Breadth first means that we start at the top of the hierarchy and then go to the next level. We develop and test all modules at this level before continuing with another level.

Steps:

Main control module used as the test driver, with stubs for all subordinate modules.
Replace stubs either depth first or breadth first.
Replace stubs one at a time.
Test after each module integrated.

Use regression testing (conducting all or some of the previous tests) to ensure new errors are not introduced.

Features:

· Control program is tested first.

· Modules are integrated one at a time

Major emphasis is on interface testing

· Starts at sub-system level with modules as ‘stubs’

· Then tests modules with functions as ‘stubs’

· Used in conjunction with top-down program development

Bottom-Up Approach:

Bottom-up approach, as the name suggests, is the opposite of the Top-down method, this process starts with building and testing the low level modules first, working its way up the hierarchy.

Because the modules at the low levels are very specific, we may need to combine several of them into what is sometimes called a cluster or build in order to test them properly.

Then to test these builds, a test driver has to be written and put in place.

Steps

Lower level modules are combined into builds or clusters
Develop a driver for a cluster
Test the cluster
Replace drive with module higher in hierarchy

Features:

Allows early testing aimed at proving feasibility of particular modules
Modules can be integrated in various clusters as desired
Major emphasis is on module functionality and performance

Sandwich Approach:

Sandwich testing uses bottom-up and top-down testing simultaneously. It merges the code modules from the top and the bottom so that they eventually meet the middle. This approach is reasonable for integrating software in a large software product. The module interfaces are tested early in the test phase, and a basic prototype is available.

Steps

Combine top down and bottom up
Consider

– A, B, C, D, G, and J are logic modules ==> top down

--E, F, H, I, K, and L are functional modules ==> bottom up

When all modules have been appropriately integrated, the Interfaces between the 2 groups are tested one by one
The tester must be able to map the subsystem decomposition into three layers

i. A target layer ("the meat")

ii. A layer above the target layer ("the bread above")

iii. A layer below the target layer ("the bread below)

iv. The target layer is the focus of attention, top-down and bottom-up testing can be done in parallel

Features:

· Module drivers and stubs are needed as in bottom-up and top-down testing.

· As in the top down approach, the module interfaces are tested early in the test phase, and a basic prototype is available.

· The functional specifications of the software product also are tested early, since they are usually implemented in the lower-level modules.

Big-Bang Approach:

Big-Bang approach is very simple in its philosophy where basically all the modules or builds are constructed and tested independently of each other and when they are finished, they are all put together at the same time. This is a small approach and the most common. For small and well-designed software products, the big-bang approach is feasible

Steps for Integration Testing:

All modules should be unit tested
Choose integration testing strategy
Do White Box testing/Black Box testing, test input/output parameters
Exercise all modules and all calls
Keep records (test results, test activities, faults)

Features:

· Module stubs and drivers are not required

· Ideally, all logic errors in a module will be detected when the module is being tested independent of the others. Debugging is easier as it is localized to the module under test.

· There is significant potential for parallel testing. To test one module, we need not wait for the testing of another to complete. Given enough personnel, all modules can be tested in parallel. So, this phase of the testing can be completed quickly.

· The testing of large programs using this approach is expected to require less computer time. The full memory requirements of the program are needed only when the integrated program is being tested

· Module interface problems have to be dealt with only after individual modules have been tested. In the ideal case, all bugs found when the integrated program is being tested will be related to module interface problems alone

Programming Portal

Top Tabs

Integration Testing Standards part two

Sandwich Approach:

Steps for Integration Testing:

No comments:

Post a Comment