3. System Integration Test - Fall 2015
Agenda
3/20
Introduction
The Concept of Integration Testing
Component / Module testing
Why do we do integration testing?
The major advantages of conducting SIT
Granularity of System Integration Testing
Drivers and Stubs
Approaches in Integration Testing
Integration test tools
4. System Integration Test - Fall 2015
Introduction
4/20
Why Test?
No matter how well software has been designed and coded, it will inevitably still contain
defects.
Testing is the process of executing a program with the intent of finding faults (bugs).
A “successful” test is one that finds errors, not one that doesn’t find errors.
5. System Integration Test - Fall 2015
Introduction-cont
5/20
Why Test?
Testing can “prove” the presence of faults, but can not “prove” their absence
But can increase confidence that a program “works”
6. System Integration Test - Fall 2015
Introduction-cont
What is Test?
6/20
Unit test – test of small code unit: file, class, individual method or subroutine.
Integration test – test of several units combined to form a (sub)system, preferably adding
one unit at a time.
System (alpha) test – test of a system release by “independent” system testers.
Acceptance (beta) test – test of a release by end-users or their representatives.
7. System Integration Test - Fall 2015
Introduction-cont
When to Test?
7/20
Early
“Agile programming” developers write unit test cases before coding each unit
Many software processes involve writing (at least) system/acceptance tests in parallel
with development
Often
Regression testing: rerun unit, integration and system/acceptance tests
After refactoring
Throughout integration
Before each release
8. System Integration Test - Fall 2015
Introduction-cont
Defining a Test?
8/20
Goal – the aspect of the system being tested.
Input – specify the actions and conditions that lead up to the test as well as the
input (state of the world, not just parameters) that actually constitutes the test.
Outcome – specify how the system should respond or what it should compute,
according to its requirements .
9. System Integration Test - Fall 2015
The Concept of Integration Testing
9/20
Testing in which software components, hardware components, or both together are
combined and tested to evaluate interactions between them.
Integration testing usually go through several realword business scenarios to see whether
the system can successfully complete workflow tasks.
Integration plan specifies the order of combining the modules into partial systems.
Integration is …
Making different modules work together
10. System Integration Test - Fall 2015
for each
The Concept of Integration Testing-cont
10/20
readFile String[]String
getCharacterFreqString Frequency[]
11. System Integration Test - Fall 2015
Component / Module testing
11/20
A unit is the smallest testable piece of software. A unit
is defined as a database trigger, stored procedure,
function, report, form, batch load program or PL/SQL
program.
Unit testing is the testing that is performed to validate
that the unit does satisfy its functional specification
and/or that its implementation structure does match
the intended design structure.
Module /Component consists of units integrated into a module that performs a specific
business function.
12. System Integration Test - Fall 2015
do we do integration testing?
12/20
Unit tests only test the unit in isolation.
Many failures result from faults in the interaction of subsystems.
Often many Off-the-shelf components are used that cannot be unit tested.
Without integration testing the system test will be very time consuming.
Failures that are not discovered in integration testing will be discovered after the
system is deployed and can be very expensive.
13. System Integration Test - Fall 2015
Granularity of System Integration Testing
13/20
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
14. System Integration Test - Fall 2015
Integration testing approaches
14/20
Common approaches to perform system integration testing
Incremental
Top-down
Bottom-up
Sandwich
Big-bang
15. System Integration Test - Fall 2015
Drivers and Stubs
15/20
Driver:
A program that calls the interface procedures of the module
being tested and reports the results.
A driver simulates a module that calls the module currently being
Tested.
Stub:
A program that has the same interface procedures as a module
that is being called by the module being tested but is simpler.
A stub simulates a module called by the module currently being
tested
Driver
Tested
Unit
Stub
Module under test
Procedure call
Procedure call
16. System Integration Test - Fall 2015
Example: A 3-Layer-Design(SpreadSheet)
16/20
Layer I
Layer II
Layer III
Spread
SheetView
A
Calculator
C
BinaryFile
Storage
E
XMLFile
Storage
F
Currency
DataBase
G
Currency
Converter
D
Data
Model
B
A
C
E F G
DB
Spread
SheetView
BinaryFile
Storage
Entity
Model
A
E F
Currency
DataBase
G
Currency
Converter
DB
Calculator
C
XMLFile
Storage
17. System Integration Test - Fall 2015
Big-Bang Approach
17/20
A
C
E F G
DB
Test A
Test B
Test G
Test F
Test E
Test C
Test D
Test
A, B, C, D,
E, F, G
18. System Integration Test - Fall 2015
Bottom-up Testing Strategy
18/20
The subsystems in the lowest layer of the call hierarchy are tested individually
Then the next subsystems are tested that call the previously tested
subsystems
This is repeated until all subsystems are included
Drivers are needed.
19. System Integration Test - Fall 2015
Bottom-up Testing Strategy
19/20
A
C
E F G
DB
A
Test
A, B, C, D,
E, F, G
E
Test E
F
Test F
B
Test B, E, F
C
Test C
D
Test D,G
G
Test G
20. System Integration Test - Fall 2015
Pros and Cons of Bottom-Up Integration
Testing
20/20
Con:
Tests the most important subsystem (user interface) last,
Drivers needed.
Pro:
No stubs needed.
Useful for integration testing of the following systems,
• Object-oriented systems,
• Real-time systems,
• Systems with strict performance requirements.
21. System Integration Test - Fall 2015
Top-down testing strategy
21/20
Test the top layer or the controlling subsystem first
Then combine all the subsystems that are called by the tested subsystems
and test the resulting collection of subsystems
Do this until all subsystems are incorporated into the test
Stubs are needed to do the testing.
22. System Integration Test - Fall 2015
Top-down Integration
22/20
Test
A, B, C, D,
E, F, G
All LayersLayer I + II
Test A, B, C, D
Layer I
Test A
A
E F
B C D
G
23. System Integration Test - Fall 2015
Pros and Cons of Top-down Integration
Testing
23/20
Pro
Test cases can be defined in terms of the functionality of the system
(functional requirements)
No drivers needed
Cons
Writing stubs is difficult: Stubs must allow all possible conditions to be
tested.
Large number of stubs may be required, especially if the lowest level of the
system contains many methods.
Some interfaces are not tested separately.
24. System Integration Test - Fall 2015
Sandwich Testing Strategy
24/20
Combines top-down strategy with bottom-up strategy
The system is viewed as having three layers
A target layer in the middle
A layer above the target
A layer below the target
Testing converges at the target layer.
25. System Integration Test - Fall 2015
Sandwich Testing Strategy
25/20
Test
A, B, C, D,
E, F, G
Test B, E, F
Test D,G
Test A
Test E
Test F
Test G
Test A,B,C, D
A
E F
B C D
G
26. System Integration Test - Fall 2015
Pros and Cons of Sandwich Testing
26/20
Top and Bottom Layer Tests can be done in parallel
Problem: Does not test the individual subsystems and their interfaces
thoroughly before integration
Solution: Modified sandwich
27. System Integration Test - Fall 2015
Modified Sandwich Testing Strategy
27/20
Test in parallel:
Middle layer with drivers and stubs
Top layer with stubs
Bottom layer with drivers
Test in parallel:
Top layer accessing middle layer (top layer replaces drivers)
Bottom accessed by middle layer (bottom layer replaces
stubs).
28. System Integration Test - Fall 2015
Modified Sandwich Testing
28/20
Test F
Test E
Test B
Test G
Test D
Test A
Test C
Test B, E, F
Test D,G
Test A,C
Test
A, B, C, D,
E, F, G
A
E F
B C D
G
29. System Integration Test - Fall 2015
Continuous Testing
29/20
Continuous build:
Build from day one
Test from day one
Integrate from day one
System is always runnable
Requires integrated tool support:
Continuous build server
Automated tests with high coverage
Tool supported refactoring
Software configuration management
Issue tracking.
30. System Integration Test - Fall 2015
Continuous Testing Strategy
30/20
Spread
SheetView
BinaryFile
Storage
Data
Model
Layer I
Layer II
Layer III
A
E F
Currency
DataBase
G
Currency
Converter
DB
Calculator
C
XMLFile
Storage
Sheet View
+ Cells
+ Addition
+ File Storage
31. System Integration Test - Fall 2015
Steps in Integration Testing
31/20
4. Test subsystem decomposition: Define test cases
that exercise all dependencies
5. Test non-functional requirements: Execute
performance tests
6. Keep records of the test cases and testing
activities.
7. Repeat steps 1 to 7 until the full system is tested.
The primary goal of integration testing is to identify
failures with the (current) component configuration.
1. Based on the integration strategy,
select a component to be tested.
Unit test all the classes in the
component.
2. Put selected component together;
do any preliminary fix-up
necessary to make the integration
test operational (drivers, stubs)
3. Test functional requirements:
Define test cases that exercise all
uses cases with the selected
component
33. System Integration Test - Fall 2015
Resource
33/20
Software Testing and Quality Assurance: Theory and Practice, Chapter 7
Kshirasagar Naik, Priyadarshi Tripathy, 2008. ISBN: 978-0-471-78911-6
Object-Oriented Software Engineering Using UML, Patterns, and Java, 3e,
Chapter11, Bernd Bruegge, Allen H. Dutoit, 2009, ISBN:0136061257
Martin Fowler about CI
http://www.martinfowler.com/articles/continuousIntegration.html
http://www.qatestingtools.com/integration_testing_tools
35. System Integration Test - Fall 2015
The major advantages of conducting SIT
35/20
The major advantages of conducting SIT(System Integration Testing) 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
37. System Integration Test - Fall 2015
Integration Challenges-cont
37/20
Broken Integration
You have a broken integration when:
Source code server does not build successfully,
Shared component works in one system, but breaks others,
Unit tests fail,
Code quality fails (coding conventions, quality metrics),
Deployment fails.
The earlier you can detect problems, the easier it is to resolve them.
38. System Integration Test - Fall 2015
Integration Challenges-cont
38/20
Manual Integration
Integration becomes expensive
if made manual (build, test, deployment, …)
with too less checkin’s (hours or days…)
If integration problems and bugs are detected too late
Reduces desire to refactor
Long time between integration increases risk of merge
IDE makes many cross-cutting changes easy
39. System Integration Test - Fall 2015
Different Types of Interfaces
39/20
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.
40. System Integration Test - Fall 2015
Different Types of Interface Errors
40/20
Inadequate error processing
Additions to error processing
Inadequate post-processing
Inadequate interface support
Initialization/value errors
Validation od data constraints
Timing/performance problems
Coordination changes
Construction
Inadequate functionality
Location of functionality
Changes in functionality
Added functionality
Misuse of interface
Misunderstanding of interface
Data structure alteration
Hardware/software interfaces