System Integration Testing: Chapter-1

Software Testing and Quality Assurance
Theory and Practice

unit-4
System Integration Testing
Chapter-1
Software Testing and QA Theory and Practice (Chapter 7: System Integration Testing) © Naik & Tripathy 1
Outline of the Chapter
• The Concept of Integration Testing
• Different Types of Interface Errors
• Granularity of System Integration Testing
• System Integration Techniques: Incremental, Top-down, Bottom-up,
and Sandwich and Big-bang
• Test Plan for System Integration
The Concept of Integration Testing
• A software module is a self-contained element of a system
• Modules are individually tested commonly known as unit testing
• Next major task is to put the modules, i.e., pieces together to
construct the complete system
• Construction of a working system from the pieces is not a
straightforward task because of numerous interface errors
• The objective of system integration testing (SIT) is to build a
“working” version of the system
– Putting modules together in an incremental manner
– Ensuring that the additional modules work as expected without disturbing the
functionalities of the modules already put together
• Integration testing is said to be complete when
– The system is fully integrated togethr
– All the test cases have been executed
– All the severe and moderated defects found have been fixed
The Concept of Integration Testing
The major advantages of conducting SIT are as follows:
• Defects are detected early
• It is easier to fix defects detected earlier
• We get earlier feedback on the health and acceptability of the

individual modules and on the overall system
• Scheduling of defect fixes is flexible, and it can overlap with

development
Different Types of Interfaces
Three common paradigms for interfacing modules:
• Procedure call interface
• Shared memory interface
• Message passing interface
The problem arises when we “put modules together” because of interface errors
Interface errors
Interface errors are those that are associated with structures existing outside the
local environment of a module, but which the module uses
Different Types of Interface Errors
• Construction
• Inadequate error processing
• Inadequate functionality
• Additions to error processing
• Location of functionality
• Inadequate post-processing
• Changes in functionality
• Inadequate interface support
• Added functionality
• Initialization/value errors
• Misuse of interface
• Validation od data constraints
• Misunderstanding of interface
• Timing/performance problems
• Data structure alteration

• Coordination changes
• Hardware/software interfaces
Granularity of System Integration Testing
System Integration testing is performed at different levels of
granularity
• Intra-system testing
– This form of testing constitutes low-level integration testing with the objective
of combining the modules together to build a cohesive system
• Inter-system testing
– It is a high-level testing phase which requires interfacing independently tested
systems
• Pairwise testing
– In pairwise integration, only two interconnected systems in an overall system
are tested at a time
– The purpose of pairwise testing is to ensure that two systems under
consideration can function together, assuming that the other systems within the
overall environment behave as expected
System Integration Techniques
Common approaches to perform system integration testing
• Incremental
• Top-down
• Bottom-up
• Sandwich
• Big-bang
Pre-requisite
A module must be available to be integrated
A module is said to available for combining with other modules when the
module’s check-in request form is ready
Check-in Request Form
Incremental
• A software image is a compiled software binary
• A build is an interim software image for internal testing within an
organization
• Constructing a build is a process by which individual modules are
integrated to form am interim software image.
• The final build is a candidate for system testing
• Constructing a software image involves the following activities
– Gathering the latest unit tested, authorized versions of modules
– Compiling the source code of those modules
– Checking in the compiled code to the repository
– Linking the compiled modules into subassemblies
– Verifying that the subassemblies are correct
– Exercising version control
Incremental
• Integration testing is conducted in an incremental manner as a series
of test cycles
• In each test cycle, a few more modules are integrated with an
existing and tested build to generated larger builds
• The complete system is built, cycle by cycle until the whole system
is operational for system-level testing.
• The number of SIT cycles and the total integration time are
determined by the following parameters:
– Number of modules in the system
– Relative complexity of the module (cyclomatic complexity)
– Relative complexity of the interfaces between the modules
– Number of modules needed to be clustered together in each test cycle
– Whether the modules to be integrated have boon adequately tested before
– Turnaround time for each test-debug-fix cycle
Incremental
• A release note containing the following information accompanies a
build.
– What has changed since the last build?
– What outstanding defects have been fixed?
– What are the outstanding defects in the build?
– What new modules, or features, have been added?
– What existing modules, or features, have been enhanced, modified, or deleted?
– Are there any areas where unknown changes may have occurred?
• A test strategy is created for each new build and the following issues
are addressed while planning a test strategy
– What test cases need to be selected from the SIT test plan?
– What previously failed test cases should now be re-executed in order to test the
fixes in the new build?
– How to determine the scope of a partial regression tests?
– What are the estimated time, resource deman, and cost to test this build?
Incremental
Creating a daily build is very popular among many organization
• It facilitates to a faster delivery of the system

• It puts emphasis on small incremental testing
• It steadily increases number of test cases
• The system is tested using automated, re-usable test cases
• An effort is made to fix the defects that were found within 24 hours
• Prior version of the build are retained for references and rollback
• A typical practice is to retain the past 7-10 builds
TOpdown approach
14
Software Testing Theory and Practice (Chapter 1: Basic Concepts and Preliminaries) © Naik & Tripathy
15
Top-down
• Module A has been decomposed into modules
B, C, and D
• Modules B, D, E, F, and G are terminal
modules
• First integrate modules A and B using stubs
C` and D` (represented by grey boxes)
• Next stub D` has been replaced with its actual
instance D
Figure 7.1: A module hierarchy with • Two kinds of tests are performed:
three levels and seven modules – Test the interface between A and D
– Regression tests to look for interface defects
between A and B in the presence of module D
Figure 7.2: Top-down integration of

modules A and B
modules A, B and D
Top-down
• Stub C` has been replaced with the
actual module C, and new stubs E`,
F`, and G`
• Perform tests as follows:
– first, test the interface between A and
C;
– second, test the combined modules A,
B, and D in the presence of C Figure 7.5: Top-down integration of
• The rest of the process depicted in the modules A, B, C, D and E
right hand side figures.

Figure 7.4: Top-down integration of modules A, B, C, D, E and F
modules A, B, D and C
Top-down
Advantages
• The SIT engineers continually observe system-level functions as the
integration process continue
• Isolation of interface errors becomes easier because of the
incremental nature of the top-down integration
• Test cases designed to test the integration of a module M are reused
during the regression tests performed after integrating other modules
Disadvantages
• It may not be possible to observe meaningful system functions
because of an absence of lower level modules and the presence of
stubs.
• Test case selection and stub design become increasingly difficult
when stubs lie far away from the top-level module.
19
20
21
Bottom-up
• We design a test driver to integrate
lowest-level modules E, F, and G
• Return values generated by one module
is likely to be used in another module
• The test driver mimics module C to
integrate E, F, and G in a limited way.
• The test driver is replaced with actual Figure 7.8: Bottom-up integration of
module , i.e., C. module E, F, and G
• A new test driver is used
• At this moment, more modules such as
B and D are integrated
• The new test driver mimics the
behavior of module A
• Finally, the test driver is replaced with
module A and further test are performed
Figure 7.9: Bottom-up integration of

module B, C, and D with F, F, and G
Bottom-up
Advantages
• One designs the behavior of a test driver by simplifying the behavior
of the actual module
• If the low-level modules and their combined functions are often
invoked by other modules, then it is more useful to test them first so
that meaningful effective integration of other modules can be done
Disadvantages
• Discovery of major faults are detected towards the end of the
integration process, because major design decision are embodied in
the top-level modules
• Test engineers can not observe system-level functions from a partly
integrated system. In fact, they can not observe system-level
functions until the top-level test driver is in place
Big-bang and Sandwich
Big-bang Approach
• First all the modules are individually tested
• Next all those modules are put together to construct the entire system
which is tested as a whole
Sandwich Approach
• In this approach a system is integrated using a mix of top-down,
bottom-up, and big-bang approaches
• A hierarchical system is viewed as consisting of three layers
• The bottom-up approach is applied to integrate the modules in the
bottom-layer
• The top layer modules are integrated by using top-down approach
• The middle layer is integrated by using the big-bang approach after
the top and the bottom layers have been integrated
Test Plan for System Integration
Table 7.4: A framework for system integration entry criteria
Table 7.5: A framework for system integration exit criteria
Categories of System Integration Tests:
• Interface integrity
– Internal and external interfaces are tested as each module is integrated
• Functional validity
– Tests to uncover functional errors in each module after it is integrated
• End-to-end validity
– Tests are designed to ensure that a completely integrated system works together
from end-to-end
• Pairwise validity
– Tests are designed to ensure that any two systems work properly when connected
by a network
• Interface stress
– Tests are designed to ensure that the interfaces can sustain the load
• System endurance
– Tests are designed to ensure that the integrated system stay up for weeks

System Integration Testing: Chapter-1

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

System Integration Testing: Chapter-1

Uploaded by

Copyright:

Available Formats

Software Testing and Quality Assurance

Theory and Practice

• Defects are detected early

• It is easier to fix defects detected earlier

• We get earlier feedback on the health and acceptability of the

• Scheduling of defect fixes is flexible, and it can overlap with

• Procedure call interface

• Shared memory interface

• Message passing interface

• Data structure alteration

• It facilitates to a faster delivery of the system

Figure 7.2: Top-down integration of

Figure 7.6: Top-down integration of

Figure 7.9: Bottom-up integration of

Table 7.4: A framework for system integration entry criteria

Table 7.5: A framework for system integration exit criteria

You might also like