Control Structure testing.
In programs, conditions are very important and testing such conditions is more complex than other statements like assignment and declarative statements. Basic path testing is one example of control structure testing. There are many ways in which control structure can be tested.
Conditions Testing
Condition testing aims to exercise all logical conditions in a program module. Logical conditions may be complex or simple. Logical conditions may be nested with many relational operations.
Can define:
Relational expression: (E1 op E2), where E1 and E2 are arithmetic expressions. For example, (x+y) – (s/t), where x, y, s and t are variables.
Simple condition: Boolean variable or relational expression, possibly proceeded by a NOT operator.
Compound condition: composed of two or more simple conditions, Boolean operators and parentheses along with relational operators.
Boolean expression: Condition without relational expressions.
Normally errors in expressions can be due to due to one or all or the following:
Boolean operator error
Boolean variable error
Boolean parenthesis error
Relational operator error
Arithmetic expression error
Mismatch of types
Condition testing methods focus on testing each condition in the program of any type of conditions. There are many strategies to identify errors.
Some of the strategies proposed include:
· Branch testing: Every branch is executed at least once.
· Domain Testing: Uses three or four tests for every relational operator depending on the complexity of the statement.
· Branch and relational operator testing: Uses condition constraints. Based on the complexity of the relational operators, many branches will be executed.
Example 1: C1 = B1 & B2
where B1, B2 are boolean conditions..
Condition constraint of form (D1,D2) where D1 and D2 can be true (t) or false(f).
The branch and relational operator test requires the constraint set {(t,t),(f,t),(t,f)} to be covered by the execution of C1.
Coverage of the constraint set guarantees detection of relational operator errors.
Data Flow Testing
First, a proper data flow diagram like control flow(see basis path flow) is drawn. Then selects test paths according to the location of definitions and use of variables. Any variables that have been defined in any program behaves in the following way:
D: define the variable, normally defined in declarative section,
U: use the variables which is defined earlier, in the program.
K: kill the variable, which is another state of the variable at any time of the execution of the program.
Any variable that is part of the program will undergo any of the above state. However, the sequence of states is important. We can avoid following anomalies during the program execution:
· DU: Normal,
· UK, UU: Normal,
· DD: Suspicious
· DK: Probable bug
· KD: Normal
· KK: Probable bug
· KU: bug
· UD: Normal
For example,
DU: Normal means a variable is defined first and then used in the program which is normal behavior of the data flow in the program.
DK: Probable bug means a variable is defined and then killed before using in the program. This may be bug as why the variable is defined and killed with out using in the program.
RELATED POST
INTEGRATION TESTING PART ONE
INTEGRATION TESTING PART TWO
INTEGRATION TESTING PART THREE
INTEGRATION TESTING PART FOUR
INTEGRATION TESTING PART FIVE
INTEGRATION TEST STANDARDS
INTEGRATION TEST STANDARDS PART TWO
QUALITY TESTING
QUALITY ASSURANCE
QUALITY ASSURANCE PART TWO
QUALITY ASSURANCE SQA
QUALITY OF DESIGN OF TEST CASE
QUALITY MANAGEMENT IN SOFTWARE TESTING
TOOLS FOR QUALITY MANAGEMENT
STATICAL QUALITY ASSURANCE
ISO APPROACH TO QUALITY TESTING
No comments:
Post a Comment