Integration Testing Beyond unit testing. 2 Testing in the V-Model Requirements Detailed Design Module implementation Unit test Integration test System

  • Published on

  • View

  • Download

Embed Size (px)


  • Integration TestingBeyond unit testing

  • Testing in the V-ModelRequirementsDetailedDesignModuleimplementationUnit testIntegration testSystem testAcceptancetestRun testsWrite testsCustomerDeveloperFunctional(BB)


  • Testing stagesUnit testingTesting of individual componentsIntegration testingTesting to expose problems arising from the combination of componentsSystem testingTesting the complete system prior to delivery Acceptance testingTesting by users to check that the system satisfies requirements. Sometimes called alpha testing

  • Integration TestingTesting the interfaces and interactions among separately tested unitsThree different approachesBased on functional decompositionBased on call graphBased on paths

  • Functional DecompositionFunctional Decomposition is defined as a method in which a problem is broken up into several independent task units, or functions, which can be run either sequentially and in a synchronous call-reply manner or simultaneously on different processorsThis method is used during planning, analysis and design, and creates a functional hierarchy for the software

  • Example functional decomposition

  • Top-Down IntegrationTop-down integration strategy focuses on testing the top layer or the controlling subsystem first (i.e. the main, or the root of the call tree)The general process in top-down integration strategy is to gradually add more subsystems that are referenced/required by the already tested subsystems when testing the applicationDo this until all subsystems are incorporated into the test

  • Top-Down IntegrationSpecial code is needed to do the testingTest stubA program or a method that simulates the input-output functionality of a missing subsystem by answering to the decomposition sequence of the calling subsystem and returning back simulated data

  • Top-Down Integration IssuesWriting stubs can be difficult especially when parameter passing is complex. Stubs must allow all possible conditions to be testedPossibly a very large number of stubs may be required, especially if the lowest level of the system contains many functional unitsOne solution to avoid too many stubs: Modified top-down testing strategyTest each layer of the system decomposition individually before merging the layers Disadvantage of modified top-down testing: Both, stubs and drivers are needed

  • Bottom-Up IntegrationBottom-Up integration strategy focuses on testing the units at the lowest levels first Gradually includes the subsystems that reference/require the previously tested subsystemsThis is done repeatedly until all subsystems are included in the testingSpecial driver code is needed to do the testingThe driver is a fake routine that requires a subsystem and passes a test case to it

  • Bottom-Up IntegrationTop Subtree(Sessions 29-32)Second Level Subtree(Sessions 25-28)Bottom Level Subtree(Sessions 13-17)

  • Bottom-Up Integration IssuesNot optimal strategy for functionally decomposed systems:Tests the most important subsystem (UI) lastMore useful for integrating object-oriented systemsDrivers may be more complicated than stubsLess drivers than stubs are typically required

  • Sandwich IntegrationCombines top-down strategy with bottom-up strategyLess stub and driver development effortAdded difficulty in fault isolation

  • Call Graph-Based IntegrationThe basic idea is to use the call graph instead of the decomposition tree

    The call graph is a directed, labeled graph

    Two types of call graph based integration testingPair-wise Integration TestingNeighborhood Integration Testing

  • Pair-Wise IntegrationThe idea behind Pair-Wise integration testing is to eliminate the need for developing stubs/driversThe objective is to use actual code instead of stubs/driversIn order not to deteriorate the process to a big-bang strategy, we restrict a testing session to just a pair of units in the call graphThe result is that we have one integration test session for each edge in the call graph

  • Neighbourhood IntegrationWe define the neighbourhood of a node in a graph to be the set of nodes that are one edge away from the given nodeIn a directed graph means all the immediate predecessor nodes and all the immediate successor nodes of a given nodeNeighborhood Integration Testing reduces the number of test sessionsFault isolation is harder

  • Pros and Cons of Call-Graph IntegrationAim to eliminate / reduce the need for drivers/stubsCloser to a build sequenceNeighborhoods can be combined to create villagesSuffer from the fault isolation problem especially for large neighborhoodsNodes can appear in several neighborhoods

  • Path-Based IntegrationThe basic motivation is to combine structural and behavioral type of testing for integration testing as we did for unit testingThe basic idea is to focus on interactions among system units rather than merely to test interfaces among separately developed and tested unitsIn this respect, interface-based testing is structural while interaction-based is behavioral

  • Extended Concepts (1)Source node: a program statement fragment at which program execution begins or resumes. for example the first begin statement in a program. also, immediately after nodes that transfer control to other units. Sink node:a statement fragment at which program execution terminates. the final end in a program as well as statements that transfer control to other units.

  • Extended Concepts (2) Module execution path:a sequence of statements that begins with a source node and ends with a sink node with no intervening sink nodes. Message:a programming language mechanism by which one unit transfers control to another unit. usually interpreted as subroutine invocationsthe unit which receives the message always eventually returns control to the message source.

  • MM-Paths MM-Path: an interleaved sequence of module execution paths and messages. we can describe sequences of module execution paths that include transfers of control among separate units.MM-paths always represent feasible execution paths, and these paths cross unit boundaries.

  • MM-Path Example 1




















    In module A nodes 1 and 5 are source nodes while nodes 4 and 6 are sink nodes. and are module execution pathsAn MM-path is shown in bold

  • Module execution paths The complete list of module execution paths:

    MEP(A,1) = MEP(B,1) = MEP(A,2) = MEP(B,2) = MEP(A,3) = MEP(C,1) = MEP(C,2) =

  • MM-Path Graph Given a set of units their MM-Path graph is the directed graph in whichnodes are module execution pathsedges correspond to messages and returns from one unit to anotherThe definition is with respect to a set of units It directly supports composition of units and composition-based integration testing

  • MEP(A,2)







    The MM-Path graph for our example.The solid arrows indicate messages and the corresponding returns are indicated by dotted arrows. MM-Path Graph Example

  • Pros and cons of path-based integrationPath-based integration is closely coupled with actual system behaviourThere is a significant effort involved in identifying MM-PathsNo need for stub and driver development


View more >