3

Experiment No. 1
Class Diagram of Online Railway Reservation System
Creating a class diagram for an online railway reservation system involves modeling the various entities and
their interactions required to manage reservations, trains, passengers, and ticketing. Here’s a simplified class
diagram to illustrate the key components of such a system:

1. Train

 Attributes:
o trainID: int
o trainName: string
o source: string
o destination: string
o departureTime: datetime
o arrivalTime: datetime
o totalSeats: int
o availableSeats: int
 Methods:
o updateSeats(int): void
o getSchedule(): string

2. Passenger

 Attributes:
o passengerID: int
o name: string
o email: string
o phoneNumber: string
 Methods:
o bookTicket(Ticket): void
o cancelTicket(Ticket): void
o viewBookingHistory(): List<Ticket>

3. Ticket

 Attributes:
o ticketID: int
o trainID: int
o passengerID: int
o bookingDate: datetime
o travelDate: datetime
o seatNumber: int
o status: string (e.g., "booked", "canceled", "completed")
 Methods:
o generateTicket(): string
4

o cancelTicket(): void

4. Reservation

 Attributes:
o reservationID: int
o ticketID: int
o passengerID: int
o reservationDate: datetime
o status: string (e.g., "confirmed", "pending", "canceled")
 Methods:
o confirmReservation(): void
o cancelReservation(): void

5. Schedule

 Attributes:
o scheduleID: int
o trainID: int
o date: datetime
o departureTime: datetime
o arrivalTime: datetime
 Methods:
o updateSchedule(): void
o getTrainSchedule(): string

6. Payment

 Attributes:
o paymentID: int
o ticketID: int
o amount: float
o paymentDate: datetime
o status: string (e.g., "completed", "failed")
 Methods:
o processPayment(): boolean
o refundPayment(): void

Relationships:

 Train ↔ Ticket: One-to-many (A train can have multiple tickets)

 Passenger ↔ Ticket: One-to-many (A passenger can have multiple tickets)
 Ticket ↔ Reservation: One-to-one (A ticket has one reservation)
 Train ↔ Schedule: One-to-many (A train can have multiple schedules)
 Ticket ↔ Payment: One-to-one (A ticket has one payment record)
5

Notes:

 Train schedules might be managed separately from train details if trains run on different schedules or
routes.
 Payment could be a more detailed class, depending on the complexity of the payment processing
system.
6

Experiment No.2
Class Diagram Of Library Management System

Creating a class diagram for a library management system involves identifying the main classes that would be
involved in managing the various aspects of a library. These classes usually include entities such as books, members, and
staff, and their interactions.

1. Book
Attributes:

- `bookID`: int

- `title`: string

- `author`: string

- `publisher`: string

- `publicationYear`: int

- `ISBN`: string

- `availableCopies`: int

Methods:

- `checkAvailability()`: boolean

- `updateCopies(int)`: void

2. Member
Attributes:

- `memberID`: int

- `name`: string

- `address`: string

- `phoneNumber`: string

- `email`: string

- `membershipDate`: date

- Methods:
7

- `borrowBook(Book)`: boolean

- `returnBook(Book)`: void

- `reserveBook(Book)`: boolean

3. Staff
Attributes:

- `staffID`: int

- `name`: string

- `position`: string

- `email`: string

Methods:

- `addBook(Book)`: void

- `removeBook(Book)`: void

- `updateBookInfo(Book)`: void

- `registerMember(Member)`: void

- `deregisterMember(Member)`: void

4. Transaction
Attributes:

- `transactionID`: int

- `memberID`: int

- `bookID`: int

- `transactionDate`: date

- `dueDate`: date

- `returnDate`: date

- `status`: string (e.g., "borrowed", "returned", "overdue")

Methods:

- `calculateFine()`: float

- `recordTransaction()`: void
8

5. Reservation
Attributes:

- `reservationID`: int

- `memberID`: int

- `bookID`: int

- `reservationDate`: date

- `status`: string (e.g., "active", "fulfilled", "cancelled")

Methods:

- `cancelReservation()`: void

Relationships:

-Book ↔ Transaction : One-to-many (A book can have multiple transactions)

- Member ↔ Transaction : One-to-many (A member can have multiple transactions)

- Member ↔ Reservation : One-to-many (A member can have multiple reservations)

- Book ↔ Reservation : One-to-many (A book can have multiple reservations)

Notes:

- Library class can be included to manage the overall library operations, members, and books.
9

- Library might not always be a separate class in some diagrams but could be part of the system's operational logic.

This class diagram provides a foundation, but depending on the specific requirements or functionalities, you may need
to adjust or expand upon it.
10

Experiment No.3
Use-Case Model For Student Admission System in a University

A use case model for a student admission system in a university outlines the interactions between the various
actors (users) and the system to manage the student admission process. This model helps in understanding the
functional requirements and the interactions that different users have with the system.

Actors

1. Prospective Student: An individual looking to apply for admission.

2. Admission Officer: Staff responsible for processing and managing applications.
3. University Administrator: Manages overall system settings and user roles.
4. Registrar: Handles student records and enrollments.

Use Cases

1. Apply for Admission: A prospective student submits an application for admission.

2. Submit Documents: A prospective student submits necessary documents.
3. Track Application Status: A prospective student checks the status of their application.
4. Review Applications: An admission officer reviews submitted applications.
5. Request Additional Information: An admission officer requests additional information from the
prospective student.
6. Update Application Status: An admission officer updates the status of an application (e.g., accepted,
rejected).
7. Send Admission Offer: An admission officer sends an admission offer to the accepted student.
8. Enroll in Program: An accepted student enrolls in a specific program or course.
9. Generate Reports: A university administrator generates various reports (e.g., number of applications,
admission statistics).
10. Manage Users: A university administrator manages user roles and permissions.
11. Manage Programs and Courses: A university administrator manages programs and courses offered by
the university.
12. Update Student Records: The registrar updates and maintains student records after enrollment.

Use Case Diagram

Here's a textual representation of how the use case diagram would be structured:
11

Description of Use Cases

1. Apply for Admission: Prospective students fill out an application form online or offline.
2. Submit Documents: Prospective students upload or submit required documents (e.g., transcripts,
recommendation letters).
3. Track Application Status: Prospective students log in to view the status of their application.
4. Review Applications: Admission officers evaluate the submitted applications based on criteria.
5. Request Additional Information: If needed, admission officers request further information from the
applicant.
6. Update Application Status: Admission officers update the status of the application to accepted,
rejected, or pending.
7. Send Admission Offer: Accepted students receive an official offer of admission.
8. Enroll in Program: Accepted students select and enroll in a specific program or course.
9. Generate Reports: University administrators create reports on application statistics, admission trends,
etc.
10. Manage Users: University administrators create, modify, or delete user accounts and roles.
11. Manage Programs and Courses: Administrators update or add new programs and courses to the
system.
12. Update Student Records: Registrars maintain and update student records post-admission.

This use case model provides a high-level view of the functional requirements of a student admission system
and the interactions between different types of users and the system.
12

Experiment No. 4
Develop Use Case Diagram for Library where a member can perform two operations:
Book and return a book is issue to a member after verifying his credentials

To develop a use case diagram for a library system where a member can perform operations to borrow and
return books, and where these operations are dependent on verifying the member's credentials, follow these
steps:

Actors

1. Library Member: The user of the library who can borrow and return books.
2. Library Staff: Responsible for verifying the credentials of the library members and processing book
transactions.

Use Cases

1. Borrow Book: The member requests to borrow a book. This involves:

o Verify Member Credentials: Library staff checks the member's credentials.
o Check Book Availability: Library staff verifies if the book is available.
o Issue Book: If both conditions are satisfied, the book is issued to the member.
2. Return Book: The member returns a previously borrowed book. This involves:
o Verify Member Credentials: Library staff checks the member's credentials.
o Accept Returned Book: Library staff updates the system to mark the book as returned and
available for others.

Use Case Diagram

Here’s a textual representation of the use case diagram:

13

Description of Use Cases

1. Borrow Book:
o Member: Initiates the request to borrow a book.
o Library Staff:
 Verify Member Credentials: Staff verifies the member’s identity to ensure they are
eligible to borrow books.
 Check Book Availability: Staff checks if the requested book is available in the library.
 Issue Book: If credentials are verified and the book is available, the book is issued to the
member.
2. Return Book:
o Member: Returns a book to the library.
o Library Staff:
 Verify Member Credentials: Staff verifies the member’s identity to ensure the return is
legitimate.
 Accept Returned Book: Staff processes the return and updates the system to reflect that
the book is now available.

Visual Representation

The visual representation would look something like this:

14

Notes

 Library Staff is responsible for both verifying member credentials and processing transactions.
 Library Member interacts with the system to borrow and return books but relies on the library staff to
handle the behind-the-scenes verification and updating.

This diagram provides a high-level overview of the main interactions and roles within the library system related
to borrowing and returning books.
15

Experiment No.5
Use Case Diagram For a Travel Agent

A use case diagram for a travel agent system outlines the interactions between the various actors (users) and the
system to manage travel bookings, inquiries, and other related activities. The primary actors in this system are
the Customer and the Travel Agent. Below is a detailed breakdown and textual representation of the use case
diagram.

Actors

1. Customer: The individual who interacts with the travel agent system to book travel services.
2. Travel Agent: The professional who manages bookings, provides assistance, and handles customer
inquiries.

Use Cases

1. Search for Travel Options: The customer searches for available travel options such as flights, hotels,
and car rentals.
2. Book Travel: The customer books travel services based on their search results.
3. Cancel Booking: The customer cancels a previously made booking.
4. Modify Booking: The customer makes changes to an existing booking.
5. Make Inquiry: The customer asks for more information or clarifications about travel options.
6. Provide Travel Information: The travel agent provides information about travel options, pricing, and
other details.
7. Process Booking: The travel agent processes and confirms travel bookings made by customers.
8. Manage Cancellations: The travel agent handles and processes booking cancellations.
9. Update Travel Information: The travel agent updates information about travel options, prices, and
availability.
10. Generate Reports: The travel agent generates reports related to bookings, sales, and customer inquiries.

Use Case Diagram

Here’s a textual representation of the use case diagram for a travel agent system:
16

Description of Use Cases

1. Search for Travel Options:

o Customer: Searches for flights, hotels, car rentals, etc., based on their travel preferences.
2. Book Travel:
o Customer: Selects and books travel options (flights, hotels, etc.) based on the search results.
3. Cancel Booking:
o Customer: Cancels a previously made booking, often involving refunds or rescheduling.
4. Modify Booking:
o Customer: Changes details of an existing booking, such as dates or travel options.
5. Make Inquiry:
o Customer: Asks questions regarding travel options, pricing, or other related information.
6. Provide Travel Information:
o Travel Agent: Provides customers with details on travel options, pricing, and availability.
7. Process Booking:
o Travel Agent: Confirms and processes travel bookings made by customers.
8. Manage Cancellations:
o Travel Agent: Handles cancellations and updates booking records accordingly.
9. Update Travel Information:
o Travel Agent: Updates information about travel options, prices, and availability in the system.
10. Generate Reports:
o Travel Agent: Creates reports on booking statistics, customer inquiries, sales performance, etc.

Visual Representation

The visual representation of the use case diagram can be illustrated as follows:
17

This use case diagram provides a high-level overview of the interactions within a travel agent system, showcasing the
roles of both customers and travel agents in managing travel bookings and inquiries.
18

Experiment No.6
Uml Sequence Diagram for Information system For Online Book Store
Creating a UML sequence diagram for an online bookstore involves modeling the interactions between various
components of the system over time. Let's break down the key components and interactions typically found in
such a system.

Key Components

1. User - Represents the customer interacting with the bookstore.

2. Web Interface - The front-end interface through which the user interacts with the system.
3. Controller - Handles user requests and interactions.
4. Book Inventory Service - Manages the book catalog and inventory.
5. Order Service - Manages order creation, processing, and tracking.
6. Payment Service - Handles payment processing.
7. Database - Stores data related to books, users, orders, etc.
8. Shipping Service - Manages shipping and delivery of orders.

Sequence Diagram Scenario: User Places an Order

1. User Browses Books

 User -> Web Interface: Request to view book catalog

 Web Interface -> Controller: Fetch book catalog
 Controller -> Book Inventory Service: Request book catalog
 Book Inventory Service -> Database: Query book catalog
 Database -> Book Inventory Service: Return book catalog
 Book Inventory Service -> Controller: Return book catalog
 Controller -> Web Interface: Provide book catalog
 Web Interface -> User: Display book catalog

2. User Selects a Book and Places an Order

 User -> Web Interface: Select a book and add to cart

 Web Interface -> Controller: Add book to cart
 Controller -> Web Interface: Confirm addition to cart

3. User Proceeds to Checkout

 User -> Web Interface: Proceed to checkout

 Web Interface -> Controller: Initiate checkout process
 Controller -> Order Service: Create order
 Order Service -> Database: Store order details
 Database -> Order Service: Confirm order storage
 Order Service -> Controller: Confirm order creation

4. User Provides Payment Details

19

 User -> Web Interface: Enter payment information

 Web Interface -> Controller: Submit payment details
 Controller -> Payment Service: Process payment
 Payment Service -> Database: Record payment transaction
 Database -> Payment Service: Confirm payment recording
 Payment Service -> Controller: Confirm payment success
 Controller -> Web Interface: Notify user of successful payment

5. Order Fulfillment and Shipping

 Order Service -> Shipping Service: Initiate shipping process

 Shipping Service -> Database: Update shipping status
 Database -> Shipping Service: Confirm status update
 Shipping Service -> Order Service: Confirm shipping initiation
 Order Service -> Controller: Notify user of order shipment
 Controller -> Web Interface: Display order shipment status
 Web Interface -> User: Show shipment status

Sequence Diagram Visualization

Here’s a textual representation of the UML sequence diagram:

You can use a UML tool like Lucidchart, Microsoft Visio, or even online tools like draw.io to create a graphical
representation of this sequence diagram.
20

Experiment No.7
Uml Class And Sequence Diagram For Car Manufacturing

UML Class Diagram

A Class Diagram is used to show the static structure of a system, depicting classes, their attributes, methods,
and relationships between classes.

For a car manufacturing system, the Class Diagram might include the following classes:

1. Car
o Attributes: model, engineType, color, price
o Methods: assemble(), paint(), testDrive()
2. Engine
o Attributes: engineType, horsepower, fuelType
o Methods: assemble(), test()
3. Transmission
o Attributes: transmissionType, numberOfGears
o Methods: assemble(), test()
4. Manufacturer
o Attributes: name, location
o Methods: produceCar(), testCar()
5. Supplier
o Attributes: name, contactInfo
o Methods: supplyParts()
6. ProductionLine
o Attributes: lineID, capacity
o Methods: startProduction(), stopProduction()
7. Worker
o Attributes: name, role, shift
o Methods: performTask()

Relationships:

 Car has a composition relationship with Engine and Transmission (i.e., a Car "has a" Engine and
Transmission).
 Manufacturer uses Supplier to get parts.
 Manufacturer utilizes ProductionLine to produce cars.
 ProductionLine involves Workers for different tasks.

Here’s how the Class Diagram might look:

21

UML Sequence Diagram

A Sequence Diagram shows how objects interact in a particular sequence. Let’s consider the process of
manufacturing a car:

1. Customer orders a car.

2. Manufacturer receives the order.
3. Manufacturer requests parts from Supplier.
4. Supplier provides the parts.
5. Manufacturer assembles the car using ProductionLine and Workers.
6. Car is tested and finished.

Here’s a simplified Sequence Diagram:

22

Summary

 Class Diagram shows the structure of the car manufacturing system including key classes and their
relationships.
 Sequence Diagram shows the process flow of manufacturing a car from order to delivery.
23

Experiment No.8
State transition Diagram For Online Air Reservation System
Creating a state transition diagram for an Online Air Reservation System involves mapping out the various
states of the system and how it transitions between these states based on different events. Here's a conceptual
outline for such a diagram:

States:

1. Idle/Start: Initial state where the system is waiting for user input.
2. Search Flights: User is searching for available flights.
3. Select Flight: User selects a flight from the search results.
4. Enter Passenger Details: User enters passenger details.
5. Payment: User proceeds to payment for the reservation.
6. Confirmation: System confirms the booking and provides a reservation number.
7. Cancel Reservation: User cancels the reservation.
8. Modify Reservation: User modifies the reservation details.

Transitions:

1. Idle/Start → Search Flights: User initiates a search for flights.

2. Search Flights → Select Flight: User selects a flight from the search results.
3. Select Flight → Enter Passenger Details: User chooses a flight and proceeds to enter details.
4. Enter Passenger Details → Payment: User submits passenger details and proceeds to payment.
5. Payment → Confirmation: Payment is processed successfully, and the system confirms the
reservation.
6. Payment → Enter Passenger Details: Payment fails, user is prompted to re-enter details or correct
information.
7. Confirmation → Idle/Start: User completes the booking and returns to the start or home page.
8. Idle/Start → Cancel Reservation: User opts to cancel a reservation.
9. Cancel Reservation → Confirmation: System confirms the cancellation.
10. Idle/Start → Modify Reservation: User decides to modify an existing reservation.
11. Modify Reservation → Payment: User modifies the reservation and proceeds to payment for any
additional charges or adjustments.
12. Payment → Confirmation: Payment for the modified reservation is successful, and the system
confirms the changes.

Diagram Representation:

In a state transition diagram, you would typically represent states as circles or rectangles, and transitions as
arrows between these states. Here's a simplified visual representation:

sql
Copy code
+-------------+
| Idle/Start |
+------+------+
|
24

v
+------+------+
| Search |
| Flights |
+------+------+
|
v
+------+------+
| Select |
| Flight |
+------+------+
|
v
+------+------+
| Enter |
| Passenger |
| Details |
+------+------+
|
v
+------+------+
| Payment |
+------+------+
/ \
/ \
v v
+------+-------+ +--------+
| Confirmation | | Enter |
+--------------+ | Passenger |
| Details |
+----------+
|
v
+-------+--------+
| Modify |
| Reservation |
+-------+--------+
|
v
+-------+--------+
| Payment |
+-------+--------+
|
v
+-------+--------+
| Confirmation |
+----------------+

(Cancellation flows would also return to the Idle/Start state)

This diagram helps in understanding the flow of operations and the states the system can be in, providing clarity
on user interactions and system responses.
25

Experiment N0.9
Deployment Diagram for Different Scenario of Railway System
Creating a deployment diagram for a railway system involves detailing how the various components of the
system are distributed across hardware nodes and how they interact with each other. Deployment diagrams are
part of UML (Unified Modeling Language) and help visualize the physical deployment of artifacts on nodes.

Here’s a general approach to creating a deployment diagram for a railway system with different scenarios:

1. Basic Components of the Railway System

 Track Control System (TCS): Manages train movements, signals, and track switching.
 Signal Control System (SCS): Controls the signaling along the tracks.
 Train Management System (TMS): Manages train schedules, routes, and communications.
 Station Management System (SMS): Handles ticketing, platform management, and passenger
information.
 Communication System (CS): Facilitates communication between trains, stations, and control centers.
 Maintenance System (MS): Manages the maintenance of tracks, trains, and other infrastructure.
 User Interfaces: For operators, conductors, and passengers.

2. Nodes

Nodes represent physical hardware or virtual environments where components are deployed. Examples include:

 Central Control Node: Hosts TCS, SCS, and some parts of TMS.
 Station Node: Hosts SMS, communication interfaces, and local TMS components.
 Train Node: Contains onboard TMS, communication interfaces, and sensor systems.
 Maintenance Node: Hosts MS and diagnostic tools.
 Communication Node: Dedicated to the Communication System.

3. Deployment Diagram for Various Scenarios

Scenario 1: Normal Operation

 Central Control Node:

o TCS
o SCS
o TMS (Centralized)
 Station Node:
o SMS
o Local TMS (for scheduling and management)
o Communication Interfaces
 Train Node:
o Onboard TMS
o Communication Interfaces
o Sensors and Monitoring Systems
 Maintenance Node:
o MS
26

o Diagnostic Tools
 Communication Node:
o CS

Interactions:

 Trains communicate with the central control node via the communication system.
 Station systems interact with the central control node for scheduling and signal management.
 Maintenance systems gather data from various nodes for diagnostics and updates.

Scenario 2: Emergency Situation

 Central Control Node:

o TCS (with emergency protocols)
o SCS (with emergency signaling)
o TMS (with emergency rerouting)
 Station Node:
o SMS (with emergency notifications)
o Local TMS
o Communication Interfaces
 Train Node:
o Onboard TMS (with emergency procedures)
o Communication Interfaces
o Sensors (for emergency monitoring)
 Maintenance Node:
o MS (with emergency response capabilities)
o Diagnostic Tools
 Communication Node:
o CS (with prioritized emergency channels)

Interactions:

 Central control takes immediate action to reroute trains and update signals.
 Stations handle emergency notifications and manage passenger information.
 Trains follow emergency protocols and communicate critical information back to control centers.
 Maintenance teams are alerted and dispatched based on emergency diagnostics.

Scenario 3: Maintenance Period

 Central Control Node:

o TCS (with limited functionalities or maintenance mode)
o SCS (with monitoring capabilities)
o TMS (with reduced operations)
 Station Node:
o SMS (with adjusted scheduling)
o Local TMS (adjusted for maintenance)
o Communication Interfaces
 Train Node:
o Onboard TMS (adjusted for operational limits)
o Communication Interfaces
27

o Sensors (for maintenance data)

 Maintenance Node:
o MS (with active maintenance operations)
o Diagnostic Tools
 Communication Node:
o CS (with maintenance monitoring)

Interactions:

 Maintenance systems coordinate with central control for scheduling and operational adjustments.
 Stations manage altered schedules and communicate changes to passengers.
 Trains operate under modified schedules and report maintenance data.
 Communication systems monitor and report maintenance impacts.

Diagram Example

Here’s a simplified representation of the deployment diagram for the Normal Operation scenario:

sql
Copy code
+---------------------------------------+
| Central Control Node |
| +-------------------------------+ |
| | TCS | |
| +-------------------------------+ |
| +-------------------------------+ |
| | SCS | |
| +-------------------------------+ |
| +-------------------------------+ |
| | TMS (Centralized) | |
| +-------------------------------+ |
+---------------------------------------+
| |
| |
+-----------------+ +------------------+
| Station Node | | Communication |
| +-----------+ | | Node |
| | SMS | | | +-----------+ |
| +-----------+ | | | CS | |
| +-----------+ | | +-----------+ |
| | Local TMS | | +------------------+
| +-----------+ |
| +-----------+ |
| | Comm. Intf.| |
| +-----------+ |
+-----------------+
|
|
+-----------------+
| Train Node |
| +-----------+ |
| | Onboard TMS | |
| +-----------+ |
| +-----------+ |
| | Comm. Intf.| |
| +-----------+ |
| +-----------+ |
28

| | Sensors | |
| +-----------+ |
+-----------------+
|
|
+-----------------+
| Maintenance Node|
| +-----------+ |
| | MS | |
| +-----------+ |
| +-----------+ |
| | Diagnostic | |
| | Tools | |
| +-----------+ |
+-----------------+

This diagram and its variations illustrate how different components of the railway system interact and are
deployed in various operational scenarios. Adjustments would be made based on the specific architecture and
requirements of the system you are modeling.
29

Experiment No. 10
Develop test cases for various white box and black box testing techniques

White Box Testing Techniques

1. Statement Coverage

Objective: Ensure every line of code is executed.

Example Code:

python
Copy code
def calculate_discount(price, discount_rate):
discounted_price = price
if discount_rate > 0:
discounted_price = price - (price * discount_rate / 100)
return discounted_price

Test Cases:

 Test Case 1:
o Input: price = 100, discount_rate = 10
o Expected Output: 90.0
o Reasoning: Covers the condition where discount_rate > 0.
 Test Case 2:
o Input: price = 100, discount_rate = 0
o Expected Output: 100.0
o Reasoning: Covers the scenario where discount_rate = 0.

2. Branch Coverage

Objective: Ensure each branch (true/false) of every decision point is executed.

Example Code:

python
Copy code
def check_even_odd(number):
if number % 2 == 0:
return 'Even'
else:
return 'Odd'

Test Cases:

 Test Case 1:
o Input: number = 4
o Expected Output: Even
o Reasoning: Tests the true branch of the condition.
 Test Case 2:
30

o Input: number = 5
o Expected Output: Odd
o Reasoning: Tests the false branch of the condition.

3. Path Coverage

Objective: Ensure all possible paths through the code are tested.

Example Code:

python
Copy code
def compute_value(x, y):
if x > y:
result = x + y
if result > 10:
return 'High'
else:
return 'Low'
else:
result = x - y
if result < 0:
return 'Negative'
else:
return 'Positive'

Test Cases:

 Test Case 1:
o Input: x = 7, y = 3
o Expected Output: High
o Reasoning: Tests the path where x > y and result > 10.
 Test Case 2:
o Input: x = 5, y = 7
o Expected Output: Negative
o Reasoning: Tests the path where x <= y and result < 0.

4. Condition Coverage

Objective: Ensure each condition in a decision is tested both true and false.

Example Code:

python
Copy code
def validate_age(age):
if age >= 18 and age <= 65:
return 'Valid'
else:
return 'Invalid'

Test Cases:
31

 Test Case 1:
o Input: age = 20
o Expected Output: Valid
o Reasoning: Tests age >= 18 as true, age <= 65 as true.
 Test Case 2:
o Input: age = 16
o Expected Output: Invalid
o Reasoning: Tests age >= 18 as false.

5. Loop Testing

Objective: Test loops with various iterations.

Example Code:

python
Copy code
def sum_first_n(n):
total = 0
for i in range(n):
total += i
return total

Test Cases:

 Test Case 1:
o Input: n = 5
o Expected Output: 10
o Reasoning: Tests multiple iterations (0, 1, 2, 3, 4).
 Test Case 2:
o Input: n = 0
o Expected Output: 0
o Reasoning: Tests the loop with no iterations.

Black Box Testing Techniques

1. Equivalence Partitioning

Objective: Test representative values from equivalence classes.

Example Code:

python
Copy code
def categorize_age(age):
if age < 0:
return 'Invalid'
elif age < 13:
return 'Child'
elif age < 18:
return 'Teenager'
else:
32

return 'Adult'

Test Cases:

 Test Case 1:
o Input: age = 5
o Expected Output: Child
o Reasoning: Tests age in the Child class.
 Test Case 2:
o Input: age = 15
o Expected Output: Teenager
o Reasoning: Tests age in the Teenager class.
 Test Case 3:
o Input: age = 25
o Expected Output: Adult
o Reasoning: Tests age in the Adult class.
 Test Case 4:
o Input: age = -1
o Expected Output: Invalid
o Reasoning: Tests invalid age.

2. Boundary Value Analysis

Objective: Test values at the edges of equivalence classes.

Example Code:

python
Copy code
def get_grade(marks):
if marks >= 90:
return 'A'
elif marks >= 80:
return 'B'
elif marks >= 70:
return 'C'
elif marks >= 60:
return 'D'
else:
return 'F'

Test Cases:

 Test Case 1:
o Input: marks = 89
o Expected Output: C
o Reasoning: Tests just below the boundary between B and C.
 Test Case 2:
o Input: marks = 90
o Expected Output: A
o Reasoning: Tests the boundary where grade changes to A.
 Test Case 3:
33

o Input: marks = 80
o Expected Output: B
o Reasoning: Tests the boundary where grade changes to B.

3. Decision Table Testing

Objective: Test combinations of input conditions.

Example Code:

python
Copy code
def check_login(username, password):
if username == 'admin' and password == 'password123':
return 'Login successful'
elif username == 'admin' or password == 'password123':
return 'Login failed'
else:
return 'Invalid username or password'

Test Cases:

Username Password Expected Output

admin password123 Login successful
admin wrongpass Login failed
user password123 Login failed
user wrongpass Invalid username or password

4. State Transition Testing

Objective: Test states and transitions between them.

Example Code:

python
Copy code
class LightSwitch:
def __init__(self):
self.state = 'OFF'

def toggle(self):
if self.state == 'OFF':
self.state = 'ON'
else:
self.state = 'OFF'
return self.state

Test Cases:

 Test Case 1:
o Input: toggle()
o Expected Output: ON
o Reasoning: Tests transition from OFF to ON.
34

 Test Case 2:
o Input: toggle()
o Expected Output: OFF
o Reasoning: Tests transition from ON back to OFF.

5. Use Case Testing

Objective: Test system functionality based on user scenarios.

Example Code:

python
Copy code
def process_order(order):
if order.is_valid():
if order.payment_successful():
return 'Order processed'
else:
return 'Payment failed'
else:
return 'Invalid order'

Test Cases:

 Test Case 1:
o Input: order = valid order with successful payment
o Expected Output: Order processed
o Reasoning: Tests a valid order with successful payment.
 Test Case 2:
o Input: order = valid order with failed payment
o Expected Output: Payment failed
o Reasoning: Tests a valid order with failed payment.
 Test Case 3:
o Input: order = invalid order
o Expected Output: Invalid order
o Reasoning: Tests an invalid order.

These test cases aim to cover various aspects of white box and black box testing to ensure comprehensive
testing of the code. Adjustments might be needed based on the actual implementation details and requirements.