For example in case of an ATM (Automatic Teller Machine) System Testing would be inserting a valid debit card, followed by correct pin code and knowing the balance amount in the account. Another scenario would be inserting a valid debit card, followed by correct pin code and withdrawing more amount then the allowed limit.
Integration testing scenario could be like if the ATM has different modules ValidatePIN & GetPIN then how some value passed into GetPIN affects ValidatePIN. etc
For complete example see here.
Examples of Top Down integration
As the above picture shows,
* The main module, Module I, calls Modules II, and III,
* Module II calls Modules IV and V,
* Module III calls Modules V and VI,
* Modules IV, V, and VI don't call any others.
You could perform top down integration in either a breadth first manner or in a depth first manner.
In a breadth first approach think of the modules in the structure chart as sitting at various "levels" in the chart. Thus, in the above example, module I is at level 1, modules II and III are at level 2, and modules IV, V, and VI are at level 3. When using a "breadth first" strategy, you include all the modules at a given level (when constructing subsystems) before you include any of the modules that are at lower levels in the structure chart.
For example, if a breadth first strategy is applied to the example, then you might consider subsystems that include the modules, and need the stubs, listed below (in the order in which they're listed):
1.
Modules Included: I
Stubs Required for Modules: II, III
2.
Modules Included: I, II
Stubs Required for Modules: III, IV, V
3.
Modules Included: I, II, III
Stubs Required for Modules: IV, V, VI
4.
Modules Included: I, II, III, IV
Stubs Required for Modules: V, VI
5.
Modules Included: I, II, III, IV, V
Stubs Required for Modules: VI
6.
Modules Included: I, II, III, IV, V, VI
No Stubs Required
If a depth first approach is used then think of the modules as lying along paths that all start from the main module, and follow the (control) connections shown by arrows on the structure chart. You add modules by following a path as far as you can go, until a utility module (or some other module whose children have all already been included) is reached. At that point you "backtrack" until you can find another module to include.
For example, if a depth first strategy is applied to the example, then you might consider subsystems that include the modules, and need the stubs, that are listed below. (Note that the first two subsystems are the same as above, but the third is different.)
1.
Modules Included: I
Stubs Required for Modules: II, III
2.
Modules Included: I, II
Stubs Required for Modules: III, IV, V
3.
Modules Included: I, II, IV
Stubs Required for Modules: III, V
4.
Modules Included: I, II, IV, V
Stubs Required for Modules: III
5.
Modules Included: I, II, III, IV, V
Stubs Required for Modules: VI
6.
Modules Included: I, II, III, IV, V, VI
No Stubs Required
[Source]
Real-world examples? Well, let's assume you are developing a large retail management system, and an inventory control component is ready for integration. Bottom-up testing would imply that you set up a fair amount of equivalence-classed data in the new component and introduced that new data into the system as a whole. How does the system respond? Are the inventory amounts updated correctly? If you have inventory-level triggers (e.g., if the total count of pink iPod Nanos falls below a certain threshold, generate an electronic order for more), does the order management system respond accordingly? This is bottom-up testing.
At the same time, you want to track how well the component consumes data from the rest of the system. Is it handling inventory changes coming in from the Web site? Does it integrate properly with the returns system? When an item's status is updated by the warehouse system, is it reflected in the new component?
[Source]
See here for another example of integration testing.
Also See:
Big-Bang Testing
Disadvantages of Big-Bang Testing
Acceptance Testing
Integration Testing
Difference between Acceptance & System Testing
System Testing
Difference between Integration & System Testing
Integration Test Plan Template
Integration & System Testing Checklist