Software Design and Integration Testing
Meenakshi D’Souza
International Institute of Information Technology Bangalore.
Outline and goals
Applying graph coverage criteria (structural and data flow) to
design elements.
Phase of testing where this will apply— Integration testing.
We will understand what integration testing is, what interfaces
are, how to define graph models and coverage criteria.
Design: Modules, Interfaces and Integration Testing
Sofware design basically dictates how the software is organized
into modules.
A module or a component is a self-contained element of a
system.
Modules interact with each other using well-defined interfaces.
Interfaces implement a mechanism for passing control and
data between modules.
Integration testing involves testing if the modules that have
been put together as per design meet their functionalities and
if the interfaces are correct.
Integration Testing
Begins after unit testing, each module has been unit tested.
Modules are put together in an incremental, pre-defined
manner
Integration testing is the testing needed to integrate the
modules into a bigger working component.
Focus is on testing the interfaces.
This testing is done while the system is being put together,
module after module.
Both software-software integration and software-hardware
integration are done. We will focus on software-software
integration.
Interfaces: Types
Procedure call interface: A procedure/method in one module
calls a procedure/method in another module.
Control and/or data can be passed in both directions.
Shared memory interface: A block of memory is shared
between two modules.
Data is written to/read from the memory block by the
modules. The memory block itself can be created by a third
module.
Message-passing interface: One modules prepares a message
of a particular type and sends it to another module through
this interface.
Client-server systems and web-based systems use such
interfaces.
Interfaces: Errors
Empirical studies account for up to quarter of all the errors in
a system to be interface errors.
Categories of interface errors:
Module functionality related: Functionality can be inadequate,
could be in a location that wasn’t agreed upon, could have
changed, new functionality could have got added.
Interface related: Interface can be mis-used (wrong parameter
type, order or number), can be mis-understood etc.
Inadequate error processing by the called and the calling
modules.
Initialization and other value errors.
Timing and performace problems, leading to wrong
synchronization, race conditions etc.
Stubs and Drivers
Integration testing need not wait until all the modules of a
system are coded and unit tested.
When testing incomplete portions of software, we need extra
software components, sometimes called scaffolding.
Two common types of scaffolding:
Test stub is a skeletal or special purpose implementation of a
software module, used to develop or test a component that
calls the stub or otherwise depends on it.
Test driver is a software component or test tool that replaces a
component that takes care of the control and/or the calling of
a software component.
Test stubs and drivers are essential for integration testing.
Integration testing: Techniques
There are five approaches to do integration testing.
Incremental
Top-down
Bottom-up
Sandwich
Big bang
Incremental approach to integration testing
Integration testing is conducted in an incremental manner.
The complete system is built incrementally, cycle by cycle,
until the entire system is operational.
Each cycle is tested by integrating the corresponding modules,
errors are fixed before the testing of next cycle begins.
Top-down approach to integration testing
Works well for systems with hierarchical design.
In hierarchical design, there is a first top-level module, which is
decomposed into some second-level modules, some of which,
are in turn, decomposed into third-level modules and so on.
Terminal modules are those that are not decomposed and can
occur at any level.
Module hierarchy document is the reference document.
A Three levels.
Seven modules.
B C D
E F G
Top-down integration testing: Steps
A A
B C D B C D
Step I Step II
A Actual module (unit tested)
B C D Stubbed module
E F G
Step III
Top-down integration testing: Steps
A A
B C D B C D
E F G E F G
Step IV Step V
Actual module (unit tested)
A Stubbed module
B C D
E F G
Step VI
Bottom-up approach to integration testing
System integration begins with the integration of lowest level
modules.
A lowest level module is one that does not invoke another
module.
A test driver module invokes the (lowest level) modules to be
integrated.
Once integration testing is done, the test driver is replaced
with actual module and another test driver is used to
integrate modules at higher level...
Bottom-up integration testing: Steps
Test
Test Driver
Driver
B C D
E F G
Step I
E F G
Step II
B C D
E F G
Step III
Sandwich and big bang approach to integration testing
Sandwich approach tests a system by using a mix of top-down
and bottom-up testing.
Lower level modules are tested using bottom-up approach, top
level modules are integrated using top-down approach, rest of
the modules are put in the middle layer.
In big bang approach, all individually tested modules are put
together to construct the entire system which is tested as a
whole.
Design integration testing and graph coverage criteria
Graph models for integration testing:
Nodes are modules/test stubs/test drivers.
Edges are interfaces.
Structural coverage criteria: Deals with calls over interfaces.
Data flow coverage criteria: Deals with exchange of data over
interfaces.