MODULE-III

18FD09 SOFTWARE ENGINEERING

 TAXONOMY OF SOFTWARE
TESTING

Testing Goals
 To demonstrate to the developer and
the customer that the software meets
its requirements
 To discover situations in which the
behavior of the software is incorrect
and undesirable

18PD09 SOFTWARE ENGINEERING

 TAXONOMY OF SOFTWARE
TESTING
 Validation: Are we building the right
product?

 Verification: Are we building the product

right?’

18PD09 SOFTWARE ENGINEERING

 TAXONOMY OF SOFTWARE
TESTING

 Validation
To ensure that the software
meets the customer’s
expectations
 Verification
To check that the software
meets its stated functional
and non-functional
requirements

18PD09 SOFTWARE ENGINEERING

 LEVELS OF
TESTING
 Unit Testing
 Integration Testing
 System Testing
 Acceptance Testing

18PD09 SOFTWARE ENGINEERING

 LEVELS OF TESTING
 Unit Testing
• focus on testing the functionality of objects or
methods
 Integration Testing
• individual units are integrated to create
composite components ie.focus on testing
component interfaces.
 System Testing
• system are integrated and the system is tested
as a whole

18PD09 SOFTWARE ENGINEERING

 UNIT TESTING

Checks Appropriate
• argument values
• method sequence
• assertions
• Source code levels..
• Logic

18PD09 SOFTWARE ENGINEERING

 UNIT TESTING

COMPONENT TESTING
18PD09 SOFTWARE ENGINEERING
 SYSTEM TESTING

INTEGRATION
TESTING

18PD09 SOFTWARE ENGINEERING

 TEST ACTIVITIES
 Test planning
 Test case design
 Test execution
 Data collection
 Effective evaluation

18PD09 SOFTWARE ENGINEERING

 TEST ACTIVITIES
• Test planning
– Test plan/script is prepared
– Generated from requirement analysis
document
– For black box and white box testing
• Test case design
– Create a set of tests that are effective in
testing

18PD09 SOFTWARE ENGINEERING

 TEST ACTIVITIES
• Test Execution
– Test data is derived through various test
cases in order to obtain the test result
• Data Collection
– Test results are collected and verified
• Effective evaluation
– Performed on the software model
– No.of errors are un-coverd

18PD09 SOFTWARE ENGINEERING

 TYPES OF SOFTWARE
TESTING
• Black box testing
• White box testing
• Unit testing
• Integration testing
• Regression testing
• Validation testing
• Loop testing

18PD09 SOFTWARE ENGINEERING

 BLACK BOX TESTING
 Functionalities of software applications are tested
 Doesn’t need knowledge of internal code structure or
implementation details
 Focuses on input and output of software applications
 Based on software requirements and specifications
 It is also known as behavioral testing

18PD09 SOFTWARE ENGINEERING

 BLACK BOX TESTING
Purpose of black box testing – finding different kinds
of errors
 Correct or missing functions
 Interface errors
 Data structures or database access
 Behaviour or performance errors
 Intialization or terminination errors

18PD09 SOFTWARE ENGINEERING

 Testing boundary conditions

 Boundary value analysis is a type of black box

testing technique in which tests are performed
using the boundary values.

 It is done to check boundry conditions of

elements to selected and tested

 Boundary values are validated against both the

valid boundaries and invalid boundaries

18PD09 SOFTWARE ENGINEERING

 Testing boundary
conditions
Guidelines
1.If input / output condition is specified with range (X,Y) then test
cases should be designed with values above X and below Y

2. If input / output condition is specified with no.of values then

test cases should be designed with min and max values.(above
min below max)

3.If integral program data structures specify boundaries then test

cases must be according to data structure boundry

18PD09 SOFTWARE ENGINEERING

 Testing boundary
conditions
Example:
An exam has a pass boundary at 50 percent, merit at 75 percent
and distinction at 85 percent.
Valid Boundary values
• 49, 50 - for pass
• 74, 75 - for merit
• 84, 85 - for distinction
Invalid Boundary values
• 0 - for lower limit boundary value
• 101 - for upper limit boundary value

18PD09 SOFTWARE ENGINEERING

 Structural Testing

18PD09 SOFTWARE ENGINEERING

 Structural Testing
 used to test the internal design of the software or
structure of the coding for the particular software.
 also known as White box /Glass box testing/ Clear
testing

Techniques
1) statement coverage
2) Branch coverage
3) Path coverage

18PD09 SOFTWARE ENGINEERING

 Statement Coverage
 Aims at executing all programming statements at
least once with minimal no. of tests
 Principal idea : Unless a statement is tested , we
never know if any error exists in the statement.
 However observing that statement works for one
input value : gives no guarantee that it will work
for all input

18PD09 SOFTWARE ENGINEERING

 Statement Coverage
 Statement testing coverage:
(No. of statements executed / Total statements ) *
100
EXAMPLE
1. Int f1(int x ,int y) Test cases : statement coverage
2. While(x!=y) { x= 7 y=7
3. if(x>y) then x= 7 y= 3
4. x=x-y x= 7 y=10
5. else y=y-x;
6. }
7. return x;
8. }

18PD09 SOFTWARE ENGINEERING

 Branch Coverage
 Test cases are designed that each branch
condition is tested with truth values.
 Condition testing supports to test branch coverage

Example: if (a>10 && b< 19)

Test cases : a=15 , b= 18
a= 4 , b= 63

18PD09 SOFTWARE ENGINEERING

 Branch Coverage
 Consider : ((c1 and c2) or c3)
 Each of c1 , c2 and c3 are exercised with all
possible values : True and False
 Each basic condition to be executed once
 Coverage: Truth values by all basic conditions / 2 *
basic conditions

Example: ((a>10 II b< 29 ) && c>15)

18PD09 SOFTWARE ENGINEERING

 Path Coverage
 This coverage technique corresponds to testing all
possible paths : ie. Statement and branches are
executed.
 Every program composed of three blocks
• Sequence
• Selection
• Iteration
 CFG : Control Flow Graph is constructed

18PD09 SOFTWARE ENGINEERING

 Path Coverage

CFG : Control Flow Graph

Sequence :
1. int a=5
2. c=a*3;
3. length = (c *a) + 0.25;
4. print length

18PD09 SOFTWARE ENGINEERING

 Path Coverage

CFG : Control Flow Graph

Selection :
1. if(a>b) then
2. c=3;
3. else c=5;
4. c= c*b

18PD09 SOFTWARE ENGINEERING

 Path Coverage

CFG : Control Flow Graph

Iteration :
1. while(a>b) {
2. b=b*a;
3. b=b-1;}
4. c=b+a;

18PD09 SOFTWARE ENGINEERING

 Path Coverage
Mc Cabe cyclomatic metric
 There will be n number of paths
 All path testing is impractical
 Linearly independent paths are to be tested
 To find independent paths – Cylomatic
complexity

18PD09 SOFTWARE ENGINEERING

 Path Coverage
Mc Cabe cyclomatic metric
 Mc Cabe cyclotic complexity Formula
V(G)= E- N+2
N is the number of nodes in G
E is the number of edges in G

18PD09 SOFTWARE ENGINEERING

 Path Coverage
Cyclomatic complexity
Another way :
1. determine no.of bounded
areas
2 V(G) = Total bounded areas +
1
Bounded areas – Any region
enclosed by nodes and edge
sequence
18PD09 SOFTWARE ENGINEERING
 Path Coverage
Mc cabe’s metric
 Mc cabes’s metric provides measure of testing difficulty
 No.of bounded areas increases with the number of decision
nodes and loops
 It provides lower bound on of no. of test cases to be designed
 It guarantees the coverage of all linearly independent paths
 It doesn’t make to derive the test cases.

18PD09 SOFTWARE ENGINEERING

 Path Coverage
Cyclomatic complexity
 It helps to understand the structural complexity of
program
 It helps to find difficulty level of understanding
program
 From maintenance perspective, - helps to limit
cyclomatic complexity to reasonable value.
 Dataflow Testing

18PD09 SOFTWARE ENGINEERING

Dataflow Testing
 It checks definition and uses of different
variables in a program
 It checks the execution of each variable
declared in a program
Example: a= b;
Data flow

b= c * d;
d= a;
 Datapath Testing
x(){
int a= 7; / * declaration of a*/
…………
while (c>5)
{
if (d < 50)
b=a*a; / * use of a*/
a=a-1; / * definition and use of a*/
…………………..
print (a);} / * use of a*/

18PD09 SOFTWARE ENGINEERING

 Datapath Testing
For statement numbered N
DEF(N) = {x/ statement N contains definition of
x}
USES(N) = {x/ statement N contains use of x}

Example : 1. a=b
2. a= a+c
DEF (1)= {a} , USES (1) = {a,b}
DEF (2) = {a} , USES (2) = {a,c}
 Datapath Testing
A variable X is said to be live at statement S2 , if
 X is defined at a statement S1;
There exists path from S1 to S2 not containing
any definition of X in between the path
[X, S1, S2]
• S1 and S2are statement numbers
• X in DEF(S1)
• X in USES(S2) and
• Definition of X is live at Statement S2

18PD09 SOFTWARE ENGINEERING

 Dataflow Testing (DU Chain)
A DU chain consists of definition of variable and all the uses reachable from
definition without any intervening definitions
1. x(){
2. int a= 7; / * declaration of a */ S1 DEF(S2) = {a}
3. …………
4. while (c>5)
5. {
6. if (d < 50)
7. b=a*a; / * use of a */ /* declaration of b */ S2
USES(S7)={a,b}
8. a=a-1; / * definition and use of a */
9. ………………….. [a, S1,S7 ] DU chain
10. print (a,b);} / * use of a,b*/
 Find DU chain
1. x(){
2. int a= 7;
3. int d= 45;
4. …………………
5. while (c>5)
6. {
7. if (d < 50)
8. b=a*a;
9. a=a-1; }
10. ………………..
11. print ( a, b);
18PD09 SOFTWARE ENGINEERING
 Dataflow Testing
Dataflow strategy:
Every DU chain has to be tested at least once
 Checking all DU chain doesn’t mean it covers all
paths
 It checks the definition and usability of variables

18PD09 SOFTWARE ENGINEERING

 Summary
 Taxonomy
 Test levels
 Test activities
 Test types
 Black box testing
 Boundary conditions
 White box - Structural testing
 Test coverage (statement, branch/conditional, path)
 Path coverage ( Mc cabe’s , Cyclomatic complexity)
 Data flow mechanisms ( DU chain)
18PD09 SOFTWARE ENGINEERING