ST Project Ayush
ST Project Ayush
NEW PANVEL
PROJECT REPORT ON
“Software Testing Performed on Travel Website”
IN PARTIAL FULFILLMENT OF
SEMESTER VI – 2023-24
PROJECT GUIDE
Prof. Sharan Sachdev
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.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.
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.
5
5. NONFUNCTIONAL REQUIREMENTS-:
6
6. BVA applied to one scenario of the project-:
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-:
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:
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