0% found this document useful (0 votes)
7 views13 pages

ST Project Ayush

Software Tasting Project

Uploaded by

ayush pal
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
7 views13 pages

ST Project Ayush

Software Tasting Project

Uploaded by

ayush pal
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 13

MAHATMA EDUCATION SOCIETY’S

PILLAI COLLEGE OF ARTS, COMMERCE & SCIENCE


(Autonomous)

NEW PANVEL

PROJECT REPORT ON
“Software Testing Performed on Travel Website”

IN PARTIAL FULFILLMENT OF

BACHELOR OF INFORMATION TECHNOLOGY

SEMESTER VI – 2023-24

PROJECT GUIDE
Prof. Sharan Sachdev

SUBMITTED BY: Ayush Pal


ROLL NO: 8303
Table of Contents
Sr. No. Topic Page No. Sign
1 Introduction 3
2 Overall Description 4
3 System Features 5
4 External Interface 5
Requirement
5 Other Non-Functional 6
Requirements
6 Boundary Value 7
Analysis(BVA)
7 Equivalence Partition 9
Testing
8 Decision Table 11
9 State Transition Table 12
10 Use Case Testing 13

2
Software Requirements Specification (SRS) Document

1. INTRODUCTION-:
1.1 PURPOSE
This document aims to guide the development of an online flight management
system tailored for use within the college premises. The system intends to
streamline flight management processes, making it easier for both the flight
management team and passengers to handle flight-related tasks.

1.2 DOCUMENT CONVENTIONS


Throughout this document, the following conventions will be used:
DB: Database
DDB: Distributed Database
ER: Entity Relationship

1.3 INTENDED AUDIENCE AND READING SUGGESTIONS


This document is intended for stakeholders involved in the development and use
of the flight management system within the college premises. This includes
developers, college professors guiding the project, the flight management team,
and potential users (passengers).

1.4 PROJECT SCOPE


The online flight management system aims to simplify flight management
processes and provide a user-friendly interface for passengers to book airline
tickets. It will utilize a relational database to store and manage flight
information, supporting a wide range of cities and flights from various airline
companies. The system prioritizes user experience and affordability.

1.5 REFERENCES
Example Reference 1
Fundamentals of Database Systems by Ramez Elmasri and Shamkant B.
Navathe

3
2. OVERALL DESCRIPTION-:
2.1 PRODUCT PERSPECTIVE
The flight management system will be a distributed database system capable of
storing and managing various types of information, including flight details,
customer profiles, and reservations. This system will provide a centralized
platform for efficient flight management and passenger interaction.

2.2 PRODUCT FEATURES


Key features of the airline database system will be depicted in an entity–
relationship model, facilitating flight and reservation management. This includes
features such as flight information retrieval, reservation handling, and customer
management functionalities.

2.3 USER CLASS AND CHARACTERISTICS


Users of the system will include both customers and employees. Customers will
have access to functionalities such as flight search, reservation making, and
itinerary viewing. Employees, on the other hand, will have additional privileges
for managing flights, customers, and reservations.

2.4 OPERATING ENVIRONMENT


The flight management system will operate in a distributed environment, utilizing
client/server architecture. It will be compatible with Windows operating systems
and will rely on SQL+ database management for data storage and retrieval. The
system can be accessed via various platforms such as VB.NET, Java, or PHP.

2.5 DESIGN AND IMPLEMENTATION CONSTRAINTS


Constraints include designing global, fragmentation, and allocation schemas for
the distributed database, implementing SQL commands for database
management, and ensuring seamless integration of various database fragments to
execute global queries.

2.6 ASSUMPTION DEPENDENCIES


Assumptions include scenarios such as booking/cancellation requests,
calculation of frequent flyer rewards, and a distributed database architecture
across four cities, namely Delhi, Mumbai, Chennai, and Kolkata.

4
3. SYSTEM FEATURES-:
DESCRIPTION AND PRIORITY
System features prioritize functionalities such as flight information management,
reservation handling, and cancellation procedures to ensure a seamless travel
experience for passengers.

STIMULUS/RESPONSE SEQUENCES
Users can initiate actions such as searching for flights, making reservations, and
canceling existing bookings, with the system responding accordingly to each
action.

FUNCTIONAL REQUIREMENTS
Functionalities include distributed database management to ensure efficient data
handling across multiple locations and client/server interactions for seamless user
experiences.

4. EXTERNAL INTERFACE REQUIREMENTS-:

4.1 USER INTERFACES


The user interface will be developed using VB.NET, providing a user-friendly
experience for passengers and flight management personnel. SQL+ will be used
as the backend software for data management.

4.2 HARDWARE INTERFACES


The system will be compatible with Windows-based hardware configurations,
with browser support for CGI, HTML, and Javascript for web-based interactions.

4.3 SOFTWARE INTERFACES


Software interfaces include the operating system (Windows), database
management system (SQL+), and programming language (VB.NET) for
application development and deployment.

4.4 COMMUNICATION INTERFACES


The system will support various web browsers, allowing users to interact with
electronic forms for reservation and booking processes.

5
5. NONFUNCTIONAL REQUIREMENTS-:

5.1 PERFORMANCE REQUIREMENTS


Performance requirements include designing an E-R Diagram, normalization, and
ensuring efficient data retrieval for seamless user experiences.

5.2 SAFETY REQUIREMENTS


Safety measures include database backup and recovery procedures to mitigate the
impact of catastrophic failures and ensure data integrity.

5.3 SECURITY REQUIREMENTS


Security measures will be implemented to safeguard sensitive data stored within
the system, ensuring secure transactions and data access.

5.4 SOFTWARE QUALITY ATTRIBUTES


Quality attributes include availability, correctness, maintainability, and usability,
ensuring a reliable and user-friendly flight management system.
This detailed framework provides a comprehensive overview of the project's
purpose, features, constraints, and requirements, ensuring clarity and alignment
with project goals and specifications.

6
6. BVA applied to one scenario of the project-:

Scenario: Making a New Reservation

In this scenario, we'll consider the boundary values for different parameters
involved in making a new reservation, such as the number of passengers, the date
of travel, and the type of reservation (one-way, round-trip, or multi-city).

Parameters:
Number of Passengers
Date of Travel
Type of Reservation (One-way, Round-trip, Multi-city)

Boundary Values:
For each parameter, we'll identify the lower and upper boundary values, as well
as values just within those boundaries.

Number of Passengers:
Lower Boundary: 1 (Minimum allowed passengers)
Upper Boundary: 10 (Assuming maximum allowed passengers per reservation)
Boundary Values: 0, 1, 2, 9, 10, 11

Date of Travel:
Lower Boundary: Today's date (Minimum allowed date)
Upper Boundary: Next year's date (Assuming reservations can be made up to one
year in advance)
Boundary Values: Today's date, Today's date - 1, Today's date + 1, Next year's
date - 1, Next year's date

Type of Reservation:
One-way: A single trip from one destination to another
Round-trip: A trip to a destination and back to the original starting point
Multi-city: Involving multiple stops in different cities

7
Boundary Value Table-:

The lower and upper boundaries are included to test the extreme values.
The boundary values just within the boundaries are included to test the system's
behavior at the edge of its range.
Normal values are included to test typical scenarios.
By testing these boundary values, we can ensure that the system behaves as
expected at the limits of its functionality, helping to identify any potential issues
or bugs.

8
7. EQP applied to one scenario of the project-:

Scenario: Making a New Reservation


In this scenario, we'll partition the input space into equivalence classes and select
representative values from each class to test the system's behavior.
Parameters:
Number of Passengers
Date of Travel
Type of Reservation (One-way, Round-trip, Multi-city)
Equivalence Classes:
For each parameter, we'll identify valid and invalid equivalence classes.
Number of Passengers:
Valid Equivalence Classes: 1 to 10 (Range of allowed passengers)
Invalid Equivalence Classes: Less than 1, More than 10
Date of Travel:
Valid Equivalence Classes: Today's date to Next year's date (Range of allowed
dates)
Invalid Equivalence Classes: Dates before today, Dates more than one year in the
future
Type of Reservation:
Valid Equivalence Classes: One-way, Round-trip, Multi-city
Invalid Equivalence Classes: Any other type not listed (e.g., 'Return trip')
Representative Values:
We'll choose one value from each equivalence class to use for testing.

9
Equivalence Partitioning Table:

Equivalence partitioning divides the input domain into classes to reduce the
number of test cases while ensuring thorough coverage.
Valid equivalence classes represent inputs that are expected to be accepted by the
system, while invalid equivalence classes represent inputs that are expected to be
rejected.
We select one representative value from each equivalence class to use for testing,
ensuring that we cover both valid and invalid scenarios effectively.
Testing these representative values from each equivalence class will help identify
any potential issues or discrepancies in the system's behavior across different
input ranges.

10
8. Decision Table
Scenario: Making a New Reservation
In this scenario, we'll create a decision table to determine the actions to be taken
based on various conditions related to making a new reservation.
Conditions:
Number of Passengers
Date of Travel
Type of Reservation
Actions:
Validating Reservation
Booking Reservation
Providing Confirmation
Decision Table:

The decision table helps in capturing the different conditions and corresponding
actions to be taken for making a new reservation.
Each condition represents a variable that can influence the outcome of the
reservation process.
The actions are determined based on the combination of conditions that are met.
For example, if the number of passengers is between 1 and 10, the date of travel
is within the valid range, and the type of reservation is one of the listed options,
the system will perform validation, book the reservation, and provide
confirmation.
If any condition is not met, the system will display an error message, not book
the reservation, and not provide confirmation.
Testing the decision table with different combinations of conditions will ensure
that the system behaves correctly under various scenarios related to making a
new reservation.

11
9. State Transition diagram-:
Scenario: Cancelling an Existing Reservation
In this scenario, we'll identify the different states of a reservation and the
transitions between these states based on the cancellation process.
States:
Reserved: The reservation exists and is confirmed.
Canceled: The reservation has been canceled.
Transitions:
Initial State: Reserved
Event: Cancel Reservation
Transition: Reserved -> Canceled
State Transition Diagram:

State Transition Table

The initial state of a reservation is "Reserved".


When the "Cancel Reservation" event occurs, the reservation transitions from the
"Reserved" state to the "Canceled" state.
The State Transition Diagram visually represents the transition from the
"Reserved" state to the "Canceled" state upon canceling the reservation.
The State Transition Table summarizes the transitions between states based on
the events occurring in the system.
Testing this scenario will involve verifying that the reservation transitions
correctly from the "Reserved" state to the "Canceled" state when the cancellation
event is triggered.

12
10. Use case testing-:
Use Case: Making a New Reservation
In this scenario, we'll identify various use cases involved in making a new
reservation and define test cases for each use case.
Use Cases:
Search Flights: The user searches for available flights based on the desired travel
dates and destinations.
Select Flight: The user selects a flight from the list of available options.
Enter Passenger Details: The user enters passenger details such as name, contact
information, and number of passengers.
Choose Reservation Type: The user selects the type of reservation (one-way,
round-trip, or multi-city).
Confirm Reservation: The user confirms the reservation and proceeds to payment.
Make Payment: The user completes the payment process to finalize the
reservation.
Test Cases:

Each test case corresponds to a specific use case involved in making a new
reservation.
The test description outlines the actions to be performed for each test case.
The expected result specifies the outcome expected after executing each test case.
Testing these test cases will ensure that the system

13

You might also like