Software Testing Introduction (Part 2)

Functional Testing
• Functional testing techniques attempt to design those
test cases which have a higher probability of making a
software fail.
• These techniques also attempt to test every possible
functionality of the software.
• Test cases are designed on the basis of functionality
and the internal structure of the program is
completely ignored.
• Observed output(s) is (are) compared with expected
output(s) for selected input(s) with preconditions, if
any.
• The software is treated as a black box and therefore,
it is also known as black box testing as shown in
Figure 2.1

Every dot in the input domain represents a set of inputs and
every dot in the output domain represents a set of outputs.
•Every set of input(s) will have a corresponding set of
output(s).
The test cases are designed on the basis of user requirements
without considering the internal structure of the program.
This black box knowledge is sufficient to design a good
number of test cases.
Many activities are performed in real life with only black box
knowledge like

• driving a car, using a cell phone, operating a
computer, etc.
• 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 behavior of the program.
• These techniques can be used at all levels of
software testing like unit, integration, system
and acceptance testing.
• They also help the tester to design efficient and
effective test cases to find faults in the software.

• Functional testing include:
1. BOUNDARY VALUE ANALYSIS
2. EQUIVALENCE CLASS TESTING
3. DECISION TABLE BASED TESTING
4 .CAUSE-EFFECT GRAPHING TECHNIQUE

1. BOUNDARY VALUE ANALYSIS
• This is a simple but popular functional testing
technique.
• Here, we concentrate on input values and design test
cases with input values that are on or close to
boundary values.
• Experience has shown that such test cases have a
higher probability of detecting a fault in the software.
• Suppose there is a program ‘Square’ which takes ‘x’ as
an input and prints the square of ‘x’ as output.
• The range of ‘x’ is from 1 to 100.
• One possibility is to give all values from 1 to 100 one
by one to the program and see the observed behavior.
• We have to execute this program 100 times to check
every input value.
• In boundary value analysis, we select values on or
close to boundaries and all input values may have one
of the following

• Minimum value
• Just above minimum value
• Maximum value
• Just below maximum value
• Nominal (Average) value

• These five values (1, 2, 50, 99 and 100) are
selected on the basis of boundary value analysis
and give reasonable confidence about the
correctness of the program.
• There is no need to select all 100 inputs and
execute the program one by one for all 100 inputs.
• The number of inputs selected by this technique is
4n + 1 where ‘n’ is the number of inputs.
• One nominal value is selected which may
represent all values which are neither close to
boundary nor on the boundary. Test cases for
‘Square’ program are given in Table 2.1.

Software Testing Introduction (Part 2)

The ‘x’ and ‘y’ inputs are required for the execution of the
program.
The input domain of this program ‘Addition’ is shown in Figure 2.4.
Any point within the inner rectangle is a legitimate input to the
program

• We also consider ‘single fault’ assumption theory
of reliability which says that failures are rarely the
result of the simultaneous occurrence of two (or
more) faults.
• Normally, one fault is responsible for one failure.
• With this theory in mind, we select one input
value on boundary (minimum), just above
boundary (minimum +), just below boundary
(maximum –), on boundary (maximum), nominal
(average) and other n-1 input values as nominal
values.
• The inputs are shown graphically in Figure 2.5 and
the test cases for ‘Addition’ program are given in
Table 2.2.

300 is nominal value for y
set 300 for y and extreme
values(boundary value) of
x(100,101,200,299,300)
Boundary
values
Boundary
values
Single fault means Only one
variable can have boundary
values and other variables
will have nominal values

• In Table 2.2, two test cases are common (3
and 8), hence one must be selected.
• This technique generates 9 test cases where
all inputs have valid values.
• Each dot of the Figure 2.5 represents a test
case and inner rectangle is the domain of
legitimate input values.
• Thus, for a program of ‘n’ variables, boundary
value analysis yields 4n + 1 test cases.
• Cases like (300,400) where values are on
boundary are not taken because of single fault
assumption.

• Example 2.3: Consider a program for
classification of a triangle.
• Its input is a triple of positive integers (say a, b, c)
and the input parameters are greater than zero
and less than or equal to 100.
• The triangle is classified according to the following
rules:
• Right angled triangle: c^2 = a^2 + b^2 or a^2 =
b^2 + c^2 or b^2 = c^2 + a^2
• Obtuse angled triangle: c^2 > a^2 + b^2 or a^2 >
b^2 + c^2 or b^2 > c^2 + a^2
• Acute angled triangle: c^2 < a^2 + b^2 and a^2 <
b^2 + c^2 and b^2 < c^2 + a^2
• Invalid Traingle: a=b+c or b=a+c or c=a+b

Boundary
values
Boundary
values
Boundary
values

• Example 2.4: Consider a program for
determining the day of the week.
• Its input is a triple of day, month and year
with the values in the range

• Example 2.1: Consider a program for the
determination of the largest amongst three
numbers.
• Its input is a triple of positive integers (say x,y
and z) and values are from interval [1, 300].
Design the boundary value test cases

• Generate test case using BVA for a program
having three inputs ranges [1-100]
1<=x<=100
1<=y<=100
1<=z<=100

Test Case X Y z
1 1 50 50
2 2 50 50
3 50 50 50
4 99 50 50
5 100 50 50
6 50 1 50
7 50 2 50
8 50 99 50
9 50 100 50
10 50 50 1
11 50 50 2
12 50 50 99
13 50 50 100

Total Number of Test Case
• 4n+1=4*3+1=13 where n is the number of
variables

2. Robustness Testing
• This is the extension of boundary value analysis.
• Here, we also select invalid values and see the
responses of the program.
• Invalid values are also important to check the
behavior of the program.
• Hence, two additional states are added i.e. just
below minimum value (minimum value –) and
just above maximum value (maximum value +).
• We want to go beyond the legitimate domain of
input values.
• This extended form of boundary value analysis is
known as robustness testing.

• The inputs are shown graphically in Figure 2.6
and the test cases for the program ‘Addition’
are given in Table 2.7.
• There are four additional test cases which are
outside the legitimate input domain.
• Thus, 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:

• Minimum value
• Just below minimum value
• Just above maximum value
• Maximum value

only one extrem value
can be used
Boundary
values
Boundary
values

3. 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.
• More than one variable will have extreme
value.
• The implication of this concept in boundary
value analysis is that all input values may have
one of the following

• Minimum value
• Maximum value

• The restriction of one input value at any of
the above mentioned values and other input
values must be at nominal is not valid in
worst-case testing.
• This will increase the number of test cases
from 4n + 1 test cases to 5^n test cases,
where ‘n’ is the number of input values.
• The inputs for ‘Addition’ program are shown
graphically in Figure 2.7.
• The program ‘Addition’ will have 5^2 = 25 test
cases and these test cases are given in Table
2.8.

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
[JORG07].
both extream value

4. Robust Worst-Case Testing
• In robustness testing, we add two more states i.e. just
below minimum value (minimum value–) and just
above maximum value (maximum value+).
• We also give invalid inputs and observe the behaviour
of the program.
• A program should be able to handle invalid input
values, otherwise it may fail and give unexpected
output values.
• There are seven states (minimum -, minimum,
minimum +, nominal, maximum –, maximum,
maximum +) and a total of 7^n test cases will be
generated.
• This will be the largest set of test cases and requires
the maximum effort to generate such test cases.

• The inputs for the program ‘Addition’ are
graphically shown in Figure 2.8.
• The program ‘Addition’ will have 7^2 = 49 test
cases and these test cases are shown in Table
2.9.

2. EQUIVALENCE CLASS TESTING
• As we have discussed earlier, a large number of
test cases are generated for any program.
• It is neither feasible nor desirable to execute all
such test cases.
• We want to select a few test cases and still wish to
achieve a reasonable level of coverage.
• Many test cases do not test any new thing and
they just execute the same lines of source code
again and again.
• We may divide input domain into various
categories with some relationship and expect
that every test case from a category exhibits the
same behaviour.

• If categories are well selected, we may assume
that if one representative test case works
correctly, others may also give the same
results.
• This assumption allows us to select exactly
one test case from each category and if there
are four categories, four test cases may be
selected.
• Each category is called an equivalence class
and this type of testing is known as
equivalence class testing.

Creation of Equivalence Classes
• 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.
• The input domain equivalence classes for the
program ‘Square’ which takes ‘x’ as an input
(range 1-100) and prints the square of ‘x’
(seen in Figure 2.2) are given as:

• (i) 1 = { 1 x 100 }(Valid input range from 1 to
100)
• (ii) 2 = { x < 1 } (Any invalid input where x is
less than 1)
• (iii) 3 = { x > 100 } (Any invalid input where x is
greater than 100)

• The equivalence classes of input domain may be
mutually exclusive (as shown in Figure 2.10 (a))
and they may have overlapping regions (as shown
in Figure 2.10 (b)).
• We may also partition output domain for the
design of equivalence classes.
• Every output will lead to an equivalence class.
Thus, for ‘Square’ program, the output domain
equivalence classes are given as: O1 = {square of
the input number ‘x’} O2 = {Invalid input)
• The test cases for output domain are shown in
Table 2.20.
• Some of input and output domain test cases may
be the same.

Types of equivalence class testing
• Following four types of equivalence class
testing are presented here
1) Weak Normal Equivalence Class Testing.
2) Strong Normal Equivalence Class Testing.
3) Weak Robust Equivalence Class Testing.
4) Strong Robust Equivalence Class Testing.

1. Weak Normal Equivalence Class
Testing
• The word ‘weak’ means ‘single fault
assumption’.
• This type of testing is accomplished by using
one variable from each equivalence class in a
test case.
• We would, thus, end up with the weak
equivalence class test cases as shown in the
following figure.

• Each dot in above graph indicates a test data.
• From each class we have one dot meaning
that there is one representative element of
each test case.
• In fact, we will have, always, the same
number of weak equivalence class test cases
as the classes in the partition.
• Number of test case is
• MAX (no of equivalence class of inputX, no of
equivalence class of inputY)
• MAX(3,4)=4

2. Strong Normal Equivalence Class
Testing
• This type of testing is based on the multiple
fault assumption theory.
• So, now we need test cases from each
element of the Cartesian product of the
equivalence classes, as shown in the following
figure.

• The Cartesian product guarantees that we
have a notion of “completeness” in following
two ways
a) We cover all equivalence classes.
b) We have one of each possible combination
of inputs.

3. Weak Robust Equivalence Class
Testing:
• The name for this form of testing is counter intuitive
and oxymoronic.
• The word’ weak’ means single fault assumption
theory and the word ‘Robust’ refers to invalid values.
• The test cases resulting from this strategy are shown in
the following figure.
• Each dot in above graph indicates a test data.
• From each class we have one dot meaning that there is
one representative element of each test case.
• In fact, we will have, always, the same number of
weak equivalence class test cases as the classes in the
partition.

Invalid Input
Valid Value
Below Min
and Above
Max
MAX(5,6)=6 test case

4) Strong Robust Equivalence Class
Testing:
• This form of equivalence class testing is
neither counter intuitive nor oxymoronic, but
is just redundant.
• As explained earlier also, ‘robust’ means
consideration of invalid values and the
‘strong’ means multiple fault assumption.
• We obtain the test cases from each element of
the Cartesian product of all the equivalence
classes as shown in the following figure.

below
min
Invalid Input
Valid Input
Above Max

• We find here that we have 18 robust (invalid)
test cases and 12 strong or valid inputs.
• Each one is represented with a dot.
• So, totally we have 30 test cases (represented
as 20 dots) using this technique.

3. DECISION TABLE BASED TESTING
• Decision tables are used in many engineering
disciplines to represent complex logical
relationships.
• An output may be dependent on many input
conditions and decision tables give a pictorial
view of various combinations of input
conditions.
• There are four portions of the decision table
and are shown in Table 2.30.
• The decision table provides a set of conditions
and their corresponding actions.

Parts of the Decision Table
• The four parts of the decision table are given
as: Condition Stubs:
• All the conditions are represented in this
upper left section of the decision table.
• These conditions are used to determine a
particular action or set of actions.
1. Action Stubs: All possible actions are listed in
this lower left portion of the decision table.
2. Condition Stubs: All the conditions are
represented in this upper left section of the
decision table. These conditions are used to
determine a particular action or set of actions.

3. Condition Entries:
In the condition entries portion of the decision
table, we have a number of columns and each
column represents a rule.
Values entered in this upper right portion of the
table are known as inputs.
3. Action Entries:
• Each entry in the action entries portion has some
associated action or set of actions in this lower
right portion of the table.
• These values are known as outputs and are
dependent upon the functionality of the program.

‘Do Not Care’ Conditions and Rule
Count
• We consider the program for the classification
of the triangle as explained in example 2.3.
• The decision table of the program is given in
Table 2.32, where inputs are depicted using
binary values

a^2<b^2+c^2
Each column is a
test case or rule
Impossible
conditions

Note
If sum of two sides is greater than third side
than only triangle is valid
so if the condition :
1. a<b+c is false than it is not a triangle
2. b<a+c is false than it is not a triangle
3. c<a+b is false than it is not a triangle

Conditions for right angle triangle
a=3 b=4 c=5
3<4+5=3<9 true
4<3+5=4<8 true
5<3+4=5<7 true
5^2=3^2+4^2 c^2=a^2+b^2
25=9+16=25=25 true

Conditions for acute angle triangle
a=4 b=5 c=6
4<5+6=4<11 true
5<4+6=5<10 true
6<4+5=6<9 true
4^2<5^2+6^2=16<25+36=16<61 true
5^2<4^2+6^2=25<16+36=25<52 true
6^2<4^2+5^2=36<16+25=36<41 true
Because All the three conditions are true so it is
acute angle triangle

Conditions for obtuse angle
triangle
a=4 b=3 c=2
4<3+2=4<5 true
3<2+4=3<6 true
2<4+3=2<7 true
4^2>3^2+2^2
16>9+4=16>13 true
if any One condition is true than it is a obtuse
angle triangle

• The ‘do not care’ conditions are represented by
the ‘-‘sign.
• A ‘do not care’ condition has no effect on the
output.
• If we refer to column 1 of the decision table,
where condition c1: a < b + c is false, then other
entries become ‘do not care’ entries.
• If c1 is false, the output will be ‘Invalid triangle’
irrespective of any state (true or false) of other
conditions like c2, c3, c4, c5 and c6.
• These conditions become do not care conditions
and are represented by ‘-‘sign.
• If we do not do so and represent all true and false
entries of every condition, the number of
columns in the decision table will unnecessarily
increase.

• This is nothing but a representation facility in the
decision table to reduce the number of columns and
avoid redundancy.
• Ideally, each column has one rule and that leads to a
test case.
• A column in the entry portion of the table is known as
a rule.
• In the Table 2.32, a term is used as ‘rule count’ and 32
is mentioned in column 1.
• The term ‘rule count’ is used with ‘do not care’ entries
in the decision table and has a value 1, if ‘do not care’
conditions are not there, but it doubles for every ‘do
not care’ entry.
• Hence each ‘do not care’ condition counts for two
rules. Rule count can be calculated as: Rule count =
2^number of do not care conditions

• Hence, the actual number of columns in any decision
table is the sum of the rule counts of every column
shown in the decision table.
• The triangle classification decision table has 11
columns as shown in Table 2.32.
• However the actual columns are a sum of rule counts
and are equal to 64.
• Hence, this way of representation has reduced the
number of columns from 64 to 11 without
compromising any information.
• If rule count value of the decision table does not
equal to the number of rules computed by the
program, then the decision table is incomplete and
needs revision.

• Example 2.1: Consider a program for the
determination of the largest amongst three
numbers.
• Its input is a triple of positive integers (say x,y
and z) and values are from interval [1, 300].
Design the boundary value test cases.

• Example 2.13: Consider the problem for
determining of the largest amongst three
numbers as given in example 2.1. Identify the
test cases using the decision table based
testing.

4 .CAUSE-EFFECT GRAPHING
TECHNIQUE
• This technique is a popular technique for small
programs and considers the combinations of
various inputs which were not available in earlier
discussed techniques like boundary value analysis
and equivalence class testing.
• 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, which are nothing but inputs
and outputs respectively.
• The steps for the generation of test cases are
given in Figure 2.11.

Identification of Causes and Effects
• The SRS document is used for the
identification of 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.

Design of Cause-Effect Graph
• The relationship amongst causes and effects
are established using cause-effect graph.
• The basic notations of the graph are shown in
Figure 2.12.

• In Figure 2.12, each node represents either true
(present) or false (absent) state and may be
assigned 1 and 0 value respectively.
The purpose of four functions is given as:
1. Identity: This function states that if c1 is 1, then
e1 is 1; else e1 is 0.
2. NOT: This function states that if c1 is 1, then e1 is
0; else e1 is 1.
3. AND: This function states that if both c1 and c2
are 1, then e1 is 1; else e1 is 0.
4. OR: This function states that if either c1 or c2 is
1, then e1 is 1; else e1 is 0.
The AND and OR functions are allowed to have any
number of inputs.

Use of Constraints in Cause-Effect
Graph
• There may be a number of causes (inputs) in
any program.
• We may like to explore the relationships
amongst the causes and this process may lead
to some impossible combinations of causes.
• Such impossible combinations or situations
are represented by constraint symbols which
are given in Figure 2.13.

• The purpose of all five constraint symbols is
given as:
(a)The Exclusive (E) constraint states that at
most one of c1 or c2 can be 1 (c1 or c2
cannot be 1 simultaneously). However, both
c1 and c2 can be 0 simultaneously.
(b) The Inclusive (I) constraints states that at
least one of c1 or c2 must always be 1.
Hence, both cannot be 0 simultaneously.
However, both can be 1. One and Only One
(c) The one and only one (O) constraint states
that one and only one of c1 and c2 must be
1.

• (d) The requires (R) constraint states that for
c1 to be 1, c2 must be 1; it is impossible for
c1to be 1 if c2 is 0.
• (e) Mask : This constraint is applicable at the
effect side of the cause-effect graph.
• This states that if effect e1 is 1, effect e2 is
forced to be 0.

• Consider the example of keeping the record
of marital status and number of children of a
citizen.
• The value of marital status must be ‘U’ or ‘M’.
• The value of the number of children must be
digit or null in case a citizen is unmarried.
• If the information entered by the user is
correct then an update is made.
• If the value of marital status of the citizen is
incorrect, then the error message 1 is issued.
• Similarly, if the value of number of children is
incorrect, then the error message 2 is issued

• The causes are:
c1: marital status is ‘U’ c2: marital status is ‘M’ c3:
number of children in a digit
• the effects are:
e1: updation made e2: error message 1 is issued e3:
error message 2 is issued
The cause-effect graph is shown in Figure 2.14.
There are two constraints exclusive (between c1
and c2) and requires (between c3 and c2), which
are placed at appropriate places in the graph.
Causes c1 and c2 cannot occur simultaneously and
for cause c3 to be true, cause c2 has to be true.
However, there is no mask constraint in this graph.

Example 2.18: Consider the triangle
classification problem (‘a’ is the largest side)
specified in example 2.3.
Draw the cause-effect graph and design
decision table from it.

if C1 is 0 output is 1 means e1
is 1 means invalid triangle
same for c2 and c3
E can
have all
0’s
C4=0
C5=0
C6=0
Impossible case

Explanation
c1=1,c2=1 and c3=1 output will be 0
not 0 =1
when C4 is 1 which means condition of right angle
triangle is true and c1=1,c2=1 and c3=1
So output is e2.
not 0 =1
c6 is 1 which means condition of acute angle triangle
is true and c1=1,c2=1 and c3=1
So output is e4.

Explanation
not 0 =1
when C5 is 1 which means condition of obtuse angle
triangle is true and c1=1,c2=1 and c3=1
So output is e3.
Condition for invalid triangle
c1=0 Not of c1=1 so e1=1 which means invalid
triangle
triangle
triangle

Condition for impossible triangle
C1=1,C2=1,C3=1,C4=0,C5=0 and C6=0
Not of C4=1
Not of C5=1
Not of C6=1
In Exclusive c4=0,c5=0 and c6=0 is possible
So (not of C4).(not of C5).(not of C6)
(1.1.1)==1
Not of C1=0
Not of C2=0
Not of C3=0

C1=1,C2=1,C3=1,C4=1,C5=1 and C6=1
Not of C4=0
Not of C5=0
Not of C6=0
In Exclusive c4=1,c5=1 and c6=1 is not
possible according to definition of E

C1=1,C2=1,C3=1,C4=0,C5=1 and C6=1
Not of C4=0
Not of C5=0
Not of C6=0

C1=1,C2=1,C3=1,C4=1,C5=0 and C6=1
Not of C4=0
Not of C5=0
Not of C6=0

C1=1,C2=1,C3=1,C4=1,C5=1 and C6=0
Not of C4=0
Not of C5=0
Not of C6=0

What is Adhoc Testing?
When a software testing performed without proper planning and
documentation, it is said to be Adhoc Testing.
Such kind of tests are executed only once unless we uncover the
defects.
Adhoc Tests are done after formal testing is performed on the
application.
Adhoc methods are the least formal type of testing as it is NOT a
structured approach.
Hence, defects found using this method are hard to replicate as there
are no test cases aligned for those scenarios.
Testing is carried out with the knowledge of the tester about the
application and the tester tests randomly without following the
specifications/requirements.

Hence the success of Adhoc testing depends upon the
capability of the tester, who carries out the test.
The tester has to find defects without any proper
planning and documentation, solely based on tester's
intuition.
When to Execute Adhoc Testing ?
Adhoc testing can be performed when there is limited
time to do exhaustive testing and usually performed after
the formal test execution.
Adhoc testing will be effective only if the tester has in-
depth understanding about the System Under Test.

The Five Essentials of Software Testing
There are primarily five essentials of software
testing that are imperative to the process of
software testing.

1. Test Strategy
● Planning a strategy is an essential component in the process of
attaining a successful result.
● One needs to take into account the possible number of risks
involved, degree of accuracy of test results etc.
● A test strategy thus helps to uncover the facts like which type of
testing best suits our requirements, the sequence in which the tests
are to be performed etc.
● Basically, a test strategy helps to sort our tasks in a wise manner
and that results in less wastage of time and efforts.

2. Testing Plan
● -A test plan is a layout of how a project's testing
activities are to be carried out.
● It is about classifying as to who will be assigned which
task, in which order the tasks shall begin, the
optimum time allocated to each task etc.
● A test plan is exercised after the test strategy is in
place.

3. Test Cases
Test cases are the set of conditions that needs to be
checked to fulfill a criteria.
Test cases are generally prepared followed by the test
strategy.
A test case or test script is intended to check if the
software functions as per the given set of requirements.
A test case should be robust enough in order to ascertain
that our expected results are delivered.
A good test case also brings out the defects in the system.

Example
WAP to print a number from 1 to 100
Test Case :
1. Any number between 1 to 100
2. number less than 1
3. number greater than 100

4. Test Data
● -Data is crucial.
● Test data is simply the input values to be passed to
the system under test.
● For instance, our test data can be customer's phone
number, customer's address, postal address etc.

5. Test Environment
● -The environment here refers to the platform
used for testing an application.
● The environment could be the operating
system used, the automation tool used or
servers/networks.

Structural Testing
• Structural testing is considered more technical
than functional testing.
• It attempts to design test cases from the source
code and not from the specifications.
• The source code becomes the base document
which is examined thoroughly in order to
understand the internal structure and other
implementation details.
• It also gives insight in to the source code which
may be used as an essential knowledge for the
design of test cases.
• Structural testing techniques are also known as
white box testing techniques due to
consideration of internal structure and other
implementation details of the program.

• Many structural testing techniques are
available and some of them are given in this
chapter like control flow testing, data flow
testing, slice based testing and mutation
testing.

1. CONTROL FLOW TESTING
• This technique is very popular due to its simplicity and
effectiveness.
• We identify paths of the program and write test cases
to execute those paths.
• As we all know, path is a sequence of statements that
begins at an entry and ends at an exit.
Types of Control FLow Testing
1. Statement Coverage
2. Branch Coverage
3. Conditional Coverage
4. Path Coverage

1. Statement Coverage
• We want to execute every statement of the
program in order to achieve 100% statement
coverage.
• Consider the following portion of a source
code along with its program graph given in
Figure 4.1.

• The cyclomatic complexity of this graph is: V(G) =
e – n + 2P = 16 – 15 + 2 = 3
• V(G) = no. of regions = 3
• V(G) = number of predicate nodes + 1 = 2 + 1 = 3
If, we select inputs like: a=9, b=8, c=7, all statements
are executed and we have achieved 100%
statement coverage by only one test case.
The total paths of this program graph are given as:
• 1–7, 10, 13–15
• 1–7, 10–15
• 1–10, 13–15
• 1–15

• Hence, independent paths are three and are
given as:
• 1–7, 10, 13–15
• 1–7, 10–15
• 1–10, 13–15
Only one test case may cover all statements but
will not execute all possible four paths and not
even cover all independent paths (three in this
case).

2. Branch Coverage
• We want to test every branch of the program.
• Hence, we wish to test every ‘True’ and ‘False’
condition of the program.
• We consider the program given in Figure 4.1.
• If we select a = 9, b = 8, c = 7, we achieve
100% statement coverage and the path
followed is given as (all true conditions):
• Path = 1–15 We also want to select all false
conditions with the following inputs: a = 7, b =
8, c = 9, the path followed is Path = 1–7, 10,
13–15

• These two test cases out of four are sufficient
to guarantee 100% branch coverage.
• The branch coverage does not guarantee
100% path coverage but it does guarantee
100% statement coverage.
• path not covered in branch coverage is
• 1-10,13-15
• 1-7,10-15

3. Condition Coverage
• Condition coverage is better than branch
coverage because we want to test every
condition at least once.
• However, branch coverage can be achieved
without testing every condition.
• Consider the seventh statement of the
program given in Figure 4.1.
• The statement number 7 has two conditions
(a>b) and (a>c).
• There are four possibilities namely:

• Both are true
• First is true, second is false
• First is false, second is true
• Both are false
• If a > b and a > c, then the statement number
7 will be true (first possibility).
• However, if a < b, then second condition (a >
c) would not be tested and statement number
7 will be false (third and fourth possibilities).
• If a > b and a < c, statement number 7 will be
false (second possibility).

• Hence, we should write test cases for every
true and false condition.
• Selected inputs may be given as:
a = 9, b = 8, c = 7 (first possibility when both are
true)
• a = 9, b = 8, c = 10 (second possibility – first is
true, second is false)
• a = 7, b = 8, c = 9 (third and fourth
possibilities- first is false, statement number 7
is false)
• Hence, these three test cases out of four are
sufficient to ensure the execution of every
condition of the program.

4. Path Coverage
• In this coverage criteria, we want to test every
path of the program.
• There are too many paths in any program due
to loops and feedback connections.
• It may not be possible to achieve this goal of
executing all paths in many programs.
• If we do so, we may be confident about the
correctness of the program.
• If it is unachievable, at least all independent
paths should be executed.

The program given in Figure 4.1 has four paths as
given as:
•1–7, 10, 13–15
•1–7, 10–15
•1–10, 13–15
•1–15
• Execution of all these paths increases confidence
about the correctness of the program. Inputs for test
cases are given as:

• Path testing guarantee statement coverage,
branch coverage and condition coverage.
However, there are many paths in any
program and it may not be possible to execute
all the paths.
• We should do enough testing to achieve a
reasonable level of coverage.
• We should execute at least (minimum level)
all independent paths which are also referred
to as basis paths to achieve reasonable
coverage.

Dec 2016
Generate all the independent paths required
for tesitng program that finds all even numbers
between 1-50.

Program
int main()...................................................1
{..................................................................2
int i…..........................................................3
for(i=1;i<=50;i++).......................................4
{..................................................................5
if(i%2==0)................................................6
printf(“%d is a even number “,i);.......7
}…………………………………………………..........8
}……………………………………………………………9

e – n + 2P =11-9+2=2+2=4
• V(G) = no. of enclosed regions+1 = 3+1=4
• V(G) = no of predicate nodes+1 =3+1=4
Independent path
• 1-9
• 1-6,8,4,9
• 1-8,4,9
• 1-6,8,9

e – n + 2P =28-24+2=4+2=6
• V(G) = no. of enclosed regions+1 = 5+1=6
• V(G) = no of predicate nodes+1 =5+1=6
Predicate nodes(Nodes having out degree 2)
=2,6,8,13,19

2. DATA FLOW TESTING
• In control flow testing, we find various paths
of a program and design test cases to execute
those paths.
• We may like to execute every statement of the
program at least once before the completion
of testing.
• Consider the following program:

• What will be the output? The value of ‘a’ may be
the previous value stored in the memory location
assigned to variable ‘a’ or a garbage value.
• If we execute the program, we may get an
unexpected value (garbage value).
• The mistake is in the usage (reference) of this
variable without first assigning a value to it.
• We may assume that all variables are
automatically assigned to zero initially.
• This does not happen always. If we define at line
number 4, ‘static int a, b, c’, then all variables are
given zero value initially.
• However, this is a language and compiler
dependent feature and may not be generalized.

• Data flow testing may help us to minimize such
mistakes.
• It has nothing to do with dataflow diagrams.
• It is based on variables, their usage and their
definition(s) (assignment) in the program.
• The main points of concern are:
1. Statements where variables receive values
(definition).
2. Statements where these values are used
(referenced).
• Data flow testing focuses on variable definition and
variable usage.
In line number 5 of the above program, variable ‘a’ is
defined and variables ‘b’ and ‘c’ are used. The
variables are defined and used (referenced)
throughout the program.
Hence, this technique concentrates on how a variable is
defined and used at different places of the program.

Testing Strategies Using du-Paths
We want to generate test cases which trace
every definition to each of its use and every use
is traced to each of its definition.
Some of the testing strategies are given as:

Test All du-path
All du-paths generated for all variables are
tested.
This is the strongest data flow testing strategy
covering all possible du-paths.

Test all uses
Find at least one path from every definition of
every variable to every use of that variable
which can be reached by that definition.
For every use of a variable, there is a path
from the definition of that variable to the
use of that variable.

Test all definitions
Find paths from every definition of every
variable to at least one use of that variable;
we may choose any strategy for testing.
As we go from ‘test all du-paths’ (no. (i)) to
‘test all definitions’ (no.(iii)), the number of
paths are reduced. However, it is best to test
all du-paths (no. (i)) and give priority to those
du-paths which are not definition clear paths.

Variable A is defined
Variable B is defined
Variable C is defined

• Consider the program given in Figure 3.11 to
find the largest number amongst three
numbers.
• Its program graph is given in Figure 3.12.
• There are three variables in the program
namely A, B and C.
• Define /use nodes for all these variables are
given below:

Definition clear
Yes means
definition of
same variable is
not done within
path

Program Graph Node DD path graph Node
1 Source
2-10 A
18 B
12 C
13,14 D
16,17 F
18,19,20 G
21 H
22,23,24 I
25 J
26 Destination

3. SLICE BASED TESTING
• “Program slicing is a technique for restricting
the behavior of a program to some specified
subset of interest.
• A slice S(V , n) of program P on variable V, or
set of variables, at statement n yields the
portions of the program that contributed to
the value of just before statement n is
executed. S ( V, n) is called a slicing criteria.
• Slices can be computed automatically on
source programs by analyzing data flow.
• A program slice has the added advantage of
being an executable program.”

• Hence, slices are smaller than the original
program and may be executed
independently.
• Only two things are important here, variable
and its selected location in the program.

Guidelines for Slicing
• The following guidelines may be used for the
creation of program slices.
1. All statements where variables are defined
and redefined should be considered.
• Consider 1. the program for classification of a
triangle (given in Figure 3.18) where variable
‘valid’ is defined at line number 5 and
redefined at line number 15 and line number
18.

Program Graphs
• Program graph is a graphical representation of the
source code of a program.
• The statements of a program are represented by
nodes and flow of control by edges in the program
graph.
• The definition of a program graph is [JORG07]: “A
program graph is a directed graph in which nodes are
either statements or fragments of a statement and
edges represent flow of control.”
• The program graph helps us to understand the internal
structure of the program which may provide the basis
for designing the testing techniques.
• The basic constructs of the program graph are given in
Figure 3.9.

• The program graph (G) is a directed graph
with single entry node and single exit node.
• A connected graph is a program graph where
all nodes are reachable from entry node, and
exit node is also reachable from all nodes.

DD Path Graphs
• The Decision to Decision (DD) path graph is an extension of
a program graph.
• It is widely known as DD path graph.
• There may be many nodes in a program graph which are in
a sequence.
• When we enter into the first node of the sequence, we can
exit only from the last node of that sequence.
• In DD path graph, such nodes which are in a sequence are
combined into a block and are represented by a single
node.
• Hence, the DD path graph is a directed graph in which
nodes are sequences of statements and edges are control
flow amongst the nodes.
• All programs have an entry and an exit and the
corresponding program graph has a source node and a
destination node.
• Similarly, the DD path graph also has a source node and a
destination node.

We consider program ‘Square’ and its program graph given
in Figure 3.10.
We prepare a mapping table and a DD path graph as shown
in Figure 3.13.
All nodes are sequential nodes except node 1 and node 8
which are source node and destination node respectively.

• The triangle is classified according to the following
rules:
• Right angled triangle: c^2 = a^2 + b^2 or a^2 =
b^2 + c^2 or b^2 = c^2 + a^2
• Obtuse angled triangle: c^2 > a^2 + b^2 or a^2 >
b^2 + c^2 or b^2 > c^2 + a^2
• Acute angled triangle: c^2 < a^2 + b^2 and a^2 <
b^2 + c^2 and b^2 < c^2 + a^2
• Invalid Traingle: a=b+c or b=a+c or c=a+b

Conditions for obtuse angle
triangle
a=4 b=3 c=2
a1=(4*4+3*3)/2*2
a1=(16+9)/4
a1=25/4=6.25
a1=6.25>1
a2=(3*3+2*2)/4*4
a2=9+4/16
a2=13/16=0.8125<1 true so it is obtuse angle

NOTE
In case of a2:
(denominator value is greater so answer will
always be less than 0)

a3=(2*2+4*4)/(3*3)
a3=(4+16)/9
a3=(20)/9=2.22
if any One condition is true than it is a obtuse
angle triangle

Conditions for right angle triangle
a=3 b=4 c=5
a1=(3*3+4*4)/(5*5)
9+16/25=25/25=1
a1==1 so it is right angle triangle
a2=(4*4+5*5)/(3*3)
a2=(16+25)/9
a2=41/9=4.55
a3=(5*5+3*3)/4*4
a3=(25+9)/16=34/16=2 .125

Conditions for acute angle triangle
a=4 b=5 c=6
a1=(4*4+5*5)/6*6
a1=(16+25)/36
a1=41/36=1.13>1 true
a2=(5*5+6*6)/4*4
a2=(25+36)/16=61/16=3.81>1 true
a3=(6*6+4*4)/(5*5)
a3=(36+16)/25=52/25=2.08>1 true

• Example 3.4: Consider the program for
classification of a triangle.
• Its input is a triple of positive integers (say a, b
and c) and values from the interval [1, 100].
• The output may be [Right angled triangle,
Acute angled triangle, Obtuse angled
triangle, Invalid triangle, Input values are out
of Range].
• The program is given in Figure 3.18. Draw the
program graph and the DD path graph.

Decision node
Junction node
Terminal Node

1 S
2 to 6 N1
7 N2
8 N3
9 N4
10,11 N5
12 N6
13 N7
14 N8
15 N9
16,17 N10

18 N11
19,20 N12
21,22,23 N13
24 N14
35 N15
26,27 N16
28,29,30 N17
31 N18
32 D

Cyclomatic Number
• The cyclomatic number of a graph G is given
by V(G) = e – n + 2p, where
• e is the number of edges in G.
• n is the number of nodes in G.
• p is the number of components in G.
• V(G) is the number of distinct regions in a
strongly connected directed graph

IDENTIFICATION OF INDEPENDENT
PATHS
• Cyclomatic Complexity
This concept involves using cyclomatic number
of graph theory which has been redefined as
cyclomatic complexity.
This is nothing but the number of independent
paths through a program.

Properties of Cyclomatic complexity
• V(G)>=1
• V(G) is the maximum number of independent
paths in program graph G.
• Addition or deletion of functional statements
to program graph G does not affect V(G).
• G has only one path if V(G)=1
• V(G) depends only on the decision structure of
G.

• V(G) = e – n + 2P
where V(G) = Cyclomatic complexity
G : program graph
n : number of nodes
e : number of edges
P : number of connected components

2 Cyclomatic complexity is equal to the number
of regions of the program graph.
3 Cyclomatic complexity
• V(G) = + 1 where is the number of predicate
nodes contained in the program graph (G).
• The only restriction is that every predicate
node should have two outgoing edges i.e. one
for ‘true’ condition and another for ‘false’
condition

Graph Matrices
• The graphs are commonly used in testing to
find independent paths.
• Cyclomatic complexity also gives us the
number of independent paths in any graph.
• When the size of the graph increases, it
becomes difficult to identify those paths
manually.
• We may do so with the help of a software tool
and graph matrices may become the basis for
designing such a tool.

• A graph matrix is a square matrix with one
row and one column for every node of the
graph.
• The size of the matrix (number of rows and
number of columns) is the number of nodes of
the graph.
• Some examples of program graphs and their
graph matrices are given in Figure 3.26.

• Consider the program graph shown in Figure
3.29 and draw the graph and connection
matrices. Find out the cyclomatic complexity
and two/three link paths from a node to any
other node.

The graph and connection matrices are given below:
Cyclomatic complexity = e-n+2P = 6-5+2= 3
There are 3 regions in the program graph.
•The formula predicate node+1 ( +1) is not applicable
because predicate node 3 has three outgoing edges

Software Testing Introduction (Part 2)

Recommended

More Related Content

Similar to Software Testing Introduction (Part 2) (20)

More from Thapar Institute (18)

Recently uploaded (20)

Software Testing Introduction (Part 2)