Chapter - 10 LOGIC-BASED TESTING

Programmers and Logic “Logic” is one of the most often used words In programmers’ vocabularies but one of their least used techniques. Boolean Algebra is being the simplest form of logic. Boolean Algebra is to logic as arithmetic is to mathematics.

Hardware Logic Testing Logic has been the primary tool of hardware logic designers. Many test methods developed for hardware logic testing are adapted to software logic testing. Because hardware testing automation is 10 to 15 years ahead of software testing automation. So hardware testing methods and its associated theory is a fertile ground for software testing methods. We can expect the both hardware and software designers meet at a middle ground where Boolean algebra will be a basic to their common language of disclosure.

Specification Systems and Languages The trouble with specifications is that they’re hard to express. Boolean Algebra (Sentential Calculus) is the most basic of all logic systems. Higher order logic systems are needed and used for formal specifications. These tools incorporate methods to simplify, transform, and check specifications, and the methods are to a large extent based on 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 data base. The data can be queried and interacted to provide solutions to problems in that domain. Other 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 processing is done by a program called Inference Engine.

Decision Tables A decision table is a table that consists of four areas called the 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.

An example of a Decision Table RULE 1RULE 2RULE 3RULE 4 CONDITION 1 CONDITION 2 CONDITION 3 CONDITION 4 YES NO YES I YES NO I YES ACTION 1 ACTION 2 ACTION 3 YES NO YES NO YES NO YES

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 conditions must be met, and “No” means that conditions must not be met, and “I” means that the conditions plays no part in the rule, or it is immaterial to the 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. Some of the rules are not specified by the decision table for which a default action to be taken are called Default Rules.

Decision Table Processors Decision tables can be automatically translated into code and as such are a higher order language. The decision table translator checks the source decision table for consistency and completeness and fills in any required default rules. Decision tables as a source language have the virtue of clarity, direct correspondence to specifications, and maintainability.

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. If a program’s logic is implemented as a decision table, decision table should also be used as a basis for test design. It is not always possible or desirable to implement the program as a decision table because the 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. The use of a decision table model to design tests is warranted when: The specification is given as a decision table or can be easily converted into one. The order in which the predicates are to be evaluated does not affect interpretation of the rules or the resulting action. Once a rule is satisfied and an action is selected, no other rule need be examined. If several actions can result from satisfying 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 doesnot depend on the condition. It doesn’t mean that the case is impossible. 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 Rule 2.1Rule 2.2Rule 4.1Rule 4.2Rule 4.3Rule 4.4 CONDITION1 CONDITION2 CONDITION3 CONDITION4 YES NO YES NO YES NO YES NO YES NO YES NO YES

The expansion of an Inconsistent Specification Rule 1Rule 2 Condition 1 Condition 2 Condition 3 Condition 4 Yes I Yes No Yes No I No Action 1 Action 2 Yes No yes Rule 1.1Rule 1.2Rule 2.1Rule 2.2 Yes No Yes No Yes No Yes No Yes No Yes No Yes No Yes No Yes No Yes

Test Case Design Test case design by decision tables begins with examining the specification’s consistency and completeness. This is done by expanding all immaterial cases and checking the expanded tables. Once the specification have been verified, the objective of the test case 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 Action 1 Action 3 Action 2 A B D D C A A1A1 B B1B1 D D1D1 C C1C1 D D1D1 R1 R3 R5 R6 R2 R4

Rule 1Rule 2Rule 3Rule 4Rule 5Rule 6 Condition A Condition B Condition C Condition D Yes I Yes No I Yes I No I Yes I No I No Yes No I No Action 1 Action 2 Action 3 Yes No Yes No Yes No Yes No Yes No Yes The decision table corresponding to the previous decision tree

Predicates&Relational Operators A predicate is implemented as a process whose outcome is a truth functional value. Predicates are based on relational operators, of which the arithmetic relational operators are most common. A sample of some other relational operators are: is a member of…….,is a subset of……..,is a substring of………, is above……, is below………..

Case statements and Multivalued Logic Predicates need not be restricted to binary truth values (TRUE/FALSE). There are multiway predicates, of which FORTRAN three-way IF is the most problematic and the case statement the most useful.

What goes Wrong with Predicates? Several things can go wrong with predicates, especially if the predicate has to interpreted in order to express it as a predicate over input values. The wrong relational operator is used. The predicate expression of a compound predicate is incorrect. The wrong operands are used The processing leading to the predicate is faulty.

Boolean Algebra Steps taken to get the predicate expression of a path: Label each decision with an uppercase letter that represents the truth value of the predicate. The YES/TRUE branch is labeled with a letter and the NO/FALSE branch with the same letter over scored. The truth value of a path is the product of the individual labels. If two or more paths merge at a node, the fact is expressed by use of a plus sign (+) which means “OR”.

The Rules of Boolean Algebra Boolean Algebra has three operators: x – meaning AND. Also called multiplication. A statement such s AB means “A and B both are true”. This symbol is usually left out as ordinary Algebra. + - meaning OR. “A+B” means either A is true or B is true or both. A 1 meaning NOT. Also negation or complementation. This is read as either not A or A bar.

Laws of Boolean Algebra A+A=A A 1 +A 1= A 1 A+1=1 A+0=A A+B=B+A A+A 1 =1 AA=A A 1 A 1= A 1 AX1=A AX0=0 AB=BA AA 1= 0 (A 1 ) 1 =A 0 1 =1 1 1 =0 (A+B) 1 =A 1 B 1 (AB) 1 =A 1 +B 1 A(B+C)=AB+AC (AB)C=A(BC) (A+B)+C=A+(B+C) A+A 1 B=A+B 1 A+AB=A

KV-Charts The Boolean algebraic expressions are used to determine which cases are interesting and which combination of predicate values should be used to reach which node. If you had deal with expressions in four or five or six variables, you could get bogged down in the algebra and make as many errors in the designing test cases as there are bug in the routine you’re tesing. The karnaugh – Veitch chart reduces boolean algebraic manipulations to graphical trivia.

One Variable Map 00 A 0 1 0The function is never true AThe function is true when A is true A1A1 The function is true when A is false The function is always true

Two Variable Map

Representation of Functions in the Map

Three variable Map

Three variable map-example

Four variable map-example

Five variable map-example

Example Use a Karnaugh map to minimize F(A,B,C,D)=AB’C’D’+A’B’C’D’+ABC’D+A’BCD+ABD+ B’CD’+A’B Some of the terms in the above sum of products form does not contain all the variables. F(A,B,C,D)=AB’C’D’+A’B’C’D’+ABC’D+A’BCD+AB D+B’CD’+A’B Multiply those terms with the missing variables in (X+X 1 ) form.

F(A,B,C,D)=AB’C’D’+A’B’C’D’+ABC’D+A’BCD+ABD+B’CD’+ A’B ABD=ABD(C+C’)=ABCD+ABC’D B’CD’=B’CD’(A+A’)=AB’CD’ +A’B’CD’ A’B= A’B(C+C’)(D+D’) =(A’BC+A’BC’)(D+D’) =A’BCD+A’BCD’+ A’BC’D+A’BC’D’ Finally, the function can be written as F(A,B,C,D)=AB’C’D’+A’B’C’D’+ABC’D+A’BCD+ ABCD+ABC’D+AB’CD’+A’B’CD’+A’BCD+A’BCD’+ A’BC’D+A’BC’D’=∑(8,0,13,7,15,13,10,2,7,6,5,4) =∑(0,2,4,5,6,7,8,10,13,15)

F(A,B,C,D)=∑(0,2,4,5,6,7,8,10,13,15)

AB CD F(A,B,C,D)=∑(0,2,4,5,6,7,8,10,13,15)=A 1 B+BD+B 1 D 1