Software Testing -

Integration Level
by Dr. Lam-Son Lê
Vietnamese-German University, Ben Cat, Binh Duong Province
Slides adopted from the textbook
 TABLE OF CONTENTS

01 03
Fundamentals AI and Regression
Testing

02
Integration
04
Testing In the OO Context
 01
Fundamentals
 A Good Test?

A good test has a high probability of finding an error. To achieve this goal, the tester must
understand the software and attempt to develop a mental picture of how the software might fail.
A good test is not redundant. Testing time and resources are limited. There is no point in
conducting a test that has the same purpose as another test. Every test should have a different
purpose (even if it is subtly different).
A good test should be “best of breed”. In a group of tests that have a similar intent, time and
resource limitations may dictate the execution of only those tests that have the highest
likelihood of uncovering a whole class of errors.
A good test should be neither too simple nor too complex. Although it is sometimes possible to
combine a series of tests into one test case, the possible side effects associated with this
approach may mask errors. In general, each test should be executed separately
 Black-Box Testing

Black-box testing alludes to integration testing that is conducted by

exercising the component interfaces with other components and with other
systems. It examines some fundamental aspect of a system with little regard
for the internal logical structure of the software. Instead, the focus is on
ensuring the component executes correctly in the larger software build when
the input data and software context specified by its preconditions is correct
and behaves in the ways specified by its postconditions. It is of course
important to make sure that the component behaves correctly when its
preconditions are not satisfied (e.g., it can handle bad inputs without
crashing). Black-box testing is based on the requirements specified in user
stories.
 White-Box Testing

White-box testing, sometimes called glass-box testing or structural testing, is an

integration testing philosophy that uses implementation knowledge of the control
structures described as part of component-level design to derive test cases. White-box
testing of software is predicated on close examination of procedural implementation details
and data structure implementation details. White-box tests can be designed only after
component-level design (or source code) exists. The logical details of the program must be
available. Logical paths through the software and collaborations between components are
the focus of white-box integration testing. At first glance it would seem that very thorough
white-box testing would lead to “100 percent correct programs.” All we need do is define
all logical paths, develop test cases to exercise them, and evaluate results, that is, generate
test cases to exercise program logic exhaustively.
 02
INTEGRATION TESTING
 Top-Down Integration

● Top-down integration testing is an incremental approach to

construction of the software architecture. Modules (also
referred to as components in this book) are integrated by
moving downward through the control hierarchy, beginning
with the main control module (main program). Modules
subordinate (and ultimately subordinate) to the main control
module are incorporated into the structure in either a
depth-first or breadth-first manner.
 depth-first integration

1. The main control module is used as a

test driver, and stubs are substituted for
all components directly subordinate to
the main control module.
2. Depending on the integration approach
selected (i.e., depth or breadth first),
subordinate stubs are replaced one at a
time with actual components.
3. Tests are conducted as each component
is integrated.
4. On completion of each set of tests,
another stub is replaced with the real
component.
5. Regression testing (discussed later in
this section) may be conducted to
ensure that new errors have not been
introduced.
 Bottom-Up Integration

Bottom-up integration testing, as its name implies, begins

construction and testing with atomic modules (i.e.,
components at the lowest levels in the program structure).
Bottom-up integration eliminates the need for complex stubs.
Because components are integrated from the bottom up, the
functionality provided by components subordinate to a given
level is always available and the need for stubs is eliminated.
 How to proceed?

1. Low-level components are combined

into clusters (sometimes called
builds) that perform a specific
software subfunction.
2. A driver (a control program for
testing) is written to coordinate
test-case input and output.
3. The cluster is tested.
4. Drivers are removed and clusters are
combined, moving upward in the
program structure.
 Continuous Integration

Continuous integration is the practice of merging components into the evolving software
increment once or more each day. This is a common practice for teams following agile
development practices such as XP or DevOps. Integration testing must take place quickly and
efficiently if a team is attempting to always have a working program in place as part of
continuous delivery. It is sometimes hard to maintain systems with the use of continuous
integration tools.

Smoke testing is an integration testing approach that can be used when product software is
developed by an agile team using short increment build times. Smoke testing might be
characterized as a rolling or continuous integration strategy. The software is rebuilt (with new
components added) and smoke tested every day. It is designed as a pacing mechanism for
time-critical projects, allowing the software team to assess the project on a frequent basis.
 Smoke Testing

1. Software components that have been translated into code are integrated into a
build. A build includes all data files, libraries, reusable modules, and engineered
components that are required to implement one or more product functions.
2. A series of tests is designed to expose errors that will keep the build from
properly performing its function. The intent should be to uncover “show-stopper”
errors that have the highest likelihood of throwing the software project behind
schedule.
3. The build is integrated with other builds, and the entire product (in its current
form) is smoke tested daily. The integration approach may be top down or bottom
up.
 Benefits of Smoke Testing

● Integration risk is minimized. Because smoke tests are conducted daily, incompatibilities and
other showstopper errors are uncovered early, thereby reducing the likelihood of serious
schedule impact when errors are uncovered.
● The quality of the end product is improved. Because the approach is construction
(integration) oriented, smoke testing is likely to uncover functional errors as well as architectural
and component-level design errors. If these errors are corrected early, better product quality will
result.
● Error diagnosis and correction are simplified. Like all integration testing approaches, errors
uncovered during smoke testing are likely to be associated with “new software
increments”—that is, the software that has just been added to the build(s) is a probable cause of
a newly discovered error.
● Progress is easier to assess. With each passing day, more of the software has been
integrated and more has been demonstrated to work. This improves team morale and gives
managers a good indication that progress is being made.
 03
AI & REGRESSION TESTING
 Regression Testing
Each time a new module is added as part of integration testing, the software
changes. New data flow paths are established, new input/output (I/O) may
occur, and new control logic is invoked. Side effects associated with these
changes may cause problems with functions that previously worked flawlessly.
In the context of an integration test strategy, regression testing is the
re-execution of some subset of tests that have already been conducted to
ensure that changes have not propagated unintended side effects. Regression
tests should be executed every time a major change is made to the software
(including the integration of new components). Regression testing helps to
ensure that changes (due to testing or for other reasons) do not introduce
unintended behavior or additional errors
 Regression Testing Suite
The regression test suite (the subset of tests to be
executed) contains three different classes of test
cases:
● A representative sample of tests that will exercise all
software functions
● Additional tests that focus on software functions that
are likely to be affected by the change
● Tests that focus on the software components that
have been changed
 The uses of AI
As integration testing proceeds, the number of regression tests can
grow quite large. Therefore, the regression test suite should be
designed to include only those tests that address one or more
classes of errors in each of the major program functions.
A software tool could examine the dependencies among the
components in the software increment after the new components
have been added and generate test cases automatically to use for
regression testing. Another possibility would be using machine
learning techniques to select sets of test cases that will optimize the
discovery of component collaboration errors. This work is promising,
but still requires significant human interaction to review the test
cases and the recommended order for executing them.
 04
INTEGRATION TESTING
IN THE OO CONTEXT
 Thread-based & Use-based Testing
Thread-based testing integrates the set of classes required to respond to one input
or event for the system. Each thread is integrated and tested individually. Regression
testing is applied to ensure that no side effects occur. An important strategy for
integration testing of OO software is thread-based testing. Threads are sets of
classes that respond to an input or event.

Use-based testing begins the construction of the system by testing those classes
(called independent classes) that use very few (if any) server classes. After the
independent classes are tested, the next layer of classes, called dependent classes,
that use the independent classes are tested. This sequence of testing layers of
dependent classes continues until the entire system is constructed. Use-based tests
focus on classes that do not collaborate heavily with other classes.
 Scaffolding
The use of scaffolding software also changes when integration testing
of OO systems is conducted. Drivers can be used to test operations at
the lowest level and for the testing of whole groups of classes. A
driver can also be used to replace the user interface so that tests of
system functionality can be conducted prior to implementation of the
interface. Stubs can be used in situations in which collaboration
between classes is required but one or more of the collaborating
classes has not yet been fully implemented.
 Clustering Testing

Cluster testing is one step in the integration

testing of OO software. Here, a cluster of
collaborating classes (determined by
examining the CRC and object-relationship
model) is exercised by designing test cases
that attempt to uncover errors in the
collaborations.
 Fault-Based Test-Case Design
The objective of fault-based testing within an OO system is to design tests that have a high likelihood of
uncovering plausible faults. Because the product or system must conform to customer requirements,
preliminary planning required to perform fault-based testing begins with the analysis model. The strategy
for fault-based testing is to hypothesize a set of plausible faults and then derive tests to prove each
hypothesis. The tester looks for plausible faults (i.e., aspects of the implementation of the system that may
result in defects). To determine whether these faults exist, test cases are designed to exercise the design or
code.

Integration testing looks for plausible faults in operation calls or message connections. Three types of
faults are encountered in this context: unexpected result, wrong operation/message used, and incorrect
invocation. To determine plausible faults as functions (operations) are invoked, the behavior of the
operation must be examined.

It is important to note that integration testing attempts to find errors in the client object, not the server.
Stated in conventional terms, the focus of integration testing is to determine whether errors exist in the
calling code, not the called code. The operation call is used as a clue, a way to find test requirements that
exercise the calling code.
multiple-class partition testing
 a sequence of operations for Bank
consider a sequence of operations for the Bank class relative to an ATM class

verifyAcct•verifyPIN•[[verifyPolicy•withdrawReq]|depositReq|acctInfoREQ]n

A random test case for the Bank class might be

Test case r3 = verifyAcct•verifyPIN•depositReq

To consider the collaborators involved in this test, the messages associated with each of the operations
noted in test case r3 are considered. Bank must collaborate with ValidationInfo to execute the
verifyAcct() and verifyPIN(). Bank must collaborate with Account to execute depositReq(). Hence, a new test
case that exercises these collaborations is

Test case r4 = verifyAcct [Bank:validAcctValidationInfo]•verifyPIN

[Bank: validPinValidationInfo]•depositReq [Bank: depositaccount
 Scenario-Based Test-Case Design
Fault-based testing misses two main types of errors: (1) incorrect specifications and
(2) interactions among subsystems. When errors associated with an incorrect specification
occur, the product doesn’t do what the customer wants. It might do the wrong thing or omit important
functionality. But in either circumstance, quality (conformance to requirements) suffers. Errors associated
with subsystem interaction occur when the behavior of one subsystem creates circumstances (e.g., events,
data flow) that cause another subsystem to fail.

Scenario-based testing will uncover errors that occur when any actor interacts with the software.
Scenario-based testing concentrates on what the user does, not what the product does. This means
capturing the tasks (via use cases) that the user has to perform and then applying them and their variants
as tests. This is very similar to thread testing.
 Testing Patterns
Testing patterns describe common testing problems and solutions that can assist you in dealing with them.
Much of software testing, even during the past decade, has been an ad hoc activity. If testing patterns can
help a software team to communicate about testing more effectively, to understand the motivating forces
that lead to a specific approach to testing, and to approach the design of tests as an evolutionary activity
in which each iteration results in a more complete suite of test cases, then patterns have accomplished
much.
Some Exemplary Testing Patterns
 THANKS!
Do you have any questions?
youremail@[Link]
+91 620 421 838
[Link]

CREDITS: This presentation template was created by

Slidesgo, incluiding icons by Flaticon, and
infographics & images by Freepik.

Please, keep this slide for attribution.