Department of Information Science and Engineering

Course Name : Software Testing

Course Code : 21IS62

By,
Mrs. Swathi Darla,
Assistant Professor,
Dept of ISE, RVITM
 Module-4

Levels of Testing
Integration Testing:
LEVELS OF TESTING, INTEGRATION TESTING : Traditional View of Testing Levels

The traditional model of software development is the Waterfall model, which is drawn as a V

Fig: 4.1 Verification and validation Model

 Continue…
• Figure 4.2 contains a partial functional decomposition of our ATM system. With this decomposition. top-
down integration would begin with the main program, checking the calls to the three next level procedures
(Terminal I/O, ManageSessions, and ConductTransactions).
• Following the tree ,the ManageSessions procedure would be tested, and then the CardEntry, PIN Entry, and
SelectTransaction procedures. In each case, the actual code for lower level units is replaced by a stub, which
is a throw-away piece of code that takes the place of the actual code.
• Bottomup integration would be the opposite sequence, starting with the CardEntry, PIN Entry,and
SelectTransaction procedures, and working up toward the main program. In bottom-up integration, units at
higher levels are replaced by drivers (another form of throw-away code) that emulate the procedure calls.
 Alternative Life Cycle Models
• There are three mainline derivatives of the waterfall model: incremental development, evolutionary
development, and the Spiral model.
• Each of these involves a series of increments or builds, as shown in Figure 4.3. Within a build, the
normal waterfall phases from detailed design through testing occur, with one important difference:
system testing is split into two steps, regression and progression testing.
 Continue…
• The differences among the three spin-off models are due to how the builds are
identified. In incremental development, the motivation for separate builds is
usually to level off the staff profile.
• In evolutionary development, there is still the presumption of a build sequence,
but only the first build is defined. Based on it, later builds are identified, usually
in response to priorities set by the customer/user, so the system evolves to meet
the changing needs of the user.

• The spiral model is a combination of rapid prototyping and evolutionary

development, in which a build is defined first in terms of rapid prototyping, and
then is subjected to a go/no go decision based on technology-related risk factors.
Formulations of the SATM System
In this and the next three chapters, we will relate our discussion to a higher level example, the Simple
Automatic Teller Machine (SATM) system. there are function buttons B1, B2, and B3, a digit keypad
with a cancel key, slots for printer receipts and ATM cards, and doors for deposits and cash withdrawals.
The SATM system is described here in two ways: with a structured analysis approach, and with an
object- oriented approach. These descriptions are not complete, but they contain detail sufficient to
illustrate the testing techniques under discussion.
SATM with Structured Analysis
The structured analysis approach to requirements specification is the most widely used
method in the world. It enjoys extensive CASE tool support as well as commercial training,
and is described in numerous texts. The technique is based on three complementary
models: function, data, and control. Here we use data flow diagrams for the functional
models,
 Screens for the SATM System

Screens for the SATM System

Screen 1 Welcome
Screen 2 enter PIN
Screen 3 Wrong PIN
Screen 4 PIN failed, card retained
Screen 5 Select trans type
Screen 6 Select account type
Screen 7 Enter amount
Screen 8 Insufficient funds
Screen 9 Cannot dispense that amount
Screen 10 Cannot process withdrawals
Screen 11 Take your cash
Screen 12 Cannot process deposits
Screen 13 Put dep envelop in slot
Screen 14 Another transaction?
Screen 15 Thanks, take card and receipt.
 Module 4

Levels of Testing, Integration Testing: Traditional view of testing levels, Alternative life-cycle models,
The SATM system, Separating integration and system testing, A closer look at the SATM system,
Decomposition-based, call graph-based, Path-based integrations.
T1 : Chapter 12 & 13
 Integration Testing

• Type of testing where software modules are integrated logically and

tested as a group. A typical software project consists of multiple software
modules, coded by different programmers. The purpose of this level of
testing is to expose defects in the interaction betwee these software
modules when they are integrated n
• The entire system is viewed as a collection of subsystems (sets of classes)
determined during the system and object design
• Goal: Test all interfaces between subsystems and the interaction of
subsystems
• The Integration testing strategy determines the order in which the
subsystems are selected for testing and integration.
 Why do we do integration testing?
• Unit tests only test the unit in isolation
• Many failures result from faults in the interaction of subsystems
• Often many Off-the-shelf components are used that cannot be unit tested
• Without integration testing the system test will be very time consuming
• Failures that are not discovered in integration testing will be discovered
after the system is deployed and can be very expensive.

Focuses mainly on the interfaces & flow of data/information between the

modules.
Continue…
Ex. Mail Box: Check its integration to the
Delete Mails Module.
Test Case ID Test Case Test Case Expected Result
Objective Description

Check the
interface link Enter login To be directed to
1 between the credentials and the Mail Box
Login and click on the Login
Mailbox module button

Check the
interface link From Mailbox Selected email
2 select the email should appear in
between the
Mailbox and and click a delete the Deleted/Trash
Delete Mails button folder
Module
Continue…
 Integration testing

Big bang
Bottom up
Top down
Sandwich
 Stubs and Driver
Incremental Approach is carried out by using dummy programs called Stubs and Drivers.
Stubs and Drivers do not implement the entire programming logic of the software module
but just simulate data communication with the calling module.
 INCREMENTAL TESTING IS DONE BY JOINING TWO OR MORE
MODULES THAT ARE LOGICALLY RELATED.
2 METHODS: 1.BOTTOM UP 2.TOP DOWN
Bottom-up Testing Strategy
• The subsystems in the lowest layer of the call hierarchy are tested
individually
• Then the next subsystems are tested that call the previously tested
subsystems
• This is repeated until all subsystems are included
• Drivers are needed.
Pros and Cons of Bottom-Up Integration Testing
Cons:
• Tests the most important subsystem (user interface) last
• Drivers needed
Pros:
• No stubs needed
• Useful for integration testing of the following systems
• Object-oriented systems
• Real-time systems
• Systems with strict performance requirements.
 Top-down Testing Strategy

• Test the top layer or the controlling subsystem first

• Then combine all the subsystems that are called by the tested
subsystems and test the resulting collection of subsystems
• Do this until all subsystems are incorporated into the test
• Stubs are needed to do the testing.
 Pros and Cons of Top-down Integration
Testing
Pros:
• Test cases can be defined in terms of the functionality of the system

(functional requirements)
• No drivers needed
Cons:
• Writing stubs is difficult: Stubs must allow all possible conditions to be
tested.
• Large number of stubs may be required, especially if the lowest level of
the
system contains many methods.
• Some interfaces are not tested separately.
 Sandwich Testing St rategy

• Combines top-down strategy with bo ttom-up strategy

• The system is viewed as having three layers
• A target layer in the middle
• A layer above the target
• A layer below the target
• Testing converges at the target laye r
Here, top modules are tested with lower modules at
the same time lower modules are integrated with top
modules and tested. This strategy makes use of stubs as
well as drivers
 How to do Integration Testing?

• Prepare the Integration Tests Plan

• Design the Test Scenarios, Cases, and Scripts.
• Executing the test Cases followed by reporting the defects.
• Tracking & re-testing the defects.
• Steps 3 and 4 are repeated until the completion of Integration is
successful.
Ex. 10 Binary Search SOFTWARE TESTING LAB
int main()
{
#include<stdio.h>
int binsrc(int x[],int low,int high,int key) int a[20],key,i,n,succ; printf("Enter the n value"); scanf("%d",&n);
{
if(n>0)
int mid; while(low<=high) {
{
printf("enter the elements in ascending order\n");
mid=(low+high)/2;
for(i=0;i<n;i++)
scanf("%d",&a[i]);
if(x[mid]==key)
return mid; printf("enter the key element to be searched\n");
scanf("%d",&key);
if(x[mid]<key)
low=mid+1; succ=binsrc(a,0,n-1,key); if(succ>=0)

printf("Element found in position = %d\n",succ+1);

else
high=mid-1; else
} printf("Element not found \n");
return -1; }
} else

printf("Number of element should be greater than zero\n");

return 0;
}
PATH TESTING PRECONDITIONS:
Array element is in ascending order True /False
Key element is in the array True /False Independent paths :
Array has ODD number of elements True /False
1 #Edges =11 ,#nodes= 9, #p

=1 V(G)=E-N+2P=11-9+2=4
F L<=H
2
P1: 1-2-3-8-9
T X[m] = = Key
P2: 1-2-3-4-5-7-2
3
P3: 1-2-3-4-6-7-2

T F P4: 1-2-8-9
8 X[m] > Key Inputs
X[m] < Key 4 Paths Expec Remarks
X[ ] Key ted
outp
9 5
6 ut
P1: 1-2-3-8-9 {10,20,30,40,50} 30 Success Key ∈X[ ] & Key==X[mid]

7
P2: 1-2-3-4-5- {10,20,30,40,50} 20 Repeat and Key < X[ mid] search 1st half
7-2 success
P3: 1-2-3-4-6- {10,20,30,40,50} 40 Repeat and Key >X[mid] search 2nd half
7-2 success
P4: 1-2-8-9 {10,20,30,40,50} 60 Repeat Key∉X[mid]
and
Failur
e
P5: 1-2-8-9 Empty Any key Failure Empty list
 // main program

int main()
#include<stdio.h>
void quicksort(int x[10],int first,int last) {
{ int a[20],i,key,n;
Int temp,pivot,i,j;
if(first<last)
Ex. 11 Quick Sort printf("enter the size of the array");
{
scanf("%d",&n);
pivot=first;
i=first; if(n>0)
j=last; {
while(i<j)
{ printf("enter the elements of the array");
while(x[i]<=x[pivot] && i<last) for(i=0;i<n;i++)
i++; scanf("%d",&a[i]);
while(x[j]>x[pivot])
j--; quicksort(a,0,n-1);
if(i<j) printf("the elements in the sorted array is:\n");
{
temp=x[i];
x[i]=x[j];
for(i=0;i<n;i++)
x[j]=temp;
}
printf("%d\t",a[i]);
} }
temp=x[pivot]; else
x[pivot]=x[j];
{
x[j]=temp;
quicksort(x,first,j-1); printf(“size of array is invalid\n”);
quicksort(x,j+1,last);
} }}
}
 PATH TESTING
A Initialization
Independent paths – Quick sort

P1: A-B-N
First < Last P2: A-B-C-J-K-B
B
P3: A-B-C-J-K-M-B
F T
P4: A-B-C-D-F-H-C
i<j P5: A-B-C-D-F-H-I-C
sc P6: A-B-C-D-E-D-F-H
C an
F T P7: A-B-C-D-F-G-F-H
Right scan
N J
D Independent Paths:#Edges =18, #Nodes =13, #P =1
F

T
K V (G) =E-N+2P=18-13+2=7
E Left scan
F
F
T F
i<j
M sc
an
G I
H
Recursive calls
 Path Testing
• Program graph
Given a program written in programming language, the program graph
is a directed graph in which nodes are statement fragments and edges
represent flow of control.
DD Path: Decision to Decision Path-Path of nodes in a directed graph
 1
Independent Paths:
#Edges=25, #Nodes=18, #P=1
2 V(G)= E-N+2P = 25-18+2 = 09
3
P1: 1-2-4-6-8-10-11-17-19-20 E Grade
P2: 1-2-4-6-8-9-11-16-19-20 D Grade
4
P3: 1-2-4-6-7-11-15-19-20 C Grade
P4: 1-2-4-5-11-14-19-20 B Grade
5
P5: 1-2-3-11-13-19-20 A Grade
6
P6: 1-2-4-6-8-10-11-13-19-20
P7: 1-2-4-6-8-10-11-14-19-20
7
8
P8: 1-2-4-6-8-10-11-15-19-20
P9: 1-2-4-6-8-10-11-16-19-20

9
10
Paths Input per Expected output Remarks
P1:1-2-4-6-8-10-11-17-19-20 < 60 E grade , satisfactory Pass
11 P2:1-2-4-6-8-9-11-16-19-20 60-69 D grade , Above average Pass
P3:1-2-4-6-7-11-15-19-20 70-79 C grade ,good Pass
P4:1-2-4-5-11-14-19-20 80-89 B grade , very good Pass
13 14 15 16 17 P5:1-2-3-11-13-19-20 >=90 A grade , excellent Pass
P6:1-2-4-6-8-10-11-13-19-20 < 60 Excellent Pass
P7: 1-2-4-6-8-10-11-14-19-20 < 60 Very good Pass
19 P8: 1-2-4-6-8-10-11-15-19-20 < 60 Good Pass
P9: 1-2-4-6-8-10-11-16-19-20 < 60 Above average Pass
Nodes 2 through 10 nested if else-the-else constructs,
20
corresponding to the single-entry, single-exit criteria.
Structural Testing: Path Testing No loops exist, so this is a directed acyclic graph.
Continue…
Regression
Continue…
Continue…
Continue…
Continue…
Continue…
 LEVELS OF TESTING, INTEGRATION
TESTING : Traditional View of
Testing Levels
The traditional model of software development is the Waterfall model, which is drawn as a V
 Continue…
• Figure 4.2 contains a partial functional decomposition of our ATM system.
With this decomposition. top-down integration would begin with the main
program, checking the calls to the three next level procedures (Terminal I/O,
ManageSessions, and ConductTransactions).
• Following the tree ,the ManageSessions procedure would be tested, and then
the CardEntry, PIN Entry, and SelectTransaction procedures. In each case, the
actual code for lower level units is replaced by a stub, which is a throw-away
piece of code that takes the place of the actual code.
• Bottomup integration would be the opposite sequence, starting with the
CardEntry, PIN Entry,and SelectTransaction procedures, and working up toward
the main program. In bottom-up integration, units at higher levels are
replaced by drivers (another form of throw-away code) that emulate the
procedure calls.
 Alternative Life Cycle Models
• There are three mainline derivatives of the waterfall model:
incremental development, evolutionary development, and the Spiral
model.
• Each of these involves a series of increments or builds, as shown in
Figure 4.3. Within a build, the normal waterfall phases from detailed
design through testing occur, with one important difference: system
testing is split into two steps, regression and progression testing.
 Continue…

• The differences among the three spin-off models are due to how the builds are
identified. In incremental development, the motivation for separate builds is
usually to level off the staff profile. With pure waterfall development, there can
be a huge bulge of personnel for the phases from detailed design through unit
testing. Most organizations cannot support such rapid staff fluctuations, so the
system is divided into builds that can be supported by existing personnel.
• In evolutionary development, there is still the presumption of a build sequence,
but only the first build is defined. Based on it, later builds are identified, usually
in response to priorities set by the customer/user, so the system evolves to
meet the changing needs of the user.
• The spiral model is a combination of rapid prototyping and evolutionary
development, in which a build is defined first in terms of rapid prototyping, and
then is subjected to a go/no go decision based on technology-related risk
factors. From this we see that keeping preliminary design as an integral step is
difficult for the evolutionary and spiral models.
Formulations of the SATM System
In this and the next three chapters, we will relate our discussion to a higher level example, the Simple Automatic Teller Machine (SATM)
system. there are function buttons B1, B2, and B3, a digit keypad with a cancel key, slots for printer receipts and ATM cards, and doors for
deposits and cash withdrawals. The SATM system is described here in two ways: with a structured analysis approach, and with an object-
oriented approach. These descriptions are not complete, but they contain detail sufficient to illustrate the testing techniques under
discussion.
SATM with Structured Analysis
The structured analysis approach to requirements specification is the most widely used method in the world. It enjoys extensive CASE tool
support as well as commercial training, and is described in numerous texts. The technique is based on three complementary models:
function, data, and control. Here we use data flow diagrams for the functional models,
 Screens for the SATM System

Screens for the SATM System

Screen 1 Welcome
Screen 2 enter PIN
Screen 3 Wrong PIN
Screen 4 PIN failed, card retained
Screen 5 Select trans type
Screen 6 Select account type
Screen 7 Enter amount
Screen 8 Insufficient funds
Screen 9 Cannot dispense that amount
Screen 10 Cannot process withdrawals
Screen 11 Take your cash
Screen 12 Cannot process deposits
Screen 13 Put dep envelop in slot
Screen 14 Another transaction?
Screen 15 Thanks, take card and receipt.
Department of Information Science and Engineering

Course Name : Software Testing

Course Code : 18IS62

By,
Shruthi P,
Assistant
Professor,
Dept of ISE,
 Module 5
Integration and Component-Based Software Testing: Overview, Integration testing strategies, Testing components and assemblies.
System, Acceptance and Regression Testing: Overview, System testing, Acceptance testing, Usability, Regression testing, Regression test
selection techniques, Test case prioritization and selective execution.

Levels of Testing, Integration Testing: Traditional view of testing levels, Alternative life-cycle models, The SATM system, Separating
integration and system testing, A closer look at the SATM system, Decomposition-based, call graph-based, Path-based integrations.
T2: Chapter 21 & 22, T1 : Chapter 12 & 13
 Integration Testing

• Type of testing where software modules are integrated logically and

tested as a group. A typical software project consists of multiple software
modules, coded by different programmers. The purpose of this level of
testing is to expose defects in the interaction betwee these software
modules when they are integrated n
• The entire system is viewed as a collection of subsystems (sets of classes)
determined during the system and object design
• Goal: Test all interfaces between subsystems and the interaction of
subsystems
• The Integration testing strategy determines the order in which the
subsystems are selected for testing and integration.
 Why do we do integration
testing?
• Unit tests only test the unit in isolation
• Many failures result from faults in the interaction of subsystems
• Often many Off-the-shelf components are used that cannot be unit tested
• Without integration testing the system test will be very time consuming
• Failures that are not discovered in integration testing will be discovered
after the system is deployed and can be very expensive.

Focuses mainly on the interfaces & flow of data/information between the

modules.
Continue…
Ex. Mail Box: Check its integration to the
Delete Mails Module.
Test Case ID Test Case Test Case Expected Result
Objective Description

Check the
interface link Enter login To be directed to
1 between the credentials and the Mail Box
Login and click on the Login
Mailbox module button

Check the
interface link From Mailbox Selected email
2 select the email should appear in
between the
Mailbox and and click a delete the Deleted/Trash
Delete Mails button folder
Module
Continue…
 Integration testing

Big bang
Bottom up
Top down
Sandwich
 Stubs and Driver
Incremental Approach is carried out by using dummy programs called Stubs and Drivers.
Stubs and Drivers do not implement the entire programming logic of the software module
but just simulate data communication with the calling module.
 INCREMENTAL TESTING IS DONE BY JOINING TWO OR MORE
MODULES THAT ARE LOGICALLY RELATED.
2 METHODS: 1.BOTTOM UP 2.TOP DOWN
Bottom-up Testing Strategy
• The subsystems in the lowest layer of the call hierarchy are tested
individually
• Then the next subsystems are tested that call the previously tested
subsystems
• This is repeated until all subsystems are included
• Drivers are needed.
Pros and Cons of Bottom-Up Integration Testing
Cons:
• Tests the most important subsystem (user interface) last
• Drivers needed
Pros:
• No stubs needed
• Useful for integration testing of the following systems
• Object-oriented systems
• Real-time systems
• Systems with strict performance requirements.
 Top-down Testing Strategy

• Test the top layer or the controlling subsystem first

• Then combine all the subsystems that are called by the tested
subsystems and test the resulting collection of subsystems
• Do this until all subsystems are incorporated into the test
• Stubs are needed to do the testing.
 Pros and Cons of Top-down
Integration
Testing
Pros:
• Test cases can be defined in terms of the functionality of the system

(functional requirements)
• No drivers needed
Cons:
• Writing stubs is difficult: Stubs must allow all possible conditions to be
tested.
• Large number of stubs may be required, especially if the lowest level of
the
system contains many methods.
• Some interfaces are not tested separately.
 Sandwich Testing St rategy

• Combines top-down strategy with bo ttom-up strategy

• The system is viewed as having three layers
• A target layer in the middle
• A layer above the target
• A layer below the target
• Testing converges at the target laye r
Here, top modules are tested with lower modules at
the same time lower modules are integrated with top
modules and tested. This strategy makes use of stubs as
well as drivers
Continue…
Continue…
Continue…
Continue…
Continue…
Continue…
Continue…
 How to do Integration Testing?

• Prepare the Integration Tests Plan

• Design the Test Scenarios, Cases, and Scripts.
• Executing the test Cases followed by reporting the defects.
• Tracking & re-testing the defects.
• Steps 3 and 4 are repeated until the completion of Integration is
successful.
Ex. 10 Binary Search SOFTWARE TESTING LAB
int main()
{
#include<stdio.h>
int binsrc(int x[],int low,int high,int key) int a[20],key,i,n,succ; printf("Enter the n value"); scanf("%d",&n);
{
if(n>0)
int mid; while(low<=high) {
{
printf("enter the elements in ascending order\n");
mid=(low+high)/2;
for(i=0;i<n;i++)
scanf("%d",&a[i]);
if(x[mid]==key)
return mid; printf("enter the key element to be searched\n");
scanf("%d",&key);
if(x[mid]<key)
low=mid+1; succ=binsrc(a,0,n-1,key); if(succ>=0)

printf("Element found in position = %d\n",succ+1);

else
high=mid-1; else
} printf("Element not found \n");
return -1; }
} else

printf("Number of element should be greater than zero\n");

return 0;
}
PATH TESTING PRECONDITIONS:
Array element is in ascending order True /False
Key element is in the array True /False Independent paths :
Array has ODD number of elements True /False
1 #Edges =11 ,#nodes= 9, #p

=1 V(G)=E-N+2P=11-9+2=4
F L<=H
2
P1: 1-2-3-8-9
T X[m] = = Key
P2: 1-2-3-4-5-7-2
3
P3: 1-2-3-4-6-7-2

T F P4: 1-2-8-9
8 X[m] > Key Inputs
X[m] < Key 4 Paths Expec Remarks
X[ ] Key ted
outp
9 5
6 ut
P1: 1-2-3-8-9 {10,20,30,40,50} 30 Success Key ∈X[ ] & Key==X[mid]

7
P2: 1-2-3-4-5- {10,20,30,40,50} 20 Repeat and Key < X[ mid] search 1st half
7-2 success
P3: 1-2-3-4-6- {10,20,30,40,50} 40 Repeat and Key >X[mid] search 2nd half
7-2 success
P4: 1-2-8-9 {10,20,30,40,50} 60 Repeat Key∉X[mid]
and
Failur
e
P5: 1-2-8-9 Empty Any key Failure Empty list
 // main program
Ex. 11 Quick Sort
#include<stdio.h>
void quicksort(int x[10],int first,int last) int main()
{ {
Int temp,pivot,i,j;
if(first<last) int a[20],i,key,n;
{
pivot=first; printf("enter the size of the array");
i=first; scanf("%d",&n);
j=last; if(n>0)
while(i<j)
{
{
while(x[i]<=x[pivot] && i<last) printf("enter the elements of the array");
i++;
for(i=0;i<n;i++)
while(x[j]>x[pivot])
j--; scanf("%d",&a[i]);
if(i<j) quicksort(a,0,n-1);
{
temp=x[i];
printf("the elements in the sorted array is:\n");
x[i]=x[j];
x[j]=temp;
} for(i=0;i<n;i++)
} printf("%d\t",a[i]);
temp=x[pivot];
}
x[pivot]=x[j];
x[j]=temp;
else
quicksort(x,first,j-1); {
quicksort(x,j+1,last);
} printf(“size of array is invalid\n”);
} }}
 PATH TESTING
A Initialization
Independent paths – Quick sort

P1: A-B-N
First < Last P2: A-B-C-J-K-B
B
P3: A-B-C-J-K-M-B
F T
P4: A-B-C-D-F-H-C
i<j P5: A-B-C-D-F-H-I-C
sc P6: A-B-C-D-E-D-F-H
C an
F T P7: A-B-C-D-F-G-F-H
Right scan
N J
D Independent Paths:#Edges =18, #Nodes =13, #P =1
F

T
K V (G) =E-N+2P=18-13+2=7
E Left scan
F
F
T F
i<j
M sc
an
G I
H
Recursive calls
 Path Testing

• Program graph
Given a program written in programming language, the program graph
is a directed graph in which nodes are statement fragments and edges
represent flow of control.
DD Path: Decision to Decision Path-Path of nodes in a directed graph
Ex. 12 Design, develop, code and run the program in any suitable language to implement
1
an absolute letter grading procedure, making suitable assumptions. Determine the basis
paths and using them derive different test cases, execute these test cases and discuss the
test results.
switch(grade) 2
int main()
#include<stdio.h>
3
{
printf("\nEXCELLENT"); 4
{ case 'A':
5
char break;"); 6
printf("\nVerygood
float per; case 'B': 7
8

grade;
grade= 'A'; break; break; 10
9

scanf("%f",&per); case 'C' :

else if(per>=70 && per<80)
if(per>=90) break; 11

else if(per>=60 && per<70) case 'E': printf("\nGoo

d"); 14
15
13 16 1
7

else if(per>=80 && per<90) case 'D':

grade ='B';

printf("\nAbov
eAverage");
 1
Independent Paths:
#Edges=25, #Nodes=18, #P=1
2 V(G)= E-N+2P = 25-18+2 = 09
3
P1: 1-2-4-6-8-10-11-17-19-20 E Grade
P2: 1-2-4-6-8-9-11-16-19-20 D Grade
4
P3: 1-2-4-6-7-11-15-19-20 C Grade
P4: 1-2-4-5-11-14-19-20 B Grade
5
P5: 1-2-3-11-13-19-20 A Grade
6
P6: 1-2-4-6-8-10-11-13-19-20
P7: 1-2-4-6-8-10-11-14-19-20
7
8
P8: 1-2-4-6-8-10-11-15-19-20
P9: 1-2-4-6-8-10-11-16-19-20

9
10
Paths Input per Expected output Remarks
P1:1-2-4-6-8-10-11-17-19-20 < 60 E grade , satisfactory Pass
11 P2:1-2-4-6-8-9-11-16-19-20 60-69 D grade , Above average Pass
P3:1-2-4-6-7-11-15-19-20 70-79 C grade ,good Pass
P4:1-2-4-5-11-14-19-20 80-89 B grade , very good Pass
13 14 15 16 17 P5:1-2-3-11-13-19-20 >=90 A grade , excellent Pass
P6:1-2-4-6-8-10-11-13-19-20 < 60 Excellent Pass
P7: 1-2-4-6-8-10-11-14-19-20 < 60 Very good Pass
19 P8: 1-2-4-6-8-10-11-15-19-20 < 60 Good Pass
P9: 1-2-4-6-8-10-11-16-19-20 < 60 Above average Pass
Nodes 2 through 10 nested if else-the-else constructs,
20
corresponding to the single-entry, single-exit criteria.
Structural Testing: Path Testing No loops exist, so this is a directed acyclic graph.
System, Acceptance and Regression
Testing
Continue…
System Testing process
Continue…
Continue…
Continue…
Continue…
Continue…
Acceptance Testing
Acceptance Testing
Continue…
Regression
Continue…
Continue…
Continue…
Continue…
Continue…