Software Quality Engineering

Dr. Muazzam Maqsood

Department of Computer Science

COMSATS University Islamabad, Attock Campus

muazzam.maqsood@cuiatk.edu.pk
 Presentation Outline
- White Box Testing

- Pros and Cons of White Box Testing

- Unit Testing

- Code Coverage and its Types

- Control Flow Graph

- Cyclomatic Complexity

- Graph matrices

- Basis Path Testing

- Condition Testing

- Loop Testing

- Data Flow Testing

- Data Flow Coverage Criteria

- Terms used in data flow testing

- Data Flow Coverage Concept

- DC Path

All Rights Reserved

 White Box Testing

▪ White box testing (a.k.a. clear box testing, glass box testing, transparent
box testing, translucent box testing or structural testing)

▪ The tests written based on the white box testing strategy incorporate
coverage of the code written, branches, paths, statements and internal
logic of the code etc.

▪ In order to implement white box testing, the tester has to deal with the
code and hence is needed to possess knowledge of coding and logic i.e.
internal working of the code.

▪ In the language of V&V, White box testing is often used for verification
(Are we building the software right?)
 White Box Testing
▪ Using White box testing methods, the software engineer can
derive test cases that:

❑ Guarantee that all independent paths within a module have

been exercised at least once.

❑ Exercise all logical conditions on their true and false sides.

❑ Execute all loops at their boundaries and within their

operational bounds.

❑ Exercise internal data structures to ensure their validity.

 Pros and Cons of White Box Testing

▪ As the knowledge of ▪ As knowledge of code and

internal coding structure is internal structure is a
prerequisite, it becomes prerequisite, a skilled tester
very easy to find out which is needed to carry out this
type of input/data can type of testing, which
help in testing the increases the cost.
application effectively.

▪ The other advantage of

white box testing is that it
helps in optimizing the
code
 Unit Testing

▪ Unit testing focuses on

verification effort on the
smallest unit of software
design (the software
component or module).

▪ Using the component level

design description as a
guide, important control
paths are tested to uncover
errors within the boundary of
the module.

▪ The unit test is white box

oriented and the step can be
conducted in parallel for
multiple components.
 Unit Test Considerations

▪ The module interface is tested to ensure that information properly flows

into and out of the program unit under test.

▪ The local data structure is examined to ensure that data stored

temporarily maintains its integrity during all steps in an algorithm‟s
execution.

▪ Boundary conditions are tested to ensure that the module operates

properly at boundaries established to limit or restrict processing.

▪ All independent paths through the control structure are exercised to

ensure that all statements in a module have been executed at least once.

▪ Finally all error handling paths are tested.

▪ Selective testing of execution paths is an essential task during the unit

test. Test Cases should be designed to uncover errors due to erroneous
computations, incorrect comparisons, or improper control flow.
 White-Box Software Testing Methods

▪ White Box Testing tends to involve the Coverage of the

Specification in the Code.

▪ Code Coverage is defined by the following seven types.

1. Statement Coverage

2. Segment Coverage

3. Branch Coverage

4. Compound Condition Coverage

5. Basis Path Testing

6. Data Flow Testing

7. Loop Testing
 Code Coverage

▪Code coverage is a measure used in software testing. It describes the

degree to which the source code of a program has been tested.

▪It is a form of testing that looks at the code directly and as such comes
under the heading of white box testing.

All Rights Reserved

 Code Coverage Types

▪ Statement Coverage:

In this type of testing the code is executed in such a manner that

every statement of the application is executed at least once. It helps in
assuring that all the statements execute without any side effect.

▪ Segment coverage:

Each segment of code executed at least once.

▪ Branch Coverage:

A branch is the outcome of a decision, so branch coverage simply

measures which decision outcomes have been tested. Each branch in the
code is taken in each possible direction at least once.

▪ Compound Condition Coverage:

When there are multiple conditions, you must test not only each
direction but also each possible combinations of conditions, which is usually
done by using a "Truth Table".

All Rights Reserved

 Code Coverage Types

▪ Basis Path Testing:

Each independent path through the code is taken in a pre-
determined order.

▪ Data Flow Testing (DFT):

In this approach you track the specific variables through each

possible calculation, thus defining the set of intermediate paths through the
code.

▪ Loop Testing:
This strategy relate to testing single loops, concatenated loops,
and nested loops. Loops are fairly simple to test unless dependencies exist
among the loop or b/w a loop and the code it contains.

All Rights Reserved

 Program Flow Graph (Control Flow Diagram)
▪A simple notation for the representation of control flow is called a flow graph
(or program graph).

▪In flow graph each circle (a flow graph node) represents one or more
procedural statements.

▪A sequence of process boxes and a decision diamond can map into a single
node.

▪The arrows on the flow graph called edges or links represents flow of
control.

▪An edge must terminate at a node even if the node does not represent any
procedural statements.

▪Areas bounded by edges and nodes are called regions.

▪A compound condition occurs when one or more Boolean operators is

present in a conditional statement

▪Each node that contains a condition is called a predicate node & is

characterized by two or more edges emanating from it.

All Rights Reserved

 Program Flow Graph Primitives

Decision
Point
▪A decision is a program point at
which the control can diverge.

❑ (e.g., if and case statements).

▪A junction is a program point where

the control flow can merge.

❑ (e.g., end if, end loop, goto label)

▪A process block is a sequence of

program statements uninterrupted by
either decisions or junctions. (i.e.,
straight-line code).

Junction
Point

All Rights Reserved

 Paths

▪A path through a program is a sequence

of statements that starts at a junction, or
decision and ends at another (possible the
same), junction, or decision.

▪A path may go through several

junctions, processes, or decisions, one or
more times.

▪Paths consist of segments.

▪The length of a path is the number of

links in a path.

All Rights Reserved

 Program Flow Graph (Control Flow Diagram)

C
If C Then S1 else S2;
Sequential statement block

S1 S2

C Case C of
C
L1: S1; If C Then S1;
S1 Sn L2: S2;
…
Kn: Sn; S1
end;

All Rights Reserved

Program Flow Graph (Control Flow Diagram)

C I =1
While C do S; For loop:

F for I = 1 to n do S;
T S
S
yes
I <=n
no

S1 Do loop:

do S1 until C;
F
C
T

All Rights Reserved

Program Flow Graph (Control Flow Diagram)

All Rights Reserved

 Flow Graph

▪ PDL is presented with nodes identified

i=1; 2
1 total.input = total.valid = 0;
Sum=0;
Do while value[i]<>-999 and total.input <= 100 3
4 increment total.input by 1;
IF value[i] >= minimum and value[i] <=maximum 6
5 THEN increment total.valid by 1;
7 sum = sum + value[I];

8 ENDIF
increment i by 1;
9 Enddo
IF value[i] >0 10

11 THEN average = sum / total.valid;

ELSE average = -999;
12

ENDIF 13
 Flow Graph
1

10
3

12 11 4

13
5

7
8

9
 Cyclomatic Complexity

▪Cyclomatic complexity is a software metric that provides a quantitative

measure of the global complexity of a program.

▪When this metric is used in the context of the basis path testing, the value
computed for cyclomatic complexity defines the number of independent paths
in the basis set of a program.

▪ Three ways to compute cyclomatic complexity:

❑The number of regions of the flow graph correspond to the

cyclomatic complexity.

❑ Cyclomatic complexity, V(G), for a flow graph G is defined as

V(G) = E - N + 2
where E is the number of flow graph edges and N is the number of flow
graph nodes.

❑ Cyclomatic complexity, V(G) = P + 1

where P is the number of predicate nodes contained in the flow graph G.

All Rights Reserved

 An Example

1 node
No. of regions = 4
(considering the universal region)
edge 2 3
No. of edges = 9
4 No. of nodes = 7

No. of predicate nodes = 3

5
region V(G) = 3 + 1 = 4
6 V(G) = 9 - 7 + 2 = 4

All Rights Reserved

 Graph Matrices

▪ Graph Matrix is a data structure that assists in basis path testing.

▪ A graph matrix is a square matrix whose size is equal to the number of

nodes on the flow graph. Each row and column corresponds to an
identified node, and matrix entries corresponds to connections between
nodes.

▪ Referring to the figure each node on the flow graph is identified by

numbers, while each edge is identified by the letters. A letter entry is
made in the matrix to correspond to a connection between two nodes. For
example node 3 is connected to node 4 by edge b.

1
a

e b d
5
4
f
c
g
2 FLOW GRAPH

All Rights Reserved

 Graph Matrices
▪ Graph Matrix is nothing more than a tabular representation of a flow
graph. However by adding a link weight to each matrix entry, the graph
matrix can become a powerful tool for evaluating program control
structure during testing.

▪ The link weight 1(a connection exists) and 0(a connection does not
exists).

NODE 1 2 3 4 5

1 a
2
3 d b
4 c f
5 g e

Graph Matrix

All Rights Reserved

 Graph Matrices
▪ Graph Matrix is redrawn here each letter has been replaced with a 1,
indicating that a connection exists (zeros has been excluded for clarity).

▪ Representing in this form, the graph matrix is called a connection matrix.

▪ Each row with two or more entries represents a predicate node.

NODE 1 2 3 4 5

1 1
2
3 1 1
4 1 1
5 1 1

Connection Matrix

All Rights Reserved

 Basis Path Testing
Basic path testing (a white-box testing technique):

- First proposed by Tom McCabe.

- Used as a guide for defining a basis set of execution path.
- Guarantee to execute every statement in the program at least one time.

Step 1 : Using the design or code as a foundation, draw a corresponding

flow graph.
Step 2: Determine the cyclomatic complexity of the resultant flow graph.

Step 3: Determine a basis set of linearly independent paths.

For example,
path 1: 1-2-4-5-6-7
path 2: 1-2-4-7
path 3: 1-2-3-2-4-5-6-7
path 4: 1-2-4-5-6-5-6-7

Step 4: Prepare test cases that will force execution of each path in the
basis set.

Step 5: Run the test cases and check their results

All Rights Reserved

 Condition Testing
▪ Condition testing is a test case design method that exercises the logical
conditions contained in a program module.

▪ Simple condition: Boolean variable or relational expression, possibly

proceeded by a NOT operator.

▪ A relational expression takes the form, E1 < relational operator> E2

Where E1 and E2 are arithmetic expressions and < relational

operator> is one of the following: {<, , >, , =, } . For example,
(x+y) > (s/t), where x, y, s and t are variables.

▪ A compound condition is composed of two or more simple conditions,

Boolean operators and parenthesis.

▪ A condition without relational expression is referred to as a Boolean

expression

▪ Types of error in a condition includes the following:

❑ Boolean operator error

❑ Boolean variable error
❑ Relational operator error
❑ Arithmetic expression error

All Rights Reserved

 Condition Testing Strategies

▪ Branch testing is the simplest condition testing strategy.

▪ For a compound condition Com, the true and false branches of Com and
every simple condition in Com need to be executed at least once.

A B C A&B or C

TRUE TRUE TRUE TRUE

TRUE TRUE FALSE TRUE
TRUE FALSE TRUE TRUE
TRUE FALSE FALSE FALSE
FALSE TRUE TRUE TRUE
FALSE TRUE FALSE FALSE
FALSE FALSE TRUE TRUE
FALSE FALSE FALSE FALSE

All Rights Reserved

 Domain Testing
▪ Domain testing is an important white box testing method. The goal is to
check values taken by a variable, a condition, or an index, and to prove
whether they are outside the valid range or not. It also contains checking
that the program accepts only valid input , because it is unlikely to get
reasonable results if idiocy has been entered. This part can be called
``garbage in -- garbage out'' testing.

▪ Domain testing can include the following checks

❑ Are all indices used to access an array inside the array's dimensions?

❑ Are all those indices integers?

All Rights Reserved

 Loop Testing
▪ Loop testing is a white box testing technique that focuses on the
validity of loop constructs.

1. Simple loops

2. Concatenated loops

3. Nested loops

All Rights Reserved

 Simple Loops

▪ The following set of tests can be applied

to simple loops, where n is the maximum
number of allowable passes through the
loop.

1. Skip the loop entirely

2. Only one pass through the loop

3. two passes through the loop

4. m passes through the loop where

m<n

5. n-1,n,n+1 passes through the loop.

All Rights Reserved

 Nested Loops

▪ If we were to extend the test approach for simple

loops to nested loops the number of possible
tests would grow as the level of nesting
increases. Beizer suggest an approach that will
help to reduce the number of tests:

1. Start at the innermost loop. Set all other

loops to min. values

2. Conduct simple loop tests for the innermost

loop while holding the outer loops at their
min. iteration parameter values.

3. Work outward conducting tests for the next

loop, but keeping all other outer loops at
min. values and other nested loops to
typical values.

4. Continue until all loops have been tested.

All Rights Reserved

 Concatenated Loops

▪Concatenated loops can be tested

using the approach defined for simple
loops, if each of the loops are
independent of the other. However if
two loops are concatenated and the
loop counter for loop 1 is used as a
initial value for loop 2, then the loops
are not independent.

▪When the loops are not independent,

the approach applied to nested loops is
recommended.

All Rights Reserved

 Data Flow Testing
▪ Data flow testing is a structural test technique which aims to
execute sub-paths from points where each variable in a
component is defined to points where it is used.

▪ These sub-paths are known as definition-use pairs (du-pairs).

The different data flow coverage criteria require different du-
pairs and sub-paths to be executed.

▪ Data-flow testing is a white box testing technique that can be

used to detect improper use of data values due to coding errors.
Errors are inadvertently introduced in a program by
programmers. For instance, a software programmer might use a
variable without defining it.

▪ Additionally, he/she may define a variable, but not initialize it

and then use that variable in a predicate.

❑ e.g. int x ; if (x ==100) {};

All Rights Reserved

 Data Flow Testing
▪ There are four ways data can be used:

❑ defined,
❑ used in a predicate,
❑ used in a calculation, and
❑ killed.

▪ Data-flow testing monitors the lifecycle of a piece of data and

looks out for inappropriate usage of data during definition, use
in predicates, computations and termination (killing).

▪ It identifies potential bugs by examining the patterns in which

that piece of data is used.

▪ For example, A pattern which indicates usage of data in a

calculation after it has been killed is certainly a bug which needs
to be addressed.

All Rights Reserved

 Data Flow Testing

▪ The notation for representing the patterns is :

❑ d – defined, created, initialized

❑ k – killed, terminated, undefined
❑ u – used
✓ c – used in a computation
✓ p – used in a predicate
❑ ~x - indicates all prior actions are not of interest to x
❑ x~ - indicates all post actions are not of interest to x

All Rights Reserved

Data Flow Testing

All Rights Reserved

 Terms used in data flow testing
▪ DU pair: a pair of definition and use for some variable, such that
at least one DU path exists from the definition to the use
❑ x = ... is a definition of x
❑ = ... x ... is a use of x

▪ DU path: a DU path for a variable is a path from the defining

node to the usage node, thus the "flow of data". DU paths are
very good at identifying problems because the error usually
occurs between the definition and usage.
▪ All-du-path (All-Definition Use-Path) coverage testing involves :
❑ Identifying all du pairs in the program.
❑ Create a path for each du pair.
❑ Produce test data for testing the path.

All Rights Reserved

 Data Flow Coverage criteria

▪ A tool “della pasta” (Delaware Parallel Software Testing Aid) can be

used for automatic generation of all-du-paths

All Rights Reserved

 Data Flow Coverage Concept
▪ Value of x at 6 could be computed at 1 or at 4

▪ Bad computation at 1 or 4 could be revealed only if they are used at 6

▪ (1,6) and (4,6) are def-use (DU) pairs

❑ defs at 1,4
❑ use at 6

All Rights Reserved

 Definition Clear Path

▪ 1,2,3,5,6 is a definition-
clear path from 1 to 6

❑ x is not re-assigned
between 1 and 6

▪ 1,2,4,5,6 is not a
definition-clear path from
1 to 6

❑ the value of x is “killed”

(reassigned) at node 4

All Rights Reserved