TEST CASE DESIGN PART THREE

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