Please enable JavaScript.

Coggle requires JavaScript to display documents.

Integration Testing - Coggle Diagram

- - - - There are four approaches for this strategy:
        
        1.1 Big bang Integration
        
        This is one of the easiest approaches to apply in integration testing. Here we treat the whole system as a subsystem and test it in a single test phase. Figure 1.1 shows the modules used in a single test session. Normally this means simply integrating all the modules, compile them all at once and then test the resulting system. This approach requires little resources to execute as we do not need to identify critical components (like interactions paths between the modules) nor require extra coding for the “dummy modules”.
        
        1.1.1 Case Study
        
        Here we compile all the modules in the functional decomposition tree: Main, isLeap, lastDayOfMonth, GetDate ValidDate, IncrementDate, printDate and test the whole system in a single session (Figure 1.2). By doing this, we will increase the difficulty of test cases creation. This is because we must create a single set of test cases that covers conditions passed by different modules. Simultaneously, this will make the analysis of the test cases harder; when there is a test case that produces incorrect value, it will be more difficult to deduce the reasons because the data has been heavily processed. Consequently, this will make problem isolation a big issue in this approach.
        
        1.1.2 Summary
        
        In summary, big bang integration has the following characteristics:
        
        • Considers the whole system as a subsystem
        
        • Tests all the modules in a single test session
        
        • Only one integration testing session
        
        And the following advantages and disadvantages:
        
        Advantages:
        
        • Low resources requirement
        
        • Does not require extra coding
        
        Disadvantages:
        
        • Not systematic
        
        • Hard to locate problems
        
        • Hard to create test cases
        
        1.2 Top-down Integration
        
        In top-down integration, we start at the target node at root of the functional decomposition tree and work toward the leaves. shows different sessions of integration testing. Stubs2
        are used to replace the children nodes attached to the target node. A test phase consists in replacing one of the stub modules with the real code and test the resulting subsystem. If no problem is encountered then we do the next test phase. If all the children were replaced by real code at least once and meet the requirements then we move down to the next level. Now we can replace the higher level tested modules with real code and continue the integration testing.
        
        1.2.1 Case Study
        
        With our example program nextDate, this integration approach is not very useful. This is mainly because this is a very simple system (thus the functional decomposition tree does not have many levels) and secondly the main program does not have many features or complex user interface.
        
        In a way, the test cases will be limited by how and what we code in the stub. This also means that we are limiting the area we must look at when problems arise. For instance, if both incrementDate and getDate is replaced by stubs but there is a mismatch of results in the output, then most likely the problem is at printDate
        
        1.2.2 Summary
        
        In summary, top-down integration has the following characteristics:
        
        • Integration starts at the main program
        
        • Moves from the higher level modules to the lower level modules
        
        • Has nnodes − nleaves + nedges number of integration testing sessions
        
        And the following advantages and disadvantages:
        
        10
        
        Advantages:
        
        • Early SUT prototype
        
        • Interleaves design and implementation
        
        Disadvantages:
        
        • Throw-away code programming
        
        • Late interaction tests between the main program,
        
        the application layer and the hardware
        
        • Difficult to create test cases
        
        1.3 Bottom-up Integration
        
        Bottom-up integration starts at the opposite end of the functional decomposition tree, instead of starting at the main program we start at the lower-level implementation of the software. As we can see in Figure 1.5, bottom-up integration mirrors top-down integration in the sense of testing direction in the tree.
        
        1.3.1 Case Study
        
        For bottom-up integration, we can apply it to our example by starting with isLeap, then lastDayOfMonth, validDate and getDate. Some shorter but still useful test sessions includes Main and getDate, incrementDate, printDate. As we can see, bottom-up seems to be a more natural choice to use than top-down integration for this example Here we do not need to substitute as many modules with temporary throw-away modules (Figure 1.6). Also, since the lower level modules do not have a high degree of coupling (they are able to function with only their own code), the test cases are easier to be maintained
        
        In case of there are results that does not match with the expected ones, we will know that isLeap most likely is the module that is causing the problem. For example, if during the test session the returning value of the years 1900 and 2000 does not correspond to the expected result then we would check the code that handles century years in the module isLeap.
        
        1.3.2 Summary
        
        In summary, bottom-up integration has the following characteristics:
        
        • Start at the leaves of the functional decomposition tree
        
        • Work toward to the higher level, to the root of the tree
        
        • Has nnodes − nleaves + nedges number of integration testing sessions
        
        And the following advantages and disadvantages:
        
        Advantages:
        
        • Less throw-away code programming
        
        • Easy to create testing environments
        
        • Easy exceptions handling
        
        Disadvantages:
        
        • No prototype
        
        • Main program tested last
        
        • Late to identify design errors
        
        • High error correction cost
        
        1.4 Sandwich Integration
        
        Sandwich integration combines top-down integration and bottom-up integration. The main concept is to maximize the advantages of top-down and bottom-up and minimizing their weaknesses. In top-down by starting at the root of the functional decomposition tree, we will be able to test the main program at early stage. In bottom-up, we will have coverage that is easy to create test cases.
        
        Sandwich integration uses a mixed-up approach where we use stubs at the higher level of the tree and drivers at the lower level (Figure 1.7). The testing direction starts from both side of tree and converges to the centre, thus the term sandwich. This will allow us to test both the top and bottom layers in parallel and decrease the number of stubs and drivers required in integration testing
        
        1.4.1 Case Study
        
        Sandwich integration is also a good choice for integration testing in this system. This is because by doing either top-down or bottom-up approach a good part of the functional decomposition tree is covered. Sandwich integration approach is known of its flexibility in the integration, thus there are no strict guidelines in modules grouping. Consequently, there are different types of sandwich integration testing, which normally are categorized by the depth of the coverage.
        
        1.4.2 Summary
        
        In summary, sandwich integration has the following characteristics:
        
        • Combines top-down approach and bottom-up approach
        
        • Generally, higher level modules use a top-down approach (stub)
        
        • Normally, lower level modules use a bottom-up approach (driver)
        
        • Testing converges to the middle
        
        • Number of integration sessions can vary
        
        • The maximum number of sessions is the number of subtrees of the system
        
        And following advantages and disadvantages:
        
        Advantages:
        
        • Top and bottom layers can be done in parallel
        
        • Less stubs and drivers needed
        
        • Easy to contruct test cases
        
        • Better coverage control
        
        • Integration is done as soon a component is implemented
        
        Disadvantages:
        
        • Still requires throw-away code programming
        
        • Partial big bang integration
        
        • Hard to isolate problems
- - - - There are two main approaches in call graph-based integration:
        
        • Pair-wise integration
        
        • Neighbourhood integration
  - - - By going to a call graph-based strategy, we will be able to eliminate the problem of empty test sessions. This is because the edges actually represent the calls and functional dependencies of the modules.
    - - In summary, pair-wise integration has the following characteristics:
        
        • Each test session is restricted to only a pair of modules
        
        • Module pairing is based on the edges of the call graph
        
        • The number of integration testing sessions is the number of edges
        
        And the following advantages and disadvantages:
        
        Advantages:
        
        • Stub and driver need is eliminated
        
        • Use of real code
        
        Disadvantages:
        
        • Many test sessions
  - - - As we can see, we group the modules such that all the modules that are immediate successors or predecessor of the target node are within the same subsystem.
    - - In summary, neighbourhood integration has the following characteristics:
        
        • Modules are grouped as neighbourhoods
        
        • A neighbour module is a module that is the immediate successor or predecessor of another unit
        
        • The number of integration testing sessions is nnodes − nsinknodes
        
        And the following advantages and disadvantages:
        
        Advantages:
        
        • Stub and driver need is eliminated
        
        • Use of real code
        
        • Reduction of test sessions
        
        Disadvantages:
        
        • Hard to isolate faults
- - - - 3.1 MM-Path based Integration
        
        MM-Paths represent actions with inputs and outputs thus showing us the system in a functional level. The way the MM-Path graph is constructed, how the modules and messages are identified allow us to work on the system in a structural level
        
        3.1.1 Case Study
        
        3.1.2 Summary
        
        In summary, MM-Path integration has the following characteristics:
        
        • Messages sent between modules are tracked
        
        • The set of MM-Paths should cover all source-to-sink paths
        
        • Points of quiescence are natural endpoints for an MM-Path
        
        • The number of integration testing sessions is dependant to the system in question
        
        And the following advantages and disadvantages:
        
        Advantages:
        
        • Hybrid of functional and structural testing
        
        • Closely coupled with actual system behaviour
        
        • Does not require stub or driver
        
        Disadvantages:
        
        • Extra effort required to identify the MM-Paths