INDEX

Teacher's
Sr.No. Practical Aim Date
Signature

To set up a company that sells testing services to

1
software houses.

To Design test cases for testing the program with the

2
black-box strategy

To Design Decision table and test cases for Insurance

3
renewal.

To design test cases using branch , condition ,

4
decision and multiple decision coverage.

To design test cases that responds to input requests to

5
change the display mode for a time display device.

To design test cases for drawing table with various

6
function

7.1 Develop a Software Requirements Specification

for hospital management System.7.2 Develop a
7
Software Requirements Specification for Online
Ticket Booking System

To generate unit testing report for Online Ticket

8
Booking system

Perform black box testing Hotel Management

system. 9.1 Using equivalence class partitioning
9
method. 9.2 Using boundary value analysis (BVA)
method
 Perform white box testing for Online Ticket booking
system 10.1 Using branch coverage method. 10.2
Using path coverage method. a. Control Flow
Graph. b. Cyclomatic Complexity. c. Independent
10 paths. d. Test Cases table. e. Test matrix 10.3 Using
Condition coverage Method. Apply “Hotel
Management system”
 PRACTICAL NO 1.

AIM :
To set up a company that sells testing services to software houses.

Title:
Setting up a company that sells testing services to software houses

Problem Statement:

1. What is the testing process that will be followed in the company?

2. What is the focus of the testing services?
3. What kind of people are you going to hire as staff for the company?
4. How are you going to validate that a testing project carried out in the company has been beneficial to the
customer?
5. What kind of automated tools will the company use?

Solution:

Answer 1:

The testing process that will be followed by the company is:

a) Prepare for testing a software system.

b) Plan the tests that will be conducted on the software system.
c) Execute the steps as defined in the test plan.
d) Conduct acceptance testing by the software system users. (Note: This testing may be assisted by the IT
independent test group.)
e) Analyse test results and report them to the appropriate software system stakeholders.
f) Test the installation of the software into the operational environment, and test changes made to the software
after it is placed into the operational environment.
g) Conduct a post-implementation analysis to evaluate the effectiveness and efficiency of the test process.

Answer 2:

The focus of testing services will be on:

a) Software testing should reduce software development risk. Risk is present in all software development
projects, and testing is a control that reduces those risks.
b) Testing should be performed effectively. Testing should be performed in a manner in which the maximum
benefits are achieved from the software testing efforts.
c) Testing should uncover defects. Ideally, at the conclusion of testing there should be no defects in the software.
d) Testing should be performed using business logic. Money should not be spent on testing unless it can be
spent economically to reduce business risk. In other words, it does not make business sense to spend more money
on testing than the losses that might occur from the business risk.
e) Testing should occur throughout the development life cycle. Testing is not a phase, but rather a process. It
begins when development begins and ends when the software is no longer being used.
f) Testing should test both structure and function. Testing should test the functional requirements to ensure
they are correct, and test the adequacy of the software structure to process those functional requirements in an
effective and efficient manner.

Answer 3:

The company will recruit people with the following qualities:

1. A clear communicator. A defect report is no good if we can't understand it.

Software Testing
2. Patient. Sometimes it takes a lot of back-and-forth to get to the root of a problem. And programmers have egos,
they'll often try to push issues back to the tester.
3. Passionate. The best developers are the ones that really care about development and maybe even get a little
excited about it sometimes. Testing isn't that much different.
4. Creative. Really exercising a system requires one to try non-intuitive ways of accomplishing tasks, to go outside
the workflow that the program expects of them and do things that normal users wouldn't do. Task-oriented people
who receive a set of instructions and do the exact same thing every time are no good for this job.
5. Analytical. Just finding a defect isn't enough - a tester has to be able to figure out how to reproduce it. If a report
comes in as "intermittent" then there's about a 10% chance it'll get solved. Most developers won't even look at a
case without a reasonably concise sequence of repro steps. Good testers have to be able to retrace their steps and
narrow down the field of possibilities so as to come up with the simplest possible sequence of actions that trigger a
bug.
6. Not a programmer. Programmers never want to do any actual work testing. They'll spend all their time trying
to write automated tests and not do what really matters, which is to make sure the damn thing actually works the
way it is supposed to. Although there are exceptions to every rule, most programmers simply find testing boring
and will do the absolute minimum amount required.

Answer 4:

Answer 5:

Write about any 5 automation tools:

a) Selenium :

Selenium is a free (open source) automated testing suite for web applications across different browsers and
platforms. It is quite similar to HP Quick Test Pro (QTP now UFT) only that Selenium focuses on automating web-
based applications. Testing done using Selenium tool is usually referred as Selenium Testing.

Selenium is not just a single tool but a suite of software's, each catering to different testing needs of an
organization. It has four components.

 Selenium Integrated Development Environment (IDE)

 Selenium Remote Control (RC)
 WebDriver
 Selenium Grid
b) AutoIT :

AutoIt v3 is a freeware BASIC-like scripting language designed for automating the Windows GUI and general
scripting. It uses a combination of simulated keystrokes, mouse movement and window/control manipulation in
order to automate tasks in a way not possible or reliable with other languages (e.g. VBScript and SendKeys). AutoIt
is also very small, self-contained and will run on all versions of Windows out-of-the-box with no annoying
“runtimes” required!
AutoIt was initially designed for PC “roll out” situations to reliably automate and configure thousands of PCs. Over
time it has become a powerful language that supports complex expressions, user functions, loops and everything
else that veteran scripters would expect.
 Easy to learn BASIC-like syntax
 Simulate keystrokes and mouse movements
 Manipulate windows and processes
 Interact with all standard windows controls
 Scripts can be compiled into standalone executables
 Create Graphical User Interfaces (GUIs)
 COM support
 Regular expressions
 Directly call external DLL and Windows API functions
 Scriptable RunAs functions
 Detailed helpfile and large community-based support forums
 Compatible with Windows XP / 2003 / Vista / 2008 / Windows 7 / 2008 R2 / Windows 8 / 2012 R2 /
Windows 10
 Unicode and x64 support
 Digitally signed for peace of mind
 Works with Windows Vista’s User Account Control (UAC)

c) Bugzilla Software Testing :

Bugzilla is server software designed to help you manage software development.

Features:
 Optimized database structure for increased performance and scalability
 Excellent security to protect confidentiality
 Advanced query tool that can remember your searches
 Integrated email capabilities
 Editable user profiles and comprehensive email preferences
 Comprehensive permissions system
Benefits :
 Improve communication
 Increase product quality
 Improve customer satisfaction
 Ensure accountability
 Increase productivity
 Bugzilla can adapt to multiple situations

d) QTP :

QTP stands for QuickTest Professional, a product of Hewlett Packard (HP). This tool helps testers to perform an
automated functional testing seamlessly, without monitoring, once script development is complete.
HP QTP uses Visual Basic Scripting (VBScript) for automating the applications. The Scripting Engine need not
be installed exclusively, as it is available as a part of the Windows OS. The Current version of VBScript is 5.8,
which is available as a part of Win 7. VBScript is NOT an object-oriented language but an object-based language.
Testing Tools
Tools from a software testing context, can be defined as a product that supports one or more test activities right
from planning, requirements, creating a build, test execution, defect logging and test analysis.
Classification of Tools
Tools can be classified based on several parameters. It includes −

 The purpose of the tool

 The activities that are supported within the tool
 The type/level of testing it supports.
 The kind of licensing (open source, freeware, commercial)
 The technology used

e) WAPT :

WAPT Pro is a load Testing tool that can perform various types of Load Testing like Performance Testing, Stress
Testing, volume testing, Regression Testing, etc.
With WAPT Pro you can create many virtual user profiles for your test. This will help you emulate different types
of real website visitors. WAPT Pro can measure various parameters of the web server and database performance
during the test such as CPU, RAM, and network utilization.

WAPT Pro stores each profile in a file with ".wpp" extension. You can add any existing profile to your current test
scenario.

Key Features of WAPT Pro

 Tests can be recorded using any mobile or desktop browser.

 WAPT Pro can run tests with up to 4,000 concurrent virtual users with the default license and almost
unlimited number of users with the additional x64 Load Engines.
 Supports testing websites based on any OS, including all Unix and Windows platforms.
 Web application can be tested against the increasing load in terms of CPU, Memory (RAM) or network
usage.
 Can collect various database performance data for Oracle, MS SQL, or any other database that can be
retrieved through ODBC.
 Supports various web technologies like ASP.NET, JSON, Adobe Flash, etc.
 WAPT Pro enables in-depth reporting. Reports are available in both Excel and HTML formats.
 Advanced error reporting that is backed up by an integrated log viewer.
 Distributed load generation which also supports remote test control and cloud-based testing.
 Supports all types of proxy servers: HTTP(S), SOCKS4(5), etc.
 Server response processing with the JavaScript support.
 Support of IP spoofing. Hence you can emulate page requests coming from different IPs.

f) Win runner :

Win Runner is an automated functional GUI testing tool that allows a user to record and play back UI interactions
as test scripts. Win Runner is functional testing software for enterprise IT applications. It captures, verifies and
replays user interactions automatically, so you can identify defects and determine whether business processes
work as designed.

g) VTest :

vTest is a web automated testing tool for the regression & functional testing of web apps. It incorporates
record, verify, playback and reporting capabilities. vTest supports automated testing using both Microsoft
Internet Explorer and Mozilla Firefox. All popular Internet technologies such as HTTP, HTTPS/SSL, JavaScript,
DHTML & AJAX are supported. vTest also supports all major web application frameworks including ASP,
ASP.NET, J2EE, PHP, CFML, Ruby and Perl/CGI. vTest allows you to record and test your entire application in
minutes by simply pointing and clicking on your Web application. Without any programming, all objects are
automatically captured and recorded as a graphical script which shows the steps in your automated testing
script in the form of an icon-based tree. For those users who wish to use scripting, vTest uses JavaScript as the
scripting language. It provides a comprehensive JavaScript API that you can use to create customized
automated testing scripts. vTest creates scripts that adapt very well when your application's user interface
changes. Most automated testing tools create scripts that simply use the object name/ID to identify an object
in your application. vTest uses a sophisticated object identification algorithm to identify objects in your
application. This allows vTest scripts to adapt very well to changes in an application's user interface.
Benefits:
* Automate automated testing tasks and thus reduce time-to-market
* Enhance the efficiency of quality assurance engineers by allowing them to devote less time to manual
testing and more time to automated testing design
* Maximize reliability and robustness by providing the capability to run tests on demand or according to a set
schedule without the need for any user intervention
* Does not require a programming background. For those users who wish to use their programming skills,
vTest uses the industry standard JavaScript language
 PRACTICAL NO.2
AIM :
To Design test cases for testing the program with the black-box strategy.
Title:
Black Box Testing – Equivalence Partitioning and Boundary value Analysis
Problem Statement:

The program reads an arbitrary number of temperatures (as integer numbers) within the range -60°C … +60°C and
prints their mean value. Design test cases for testing the program with the black-box strategy.
Theory:

The first of the dynamic testing techniques are the specification-based testing techniques. These are also known as
'black-box' or input/output-driven testing techniques because they view the software as a black-box with inputs
and outputs, but they have no knowledge of how the system or component is structured inside the box. In essence,
the tester is concentrating on what the software does, not how it does it.
Functional testing is concerned with what the system does, its features or functions. Non-functional testing is
concerned with examining how well the system does something, rather than what it does. Non-functional aspects
(also known as quality characteristics or quality attributes) include performance, usability, portability,
maintainability, etc. Techniques to test these non-functional aspects are less procedural and less formalized than
those of other categories as the actual tests are more dependent on the type of system, what it does and the
resources available for the tests.
The four specification-based techniques are:
• Equivalence partitioning:

Equivalence partitioning (EP) is a good all-round specification-based black-box technique. It can be applied at
any level of testing and is often a good technique to use first. It is a common sense approach to testing, so much so
that most testers practise it informally even though they may not realize it.
The idea behind the technique is to divide (i.e. to partition) a set of test conditions into groups or sets that can be
considered the same (i.e. the system should handle them equivalently), hence 'equivalence partitioning'.
Equivalence partitions are also known as equivalence classes - the two terms mean exactly the same thing.
The equivalence-partitioning technique then requires that we need test only one condition from each partition.
This is because we are assuming that all the conditions in one partition will be treated in the same way by the
software. If one condition in a partition works, we assume all of the conditions in that partition will work, and so
there is little point in testing any of these others. Conversely, if one of the conditions in a partition does not work,
then we assume that none of the conditions in that partition will work so again there is little point in testing any
more in that partition. Of course these are simplifying assumptions that may not always be right but if we write
them down, at least it gives other people the chance to challenge the assumptions we have made and hopefully
help to identify better partitions.
• Boundary value analysis;

Boundary value analysis (BVA) is based on testing at the boundaries between partitions. If you have ever done
'range checking', you were probably Software Testing using the boundary value analysis technique, even if you
weren't aware of it. Note that we have both valid boundaries (in the valid partitions) and invalid boundaries (in the
invalid partitions).
• Decision tables;
• State transition testing.

Solution:
The program accepts integers between -60 and +60 so we apply Equivalence partitioning and Boundary Value
Analysis:
Equivalence partitions :
Test cases :

Conclusion:
As the program specifications are given. With the given specifications, the above test cases are generated and seem
to work well.
 PRACTICAL NO 3.
AIM :
To Design Decision table and test cases for Insurance renewal.
Title:
Cause-Effect Graphing-Black Box Software Testing Technique.
Problem Statement :

An insurance agency has the following norms fixed to provide premium for its policy holders:
a) If age<=25 and no claim has been made, premium increase will be $50, else $25.
b) If age<=25 and number of claims made is one, premium increase will be $100,else $50.
c) If age<=25 and number of claims are made is 2-4,premium increase will be $400,else $200.
d) If one or more claims are made,send warning letter. If number of claims made is 5 or more, cancel policy.
Draw the Decision table and design test cases for Insurance renewal.
Solution:
Cause Effect Graph:
Cause-Effect Graphing-Black Box Software Testing Technique:
This is basically a hardware testing technique adapted to software testing. It considers only the desired external
behaviour of a system. This is a testing technique that aids in selecting test cases that logically relate Causes
(inputs) to Effects (outputs) to produce test cases.
A “Cause” represents a distinct input condition that brings about an internal change in the system. An “Effect”
represents an output condition, a system transformation or a state resulting from a combination of causes.

According to Myer Cause & Effect Graphing is done through the following steps:
Step – 1: For a module, identify the input conditions (causes) and actions (effect).
Step – 2: Develop a cause-effect graph.
Step – 3: Transform cause-effect graph into a decision table.
Step – 4: Convert decision table rules to test cases. Each column of the decision table represents a test case.

Guidelines for cause-effect graphing:

1) If the variables refer to physical quantities, domain testing and equivalence class testing are indicated.
2) If the variables are independent, domain testing and equivalence class testing are indicated.
3) If the variables are dependent, decision table testing is indicated.
Software Testing
4) If the single-fault assumption is warranted, boundary value analysis (BVA) and robustness testing are indicated.
5) If the multiple-fault assumption is warranted, worst-case testing, robust worst-case testing and decision table
testing are identical.
6) If the program contains significant exception handling, robustness testing and decision table testing are
indicated.
7) If the variables refer to logical quantities, equivalence class testing and decision table testing are indicated

Conclusion:
The decision table and cause effect graph for the given situation are drawn.
 PRACTICAL NO.4

AIM :
To design test cases using branch , condition , decision and multiple decision coverage.

Title:
Branch – Decision – Condition Coverage
Problem Statement:

For the following liability procedure, design test cases using branch, condition, decision and multiple decision
coverage.
Procedure Liability(Age,Gender, Married,Premium)
Begin
Premium:=500;
If(Age<25) and (Gender=Male) and (not Married) Then
Premium=Premium+1500;
Else (if (Married or Gender=Female)) Then
Premium=Premium-200;
if (Age>45) and (Age<65) Then
Premium=Premium-100;
End;

Theory:

Statement Coverage:
Statement coverage is achieved when the condition becomes either true or false. The objective of statement
coverage is that all the statements in the program should be executed at least once. The statement coverage is
necessary but not sufficient.
Branch or decision coverage:
Statement coverage does not address all the outcome of the decisions. Branches like if … else, while …, for, do …
while are to be evaluated for both true and false.
Each branch direction must be traversed at least once.
Condition/Decision Coverage:
Branch coverage considers entire Boolean expression as one and tests for true and false. It ignores branches within
Boolean expressions occurring due to relational and logical operators. All conditions should be executed at least
once for true and false. Conditions using relational and logical operators should be checked for all possible
outcomes. Condition coverage checks for true and false outcome of each Boolean sub expressions.
Multiple condition coverage:
Multiple condition coverage checks whether every possible combination of Boolean sub expression occurs at least
once. Test cases required for full multiple condition coverage can be arrived at by using truth table of conditions.
A large number of test cases may be required for full multiple condition coverage.
Conclusion:
All the types of test cases are designed for testing
 PRACTICAL NO.5
AIM :
To design test cases that responds to input requests to change the display mode for a time display
device.
Title:
State Transition Testing
Problem Statement:

Specifications:
The software responds to input requests to change the display mode for a time display device.
The display mode can be set to one of the four values:
Two corresponding to displaying either time or date.
The other two when altering either time or date.
Four possible input requests:
Change mode (CM)
Reset (R)
Time Set (TS)
Date Set (DS)
Change Mode (CM):
Activation of this shall cause the display mode to move between “Display Time (T)” and “Display Date (D)”
Reset (R):
If display mode is set to T or D, then a “reset” shall cause the display mode to be set to “Alter time (AT)” or “Alter
Date (AD)” modes.
Time Set (TS):
Activation of this shall cause the display mode to return to T from AT.
Date Set (DS):
Activation of this shall cause the display mode to return to D from AD.
Draw the state transition diagram, possible transitions table, State table and write the test cases.

Theory:

State transition testing is used where some aspect of the system can be described in what is called a 'finite state
machine'. This simply means that the system can be in a (finite) number of different states, and the transitions
from one state to another are determined by the rules of the 'machine'. This is the model on which the system and
the tests are based. Any system where you get a different output for the same input, depending on what has
happened before, is a finite state system. A finite state system is often shown as a state diagram.
A state transition model has four basic parts:
• the states that the software may occupy;
• the transitions from one state to another;
• the events that cause a transition;
• the actions that result from a transition.

In any given state, one event can cause only one action, but that the same event - from a different state - may cause
a different action and a different end state.
Test conditions can be derived from the state graph in various ways. Each state can be noted as a test condition, as
can each transition. We can also consider transition pairs and triples and so on. Coverage of all individual
transitions is also known as 0-switch coverage, coverage of transition pairs is l-switch coverage, coverage of
transition triples is 2-switch coverage, etc. Deriving test cases from the state transition model is a black-box
approach. Measuring how much you have tested (covered) is
getting close to a white-box perspective. However, state transition testing is regarded as a black-box technique.
One of the advantages of the state transition technique is that the model can be as detailed or as abstract as you
need it to be. Where a part of the system is more important (that is, requires more testing) a greater depth of detail
can be modelled. Where the system is less important (requires less testing), the model can use a single state to
signify what would otherwise be a series of different states.

Testing for invalid transitions

Deriving tests only from a state graph (also known as a state chart) is very good for seeing the valid transitions, but
we may not easily see the negative tests, where we try to generate invalid transitions. In order to see the total
number of combinations of states and transitions, both valid and invalid, a state table is useful.
The state table lists all the states down one side of the table and all the events that cause transitions along the top
(or vice versa). Each cell then represents a state-event pair. The content of each cell indicates which state the
system will move to, when the corresponding event occurs while in the associated state. This will include possible
erroneous events - events that are not expected to happen in certain states. These are negative test conditions.

Test cases are initially derived from the state transition diagram to exercise each of the possible transitions (using
the abbreviated STD labels):

This indicates that for test case 1 the starting state is DISPLAYING TIME (S1), the input is 'change mode' (CM), the
expected output is 'display date' (D), and the finish state is DISPLAYING DATE (S2).
This set of six test cases exercises each of the possible transitions and so achieves 0-switch coverage [Chow]. Tests
written to achieve this level of coverage are limited in their ability to detect some types of faults because although
they will detect the most obvious incorrect transitions and outputs, they will not detect more subtle faults that are
only detectable through exercising sequences of transitions.
Tests written to achieve the next level of coverage, 1-switch, exercise all the possible sequential pairs of
transitions, of which there are ten in the manage_display_changes component:

This indicates that test case 1 comprises two transitions. For the first transition the starting state is DISPLAYING
TIME (S1), the initial input is 'change mode' (CM), the intermediate expected output is display date (D), and the
next state is DISPLAYING DATE (S2). For the second transition, the second input is 'change mode' (CM), the final
expected output is display time (T), and the finish state is DISPLAYING TIME (S1).
Note that intermediate states, and the inputs and outputs for each transition, are explicitly defined.
Longer sequences of transitions can be tested to achieve higher and higher levels of switch coverage, dependent on
the level of test thoroughness required.
A limitation of the test cases derived to achieve switch coverage is that they are designed to exercise only the valid
transitions in the component. A more thorough test of the component will also attempt to cause invalid transitions
to occur. The STD only

explicitly shows the valid transitions (all transitions not shown are considered invalid). A state model that
explicitly shows both valid and invalid transitions is the state table. The notation used for state tables is briefly
described below:

where Entry X = Finish State / Output for the given start state and input.
The state table for the manage_display_changes component is shown below:

Any entry where the state remains the same and the output is shown as null (N) represents a null transition, where
any actual transition that can be induced will represent a failure. It is the testing of these null transitions that is
ignored by test sets designed just to achieve switch coverage. Thus a more complete test set will test both possible
transitions and null transitions, which means testing the response of the component to all possible inputs in all
possible states. The state table provides an ideal means of directly deriving this set of test cases.
There are 16 entries in the table above representing each of the four possible inputs that can occur in each of the
four possible states, making 16 test cases which can be read from the state table as shown below:

Which corresponds to

If the above test cases are compared with those produced to achieve 0-switch coverage then it can be seen that by
also testing the null transitions an extra 10 test cases are created (3,4,7,8,9,10,12,13,14 and 15).
Conclusion:
The state transition table is drawn and the test cases are developed
 PRACTICAL NO.6
AIM :
To design test cases for drawing table with various function.
Title:
Data Flow Testing

For the above function, draw the following tables and write the test cases:
a. Occurrence of variables and their categories.
b. du pairs and their type
c. All c-uses
d. All p-uses

Theory:

Data flow testing is a structural testing technique that

• Aims to execute sub-paths from points where each variable is defined to points where it is referenced
• These sub-paths are called definition-use pairs or du-pairs (du-paths, du-chains)
• Data flow testing is centred on variables (data)

Most failures involve execution of an incorrect definition

– Incorrect assignment or input statement
– Incorrect path is taken, which leads to incorrect definition (predicate is faulty)
– Definition is missing (i.e. null definition)

Data flow testing follows the sequences of events related to a given data item with the objective to detect incorrect
sequences. It explores the effect of using the value produced by each and every computation.
Terminology:
• Variable definition

Occurrences of a variable where a variable is given a new value (assignment, input by the user, input from a file,
etc.)
Variable DECLARATION is NOT its definition !!!
• Variable uses

Occurrences of a variable where a variable is not given a new value (variable DECLARATION is NOT its use)
Software Testing .
– p-uses (predicate uses)

Occur in the predicate portion of a decision statement such as if-then-else, while-do etc.
– c-uses (computation uses)
All others, including variable occurrences in the right hand side of an assignment statement, or an output
statement
– du-path

A sub-path from a variable definition to its use

Data Flow testing
• Checks the correctness of the du-paths in a Control
– Flow Graph of a program
–
• Test case definitions based on four groups of coverage
– All definitions
– All c-uses
– All p-uses
– All du-paths

Data Flow testing: key steps

Given a code (program or pseudo-code)
1. Number the lines
2. List the variables
3. List occurrences & assign a category to each variable
4. Identify du-pairs and their use (p- or c- )
5. Define test cases, depending on the required coverage

Step 2: List the variables:

– A, B, C
– DISCRIM
– Is_Complex
– R1, R2

Step 3: List occurrences and assign a category to each variable

Step 4: Identify du-pairs and their use (p- or c- )
Conclusion:
13 test cases were designed for data flow testing.
 Practical No. 07

Software Requirement Specification of “Hotel Management System”

Deficiency Comments and Suggestions

There is no provision for changed rate & There should be Module to show changed rate
customer‟s feedback and space for customer‟s feedback

There was a confusion in the terms that who is We can use code name system for employees
the customer and who is a employees of the of the hotel to avoid confusion.
hotel.

Function Requirement

1. Reservation/Booking
1.1.The system shall record reservations.
1.2.The system shall record the customer‟s first name.
1.3.The system shall record the customer‟s last name.
1.4.The system shall record the number of occupants.
1.5.The system shall record the room number.
1.6.The system shall display the default room rate.
1.6.1. The system shall allow the default room rate to be changed.
1.6.2. The system shall require a comment to be entered, describing the reason for
changing the default room rate.
1.7.The system shall record the customer‟s phone number.
1.8.The system shall display whether or not the room is guaranteed.
1.9.The system shall generate a unique confirmation number for each reservation.
1.10. The system shall automatically cancel non-guaranteed reservations if the customer has
not provided their credit card number by 6:00 pm on the check-in date.
1.11. The system shall record the expected check-in date and time.
1.12. The system shall record the expected checkout date and time.
1.13. The system shall check-in customers.
1.14. The system shall allow reservations to be modified without having to reenter all the
customer information.
1.15. The system shall checkout customers.
1.15.1. The system shall display the amount owed by the customer.
1.15.2. To retrieve customer information the last name or room number shall be used
1.15.3. The system shall record that the room is empty.
1.15.4. The system shall record the payment.
1.15.5. The system shall record the payment type.
1.16. The system shall charge the customer for an extra night if they checkout after 11:00
a.m.
1.17. The system shall mark guaranteed rooms as “must pay” after 6:00 pm on the check-in
date.
The system shall record customer feedback.
2. Food
2.1.The system shall track all meals purchased in the hotel (restaurant and room service).
2.2.The system shall record payment and payment type for meals.
2.3.The system shall bill the current room if payment is not made at time of service.
2.4.The system shall accept reservations for the restaurant and room service.
3. Management
3.1.The system shall display the hotel occupancy for a specified period of time (days;
including past, present, and future dates).
3.2.The system shall display projected occupancy for a period of time (days).
3.3.The system shall display room revenue for a specified period of time (days).
3.4.The system shall display food revenue for a specified period of time (days).
3.5.The system shall display an exception report, showing where default room and food
prices have been overridden.
3.6.The system shall allow for the addition of information, regarding rooms, rates, menu
items, prices, and user profiles.
3.7.The system shall allow for the deletion of information, regarding rooms, rates, menu
items, prices, and user profiles.
3.8.The system shall allow for the modification of information, regarding rooms, rates, menu
items, prices, and user profiles.
The system shall allow managers to assign user passwords

Software Requirements Specification for “Online ticket booking system”

.

Defects Comments/Suggestion
Customer has to fill number of forms and Try to ask for only necessary information from the
Information which makes the process tedious. customer so that the processing will be quicker.
There is no provision for providing updates to the There should be some email facilities to provide
customer. updates to the customer.

Functional Requirements:

FR1: Allow all registered users to purchase tickets for concerts.

FR2: Allow someone to register to become a user.
FR3: The system will send out automated emails to validated users.
FR4: The user signup form should test that the form is filled in by a human and not a computer program.
FR5: Allow admin/staff users to add:
• Theaters
• Movies
• Show Time
• Cities/Towns
FR6: Allow admin/staff users to edit and delete:
• Theaters
• Movies
• Show time
FR6: The System will allow for semi automated emails, including:
• Birthday emails
• Movie Update emails
FR7: The system will allow clients to search for theaters by:
• City/Town
FR8: A client user should be able to edit some of their information
• Contact Details
o Address
o Telephone Number
o Email address
• Credit Card Details
• Password
FR9: The system will allow admin/staff users to make changes to certain settings including:
• Database
o Username
o Password
o Database Name
• Style and Formatting, without having to edit any PHP or CSS code.

FR10: The website should be simple to use for both client and staff so that a manual is not required for
either user, although some tool tips may be required on the administration side of the site.
 Practical No. 08

Unit Testing For “Online Ticket Booking System “

Sr. Requir Test Test Case Prereq Descrip Input data Expected Actual Res
No ement Case Objective uisite tion Output Output ult
. Id
1 FR5 TCI A Theater Run as Enter Theater A staff user Staff users Pass
_1 name can applicat the Name – Art should be are able to
be added ion details Centre, able to add add
to the and Town/City – information theaters to
system click Aberystwyth, into the the system
submit Capacity – system.
2500
2 FR5 TCI Only Run as Enter Login name: Only staff only Pass
_2 administrat applicat the Test user set as administrat
ors and ion details Password: administrat ors and
data entry and TestUser ors and data entry
staff can click data entry staff can
add submit staff should add
informatio be able to information
n gain access .
to add
information
3 FR6 TCI That a Run as select A staff user Movies Pass
_5 movie applicat movie should be information
informatio ion and able to can be
n can be click update edited.
updated delete information
button about a
movie that
exists in
the system.
4 FR6 TCI Only Run as Browse Browse Only staff only Pass
_6 administrat applicat direct direct link set as administrat
ors and ion link for for edit administrat ors and
data entry edit movies ors and data entry
staff can movies data entry staff can
edit staff should edit movies
movies be able to
gain access
to edit
movies.

5 FR6 TCI A movie Run as select click edit A staff user Movies can Pass
_7 can be applicat movie button should be be deleted.
 removed ion and able to
filled remove a
out movie from
informat the system
ion click
edit
button
6 FR5 TCI A Show Run as Enter A A Show Pass
_10 Time can applicat the staff/admin Time can
be added. ion details user should be added to
and be able to the
click add database.
submit information
about a
show time
of a movie
to the
system.
7 FR6 TCI A Show Run as Select click edit A staff user A Show Pass
_13 Time can applicat show button should be time can be
be updated ion time able to updated
filled update a
out show time
informat that exists
ion and on the
click system.
edit
8 FR6 TCI A band Run as select click delete A staff user a band can Pass
_15 can be applicat band button should be be deleted.
removed ion and able to
click remove a
delete band from
button the system.
9 FR5 TCI A city / Run as Enter City/town: A staff user A Pass
_18 town can applicat the Bristol should be city/town
be added. ion details able to add can be
and information added.
click about a
submit town or a
city into
the system.

10 FR5 TCI When a Run as click City/town: If a staff all required Pass
_19 city / town applicat submit user tries to fields must
is added ion add a city / be filled in
all require town and before the
 fields have leaves a data is
been filled required added to
in field blank the
they are database.
returned to
the concert
form and
informed
of the
error.
11 FR5 TCI A city / Run as Fill out City/town: If a staff a town or Pass
_20 town applicat city/tow Bristol user tries to city cannot
cannot be ion n name add a city be added
added and with the twice.
twice click same name
submit as another
city they
are
returned to
the concert
form and
informed
of the
error.
12 FR6, TCI A theater Run as add Movie :The If a staff A movie Pass
_24 cannot applicat movies Lost World user tries to cannot be
have two ion on same add a added if
movies time Show Time: concert for there is
booked on 3.00 p.m.- a movie already a
the same 5.30p.m. when one booking for
time. is already that movie
booked for on that
that time time.
they are
returned to
the Show
time form
and
informed
of the
error.

13 FR5, TCI The Run as a staff click submit If a staff if the Pass
FR6 _26 concert applicat user button user tries to release date
date ion tries to add a is after the
cannot be add a concert concert
after the concert with the date the
release with the ticket concert
date for ticket release date will not be
 the tickets release set after the added and
date set concert the user
after the date they will
concert are returned to
date returned to the concert
they are the concert form and
returned form and informed
to the informed of the
concert of the error.
form error.
14 FR2 TCI it is Run as filled First Name – Upon Test passed Pass
_32 possible applicat out Mark, completion – users are
for non- ion details Surname – of the able to sign
members and Bradley, client form up for the
of the site click Email the user site using
to sign up submit Address – should be the client
to become button mdb2@aber. registered form.
a member. ac.uk, Date with the
of Birth – 11 site.
June
1984,Addres
s Line 1 –
108D,Addres
s Line 2 –
Pentre Jane
Morgan,Tow
n–
Aberystwyth,
County –
Ceredigion,P
ostcode –
SY23
3TG,Telepho
ne Number –
0132244184
8,User Name
–
mdb2,Passw
ord –
password,Car
d Type: Card
B,Card
Number
0123987456,
Start Date:
07/2003,Expi
ry Date:
10/2008,Secu
rity Code
 951
15 FR2 TCI a client is Run as filled click login The client Users are Pass
_34 not able to applicat out user button should not able to
sign up ion name be able to change
without and sign up in their
the passwor the site if address
password d and the both details
in the click passwords once they
password login do not have
and re- button match. logged into
enter the site.
password
fields
matching.
16 FR9 TCI That a Run as filled click edit A client Pass
_35 client user applicat out button should be
can edit ion address able to edit
their info and their
address click address
details edit details
once they button once they
have have
signed in logged into
the
website.
17 FR9 TCI That a Run as filled click edit A client Users are Pass
_36 client user applicat out button should be able to
can edit ion credit able to edit change
their credit cart their credit their credit
card details card details card details
details and once they once they
once they click have have
have edit logged into logged into
signed in. button the the site.
website.

18 FR9 TCI That a Run as click click change A client Users are Pass
_37 client user applicat change password should be able to
can change ion passwor button able to edit change
their d link their their
password and password password
once they change once they once they
have passwor have have
signed in. d logged into logged into
the the site.
website.
19 FR8 TCI Basic Run as select click search The user User was Pass
_38 Search for applicat city and button should be shown a
a city ion search shown all list of all
returns concerts of the concerts in
correct concerts in the selected
results. the town city.
selected in
the drop
down
menu.
 Practical No. 09

Black box testing for Hotel management system

Using equivalence class partitioning method

Program:

#include<iostream.h>
#include<conio.h>
void main(){
clrscr();
int amount;
cout<<"\nEnter affordable amount for a room:";
cin>>amount;
if(amount <= 2000)
cout<<"\nRegular";
else if(amount < 4000)
cout<<"\nDelux";
else
cout<<"\nSuperDelux";
getch();}

Test no. Pre requisite Input values Expected result Actual result Remarks
T1.1 Amount 3000 Regular Regular Pass
<=2000
T1.2 2001<= 4000 Delux Super Delux Fail
Amount
<=4000
T1.3 Amount <=0 -500 Error Regular Fail
T1.4 Amount 4002 Super Delux Super Delux Pass
>=4001
T1.5 Amount 1000 Error Regular Fail
>=2000
Program Number Line number Actual Deficiencies Required Statement
1 12 Delux room is else if(amount<=4000)
categorized as Super
Delux
2 NA Error message not if(amount <= 0 ||
displayed on invalid amount >1000 )
input
Using boundary value analysis (BVA) method
#include<iostream.h>
#include<conio.h>
#include<stdlib.h>
void main()
{
clrscr();
int lower = 1;
int upper = 504;
int months;
cout<<"\nEnter any number of months between 1 and 504:\n";
cin>>months;
if(months<lower || months>upper)
{
cout<<"Entered number is not in given range";
}
if(months>=1 && months <= 6)
cout<<"\nTrainee";
else if( months > 6 && months <= 36 )
cout<<"\nJunior Staff";
else if(months>36 && months <=504)
cout<<"\nSenior Staff";
getch();
}

Test cases for BVA of given program:

Test case Prerequisite Input value Expected Actual result Remark

number result

1 months=1 1 Trainee Message Pass

”Trainee”

2 months=504 504 Senior Staff Message Pass

”Senior Staff”
3 months=0 0 Not in range Message Pass
”Entered
number is not
in given
range”

4 months=505 505 Not in range Message Pass

”Entered
number is not
in given
range”

5 months=35 35 Junior staff Message Pass

“Junior Staff”
 Practical No. 10
White box testing for Online Ticket booking system

Using branch coverage method

Program:

#include<iostream.h>
#include<conio.h>
void main()
{
clrscr();

int count = 0;
char section = „‟; // Balcony or Upperstall
bool success;
int availableInBalcony = 50
int availableInUpperstall = 75
cout<<"\nEnter length:";
cin>> count;
cout<<"\nEnter section:";
cin>> section;
success = 0;
while(count <= 100&& count >=0)
{
if(section = „Balcony‟)
{
if (count < = availableInBalcony )
{
availableInBalcony = availableInBalcony - count;
success = 1;
}
}
else
{
if (count < = availableInUpperstall)
{
availableInUpperstall = availableInUpperstall - count;
success = 1;
}
}
}
if (success = 1)
 cout"\n Your ticket is booked successfully.”;
else
cout"\n Your ticket can not be booked.”;

getch();
}

Test cases for given program using branch coverage:

Test Cases:
Test Case Input Value Expected Output Actual Output Remark

Number

Count Section

1 2 B 48 48 Pass

2 5 U 70 70 Pass

3 5 B 43 43 Pass

4 6 U 64 64 Pass

5 -5 B “MSG” “MSG” Pass

6 102 U “MSG” “MSG” Pass

7 10 B 33 33 Pass

8 34 B “MSG” “MSG” Pass

9 -10 U “MSG” “MSG” Pass

10 101 B “MSG” “MSG” Pass

Section Notation:

B=Available Balcony

U=Available Upper Stall

“MSG”= “Your ticket cannot be booked”

Branch/Loop Possible
Test Cases
values

1 2 3 4 5 6 7 8 9 10

Count<=100 T * * * * * *

F * * * *

Count<=B T * * * * *

F *

Count<=U T * *

F * *

Using Path coverage method

Program:-

#include<iostream.h>
#include<conio.h>
void main()
{
clrscr();
int charges=0;
int units=0;
int dis=0;
cout<<"\n Enter numbar of tickets :";
cin>>units;
if(units>=25)
{
dis=(500*units)/100;
charges=(units*20)-dis;
}
else
if(units>=10 && units<25)
{
 dis=(200*units)/100;
charges=(units*20)-dis;
}
else
if(units>0 && units<10)
charges=units*20;

else
cout<<"\n Number of tickets entered is INVALID";
cout<<"\n Amount of bill=Rs."<<charges;
getch();
}

a) Control Flow Graph

IF (units>=25) d

b
THE ELSE

IF((units>=10 && units<25)

e
THEN ELSE
c g
IF( units>0 && units<10)
h

THEN ELSE i

f
ENDIF k

j
ENDIF

l ENDIF m

n
b) Determine cyclomatic complexity of the control flow graph :

Cyclomatic Complexity of a graph is calculated as:

v(G) =e – n + 2

Where,
e = number of edges in the graph
n=number of nodes in the graph

Here,
e=14
n=12
And hence

v(G) = 14 – 12 + 2
=4

c) Find out basic set of independent path

Path 1: a-d-g-i-k-l-m-n
Path 2: a-d-g-h-j-l-m-n
Path 3: a-d-e-f-m-n
Path 4: a-b-c-n

d) Prepare test cases to execute each path in basic set of

Test Cases Table

Test Case Input Values Expected Output Actual Output Remark

Number

1 5 100 100 Pass

2 25 375 375 Pass

3 10 180 180 Pass

4 0 “MSG” “MSG” Pass

5 -5 “MSG” “MSG” Pass

6 7 140 140 Pass

7 27 405 405 Pass

8 12 216 216 Pass

9 29 435 435 Pass

10 32 480 480 Pass

e) Test Matrix:

Path(e.g. 1-2-3-4- Test Case Matrix

…-19)

1 2 3 4 5 6 7 8 9 10

a,d,g,i,l,m,n X X X

a,d,g,h,i,l,m,n X

a,d,e,f,m,n X X X

a,b,c,n X X X

Using condition coverage method For Hotel Management System

Program:

#include<stdio.h>
#include<conio.h>
void main()
{
int yrs,grade,hrs,bonus; //2
printf("Enter the no of years worked : "); //3
scanf("%d", &yrs); //4
printf("\nEnter the grade : "); //5
scanf("%d", &grade); //6
printf("\nEnter the no of hours worked"); //7
scanf("%d", &hrs); //8

if(yrs > 1) //9

bonus = bonus + 10; //10
if(grade > 3) //11
bonus = bonus + 10; //12
if(hrs > 180) //13
bonus = bonus + 10; //14
getch();//15
}
Conditional Coverage:

Yrs > 1 Grade > 3 Hrs > 180 Input value Possible Lines
(yrs,grd,hrs) outcome executed
(bonus)
F F F 1,1,160 0% 1-9, 11, 13,15

F F T 1,1,185 10% 1-9, 11,

13-15
F T F 1,5,100 10% 1-9,
11-13,15
F T T 1,4,190 20% 1-9, 11-15

T F F 3,2,50 10% 1-11, 13,15

T F T 3,2,200 20% 1-11, 13-15

T T F 3,4,100 20% 1-13, 15

T T T 3,5,200 30% 1-15