Database Reference
In-Depth Information
tests for modifi ed modules that lie within the fi rewall and integration tests for groups of
interfacing modules that lie within the fi rewall. Leung and White (1992) extend their tech-
nique to handle interactions involving global variables.
The fi rewall technique selects all units and integration tests of modules that lie within
the fi rewall. Because not all of these tests necessarily execute modifi ed code, the technique
selects non-modifi cation-traversing tests. It handles multiple modifi cations in a single pass
of its algorithm.
Implementing the fi rewall concepts for database applications requires three elements:
(a) Database application Call Graph.
(b) Data fl ow dependencies between interfacing modules resulting from database tables
usages.
(c) List of modifi ed database modules.
Call Graph links a database module to all the modules that it calls. It should include
links to table triggers modules in case the module contains statements that cause these trig-
gers to execute. In order to fi nd the data fl ow dependencies between interfacing database
modules, we fi rst have to fi nd the table usages in each module and then use Call Graph to
fi nd defi ne-use associations between table usages.
To fi nd modifi ed database modules, we perform impact analysis using the Component
Firewall impact analysis technique. However, not all the modules selected by impact analysis
are selected. We divide these modules into two sets. The fi rst set of modules contains the
modules that have been included because of modifi cations made to their code, or because
they use modifi ed non-module components. All modules in this set are considered by the
Call Graph Firewall regression testing technique as modifi ed. The rest of the modules are
included in the second set and are not considered modifi ed.
The new version of the database application is used only to determine the list of
modifi ed modules. If such a list is available from other sources then the new version of the
database application is not needed.
Call Graph Firewall deals with two types of test cases: integration tests and unit tests.
It determines which interfacing module couples need integration testing, so all the test cases
passing through a selected couple should be selected. The table data fl ow information is
used to determine:
(a) Modules in need of unit testing other than the directly modifi ed modules.
(b) Interfacing module couples in need of integration testing to limit propagation of
modifi cation effects.
For example, consider the Call Graph of Figure 10. Suppose that a modifi cation on
column
X
has been done at module 7. Let set
E
be the set of nodes constituting the fi rewall,
and let set
W
be the set of node couples that need integration testing as a result of change.
Applying the algorithm leads to the following: the backward walk identifi es module
4
where
a defi nition of column
X
is found. Then, modules
2
and
3
with their arcs
(2, 4)
and
(3, 4)
, to
the defi nition in module 4 are added to
W.
Module
1
with its arcs
(1, 2)
and
(1, 3)
is added
to the fi rewall
E
. Next, a depth fi rst search procedure is applied, leading to the addition of
module
7
to
W
because a c-use of column
X
is found. Also, the predecessor of module
7
,
module
5,
is added to W. Therefore, the fi rewall is composed of the components
1, 2
and
