0% found this document useful (0 votes)
176 views

Software Engineering Document

The document describes a project report for a railway reservation system created by three group members. It includes an introduction describing the current manual reservation system and need for the proposed online system. The analysis section covers requirements analysis, including functional requirements like viewing train times, reserving and paying for tickets, and canceling tickets. Non-functional requirements addressed include performance, reliability, availability, usability, security and meeting deadlines and budgets. Diagrams and models created for the system are also listed.

Uploaded by

Bharath Bunny
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
176 views

Software Engineering Document

The document describes a project report for a railway reservation system created by three group members. It includes an introduction describing the current manual reservation system and need for the proposed online system. The analysis section covers requirements analysis, including functional requirements like viewing train times, reserving and paying for tickets, and canceling tickets. Non-functional requirements addressed include performance, reliability, availability, usability, security and meeting deadlines and budgets. Diagrams and models created for the system are also listed.

Uploaded by

Bharath Bunny
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 27

SOFTWARE ENGINEERING

Project Report On
Railway Reservation System

GROUP MEMBERS:

 N.NAVEEN REDDY 18BCE1036


 ANUPAM REDDY 18BCE1172
 BHARATH SAI 18BCE1264
Contents
INTRODUCTION
a. Current system
b. Need of proposed system
ANALYSIS
a. Requirement analysis
b. Requirement Specification

FUNCTIONAL REQUIREMENTS.

NON-FUNCTIONAL REQUIREMENTS.

ER DIAGRAM.

USE CASE DIAGRAM.

ACTIVITY DIAGRAM.

SEQUENCE DIAGRAM.

TASK ANALYSIS CHART.

USE CASE ESTIMATION.

CLASS DIAGRAM.

DEPLOYMENT DIAGRAM.

SAMPLE CODE.

TESTING:

1. Black box test case.


2. White box test case.
Introduction

This system is basically concerned with the reservation and cancellation of railway
tickets to the passengers. The need of this system arose because as is the known
fact that India has the largest railway network in the whole of the world and to
handle it manually is quite a tough job. The long distance road network is very
poorly developed in most parts of India. Bulk of long distance traffic is carried by
the Indian Railway as a result Indian railways. Therefore forms a backbone of
public transport in India. The efficiency of the railway will increase result of
computerization due to dramatic reduction in communication time among
geographically dispersed offices. For the reservation of the ticket a person go to
ticket counter of the railway reservation office and expend its valuable time in
standing queue. Now to save that time we have a facility of Online Reservation
now we can book cancel or search other train information just by click on
computer.

Need of proposed system


 To reduce complexity of existing system.
 Effective management of time.
 To make work easy, simple and error free.
 Effective utilization of available resource.
 To enhance the efficiency and diversification of services activities.
 User friendly.
 Interactive graphical user interface.
 The scope of project define the project feasibility

Analysis
a.REQUIREMENT ANALYSIS:
Requirements are a feature of a system or description of something that is
capable of doing in order to fulfill the system s purpose. It provides the ’
appropriate mechanism for understanding what the customer wants, analyzing
the needs, assessing feasibility, negotiating a solution, specifying the solution
unambiguously, validating the specification and managing the requirements as
they are translated into an operational system. Requirement Analysis is a task
done under software engineering and software design. While requirements
engineering specifies software s operational characteristics i.e. function, data ’
behavior, indicates software s interface constraints, requirements analysis let the
’ software engineer (called analysis) to refine the software allocation and
construct models of data, functional and behavioral domains. Moreover,
requirements analysis provides software developer with a representation of data,
function and behavior that can be converted to data, architectural, interface and
component- level designs. At last, we can say that the requirement specification
makes available, the developer and the customer, a means to assess quality, once
the software has been built.

Software requirements analysis can be categorized into four areas of effort, as


follows-
 Evaluation and synthesis
 Modeling
 Specification
 Review

The analyst starts with the studies of system specification and the software
project plan. It is then important to understand the software in a system context.
Also, the review of the software scope, used to generate planning estimate, is
necessary. Next, communication for analysis must be established, so as to ensure
problem recognition. The reason behind is to recognize the basic problem
elements perceived by customer.
The next major area of effort for analysis is problem evaluation and
solution synthesis. The engineer (or analyst) must define all data objects that are
extremely observable. He must evaluate the content and flow of information.
Also, he must define and describe all software functions, understand software
behavior in the context of the system affected events, establish the
characteristics of system interface, and uncover additional design constraints.
After evaluating the current problems and desired information (i.e., input and
output), the engineer and analyst synthesizing one or more solutions. Initially, the
data objects, processing functions and the system behavior are defined in detail.
Once establishing this information, the analyst then considers basic architectures
for implementation. Thus the process of evaluation and synthesis proceeds until
both analyst and the customer are sure that software can be adequately specified
for subsequent development steps.
During the evaluation and synthesis activity, the analyst creates the system model
so as to better understand data and control flow, functional
processing,operational behavior and the information content. The model provides
a base forsoftware design and the creation of specifications for the software.

b.REQUIREMENT SPECIFICATIONS:
A Software Requirements Specification (SRS) is a complete
description of the behavior of the system to be developed. It includes a set
of use case that describes all the interactions that the users will have with
the software. Use cases are also known as Functional Requirements. Non-
Functional Requirements are requirements which impose constraints on
the design or implementation (such as performance requirements, quality
standards, or design constraints).

FUNCTIONAL REQUIREMENTS:
In software engineering, a functional requirement defines a function of a
software-system or component. A function is described as a set of inputs,
the behavior and outputs. Functional requirements may be calculations,
technical details, data manipulation and processing and other specific
functionality that show how a use case to be fulfilled.
Typically, a requirements analyst generates functional requirements after
building use cases. However, this may have exceptions since software
development is an iterative process and sometime certain requirements are
conceived prior to the definition of the use case. Both artifacts (use cases
documents and requirements documents) complement each other in a
bidirectional process.
A typical functional requirement will contain a unique name and number, a
brief summary, and a rationale. This information is used to help the reader
understand why the requirement is needed, and to track the requirement
through the development of the system.

1 - TRAIN DETAILS:
Customers may view the train timing at a date their name and number of
tickets.
2– RESERVATION:
After checking the number of seats available the customers reserve the
tickets.
3 – BILLING:
After reserving the required amount of tickets, the customer paid the
amount.
4 – CANCELLATION:
If the customers want to cancel the ticket, then half of the amount paid by
the customer will
be refunded to him.
5 – PERFORMANCE REQUIREMENTS:
It is available during all 2
6 – SOFTWARE SYSTEM ATTRIBUTES:
NON-FUNCTIONAL REQUIREMENTS:
In systems engineering and requirements engineering, non-functional
requirements are requirements which specify criteria that can be used to
judge the operation of system, rather than specific behaviors. Non-
functional requirements are often called qualities of a system. Other terms
for non-functional requirements are "constraints", "quality attributes",
"quality goals" and "quality of service requirements .́ Qualities, i.e. non-
functional requirements can be divided into 2 main categories:
a. Execution qualities, such as security and usability, are observable
at runtime.
b. Evolution qualities, such as extensibility and scalability, embody in
the static structure of the software system.

The nonfunctional requirements in our projects are:-


Time:-
The project should be completed within the stipulated time period.
Cost:-
The cost involved in marketing the project should be less.
Usability:-
This requirement is present, as this system will interact with user.
Performance:-
This system helps in increasing the overall performance of the Railway
Reservation functionality by shifting a large chunk of load online causing in
less hassle in ticket booking, cancellation or querying. This System is 22
hours Live per day giving us greater availability time as compared to that of
9 hours offline activity.
Reliability:-
The Reliability of the overall project depends on the reliability of the
separate components. The main pillar of reliability of the system is the
backup of the database which is continuously maintained and updated to
reflect the most 21recent changes. Also, the system will be functioning
inside a container. Thus, the overall stability of the system depends on the
stability of container and its underlying operating system.
Availability:-
The system should be available at all times, meaning the user can access it
using a web browser, only restricted by the down time of the server on
which the system runs. A customer friendly system which is in access of
people around the world should work 24 hours. In case of a hardware
failure or database corruption, a replacement page will be shown. Also, in
case of a hardware failure or database corruption, backup of the database
should be retrieved from the server and saved by the Organizer. Then the
service will be restarted. It means 24x7 availability.
Security:-
This system should work under 3-Level Architecture combining DB-Class-
Front end with different security facilities and encryption. The System use
SSL in all transactions that include any confidential customer information.
The system must automatically log out all customer after a period of
inactivity of those users respectively. The system should not leave any
cookies on the customer’s computer containing the user’s password. The
system’s back-end servers shall only be accessible to authenticated
management.
Maintainability:-
A commercial database is used for maintaining the database and the
application server takes care of the site. In case of a failure, a re-
initialization 22of the project will be done. Also the software design is being
done with modularity in mind so that maintainability can be done efficiently.
Supportability:-
The code and supporting modules of the system will be well documented
and easy to understand. Online user Documentation and Help system
requirements.
Performance:-
It should be fast enough to produce the output.
ER Diagram
E-R diagram is a relationship between two entity sets. E-R diagram can
express the overallstructure of a database graphically. E-R diagrams are
simple and clear. E-R diagram consistsof the following major components:

Rectangles, which represents entity set.


Double rectangles, which represent weak entity set.
Ellipse, which represents attribute
Diamonds, which represent relationship sets.
Lines, which link attributes to entity sets and entity sets to relationship sets.
Double lines, which represents total participation of an entity relationship
set.

Double ellipse, which represent multivalued attributes.


Dashed ellipse, which denote derived attribute.
The traditional approach to system development places a great deal of
emphasis on datastorage requirements for the new system. Data storage
requirements include the data entities,their attributes, and the relationships
among the data entities. The model used todefine thedata storage
requirements is called the Entity-Relationship Diagram.
E-R DIAGRAM:
USE CASE DIAGRAM:
A use is a description of a system s behavior as it responds to a request
that originates from outside of that system. The use case technique is used
insoftware and system engineering to capture the functional requirements
of asystem. Use cases describe the interaction between a primary actor-
the initiator ofthe interaction- and the system itself, represented as a
sequence of simple steps.Actors are something or someone which exists
outside the system under study,and that takes part in a sequence of
activities in a dialogue with a system, toachieve some goal: they may be
end users, other systems, or hardware devices.Each use case is a
complete series of events, describes from the point view of theactor.
USE CASE NAME:
A use case name provides unique identifiers for the use case. It
should be written in verb-noun format, should describe an achievable goal
and should be sufficient for the end user to understand what the use case
is about.
GOALS:
Without a goal a use case is useless. There is no need for a use case
when there is no need for any actor to achieve a goal. A briefly describes
what the user intends to achieve with this use case.
ACTORS:
An actor is someone or something outside the system that either acts
on the system- a primary actor - or is acted on by the system- a secondary
actor. An actor may be a person, a device, another system, or time. Actors
represent the different roles that something outside has in its relationship
with the system whose functional requirements are being specified. An
individual in the real world can be represented by several actors if they
have different roles and goals in regards to a system.
PRECONDITIONS:
A preconditions section defines all the condition that must be true
(i.e., describes the state of the system) for the trigger to meaningfully cause
the initiation of the use case. That is, if the state describes in the
preconditions, the behavior of the use case is indeterminate.
POSTCONDITION:
The post conditions section describes what the change in the state
of the system will be after the use case completes. Post conditions are
guaranteed to be true when the use case ends.
USE CASE DIAGRAM FOR ONLINE RAILWAY RESERVARION SYSTEM
ACTIVITY DIAGRAM:
Activity Diagrams describe how activities are coordinated to provide a
service which can be at different levels of abstraction. Typically, an event
needs to be achieved by some operations, particularly where the
operation is intended to achieve a number of different things that require
coordination, or how the events in a single use case relate to one another,
in particular, use cases where activities may overlap and require
coordination. It is also suitable for modeling how a collection of use cases
coordinate to represent business workflows
SEQUENCE DIAGRAM:
Sequence Diagram is an interaction diagram that details how operations
are carried out -- what messages are sent and when. Sequence diagrams
are organized according to time. The time progresses as you go down the
page. The objects involved in the operation are listed from left to right
according to when they take part in the message sequence.
CLASS DIAGRAM:
Class diagrams are the main building blocks of every object oriented
methods. The class diagram can be used to show the classes,
relationships, interface, association, and collaboration. UML is standardized
in class diagrams. Since classes are the building block of an application
that is based on OOPs, so as the class diagram has appropriate structure
to represent the classes, inheritance, relationships, and everything that
OOPs have in its context. It describes various kinds of objects and the
static relationship in between them.
The main purpose to use class diagrams are:
 This is the only UML which can appropriately depict various aspects of
OOPs concept.
 Proper design and analysis of application can be faster and efficient.
 It is base for deployment and component diagram.
DEPLOYMENT DIAGRAM:
Deployment diagram is a diagram that shows the configuration of run time
processing nodes and the components that live on them. Deployment
diagrams is a kind of structure diagram used in modeling the physical
aspects of an object-oriented system. They are often be used to model
the static deployment view of a system (topology of the hardware).
When to Use Deployment Diagram:
 What existing systems will the newly added system need to interact
or integrate with?
 How robust does system need to be (e.g., redundant hardware in
case of a system failure)?
 What and who will connect to or interact with system, and how will
they do it
 What middleware, including the operating system and
communications approaches and protocols, will system use?
 What hardware and software will users directly interact with (PCs,
network computers, browsers, etc.)?
 How will you monitor the system once deployed?
 How secure does the system needs to be (needs a firewall,
physically secure hardware, etc.)?
Purpose of Deployment Diagrams
 They show the structure of the run-time system
 They capture the hardware that will be used to implement the
system and the links between different items of hardware.
 They model physical hardware elements and the communication
paths between them
 They can be used to plan the architecture of a system.
 They are also useful for Document the deployment of software
components or nodes
SAMPLE CODE:
#include<stdio.h>
#include<conio.h>
#include<stdlib.h>
#include<string.h>
typedef struct{
char name[50];
int train_num;
int num_of_seats;
}pd;
void reservation(void);//main reservation function
void viewdetails(void);//view details of all the trains
void cancel(void); void printticket(char
name[],int,int,float);//print ticket
void specifictrain(int);//print data related to specific train
float charge(int,int);
//charge automatically w.r.t number of seats and train
void login();
int main()

{
printf(" \n Press any key to continue:");
getch();
system("cls");
login();
int menu_choice,choice_return;
start:
system("cls");
printf("\n=================================\n");
printf(" TRAIN RESERVATION SYSTEM");
printf("\n=================================");
printf("\n1>> Reserve A Ticket");
printf("\n------------------------");
printf("\n2>> View All Available Trains");
printf("\n------------------------");
printf("\n3>> Cancel Reservation");
printf("\n------------------------");
printf("\n4>> Exit");
printf("\n------------------------");
printf("\n\n-->");
scanf("%d",&menu_choice);
switch(menu_choice)
{
case 1:
reservation()//Fucntion still not added
break;
case 2:
viewdetails();
printf("\n\nPress any key to go to Main Menu..");
getch();
break;
case 3:
cancel();
//function not added. code has been removed due to some errors
break;
case 4:
return(0);
default:
printf("\nInvalid choice");
}
goto start;
return(0);
}
void viewdetails(void)
{
system("cls");
printf("-----------------------------------------------------------
------------------");
printf("\nTr.No\tName\t\t\tDestinations\t\tCharges\t\tTime\n");
printf("-----------------------------------------------------------
------------------");
printf("\n1001\tRed Lines Express\tBoston to
Manhattan\tRs.5000\t\t9am");
printf("\n1002\tRed Lines Express\tManhattan To
Boston\tRs.5000\t\t12pm");
printf("\n1003\tLA City Express\t\tBoston To
L.A\t\tRs.4500\t\t8am");
printf("\n1004\tLA City Express\t\tL.A To
Boston\t\tRs.4500\t\t11am");
printf("\n1005\tIron City Express\tBoston To
Chicago\tRs.4000\t\t7am");
printf("\n1006\tIron City Express\tChicago To
Boston\tRs.4000\t\t9.30am");
printf("\n1007\tKeystone Express\tBoston To
Washington\tRs.3500\t\t1pm");
printf("\n1008\tKeystone Express\tWashington To
Boston\tRs.3500\t\t4pm");
printf("\n1009\tMeteor Express\t\tBoston To
Miami\t\tRs.6000\t\t3.35pm");
printf("\n1009\tMeteor Express\t\tMiami To
Boston\t\tRs.6000\t\t4.15pm");

}
void reservation(void)
{
char confirm;
int i=0;
float charges;
pd passdetails;
FILE *fp;
fp=fopen("seats_reserved.txt","a");
system("cls");

printf("\nEnter Your Name:> ");


fflush(stdin);
gets(passdetails.name);
//error here have to take input of the name
printf("\nEnter Number of seats:> ");
scanf("%d",&passdetails.num_of_seats);
printf("\n\n>>Press Enter To View Available Trains<< ");
getch();
system("cls");
viewdetails();
printf("\n\nEnter train number:> ");
start1:
scanf("%d",&passdetails.train_num);
if(passdetails.train_num>=1001 && passdetails.train_num<=1010)
{

charges=charge(passdetails.train_num,passdetails.num_of_seats);

printticket(passdetails.name,passdetails.num_of_seats,passdetails.t
rain_num,charges);
}
else
{
printf("\nInvalid train Number! Enter again--> ");
goto start1;
}

printf("\n\nConfirm Ticket (y/n):>");


start:
scanf(" %c",&confirm);
if(confirm == 'y')
{

fprintf(fp,"%s\t\t%d\t\t%d\t\t%.2f\n",&passdetails.name,passdetails
.num_of_seats,passdetails.train_num,charges);
printf("==================");
printf("\n Reservation Done\n");
printf("==================");
printf("\nPress any key to go back to Main menu");
}
else
{
if(confirm=='n'){
printf("\nReservation Not Done!\nPress any key to go
back to Main menu!");
}
else
{
printf("\nInvalid choice entered! Enter again----->
");
goto start;
}
}
fclose(fp);
getch();
}
float charge(int train_num,int num_of_seats)
{
if (train_num==1001)
{
return(5000.0*num_of_seats);
}
if (train_num==1002)
{
return(5000.0*num_of_seats);
}
if (train_num==1003)
{
return(4500.0*num_of_seats);
}
if (train_num==1004)
{
return(4500.0*num_of_seats);
}
if (train_num==1005)
{
return(4000.0*num_of_seats);
}
if (train_num==1006)
{
return(4000.0*num_of_seats);
}
if (train_num==1007)
{
return(3500.0*num_of_seats);
}
if (train_num==1008)
{
return(3500.0*num_of_seats);
}
if (train_num==1009)
{
return(6000.0*num_of_seats);
}
if (train_num==1010)
{
return(6000.0*num_of_seats);
}
}
void printticket(char name[],int num_of_seats,int train_num,float charges)
{
system("cls");
printf("-------------------\n");
printf("\tTICKET\n");
printf("-------------------\n\n");
printf("Name:\t\t\t%s",name);
printf("\nNumber Of Seats:\t%d",num_of_seats);
printf("\nTrain Number:\t\t%d",train_num);
specifictrain(train_num);
printf("\nCharges:\t\t%.2f",charges);
}
void specifictrain(int train_num)
{
if (train_num==1001)
{
printf("\nTrain:\t\t\tRed Lines Express");
printf("\nDestination:\t\tBoston to Manhattan");
printf("\nDeparture:\t\t9am ");
}
if (train_num==1002)
{
printf("\nTrain:\t\t\tRed Lines Express");
printf("\nDestination:\t\tManhattan to Boston");
printf("\nDeparture:\t\t12pm");
}
if (train_num==1003)
{
printf("\nTrain:\t\t\tLA City Express");
printf("\nDestination:\t\tBoston to L.A");
printf("\nDeparture:\t\t8am");
}
if (train_num==1004)
{
printf("\nTrain:\t\t\tLA City Express");
printf("\nDestination:\t\tL.A to Boston");
printf("\nDeparture:\t\t11am ");
}
if (train_num==1005)
{
printf("\nTrain:\t\t\tIron City Express");
printf("\nDestination:\t\tBoston to Chicago");
printf("\nDeparture:\t\t7am");
}
if (train_num==1006)
{
printf("\ntrain:\t\t\tIron City Express");
printf("\nDestination:\t\tChicago to Boston");
printf("\nDeparture:\t\t9.30am ");
}
if (train_num==1007)
{
printf("\ntrain:\t\t\tKeystone Express");
printf("\nDestination:\t\tBoston to Washington");
printf("\nDeparture:\t\t1pm ");
}
if (train_num==1008)
{
printf("\ntrain:\t\t\tKeystone Express");
printf("\n Destination:\t\tWashington to Boston");
printf("\nDeparture:\t\t4pm ");
}
if (train_num==1009)
{
printf("\ntrain:\t\t\tMeteor Express");
printf("\nDestination:\t\tBoston to Miami");
printf("\nDeparture:\t\t3.35pm ");
}
if (train_num==1010)
{
printf("\ntrain:\t\t\tMeteor Express");
printf("\nDestination:\t\tMiami to Boston");
printf("\nDeparture:\t\t1.15 ");
}
}

void login()
{
int a=0,i=0;
char uname[10],c=' ';
char pword[10],code[10];
char user[10]="user";
char pass[10]="pass";
do
{

printf("\n ======================= LOGIN FORM


=======================\n ");
printf(" \n ENTER USERNAME:-");
scanf("%s", &uname);
printf(" \n ENTER PASSWORD:-");
while(i<10)
{
pword[i]=getch();
c=pword[i];
if(c==13) break;
else printf("*");
i++;
}
pword[i]='\0';
i=0;
if(strcmp(uname,"user")==0 && strcmp(pword,"pass")==0)
{
printf(" \n\n\n WELCOME TO OUR SYSTEM !! YOUR LOGIN IS
SUCCESSFUL");
printf("\n\n\n\t\t\t\tPress any key to continue...");
getch();//holds the screen
break;
}
else
{
printf("\n SORRY !!!! LOGIN IS UNSUCESSFUL");
a++;

getch();//holds the screen


system("cls");
}
}
while(a<=2);
if (a>2)
{
printf("\nSorry you have entered the wrong username and
password for four times!!!");

getch();

}
system("cls");
}

void cancel(void) /* Sorry this function does not work. Coding is not
completed. Codes have been removed due to some errors */
{
system("cls");
int trainnum;
printf("-----------------------\n");
printf("Enter the train number: \n");
printf("-----------------------\n");
fflush(stdin);
scanf("%i",&trainnum);
printf("\n\nCancelled");
getch();
}
Testing
Software Testing is an empirical investigationconducted to
providestakeholders with information about the quality of the product
orservice under test,with respect to thecontext in which it is intendedto
operate. Software Testing also provides an objective,independentview of
the software to allow the business to appreciate andunderstand the risks at
implementation of the software. Testtechniques include, but are not limited
to, theprocess of executing aprogram or application with the intent of
finding software bugs . It canalso be stated as the process of validating and
verifying that asoftwareprogram/application/product meets the
businessandtechnical requirements that guided itsdesign and development,
so thatit works as expected and can be implemented with
thesamecharacteristics.
Software Testing, depending on the testing method employed, can
beimplemented at any time in the development process, however the
mosttest effort is employed after the requirements have been defined
andcoding process has been completed.
Black box testing:
Block box testing treats the software as a “black box” without
anyknowledge of internal implementation. Black box testing
methodsinclude: equivalence partitioning , boundary value analysis , all-
pairstesting , fuzz testing , model-based testing , traceability matrix
,exploratory testing and specification-based testing.
Specification-based testing:
Specification-based testing aims to test the functionality of
softwareaccording to the applicable requirements. Thus, the tester inputs
datainto, and only sees the output from, the test object. This level of
testingusually requires thorough test cases to be provided to the tester,
whothen can simply verify that for a given input, the output value
(orbehavior), either ”is” or “is not” the same as the expected value
specifiedin the test case.
Specification-based testing is necessary, but it isinsufficient to guard
against certain risks.
Advantages and disadvantages:
The black box tester has no “bonds” with the code, and a tester’sperception
is very simple: a code must have bugs. Using the principle,“Ask and you
shall receive,” black box testers find bugs whereprogrammers don’t. But, on
the other hand, black box testing has beensaid to be ”like a walk in a dark
labyrinth without a flashlight,”because the tester doesn’t know how the
software being tested wasactually constructed. That’s why there are
situations when (1) a blackbox tester writes many test cases to check
something that can be testedby only one test case, and/or (2) some parts
of the back end are nottested at all.
Therefore, black box testing has the advantage of “an unaffiliatedopinion,”
on the one hand, and the disadvantage of “blind exploring,” onthe other.
White box testing:
White box testing,by contrast to black box testing, is when the testerhas
access to the internal data structures and algorithms (and the codethat
implement these)
Types of white box testing :-
The following types of white box testing exist:
 api testing - Testing of the application using Public and
Private APIs.
 code coverage - creating tests to satisfy some criteria of code
 coverage. For example, the test designer can create tests to
cause all statements in the program to be executed at least
once.
 fault injection methods.
 mutation testing methods.
 static testing - White box testing includes all static testing.

You might also like