SOFTWARE TESTING METHODOLOGIES AND TOOLS

(A1217156) SOFTWARE TESTING METHODOLOGIES AND TOOLS

UNIT IV

UNIT-IV: Logic Based testing: Overview, decision tables, path expressions, KV

charts, and specifications
Logic Based testing:

 Overview
 Decision tables
 Path expressions
 KV charts
 Specifications

Prepared by: Dept. of CSE, RGMCET Page 1

 SOFTWARE TESTING METHODOLOGIES AND TOOLS

Overview:
The fundamental requirements of many programs can be specified by decision
tables, which provide a useful basis for program and test design. Consistency
and completeness can be analyzed by using Boolean algebra, which can also be
used as a basis for test design. Boolean algebra is trivialized by using
Karnaugh -Veitch charts.

Programmers and Logic:

“Logic” is one of the most often used words in programmer‟s vocabularies but
one of their least used techniques. This chapter concerns logic in its simplest
form, Boolean algebra, and its application to program and specification test
and design. Boolean algebra is to logic as arithmetic is to mathematics.
Without it, the tester or programmer is cut off from many test and design
techniques and tools that incorporate those techniques.

Hardware logic Testing:

Logic has been, for several decades, the primary tool of hardware logic
designers. Today, hardware logic design and more important in the context of
this book, hardware logic test design, are intensely automated. Many test
methods developed for hardware logic can be adapted to software logic testing,
because hardware testing automation is 10 to 15 years ahead of software
testing automation.

Note:

Hardware testing is ahead of software testing not because hardware

testers are smarter than software testers but because hardware testing is
easier.

Prepared by: Dept. of CSE, RGMCET Page 2

 SOFTWARE TESTING METHODOLOGIES AND TOOLS

Specification Systems and Languages

As programming and test techniques have improved, the bugs have shifted
closer to requirements and their specifications. These bugs range from 8% to
30% of the total and because they‟re first-in and last-out, they‟re the costliest
of all.

The trouble with specifications is that they're hard to express. Logicians have
struggled with this problem since Aristotle's time. Boolean algebra (also known
as the sentential calculus) is the most basic of all logic systems. Higher-order
logic systems are needed and used for formal specifications. If you have a
relatively painless specification system, to understand why your specification
was rejected or how it was transformed, you'll have to understand Boolean
algebra.

Knowledge-Based Systems:

The knowledge-based system (also expert system or “artificial intelligence”

system) has become the programming construct of choice for many
applications that were once considered very difficult. Knowledge-based systems
incorporate knowledge from a knowledge domain such as medicine, law, or civil
engineering into a database. The data can then be queried and interacted with
to provide solutions to problems in that domain. One implementation of
knowledge-based systems is to incorporate the expert's knowledge into a set of
rules. The user can then provide data and ask questions based on that data.
The user's data is processed through the rule base to yield conclusions
(tentative or definite) and requests for more data. The processing is done by a
program called the inference engine.

Prepared by: Dept. of CSE, RGMCET Page 3

 SOFTWARE TESTING METHODOLOGIES AND TOOLS

Decision tables:

Decision table is a table consists of four areas called condition stub, the
condition entry, the action stub, and the action entry. Each column of the table
is a rule that specifies the conditions under which the actions named in the
action stub will take place.

 The condition stub is a list of names of conditions.

 A rule specifies whether a condition should or should not be met for the
rule to be satisfied. "YES" means that the condition must be met, "NO"
means that the condition must not be met, and "I" means that the
condition plays no part in the rule, or it is immaterial to that rule.

 The action stub names the actions the routine will take or initiate if the
rule is satisfied.

 If the action entry is "YES," the action will take place; if "NO," the action
will not take place.
 Action 1 will be taken if predicates 1 and 2 are true and if predicates 3 and
4 are false (rule 1), or if predicates 1, 3, and 4 are true (rule 2).
 Action 2 will be taken if the predicates are all false, (rule 3).
 Action 3 will take place if predicate 1 is false and predicate 4 is true (rule 4).

Prepared by: Dept. of CSE, RGMCET Page 4

 SOFTWARE TESTING METHODOLOGIES AND TOOLS

In addition to the stated rules, we also need a Default Rule that specifies the
default action to be taken when all other rules fail.
The default rules for the above table are:

Decision-table processors:

Decision tables can be automatically translated into code and, as such, are a
higher order language. The decision table's translator checks the source
decision table for consistency and completeness and fills in any required
default rules. The usual processing order in the resulting object code is, first,
to examine rule 1. If the rule is satisfied, the corresponding action takes place.
Otherwise, rule 2 is tried. This process continues until either a satisfied rule
results in an action or no rule is satisfied and the default action is taken.
Decision tables as a source language have the virtue of clarity, direct
correspondence to specifications, and maintain ability.

Decision Tables as a Basis for Test Case Design

If a specification is given as a decision table, it follows that decision tables

should be used for test case design. Similarly, if a program's logic is to be
implemented as decision tables, decision tables should also be used as a basis
for test design.
Even if you can specify the program's logic as a decision table, it is not always
possible or desirable to implement the program as a decision table because the

Prepared by: Dept. of CSE, RGMCET Page 5

 SOFTWARE TESTING METHODOLOGIES AND TOOLS

program's logical behavior is only part of its behavior. The program interfaces
with other programs, there are restrictions, or the decision-table language may
not have needed features. Any of these reasons could be sufficient to reject a
decision-table implementation.

The use of a decision-table model to design tests is warranted or necessary in

the following situations:

1. The specification is given as a decision table or can be easily converted into

one.
2. The order in which the predicate are evaluated does not affect interpretation
of the rules or the resulting action—i.e., an arbitrary permutation of the
predicate order will not, or should not, affect which action takes place.
3. The order in which the rules are evaluated does not affect the resulting
action—i.e., an arbitrary permutation of rules will not, or should not, affect
which action takes place.
4. Once a rule is satisfied and an action selected, no other rule need be
examined.
5. If several actions can result from satisfying a rule, the order in which the
actions are executed doesn't matter.

Expansion of Immaterial Cases:

Improperly specified immaterial entries (I) cause most decision-table

contradictions. If a condition's truth value is immaterial in a rule, satisfying the
rule does not depend on the condition. It doesn't mean that the case is
impossible.

Prepared by: Dept. of CSE, RGMCET Page 6

 SOFTWARE TESTING METHODOLOGIES AND TOOLS

For example,
Rule 1: “If the persons are male and over 30, then they shall receive a
15% raise. ”
Rule 2: "But if the persons are female, then they shall receive a 10% raise."

The above rules state that age is material for a male's raise, but immaterial for
determining a female's raise.

Expansion of Immaterial Cases for Rules 2 and 4 is shown below:

Rule 2.1 Rule 2.2 Rule 4.1 Rule 4.2 Rule 4.3 Rule 4.4
CONDITION 1 YES YES YES YES YES YES
CONDITION 2 YES NO YES YES NO NO
CONDITION 3 YES YES YES NO NO YES
CONDITION 4 YES YES YES YES YES YES

Rule 2 has been expanded by converting the „I‟ entry for condition 2 into a
separate rule 2.1 for YES and 2.2 for NO. Similarly, condition 2 was expanded
in rule 4 to yield intermediate rules 4.1/4.2 and 4.3/4.4, which were then
expanded via condition 3 to yield the four subrules shown.

If no default rules are given, then all cases not covered by explicit rules are
perforce default rules (or are intended to be). If default rules are given then you
must test the specification for consistency. The specification is complete if and
only if n (binary) conditions expand into 2n unique subrules. It is consistent if
and only if all rules expand into subrules whose condition combinations do not
match those of any other rules. Table (d) is an example of an inconsistent
specification in which the expansion of two rules yields a contradiction.

Prepared by: Dept. of CSE, RGMCET Page 7

 SOFTWARE TESTING METHODOLOGIES AND TOOLS

Rules 1 and 2 are contradictory because the expansion of rule 1 via condition 2
leads to the same set of predicate truth values as the expansion of rule 2 via
condition 3. Therefore action 1 or action 2 is taken depending on which rule is
evaluated first.

Test Case Design:

Test case design by decision tables begins with examining the specifications
consistency and completeness. This is done by expanding all immaterial cases
and checking the expanded tables. Also, make the default case explicit and
treat it as just another set of rules for the default action. Once the
specifications have been verified, the objective of the test cases is to show that
the implementation provides the correct action for all combinations of predicate
values.

Decision-tables and structure:

Decision tables can also be used to examine a program's structure.
Below Figure shows a program segment that consists of a decision tree.
These decisions, in various combinations, can lead to actions 1, 2, or 3.

Prepared by: Dept. of CSE, RGMCET Page 8

 SOFTWARE TESTING METHODOLOGIES AND TOOLS

If the decision appears on a path, put in a YES or NO as appropriate. If the

decision does not appear on the path, put in an I, Rule 1 does not contain
decision C, therefore its entries are: YES, YES, I, YES.

The corresponding decision table is shown in Table below:

If we expand the immaterial cases for the above Table, it results in Table as
below:

Sixteen cases are represented in the above Table, and no case appears twice.

Prepared by: Dept. of CSE, RGMCET Page 9

 SOFTWARE TESTING METHODOLOGIES AND TOOLS

Path Expressions:
Logic-based testing is structural testing when it's applied to structure (e.g.,
control flow graph of an implementation); its functional testing when it's
applied to a specification. In logic-based testing we focus on the truth values of
control flow predicates.

Predicates and Relational Operators:

A predicate is implemented as a process whose outcome is a truth-functional
value. Don't restrict your notion of predicate to arithmetic relations such as >,>
=, =, <=, <, ≠, Predicates are based on relational operators, of which the
arithmetic relational operators are merely the most common.
Here's a sample of some other relational operators:
... is a member of....,
... is a subset of...,
… is a substring of...,
... is a sub graph of....,
... dominates….. ,
... is dominated by ….,
… is above…,
... is below.....

Predicates need not be restricted to binary truth values (TRUE/FALSE). There

multiway predicates, of which the FORTRAN three-way IF is the most notorious
and the case statement the most useful.

For our purpose, logic based testing is restricted to binary predicates. If you
have case statements, you have to analyze things one case at a time if you're to
use these methods. If you have many case statements, there will be a lot of
bookkeeping and you're probably pushing the applicability of logic based
testing.

Prepared by: Dept. of CSE, RGMCET Page 10

 SOFTWARE TESTING METHODOLOGIES AND TOOLS

Consider the following sample flow graph.

The conversion of this flow graph into a decision table after expansion is shown
below:

What Goes Wrong with Predicate

Several things can go wrong with predicates, especially if the predicate has to
be interpreted in order to express it as a predicate over input values,

1. The wrong relational operator is used: e.g., > instead of <=.

2. The predicate expression of a compound predicate is incorrect: e.g., A +B
instead of AB.
3. The wrong operands are used: e.g., A > X instead of A > Z.
4. The processing leading to the predicate is faulty.

Prepared by: Dept. of CSE, RGMCET Page 11

 SOFTWARE TESTING METHODOLOGIES AND TOOLS

Logic-based testing is useful against the first two bug types, whereas data flow
testing is more useful against the latter two.

Boolean algebra:

Let's take a structural viewpoint for the moment and review the steps
taken to get the predicate expression of a path.

1. Label each decision with an uppercase letter that represents the truth
value of the predicate. The YES or TRUE branch is labeled with a letter
and the NO or FALSE branch with the same letter over scored.
2. The truth value of a path is the product of the individual labels.
Concatenation or products mean "AND”.
3. If two or more paths merge at a node, the fact is expressed by use of a
plus sign (+) which means "OR”.

Using this convention, the truth-functional values for several of the nodes can
be expressed in terms of segments from previous nodes. Use the node name to
identify the point.

N6 = A + A‟B‟C‟
N8 = (N6) B + A‟B = AB + A‟B‟C‟B + A‟B
N11 = (N8) C + (N6) B‟C
N12 = N11 + A‟B‟C
N2 = N12 + (N8) C‟ + (N6) B‟C‟

The expression for node 6 can be rewritten as:

"Either it is true that decision A is satisfied (YES) OR it is true that decision A

is not satisfied (NO) AND decision B is not satisfied AND decision C is not
satisfied ,OR both,”

Prepared by: Dept. of CSE, RGMCET Page 12

 SOFTWARE TESTING METHODOLOGIES AND TOOLS

The “OR” in Boolean algebra is always an inclusive OR, which means “A or B

or both.” The exclusive OR, which means “A or B, but not both” is A’B + AB’.

There are only two numbers in Boolean algebra: zero (0) and one (1). „1‟
means "always true” and „0‟ means "always false."

Laws of Boolean algebra:

Idempotency Law

1. A + A = A [if both stmt. are true, then the resultant stmt. is true]

A‟ + A‟ = A‟ [if both stmt. are false, then the resultant stmt. is false]

Null Law
2. A + 1 =1 [Here „1‟ is universal true. According to „+‟ operation, if
one statement is true, then the resultant statement is
always true]

3. A + 0 =A [Here „0‟ is null value]

Commutative law
4. A + B =B + A
Other Laws
5. A + A‟ =1 [If either A is true or not-A is true, then statement is always true]
6. AA =A
A‟A‟ =A‟
7. A × 1 =A
8. A × 0 =0
Commutative law of multiplication
9. AB =BA
10. AA‟ = 0 [A statement can‟t be simultaneously true and false]

Prepared by: Dept. of CSE, RGMCET Page 13

 SOFTWARE TESTING METHODOLOGIES AND TOOLS

11. (A‟)‟ =A
Involution law
12. 0‟ = 1
13. 1‟ = 0
Demorgan’s Law
14. (A + B)‟ =A‟B‟
15. (AB)‟ =A‟ + B‟
Distributive law
16. A (B + C) =AB + BC
Associative law for multiplication
17. (AB) C =A (BC)
Associative law for addition
18. (A + B) + C = A + (B + C)
Absorptive law
19. A + A‟B =A + B
20. A + AB =A

The path expressions can now be simplified by applying these rules. The steps
are shown in detail to illustrate the use of the rules. Usually, it‟s done with far
less work. It pays to practice.
N6 = A + A‟B‟C‟
= A+B‟C‟ : use Rule 19, with B=B‟C‟

N8 = (N6) B + A‟B
= (A + B‟C‟) B + A‟B
= AB + B‟C‟B + A‟B
= AB + 0C + A‟B
= B (A + A‟) = B (1) =B

Prepared by: Dept. of CSE, RGMCET Page 14

 SOFTWARE TESTING METHODOLOGIES AND TOOLS

N11 = (N8) C + (N6) B‟C

= BC + (A + B‟C‟) B‟C
= BC + AB‟C + B‟C‟B‟C
= BC + AB‟C + 0
= C (B + AB‟)
=C (B +A)
=AC + BC

N12 = N11 + A‟B‟C

= AC +BC + A‟B‟C
= C (B + A‟B‟) +AC
= C (A‟+B) + AC
= CA‟+AC+BC
= C+BC
=C

N2 = N12 + (N8) C‟ + (N6) B‟C‟

= C + BC‟ + (A +B‟C‟) B‟C‟
= C + BC‟ + AB‟C‟ +B‟C‟
= C+ BC‟ + B‟C‟ (1+A)
= C + BC‟ +B‟C‟ (1)
= C + C‟ (B+B‟)
=C +C‟ (1)
=1

Prepared by: Dept. of CSE, RGMCET Page 15

 SOFTWARE TESTING METHODOLOGIES AND TOOLS

KV Charts:

It is okay to slug through Boolean algebra expressions to determine which

cases are interesting and which combination of predicate values should be
used to reach which node; it's okay, but not necessary. If you had to deal with
expressions in four, five, or six variables, you could get bogged down in the
algebra and make as many errors in designing test cases as there are bugs in
the routine you're testing. The Karnaugh-Veitch chart reduces Boolean
algebraic manipulations to graphical trivia. Beyond six variables these
diagrams get cumbersome, and other techniques such as the Quine-
McCluskey method should be used.

One –variable map:

Below figure shows all the boolean functions of a single variable and their
equivalent representation as a KV chart.

Prepared by: Dept. of CSE, RGMCET Page 16

 SOFTWARE TESTING METHODOLOGIES AND TOOLS

Two–variable maps:

Each box corresponds to the combination of values of the variables for the row
and column of that box.

A pair may be adjacent either horizontally or vertically but not diagonally.

Any variable that changes in either the horizontal or vertical direction does not
appear in the expression.

Prepared by: Dept. of CSE, RGMCET Page 17

 SOFTWARE TESTING METHODOLOGIES AND TOOLS

In the fifth chart, the B variable changes from 0 to 1 going down the column,
and because the A variable's value for the column is 1, the chart is equivalent
to a simple A.

Given two charts over the same variables, arranged the same way, their
product is the term by term product, their sum is the term by term sum, and

Prepared by: Dept. of CSE, RGMCET Page 18

 SOFTWARE TESTING METHODOLOGIES AND TOOLS

the negation of a chart is gotten by reversing all the 0 and 1 entries in the
chart.

OR

Three–variable maps:

KV charts for three variables are shown below.

As before, each box represents an elementary term of three variables with a bar
appearing or not appearing according to whether the row-column heading for
that box is 0 or 1.

A three-variable chart can have groupings of 1, 2, 4, and 8 boxes.

Prepared by: Dept. of CSE, RGMCET Page 19

 SOFTWARE TESTING METHODOLOGIES AND TOOLS

Prepared by: Dept. of CSE, RGMCET Page 20

 SOFTWARE TESTING METHODOLOGIES AND TOOLS

Four–variable maps:

A four-variable chart and several possible adjacencies are shown below.

Adjacencies can now consist of 1, 2, 4, 8, and 16 boxes, and the terms
resulting will have 4, 3, 2, 1, and 0 literals in them respectively:

Prepared by: Dept. of CSE, RGMCET Page 21

 SOFTWARE TESTING METHODOLOGIES AND TOOLS

Five–variable maps:
Below figure is a five-variable chart with some of the adjacencies shown.

Specifications:
There's no point in getting into design and coding until you‟re sure that the
specification is logically consistent and complete. This section shows you how
much of specification analysis can be done using the KV charts, pencil and
paper.

You'll need to use such methods until your automated specification system and
language comes on stream (which needs long time).

Alternatively, if you have a specification system, this section gives you an

insight into some of the processing done by it.

The procedure for specification and validation is as follows:

1) Rewrite the specification using consistent terminology.

2) Identify the predicates on which the cases are based. Name them with
suitable letters such as A, B, C.
Prepared by: Dept. of CSE, RGMCET Page 22
 SOFTWARE TESTING METHODOLOGIES AND TOOLS

3) Rewrite the specification in English that uses only the logical connectives
AND, OR, and NOT.

4) Convert the rewritten specification into an equivalent set of boolean

expressions

5) Identify the default action and cases, it any are specified.

6) Enter the Boolean expressions in a KV chart and check for consistency.

If the specifications are consistent, there will be no overlaps, except for
cases that result in multiple actions.

7) Enter the default cases and check for consistency.

8) If all boxes are covered, the specification is complete.

9) If the specification is incomplete or inconsistent, translate the cor-

responding boxes of the KV chart back into English and get a
clarification, explanation, or revision.

10) If the default cases were not specified explicitly, translate the
default cases back into English and get a confirmation.

Finding and Translating the Logic:

The predicates are written using the AND, OR and NOT Boolean connectivities.
Therefore, the problem should be one of finding the keywords: IF, THEN, AND,
OR, and NOT.
Unfortunately we have to deal real world of specifications and
specification writers, where clarity ranges from elusive [difficult to describe],
through esoteric [Mysterious], into incomprehensible.

Samples of phrases that have been or can be used for the words we need are:

Prepared by: Dept. of CSE, RGMCET Page 23

 SOFTWARE TESTING METHODOLOGIES AND TOOLS

IF: based on, based upon, because, but, if, if and when, only if, only when,
provided that, when, when or if, whenever

THEN: applies to, assign, consequently, do, implies that, infers that, initiate,
means that, shall, should, then will, would.

AND: all, and, as well as, both, but, in conjunction with, coincidental with,
consisting of, comprising, either….or, furthermore, in addition to, including,
jointly, moreover, mutually, plus, together with, total, with.

OR: and, and if . . . then, and/or, alternatively, any of, anyone of as well as,
but, case, contrast, depending upon, each, either, either. . . or, except if,
conversely, failing that, furthermore, in addition to, nor, not only . . . but,
although, other than, otherwise, or, or else, on other hand, plus.

NOT: but, but not, by contrast, besides, contrary, conversely, contrast, except
if, excluding, excepting, fail, failing, less, neither, never, no, not, other than.

EXCLUSIVE OR: but, by contrast, conversely, nor, on the other hand, other
than, or.

IMMATERIAL: independent of, irregardless, irrespective, irrelevant, regardless,

but not if, whether or not.

Ambiguities and Contradictions

Here is a specification:

A1 = BC‟D‟ + AB‟C‟D

A2 = AC‟D‟ + AC‟D + AB‟C‟ + ABC‟

A3 = BD + BCD‟

ELSE = B‟C + A‟B‟C‟D‟

Prepared by: Dept. of CSE, RGMCET Page 24

 SOFTWARE TESTING METHODOLOGIES AND TOOLS

Here is the KV chart for this specification (here we‟re using the numerals 1, 2,
3, and 4 to represent the actions and the default case):

There is an ambiguity, probably related to the default case: A’B’C’D is missing.

The specification layout seems to suggest that this term also belongs to the
default action. I would ask the question twice:

1. Is A‟B‟C‟D also to be considered a default action?

2. May the default action be rephrased as B’C+A’B’?

Ambiguous conditions may occur in the following situations:

There are several boxes that call for more than one action. If the specification
did not explicitly call out both actions in a sentence, such as, "IF ABC’D’ then
both action1 and action 2 shall be taken,".

I would treat that each box that contained more than one action as a Potential
conflict. Similarly, if the specification did say, ". . . both A1 any A2 . . ." but did
not mention A3, as in the ABCD entry, I would also question that entry.

If no explicit default action is specified, then fill out the KV chart with explicit
entries for the explicitly specified actions, negate the entire chart and present

Prepared by: Dept. of CSE, RGMCET Page 25

 SOFTWARE TESTING METHODOLOGIES AND TOOLS

the equivalent expression as a statement of the default. In the above example,

had no default action been given, all the blank spaces would have been replaced
with 1's and the B’C+A’B’ expression would have resulted.

Be suspicious of almost complete groups of adjacencies. For example if a term

contains several adjacent boxes and lacks only one to make a full eight
adjacency, question the missing box. I would question 3 out of 8, 13 through 15
out of 16, and so on, especially if the missing boxes are not themselves adjacent.

It's also useful to present the new version of the specification, as a table that shows all
cases explicitly and also as a compact version in which you've taken advantage of the
possibility of simplifying the expression by using a KV chart.

You present the table and say that, "This table can also be expressed as. . . .”.
There may be disagreement. The specifier might insist that the table does not
correspond to the specification and that the table does not correspond to your
compact statement, which you know was derived from the table by using
Boolean algebra. Don't be smug [self-satisfied] if that happens. Just as often as
the seeming contradiction will be due to not understanding the equivalence, it
will be due to a predicate that has not been explicitly stated.

Don't-Care and Impossible Terms:

There are only three things in this universe are impossible:

1) Solving a provably unsolvable problem, such as creating a universal

program verifier.
2) Knowing both the exact position and the exact momentum of a
fundamental particle.
3) Knowing what happened before the "big bang" that started the universe.
Everything else is improbable, but not impossible. So-called "impossible"
cases can be used to advantage to simplify logic and, consequently, to simplify
the programs that implement that logic.

Prepared by: Dept. of CSE, RGMCET Page 26

 SOFTWARE TESTING METHODOLOGIES AND TOOLS

Taking advantage of "impossible" and “illogical” cases is a dangerous

practice and should be avoided, but if you insist on doing that sort of things,
you might as well does it right:

1) Identify all "impossible" and "illogical" cases and confirm them.

2) Document the fact that you intend to take advantage of them.
3) Fill out the KV chart with the possible cases and then fill in the
impossible cases. Use the combined symbol which is to be interpreted as
a 0 or 1, depending on which value provides the greatest simplification of
the logic. These terms are called don't-care terms because the case is
presumed impossible, and we don't care which value (0 or 1) is used.

Here is an example:

By not taking advantage of the impossible conditions, we get the resulting

Boolean expression

CD’+ CB + CA + A’BD’ +A’B’C’D

By taking advantage of the impossible conditions, we get

C + A’

Prepared by: Dept. of CSE, RGMCET Page 27