Topics Covered:

 Functional Testing - Boundary value analysis, Robustness Testing, Worst case Testing

 Equivalence class testing

 Cause effect graphing technique

 Decision Table based testing

 Path testing

 DD path graphs

 Cyclomatic complexity

 Structural testing – Control flow testing, Mutation Testing, Data flow testing
Functional Testing/Black box Testing
 Test cases are designed on the basis of functionality and the internal structure of

the program is completely ignored. The software is treated as a black box and
therefore, it is also known as black box testing.
 In functional testing techniques, execution of a program is essential and hence

these testing techniques come under the category of ‘validation’.

 Here, both valid and invalid inputs are chosen to see the observed behaviour of the

program.
Types - Boundary Value Analysis, Robustness Testing, Worst case Testing
Boundary Value Analysis
 Here, we design test cases with input values that are on or close to boundary values. Such test
cases have a higher probability of detecting a fault in the software. All input values may have
one of the following:
(i) Minimum value
(ii) Just above minimum value
(iii) Maximum value
(iv) Just below maximum value
(v) Nominal (Average) value
 These five values give reasonable confidence about the correctness of the program. There is
no need to select all inputs and execute the program one by one for all.
 For a program of ‘n’ variables, boundary value analysis yields 4n + 1 test cases.
 Example: Consider a problem to calculate square of an integer x (1-100):
Robustness Testing
 We want to go beyond the legitimate domain of input values. The total test cases in
robustness testing are 6n + 1, where ‘n’ is the number of input values. All input values may
have one of the following values:
(i) Minimum value
(ii) Just above minimum value
(iii) Just below minimum value
(iv) Just above maximum value
(v) Just below maximum value
(vi) Maximum value
(vii) Nominal (Average) value

 Example: Consider a program ‘Addition’ with two input values x and y and it gives the addition
of x and y as an output. The range of both input values are given as:
100 <= x <= 300
200 <= y <= 400
Robustness testing
Worst-case testing
 This is a special form of boundary value analysis where we don’t consider the ‘single fault’
assumption theory of reliability. Now, failures are also due to occurrence of more than one
fault simultaneously.
 The number of test cases are 5n, where ‘n’ is the number of input values.
 This is a more comprehensive technique and boundary value test cases are proper sub-sets of
worst case test cases.
 This requires more effort and is recommended in situations where failure of the program is
extremely critical and costly.

 All input values may have one of the following:

(i) Minimum value

(ii) Just above minimum value
(iii) Just below maximum value
(iv) Maximum value
(v) Nominal (Average) value
Equivalence class testing
 Here, we divide input domain into various categories with some relationship. Each category is
called an equivalence class. If categories are well selected, we may assume that if one
representative test case works correctly, others may also give the same results.
 The entire input domain can be divided into at least two equivalence classes: one containing
all valid inputs and the other containing all invalid inputs. Each equivalence class can further
be sub-divided into equivalence classes on which the program is required to behave
differently.
 Example: Consider a program, ‘Square’, which takes ‘x’ as an input (range 1-100) and prints
the square of ‘x’. Equivalence classes based on input domain are:
(i) I1 = { 1 <= x <= 100 }
(ii) I2 = { x < 1 }
(iii) I3 = { x > 100 }
Equivalence class testing
 Equivalence classes based on output domain are:
O1 = Valid input ( x ranges from 1 to 100)
O2 = invalid input ( x is less than 1)
O3 = invalid input ( x is greater than 100)

 Test cases based on output domain

 Test case Input (x) Expected Output

O1 12 144
O2 -6 invalid input
O3 179 invalid input
Cause-Effect Graphing
 Such techniques do not allow combinations of inputs and consider all inputs as independent
inputs.
 Two new terms are used here and these are causes and effects. Causes which are inputs to the
program and effects which are outputs of the program can easily be identified after reading
the SRS document.
 A list is prepared for all causes and effects. The relationship amongst causes and effects are
established using cause-effect graph.
 Basic notations used in cause-effect graph:
Cause-Effect Graphing
 Each node represents either true or false state and may be assigned 1 and 0 value respectively.
The purpose of four functions is given as:

(a) Identity: This function states that if c1 is 1, then e1 is 1; else e1 is 0.

(b) NOT: This function states that if c1 is 1, then e1 is 0; else e1 is 1.
(c) AND: This function states that if both c1 and c2 are 1, then e1 is 1; else e1 is 0.
(d) OR: This function states that if either c1 or c2 is 1, then e1 is 1; else e1 is 0.

 The cause-effect graph represents the relationships amongst the causes and effects and the
various conditions/combinations among them.
 Each column of the table represents a test case which are converted into the limited entry
decision table. Each column of the decision table represents a rule and gives us a test case.
 We may reduce the number of columns with the proper selection of various conditions and
expected actions.
Decision Table based testing
 Decision tables are useful for describing situations in which a no. of combinations of actions
are taken under varying sets of conditions. There are four portions of decision table -
Condition stub, Action stub, Condition entries, Action entries. When the conditions c1, c2, c3
are all true, actions a1 and a2 occur.
 When conditions c1, c2 are true and c3 is false, actions a1 and a3 occur. The decision tables in
which all entries are binary are called limited entry decision tables.
 And if conditions are allowed to have several values, resulting tables are called extended entry
decision tables.
 To identify test cases with decision tables, we interpret conditions as inputs and actions as
outputs. Because the decisions table can mechanically be forced to be completed, we have a
comprehensive set of test cases.
Path Testing
 A path in a graph is a sequence of adjacent nodes where nodes in sequence share a common
edge or sequence of adjacent pair of edges where edges in sequence share a common node.
 An independent path in a graph is a path that has at least one new node or edge in its
sequence from the initial node to its final node.
 If there is no repetition of an edge in a path from the initial node to the final node, then the
path is called a simple path.
 The number of edges in a path is called the length of the path.
 When the initial and final nodes of a path are the same and if length 0, the path is called a
cycle.

Program Graph / Flow Graph

 Program graph is a graphical representation of the source code of a program.
 A program graph is a directed graph in which nodes are either statements or fragments of a
statement and edges represent flow of control.
 Every program graph has one source node and one destination node.
 The basic constructs of the program graph are:
Program Graph/ Flow Graph Notations
DD Path Graphs
 The Decision to Decision (DD) path graph is an extension of a program graph. In DD path
graph, such nodes which are in a sequence are combined into a block and are represented by
a single node. This process may reduce the size of the program graph and convert it into a
more meaningful DD path graph.
Cyclomatic Complexity

It is the number of independent paths

through a program and is a popular measure
to know the complexity of any program.

(i) V(G) = e – n + 2P , where

V(G) = Cyclomatic complexity
G : program graph,
n : no. of nodes,
e : no. of edges,
P : no. of connected components

(ii) V(G) = no. of regions of program graph.

(iii) V(G) = π + 1 , where

π = no. of predicate nodes contained in the
program graph (G).
Properties of Cyclomatic Complexity
1. V(G) >=1
2. V(G) is the maximum number of independent paths in program graph G.
3. Addition or deletion of functional statements to program graph G does not affect V(G).
4. G has only one path if V(G)=1
5. V(G) depends only on the decision structure of G.

Example:
Structural Testing/ White Box Testing
 It is more technical than functional testing. It attempts to design test cases from the source code
and not from the specifications.
 It is also known as white box testing techniques due to consideration of internal structure and
other implementation details of the program.

 Types - Control Flow testing, Path testing, Mutation testing, Data Flow testing.

Control Flow testing

 We identify paths of the program and write test cases to execute those paths.

 We define ‘coverage’ as a ‘percentage of source code that has been tested with respect to the
total source code available for testing’.

 Condition coverage is better than branch coverage because we want to test every condition at
least once.

 In this coverage criteria, we want to test every path of the program. It may not be possible to
achieve this. If it is unachievable, at least all independent paths should be executed.
Mutation Testing
 It is a popular technique to assess the effectiveness of a test suite. The process of changing a

program is known as mutation.

 We prepare a copy of the program under test and make a change in a statement of the program.

This changed version of the program is known as a mutant of the original program.
 The behaviour of the mutant may be different from the original program due to the introduction

of a change. The mutants generated by making only one change are known as first order mutants
and so on.

Mutation Score
When we execute a mutant using a test suite, we may have any of the following outcomes:
(i) The results of the program are affected by the change and any test case of the test suite
detects it. If this happens, then the mutant is called a killed mutant.
(ii) The results of the program are not affected by the change and any test case of the test
suite does not detect the mutation. The mutant is called a live mutant.
Mutation Testing
The mutation score associated with a test suite and its mutants is calculated as:

Mutation Score = Number of mutants killed / Total number of mutants

 The total number of mutants is equal to the number of killed mutants plus the number of

live mutants.
 The mutation score measures how sensitive the program is to the changes and how accurate

the test suite is.

 A mutation score is always between 0 and 1.

 A higher value of mutation score indicates the effectiveness of the test suite.

 The live mutants are important for us and should be analyzed thoroughly.
Data Flow Testing
It is based on variables, their usage and their definitions (assignment) in the program.
(i) Statements where variables receive values (definition).
(ii) Statements where these values are used (referenced).

Definitions
A program is first converted into a program graph. There may be many paths in a program graph.

Defining node
A node of a program graph is a defining node for a variable , if and only if, the value of the
variable is defined in the statement corresponding to that node.

Usage node
A node of a program graph is a usage node for a variable , if and only if, the value of the variable
is used in the statement corresponding to that node.

Definition use Path - du path is a path from defining node to usage node of a variable, v.

Definition clear Path - If in du path, variable, v is not redefined, it is called dc path.

 Data Flow Testing
A dc-path for a variable will not have any definition of variable between initial node and final node. The
du-paths that are not definition clear paths are potential troublesome paths. They should be identified
and tested on topmost priority.

Identification of du and dc Paths

(i) Draw the program graph of the program.

(ii) Find all variables of program and prepare a table for define / use status of all variables.

(iii) Generate all du-paths from define/use variable table of step (ii).

(iv) Identify those du-paths which are not dc-paths or where variable is redefined.

Testing Strategies Using du-Paths

i) Test all du-paths
ii) Test all uses
iii) Test all definitions

Generation of Test Cases - After finding paths, test cases are generated by giving values to the input
parameter. We get different test suites for each variable.
Thank You!