Mumbai University > Information Technology > Sem 8 > Software Testing and Quality Assurance

Marks: 10 Marks

Difficulty : Medium

Why do we need Integration Testing?
- Integration testing exposes inconsistency between the modules such as improper call or return sequences.
- Data can be lost across an interface.
- One module when combined with another module may not give the desired result.
- Data types and their valid ranges may mismatch between the modules.
Thus, integration testing focuses on bugs caused by interfacing between the modules while integrating them.

Explain its approaches in integration testing. There are three approaches for integration testing, Decomposition based integration, Call based integration and Path based integration.
- Decomposition based integration The idea for this type of integration is based on the decomposition of design into functional components or modules. In the tree designed for decomposition-based integration, the nodes represent the modules present in the system and the links/edges between the two modules represent the calling sequence. The nodes on the last level in the tree are leaf nodes .Module A is linked to three subordinate modules, B, C, and D. It means that module A calls modules, B, C, and D. All integration testing methods in the decomposition-based integration assume that all the modules have been unit tested in isolation. Thus, with the decomposition-based integration, we want to test the interfaces among separately tested modules. Integration methods in decomposition-based integration depend on the methods on which the activity of integration is based. One method of integrating is to integrate all the modules together and then test it. Another method is to integrate the modules one by one and test them incrementally. Based on these methods, integration testing methods are classified into two categories: (a) non-incremental and (b) incremental.

- CALL GRAPH-BASED INTEGRATION
It is assumed that integration testing detects bugs which are structural. How- ever, it is also important to detect some behavioral bugs. If we can refine the functional decomposition tree into a form of module calling graph, then we are moving towards behavioral testing at the integration level. A call graph is a directed graph, wherein the nodes are either modules or units, and a directed edge from one node to another means one module has called another module. The call graph can be captured in a matrix form which is known as the adjacency matrix. The figure shows how one unit calls another. Its adjacency matrix This matrix may help the testers a lot. The call graph shown in Fig. 7.9 can be used as a basis for integration testing. The idea behind using a call graph for integration testing is to avoid the efforts made in developing the stubs and drivers. If we know the calling sequence, and if we wait for the called or calling function, if not ready, then call graph-based integration can be used. There are two types of integration testing based on call graph , Pair-wise Integration & Neighborhood Integration

- PATH-BASED INTEGRATION
As we have discussed, in a call graph, when a module or unit executes, some path of source instructions is executed. And it may be possible that in that path execution, there may be a call to another unit. At that point, the control is transferred from the calling unit to the called unit. This passing of control from one unit to another unit is necessary for integration testing. Also, there should be information within the module regarding instructions that call the module or return to the module. This must be tested at the time of integration. It can be done with the help of path-based integration . We need to understand the following definitions for path-based integration.
Source node It is an instruction in the module at which the execution starts or resumes. The nodes where the control is being transferred after calling the module are also source nodes.
Sink node It is an instruction in a module at which the execution terminates. The nodes from which the control is transferred are also sink nodes.
Module execution path ( MEP) It is a path consisting of a set of executable statements within a module like in a flow graph.
Message When the control from one unit is transferred to another unit, then the programming language mechanism used to do this is known as a message.
MM-path It is a path consisting of MEPs and messages. The path shows the sequence of executable statements; it also crosses the boundary of a unit when a message is followed to call another unit. In other words, MM-path is a set of MEPs and transfer of control among different units in the form of messages.
MM-path graph It can be defined as an extended flow graph where nodes are MEPs and edges are messages. It returns from the last called unit to the first unit where the call was made. In this graph, messages are highlighted with thick lines.
Now let us see the concept of path-based integration with the help of one example. Fig. 7.12 shows the MM-path as a darken line. The details regarding the example units shown in Fig. 7.12 is given in Table 7.3.
The MM-path graph