0% found this document useful (0 votes)
37 views10 pages

Unit 2 ST Notes

Uploaded by

apkbala107
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
37 views10 pages

Unit 2 ST Notes

Uploaded by

apkbala107
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 10

7/23/2024

Unit 2

PREDICATES, PATH PREDICATES AND ACHIEVABLE


PATHS

4.3.1 Predicates
• The value of the decision variable decides the direction taken
at the decision. For binary decisions, decision is taken in the
form of a Boolean expression whose outcome is either true or
false. The logical function evaluated at a decision is called a
predicate. Every path corresponds to a succession of
TRUE/FALSE values for the predicates traversed on that path.
A predicate associated with a path is called a path predicate.

1
7/23/2024

Cont...
Multiway Branches
• The path taken through a multiway branch such as GOTO, case
statements, or jump statements (in assembly language)
cannot be directly expressed in the terms of TRUE/FALSE.
Although such alternatives can be described in the terms of
multivalued logic, an easier expedient is to express multiway
branches as an equivalent set of IF..THEN..ELSE statements.
This translation may not be unique as there are several ways
create a tree of IF..THEN..ELSE.

Cont...
Inputs
• In testing, input does not only refer to the direct inputs in the
form of variables in a subroutine call, but includes all data
objects referenced by the routine whose values are fixed prior
to entering it, e.g. inputs in a calling sequence, objects in a
data structure, values left in a register. Inputs can be treated
as numbers irrespective if they are numbers, Boolean,
integers, etc. Because an array can be mapped onto a
onedimensional array, we can treat the set of inputs to the
routine as if it is a onedimensional array, which we call input
vector.

2
7/23/2024

Cont...
4.3.2 Predicate Expressions
Predicate Interpretation
• The act of symbolic substitution of operations along the path
in order to express the predicate solely in terms of the input
vector is called predicate expression. The interpretation may
depend upon the path. For example,
INPUT X
ON X GOTO A,B,C,….
A: Z := 7 @ GOTO HEM
B: Z := -7 @ GOTO HEM
C: Z := 0 @ GOTO HEM …..
HEM: DO SOMETHING
….
HEN: IF Y + Z > 0 GOTO ELL ELSE GOTO EMM

Cont...
• The predicate interpretation at HEN depends upon the path
we took through the first multiway branch. It includes three
cases i.e. “IF Y + 7 > 0 GOTO…”, “IF Y – 7 > 0 GOTO…” and “IF Y
> 0 GOTO…”. Because every path can lead to a different
interpretation of predicates along that path, a predicate that
after interpretation does not depend on input values does not
necessarily constitute a bug.
• The path predicates are the specific form of the predicates of
the decisions along the selected path after interpretation.

3
7/23/2024

Cont...
Independence and Correlation of Variables and
Predicates
A variable is independent of processing if its value does not
change as a result of processing. if all the variables on which a
predicate is based are process independent, it follows that the
predicate must be process independent and therefore its
truth value is determined by the inputs directly.
4.3.3 Predicate Coverage
Predicate coverage is said to have been achieved if all the
possible combinations of truth values corresponding to the
selected path have been explored under some test.

Cont...
4.3.4 Testing Blindness
• Testing Blindness is a pathological (harmful) situation in which
the desired path is achieved for the wrong reason.
• There are three types of Testing Blindness:
Assignment Blindness:
• Assignment blindness occurs when the buggy predicate
appears to work correctly because the specific value chosen
for an assignment statement works with both the correct and
incorrect predicate.

4
7/23/2024

Cont...
• If the test case sets Y=1 the desired path is taken in either
case, but there is still a bug.
Equality Blindness:
• Equality blindness occurs when the path selected by a prior
predicate results in a value that works both for the correct
and buggy predicate.

• The first predicate if y=2 forces the rest of the path, so that for
any positive value of x. The path taken at the second predicate
will be the same for the correct and buggy version.

Cont...
Self Blindness:
• Self blindness occurs when the buggy predicate is a multiple
of the correct predicate and as a result is indistinguishable
along that path.

• The assignment (x=a) makes the predicates multiples of each


other, so the direction taken is the same for the correct and
buggy version.

5
7/23/2024

4.5 PATH INSTRUMENTATION


• Path instrumentation is what we have to do to confirm that
the outcome was achieved by the intended path.
• Co-incidental Correctness: The coincidental correctness
stands for achieving the desired outcome for wrong reason.

Cont...
• The above figure is an example of a routine that, for the
(unfortunately) chosen input value (X = 16), yields the same
outcome (Y = 2) no matter which case we select. Therefore,
the tests chosen this way will not tell us whether we have
achieved coverage. For example, the five cases could be
totally jumbled and still the outcome would be the same. Path
Instrumentation is what we have to do to confirm that the
outcome was achieved by the intended path.
• The types of instrumentation methods include:

6
7/23/2024

Cont...
1. Interpretive Trace Program:
• An interpretive trace program is one that executes every
statement in order and records the intermediate values of all
calculations, the statement labels traversed etc.
2. Traversal Marker or Link Marker:
• A simple and effective form of instrumentation is called a
traversal marker or link marker.
• Name every link by a lower case letter.

4.6 INSTRUMENTATION AND


APPLICATION OF PATH TESTING
4.6.1 Integration, Coverage and Paths in Called
Components
• Path testing methods are used in unit testing especially for
new software.
• Integration proceeds in associated blocks of components
while a bottom-up integration strategy may be used in parts.
Stubs may be correctly avoided because its bug potential may
be higher than that of a real routine.
• Path testing relies on the assumption that we can do effective
testing one level at a time without being overly concerned
with what happens at the lower levels.
• We typically loose around 15% coverage with each level. Thus,
while we may achieve C2 at the current level, path tests will
achieve 85% one level down, 70% two levels down, and so on.

7
7/23/2024

Cont…
4.6.2 New Code
• Completely new or substantially modified code should be
subjected to enough path testing to achieve C2.
4.6.3 Maintenance
• The situation in the case of maintenance is different. Path
testing would be used first for the modified components but
called and co-requisite components will be invariably real
rather than simulated.
4.6.4 Re-hosting
• Path testing with the coverage C1 + C2 is a powerful tool for
re-hosting old software. The objective of re-hosting is to
change the environment and not the software.

5.3 TRANSACTION FLOW TESTING TECHNIQUES

• Transaction flows are like control flow graphs, and


consequently we should expect to have them in increasing
levels of detail.
5.3.1 Inspections, Reviews and Walkthroughs
• Transaction flows are natural agenda for system reviews or
inspections.
• In conducting the walkthroughs, you should:
o Discuss enough transaction types to account for 98%-99% of the
transaction the system is expected to process.
o Discuss paths through flows in functional rather than technical terms.
o Ask the designers to relate every flow to the specification and to show
how that transaction, directly or indirectly, follows from the requirements.

8
7/23/2024

Cont…
• Make transaction flow testing the corner stone of system
functional testing just as path testing is the corner stone of
unit testing.
• Select additional flow paths for loops, extreme values, and
domain boundaries.
• Design more test cases to validate all births and deaths.
• Publish and distribute the selected test paths through the
transaction flows as early as possible so that they will exert
the maximum beneficial effect on the project.

Cont…
5.3.2 PATH SELECTION:
• Select a set of covering paths (c1+c2) using the analogous
criteria you used for structural path testing.
• Select a covering set of paths based on functionally sensible
transactions as you would for control flow graphs.
• Try to find the most tortuous, longest, strangest path from the
entry to the exit of the transaction flow.
5.3.3 PATH SENSITIZATION:
• Most of the normal paths are very easy to sensitize-80% - 95%
transaction flow coverage (c1+c2) is usually easy to achieve.
• The remaining small percentage is often very difficult.
• Sensitization is the act of defining the transaction. If there are
sensitization problems on the easy paths, then bet on either a
bug in transaction flows or a design bug.

9
7/23/2024

Cont…
5.3.4 PATH INSTRUMENTATION:
• Instrumentation plays a bigger role in transaction flow testing
than in unit path testing.
• The information of the path taken for a given transaction must
be kept with that transaction and can be recorded by a central
transaction dispatcher or by the individual processing
modules.
• In some systems, such traces are provided by the operating
systems or a running log.

Cont…
5.3.5 Test Databases
• The testers and the developers to design their own databases
which are not compatible with each other. Thus, to avoid such
problems, often testing groups are given this responsibility as
the independent testers need more elaborate test setups than
programmers.
5.3.6 Execution
The transaction flow testing mostly requires test execution
automation

10

You might also like