SOFTWARE TESTING

 Testing is a process of executing software

with the intent of finding errors
 Good test case is the one which has a high
probability of finding as-yet-undiscovered
error
 Successful testing discovers unknown errors
Design a series of test cases that have a high
likelihood of finding errors.

How?

By using TESTING TECHNIQUES

Types of testing techniques ------
1. Exercises the internal logic of software components---
WHITE BOX TESTING
2. Exercises the input and output domains of the programs to
uncover errors in program, function, behavior and
performance--- BLACK BOX TESTING
Who does it?
Early stages---software engineer
As testing progresses ---- Testing Specialists
 It is a test case design method that uses the
control structure of the procedural design to derive
test cases.
 Also called glass box testing
 Examines procedural detail of the software.
Using WBT, software engineer can derive test cases
that-----
1. Guarantee that al independent paths within a
module have been exercised at least once.
2. Exercise all logical decisions on their true and false
sides.
3. Execute all loops at their boundaries
4. Exercise internal data structures to ensure their
validity.
Types of WBT techniques
1. Basis Path Testing
• Basis path testing is a white-box testing technique first
proposed by Tom McCabe.
• Basis path method enables to derive a logical complexity
measure of a procedural design and use this measure as a
guide for defining a basis set of execution paths.
• Test Cases derived to exercise the basis set are guaranteed
to execute every statement in the program at least one time
during testing.
• Uses Flow graph notation
• The flow graph depicts logical control flow within a
program
Step1 : Map flowchart into a corresponding
flow graph
Each circle, called a flow graph node, which
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 orlinks,
represent flow of control and are analogous to
flowchart arrows.
• Areas bounded by edges and nodes are called
regions.
• When counting regions, we include the area
outside the graph as a region.
• Each node that contains a condition is called a
predicate node and is characterized by two or more
edges emanating from it.
Flowchart Flowgraph
 Step 2 : Compute the cyclomatic complexity CC

• Cyclomatic complexity is a software metric that provides a

quantitative measure of the logical complexity of a program.

• The value computed for cyclomatic complexity defines the

number of independent paths in the program

• Hence gives the number of test cases to ensure that all

statements have been executed at least once.

• An independent path is any path through the program that

introduces at least one new set of processing statements or a
new condition.
Complexity is computed in one of three ways:

1. The number of regions of the flow graph correspond to the cyclomatic

complexity.

2. 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, N is the number of
flow graph nodes.

3. Cyclomatic complexity, V(G), for a flow graph, G, is also defined as

V(G) = P + 1
where P is the number of predicate nodes contained in the flow graph G.
1. The flow graph has four regions.
2. V(G) = 11 edges - 9 nodes + 2 = 4.
3. V(G) = 3 predicate nodes + 1 = 4.

Step 3: Determine a basis set (set of independent paths)

 path 1: 1-11

 path 2: 1-2-3-4-5-10-1-11

 path 3: 1-2-3-6-8-9-10-1-11

 path 4: 1-2-3-6-7-9-10-1-11

Step 4: Prepare test cases that will force execution

 V(G) = 6 regions
 V(G) = 17 edges -13 nodes + 2 = 6
 V(G) = 5 predicate nodes + 1 = 6
 path 1: 1-2-10-11-13
 path 2: 1-2-10-12-13
 path 3: 1-2-3-10-11-13
 path 4: 1-2-3-4-5-8-9-2-. . .
 path 5: 1-2-3-4-5-6-8-9-2-. . .
 path 6: 1-2-3-4-5-6-7-8-9-2-. . .

 The ellipsis (. . .) following paths 4, 5, and 6

indicates that any path through the remainder
of the control structure is acceptable.
 Data should be chosen so that conditions at
the predicate nodes are appropriately set as
each path is tested.
 Path 1 test case:
 value(k) = valid input, where k < i for 2 ≤ i ≤
100
 value(i) = 999 where 2 ≤ i ≤ 100
 Expected results: Correct average based on k
values and proper totals.
 Path 2 test case:
 value(1) = 999
 Expected results: Average = 999; other totals
at initial values.
 Path 3 test case:
 Attempt to process 101 or more values.
 First 100 values should be valid.
 Expected results: Same as test case 1.
 Path 4 test case:
 value(i) = valid input where i < 100
 value(k) < minimum where k < i
 Expected results: Correct average based on k
values and proper totals.
 Path 5 test case:
 value(i) = valid input where i < 100
 value(k) > maximum where k <= i
 Expected results: Correct average based on n
values and proper totals.
 Path 6 test case:
 value(i) = valid input where i < 100
 Expected results: Correct average based on n
values and proper totals.
 Write program to find maximum of three
numbers. Derive test cases using cyclomatic
complexity.
 Write a code to perform binary search. Draw
flowgraph. Calculate cyclomatic complexity
and derive test cases.
Control Structure Testing :
Types :
1. Condition testing (e.g. branch testing)
◦ focuses on testing each decision statement in a
software module
◦ it is important to ensure coverage of all logical
combinations of data that may be processed by the
module (a truth table may be helpful)
2. Data flow testing
◦ selects test paths based according to the locations of
variable definitions and uses in the program (e.g.
definition use chains)
3. Loop testing
◦ focuses on the validity of the program loop constructs
(i.e. while, for, go to)
1. Condition testing
Different conditions :
1. Compound condition
2 or more simple conditions connected with AND,
OR.
Eg : (a>b) AND (c<d)
2. Relational expression
(E1 rel-op E2)
E1, E2 -- arithmetic expr.
Eg : (a*b+c) > (a+b+c)
3. Boolean expression
(B1 AND B2)
Condition testing strategies -
1. Branch Testing :
• Simplest condition testing strategy.
• For a compound condition C, the true and false
branches of C and every simple condition need to
be executed at least once.
• Eg : if ( a>0 && b== null )
condition coverage can be achieved by testing with
a=1 b != null
a=1 b = null
a=0 b != null
a=0 b = null
2. Domain testing
For a relational expression 3 tests are required:
Eg : E1<Rel-op>E2
3 test cases are :
1. E1<E2
2. E1>E2
3. E1=E2

If relational operator is incorrect , all 3 tests

guarantee detection of relational operator
error
3. Branch and relational operator testing (BRO testing)
 Branch and Relational Operator Testing – uses condition
constraints
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
Example 2 :
C2 = B1 & (E3=E4)
B1-boolean expr
E3,E4- arithmetic expr.
Condition constraint of C2 is (D1,D2)

D1-(t/f)
D2- >,=,<
Hence the constraint set for C2 is
(t,t)------ (t,=)
(t,f)---- (t,<) and (t,>)
(f,t)--- (f,=)
Example 3
C3 : (E1>E2) & (E3=E4)
E1,E2,E3,E4 ---arithmetic expr.
Constraint set for C3----
{ (>,=) (=,=) (<,=) (>,>) (>,<) }
(t,t) (f,t) (f,t) (t,f) (t,f)
2. Data Flow testing
 Data flow testing selects test paths of a program according to
the locations of definitions and uses of variables in the
program.
 A USE is a reference to a variable’s value.
 A DEF is an assignment of a new value to the variable.
 A DEF-USE pair (DU chain) is a path from the point the
variable is defined to the point the variable is referenced.
 Data flow testing requires that all DEF-USE pairs to be
executed.
 Example 1 :
if(some_exp) //1
some_var=1; //2
else //3
some_var=2; //4
If(some_case) //5
P1(some_var); //6
else //7
P2(some_var); //8

 DEF: 2 and 4
 USE : 6 and 8
 4 DEF-USE pairs ----
DEF-USE-Paths DEF USE PATH
1 2 6 <1-2-5-6>
2 2 8 <1-2-5-8>
3 4 6 <1-4-5-6>
4 4 8 <1-4-5-8>
Test Cases :
(some_exp=true, some_case=true) path 1
(some_exp=true, some_case=false) path 2
(some_exp=false, some_case=true) path 3
(some_exp=false, some_case=false) path 4
Eg :
 DU Chains of the Odd() Example
– (x, 3, 4), (x, 3, 5), (x, 3, 7)
– (x, 5, 8), (x, 7, 8)

NOTE : (x, 3, 8) is NOT a DU chain since the value of x at Line 3

is redefined at Lines 5 and 7 before it reaches the use at Line 8

 Test paths selected according to all use coverage:

 path1 1-2-3-4-7-8 cover (x, 3, 4), (x, 3, 7), (x, 7, 8)

 path2 1-2-3-4-5-8 cover (x, 3, 4), (x, 3, 5), (x, 5, 8)
3. Loop Testing :
Loop Testing is a white box testing technique that focuses
exclusively on the validity of loop constructs.
Four classes of loops can be defined:
Simple loops
Concatenated loops
Nested loops
Unstructured loops.

Simple Concatenated
loop Nested loops
Loops
Unstructured
Loops
 Testing simple loops
Simple Loops: The following sets 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 is less than n.

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

Nested Loops: If we extend the test approach from simple loops
to nested loops, the number of possible tests would grow
geometrically as the level of nesting increases.
1. Start at the innermost loop. Set all other loops to minimum
values.
2. Conduct simple loop tests for the innermost loop while
holding the outer loops at their minimum iteration parameter
values.

3. Work outward, conducting tests for the next loop, but keep
all other outer loops at minimum values and other nested
loops to "typical" values.
4. Continue until all loops have been tested.
Concatenated Loops:
Concatenated loops can be tested using the approach defined
for simple loops, if each of the loops is independent of the
other.

However, if two loops are concatenated and the loop counter

for loop 1 is used as the initial value for loop 2, then the loops
are not independent.

Unstructured Loops: Whenever possible, this class of loops

should be redesigned to reflect the use of the structured
programming constructs.
 Also called behavioral/functional testing.

 Focuses on the functional requirements of the software.

 Not an alternative to WBT.

 Complementary approach to WBT.

 Uncovers different class of errors than WBT.

 Attempts to find errors in the following categories --
 Incorrect/missing function.
 Interface errors.
 Errors in database/external database access.
 Behavior/performance errors.

 Black Box Testing Techniques

◦ Equivalence Partitioning
◦ Boundary Value Analysis
◦ Graph-Based Testing methods
◦ Orthogonal Array Testing
◦ Comparison Testing
 A Black-box technique that divides the input domain into
classes of data from which test cases can be derived.

 EP defines test cases that uncovers classes of errors thereby

reducing the no. of test cases that must be developed.

 Test case design for equivalence partitioning is based on an

evaluation of equivalence classes for an input condition.

 An equivalence class represents a set of valid or invalid states

for input conditions.

 An input condition is either a specific numeric value, a range

of values, a set of related values, or a Boolean condition.
 If an input condition requires a specific value, one
valid and two invalid equivalence classes are
defined

 If input condition specifies a range, one valid and

two invalid equivalence classes are defined

 If an input condition specifies a member of a set,

one valid and one invalid equivalence class is
defined

 If an input condition is Boolean, one valid and one

invalid equivalence class is defined
 Applying these guidelines test cases for each input domain
can be developed.
 E.g. A program reads an input number in the range 1 and
5000 and computes the square of the input number.
3 Equivalence classes are -----
1. Set of numbers less than 1.
2. Set of numbers between 1 and 5000.
3. Set of numbers greater than 5000.

A possible test case {-10,100,7000}

 During the log-on sequence, the software supplied for the
banking application accepts data in the form

 area code—blank or three-digit number

 prefix—three-digit number not beginning with 0 or 1
 suffix—four-digit number
 password—six digit alphanumeric string
 commands—check, deposit, bill pay, and the like
 The input conditions associated with each data element for
the banking application can be specified as
 area code: Input condition, Boolean—the area code may or
may not be present.
Input condition, range—values defined between 200 and 999,
with specific exceptions.
 prefix: Input condition, range—specified value >200
Input condition, value—four-digit length
 password: Input condition, Boolean—a password may or may
not be present.
Input condition, value—six-character string.
 command: Input condition, set—containing commands noted
previously
 Boundary value analysis is a test case design
technique that complements equivalence
partitioning.
 Boundary value analysis leads to a selection of test
cases that exercise bounding values.
 Rather than selecting any element of an
equivalence class, BVA leads to the selection of test
cases at the "edges" of the class.
 Rather than focusing solely on input conditions,
BVA derives test cases from the output domain as
well
 Guidelines:
1. If input condition specifies a range bounded by values a
and b, test cases should include a and b, values just
above and just below a and b.

2. If an input condition specifies an number of values, test

cases should exercise the minimum and maximum
numbers, as well as values just above and just below the
minimum and maximum values

3. Apply guidelines 1 and 2 to output conditions, test cases

should be designed to produce the minimum and
maximum output reports

4. If internal program data structures have boundaries (e.g.

size limitations), be certain to test the boundaries
 Suppose you have a very important tool at
office, that accepts valid User Name and
Password field to work on that tool, and
accepts minimum 8 characters and maximum
12 characters.
 Valid range 8-12, Invalid range 7 or less than
7 and Invalid range 13 or more than 13.
 Write Test Cases for Valid partition value, Invalid
partition value and exact boundary value.
 Test Cases 1: Consider password length less than
8.
 Test Cases 2: Consider password of length exactly
8.
 Test Cases 3: Consider password of length between
9 and 11.
 Test Cases 4: Consider password of length exactly
12.
 Test Cases 5: Consider password of length more
than 12.

 Test cases for the application whose input box
accepts numbers between 1-1000. Valid range 1-
1000, Invalid range 0 and Invalid range 1001 or
more.
 Test Cases 1: Consider test data exactly as the
input boundaries of input domain i.e. values
1 and 1000.
 Test Cases 2: Consider test data with values just
below the extreme edges of input domains i.e.
values 0 and 999.
 Test Cases 3: Consider test data with values just
above the extreme edges of input domain i.e.
values 2 and 1001.
 Compare white box testing and black box testing.
 Explain basis path testing and cyclomatic
complexity in detail.
 What is equivalence partitioning approach in black
box testing. Write guidelines to perform EP.
 What is boundary value analysis approach in black
box testing. Write guidelines to perform BVA.
 Explain DEF-USE testing with example.