Decision Tables
Image 1 shows the limited-entry decision table
The four areas in the limited-entry decision table are: condition stub, condition entry, action stub and action entry
Each column of the table is a rule that specifies the conditions under which the actions named iin the action stub will take place
The condition stub is a list of names of conditions
A more general decision table is shown in the image 2
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 irrelevant to that rule
The action stub names the actions the routine takes or initiate if the rule is satisfied
If the action entry is "YES", the action takes place, if "NO", the action does not take place
Decision Table Processors
Decision Tables as Basis for Test Case Design
Decision Tables and Structure
Decision Table Processors
Decision tables can be automatically translated into code as higher order language
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 have become a useful tool in the programmers kit, especially in business data processing
Decision Tables as Basis for Test Case Design
The specification can be given as decision table or it can be easily converted into decision table
The order in which the predicates 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
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
No other rule needs are examined if the rule is satisfied once and an action is selected
The order of the actions execution are ignored if the several action can result from satisfying a rule
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 irrelevant to that rule
The action stub names the actions the routine takes or initiate if the rule is satisfied
If the action entry is "YES", the action takes place, if "NO", the action does not take place
The table image 2 can be translates as follows:
Action 1 will take place if conditions 1 and 2 are met and if conditions 3 and 4 are not met (rule 1) or if conditions 1, 3, 4 are met (rule 2)
"condition" is another word for predicate
Decision table uses "condition" and "satisfied" or "met", let us use "predicate" and TRUE/FALSE
Now the above translation become:
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 be take place if predicate 1 is false and predicate 4 is true (rule 4)
In addition to the stated rules, we also need a Default rule that specifies the default action to be taken when all other rules fil. the default rules for table in Image 1 is shown in the image 3
Decision Table Processors
Decision Tables as Basis for Test Case Design
Decision Tables and Structure
Decision Table Processors
Decision tables can be automatically translated into code as higher order language
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 have become a useful tool in the programmers kit, especially in business data processing
Decision Tables as Basis for Test Case Design
The specification can be given as decision table or it can be easily converted into decision table
The order in which the predicates 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
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
No other rule needs are examined if the rule is satisfied once and an action is selected
The order of the actions execution are ignored if the several action can result from satisfying a rule
Decision Tables and Structure
A program's structure can be examined by using decision tables
Image 4 shows a program segment that consists of a decision tree
These decisions, in various combination can lead to actions 1, 2, or 3
Put YES or NO as appropriate if the decision appears on a path
Put in an I if the decision does not appear on the path. Rule 1 does not contain decision C and therefore, its entries are: YES, YES, I and YES
Table 1 shows the corresponding decision table
Put in an I if the decision does not appear on the path. Rule 1 does not contain decision C and therefore, its entries are: YES, YES, I and YES
Table 1 shows the corresponding decision table
As an example, expanding the immaterial cases results in tables shown below:
similarly, if we expand the immaterial cases for the table 1, it results in table 2
sixteen cases are represented in table 1, and no case appears twice
Consequently, the flow graph appears to be complete and consistent
As a first check, before you look for all sixteen combination, count the number of Y's and N's in each rou. They should be equal. We can find the bug this way
Consequently, the flow graph appears to be complete and consistent
As a first check, before you look for all sixteen combination, count the number of Y's and N's in each rou. They should be equal. We can find the bug this way
another Example: A Troublesome program
Consider the following specification whose putative flow graph is shown in image 5
If condition A is met, do process A1 no matter what other actions are taken or what other conditions are met
If Condition B is met, do process A2 no matter what other actions are taken or what other conditions are met
If condition C is met, do process A3 no matter what other actions are taken or what or what other condition are met
Consider the following specification whose putative flow graph is shown in image 5
If condition A is met, do process A1 no matter what other actions are taken or what other conditions are met
If Condition B is met, do process A2 no matter what other actions are taken or what other conditions are met
If condition C is met, do process A3 no matter what other actions are taken or what or what other condition are met
If none of the conditions are met, then do processes A1, A2 and A3
when more than one process is done, process A1 must be done first, then A2 and then A3. The only permissible cases are : (A1), (A2), (A3), (A1,A3) and (A1,A2,A3)
Image 5 shows a sample program with a bug
The programmer forces all three processes to be executed for ĀB̄C̄ cases but forgot the B and C predicates would be done again, thereby by passing processes A2 and A3
Image shows the conversion of this flow graph into a decision table after expansion
when more than one process is done, process A1 must be done first, then A2 and then A3. The only permissible cases are : (A1), (A2), (A3), (A1,A3) and (A1,A2,A3)
Image 5 shows a sample program with a bug
The programmer forces all three processes to be executed for ĀB̄C̄ cases but forgot the B and C predicates would be done again, thereby by passing processes A2 and A3
Image shows the conversion of this flow graph into a decision table after expansion
0 comments:
Post a Comment