Integration Testing Beyond unit testing Testing in the
Integration Testing Beyond unit testing
Testing in the V-Model te te Wri sts Detailed Design Module implementation Customer Developer System test Integration test Unit tests Architectural Design Acceptance test Run Requirements Functional (BB) Structural (WB) 2
Testing stages n Unit testing n n Integration testing n n Testing to expose problems arising from the combination of components System testing n n Testing of individual components Testing the complete system prior to delivery Acceptance testing n Testing by users to check that the system satisfies requirements. Sometimes called alpha testing 3
Integration Testing n n Testing the interfaces and interactions among separately tested units Three different approaches n n n Based on functional decomposition Based on call graph Based on paths 4
Functional Decomposition n n Functional 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 processors This method is used during planning, analysis and design, and creates a functional hierarchy for the software 5
Example functional decomposition 6
Top-Down Integration n Top-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 application Do this until all subsystems are incorporated into the test 7
Top-Down Integration n n Special code is needed to do the testing Test stub n A 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 8
9
Top-Down Integration Issues n n Writing stubs can be difficult especially when parameter passing is complex. Stubs must allow all possible conditions to be tested Possibly a very large number of stubs may be required, especially if the lowest level of the system contains many functional units One solution to avoid too many stubs: Modified top-down testing strategy Test each layer of the system decomposition individually before merging the layers n Disadvantage of modified top-down testing: Both, 10 stubs and drivers are needed
Bottom-Up Integration n n Bottom-Up integration strategy focuses on testing the units at the lowest levels first Gradually includes the subsystems that reference/require the previously tested subsystems This is done repeatedly until all subsystems are included in the testing Special driver code is needed to do the testing n The driver is a “fake” routine that requires a subsystem and passes a test case to it 11
Bottom-Up Integration Bottom Level Subtree (Sessions 13 -17) Second Level Subtree (Sessions 25 -28) Top Subtree (Sessions 29 -32) 12
Bottom-Up Integration Issues n Not optimal strategy for functionally decomposed systems: n n Tests the most important subsystem (UI) last More useful for integrating object-oriented systems Drivers may be more complicated than stubs Less drivers than stubs are typically required 13
Sandwich Integration n Combines top-down strategy with bottom-up strategy Less stub and driver development effort Added difficulty in fault isolation 14
15
Call Graph-Based Integration n The 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 testing n n Pair-wise Integration Testing Neighborhood Integration Testing 16
17
Pair-Wise Integration n n The idea behind Pair-Wise integration testing is to eliminate the need for developing stubs/drivers The objective is to use actual code instead of stubs/drivers In 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 graph The result is that we have one integration test session for each edge in the call graph 18
19
Neighbourhood Integration n n We define the neighbourhood of a node in a graph to be the set of nodes that are one edge away from the given node In a directed graph means all the immediate predecessor nodes and all the immediate successor nodes of a given node Neighborhood Integration Testing reduces the number of test sessions Fault isolation is harder 20
21
Pros and Cons of Call-Graph Integration n n Aim to eliminate / reduce the need for drivers/stubs Closer to a build sequence Neighborhoods can be combined to create “villages” Suffer from the fault isolation problem especially for large neighborhoods Nodes can appear in several neighborhoods 22
Path-Based Integration n The basic motivation is to combine structural and behavioral type of testing for integration testing as we did for unit testing The basic idea is to focus on interactions among system units rather than merely to test interfaces among separately developed and tested units In this respect, interface-based testing is structural while interaction-based is behavioral 23
Extended Concepts (1) n Source node: n n 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: n n a statement fragment at which program execution terminates. the final “end” in a program as well as statements that transfer control to other units. 24
Extended Concepts (2) n Module execution path: n n a sequence of statements that begins with a source node and ends with a sink node with no intervening sink nodes. Message: n n n a programming language mechanism by which one unit transfers control to another unit. usually interpreted as subroutine invocations the unit which receives the message always eventually returns control to the message source. 25
MM-Paths n MM-Path: n n n 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. 26
MM-Path Example 4 1 A 1 2 3 C 1 B 3 2 4 5 3 4 4 5 6 In module A nodes 1 and 5 are source nodes while nodes 4 and 6 are sink nodes. <1, 2, 4> and <1, 2, 3, 6> are module execution paths An MM-path is shown in bold 27
Module execution paths n The complete list of module execution paths: MEP(A, 1) = <1, 2, 3, 6> MEP(A, 2) = <1, 2, 4> MEP(A, 3) = <5, 6> MEP(B, 1) = <1, 2> MEP(B, 2) = <3, 4> MEP(C, 1) = <1, 2, 4, 5> MEP(C, 2) = <1, 3, 4, 5> 28
MM-Path Graph n Given a set of units their MM-Path graph is the directed graph in which n nodes are module execution paths edges correspond to messages and returns from one unit to another The definition is with respect to a set of units n It directly supports composition of units and composition-based integration testing 29
MM-Path Graph Example MEP(A, 2) MEP(B, 1) MEP(A, 1) MEP(C, 1) MEP(B, 2) MEP(A, 3) MEP(C, 2) The MM-Path graph for our example. The solid arrows indicate messages and the corresponding returns are indicated by dotted arrows. 30
Pros and cons of path-based integration n Path-based integration is closely coupled with actual system behaviour There is a significant effort involved in identifying MM-Paths No need for stub and driver development 31
- Slides: 31