Project Report

/ o]c.
)co on
~UML Based Test Case Generation
vnicv {o nc viv {v{incn o{ cqvicncn {o nc
vccc o{ ^v.c o{ (onvc .icn.c
/)/) 11)I+ +)1(1)1I, (/)/)/1

5ubmitted 8y under the quidence of
MI1ALI SkIVAS1AVA Mrs DIVA kANIAN
MSC II ear Asst kCILSSCk
8nU Varanas| 8nU Vranas|

!#TMT OF COM!UT# SCIC
B#S HIU UIV#SITY
V#SI 221005
UTT# !#SH
II

Certification

epartment Of Computer Science
Banaras Hindu University
Varanasi-221005

This is certiIy that project work entitled ~ UML Based Test Case Generation is
submitted by Miss Mitali Srivastava, 2
nd
year Msc student under the supervision and guidance oI
Mrs. Divya Ranjan mam in partial IullIillment oI the requirement oI the award oI degree oI
Master OI Computer Science Irom Banaras Hindu University, Varanasi is bonaIied record oI
work carried out by them.

Forwarded by co- ordinator
Mrs. Divaya Ranjan Mr. V. K. Singh
Asst. proI. Asst. proI.
Department oI Computer Science Department oI computer science
Banaras Hindu University Banaras Hindu University
Varanasi-221005 Varanasi-221005

CKOWLGMT

e take great honor and privilege to thank the almighty Supreme God Ior his constant blessings
which enlightened us with new and innovative thoughts that led to the successIul completion oI
this project.
Apart Irom our eIIorts, the success oI any project depends largely on the encouragement and
guidelines oI many others. e take this opportunity to express our gratitude and deep respect to
the people who have been instrumental in the successIul completion oI this project.
e wish to express our deep sense oI gratitude and recpect to our beloved teachers, ProIessor
S.K.Basu, Dr. S.Karthikeyan, Dr. P.K.Mishra, Dr. Vivek Kr. Singh, Dr. Manjari Gupta, Dr.
Divya Ranjan and Dr. Vandana Kushwaha Ior their able guidance and useIul suggestions, which
helped us in completing the project work, in time.
Finally, yet importantly, e would like to express our heartIelt thanks to our beloved parents Ior
their unconditional blessings, our Iriends/classmates Ior their help and wishes Ior the successIul
completion oI this project.

Date: MITALI SRIVASTAVA
Place: Msc IV Semeseter

Contents

Section I.............................5
Introduction
Section II...............................9
2.1Problem domain
2.2 Review oI previous work

Section III...........................25
Solution methodology
O Conversion oI sequence diagram into a sequence graph
O Merging oI sequence graphs
O Test case generation

Section IV.............................44
Result Analysis and case study

Section V............................88
5.1Conclusion
5.2Iuture prospects

Section VI.............................91
6.1 reIerences
6.2 Source code

SCTIO I

IT#OUCTIO
1.1 Object oriented testing

1.2 Motivation and objective

1.3 Framework oI our approach

Introduction:

The basic goal oI soItware development process is to produce quality soItware that has no errors
or very Iew errors. In soItware development process errors can be introduced at any stage during
development. Testing plays a critical role in quality assurance Ior soItware. Testing is the activity
where the errors remaining Irom all previous phases must be detected. As the complexity and
size oI soItware grow, the time and eIIort required to do suIIicient testing grow. Manual testing
is time-consuming and error prone. ThereIore it is pressing to automate the testing eIIort. The
testing eIIort can be divided into three parts: test case generation, test execution, and test
evaluation.
Test cases is a sequence oI steps to test the correct behavior oI a Iunctionality/Ieature oI an
application or in other words it is a set oI conditions or variables under which a tester will
determine whether an application or soItware system is working correctly or not.
Test case generation is a diIIicult task in testing because each test case cost money, as eIIort is
needed to generate the test case. That is the reason there is need to minimize the number oI test
cases. There should be some criteria to select test cases that are the coverage criteria`s.
According to these criteria`s we Iind the test cases Irom diIIerent approaches to testing.
There are two traditional approaches to testing: black box and white box.
In black-box testing, the internal logic oI the system under testing is not considered and the test
cases are decided Irom specification or the requirements.
In white-box testing, the test cases are decided entirely on the internal logic oI the program or
module being tested. The external speciIications are not considered.
hite box testing can be used Ior unit testing, while at higher level mostly black-box testing is
used. It includes integration testing, system testing, acceptance testing.

Now a days soItware is becoming more and more complex and large. Managing, maintaining oI
the soItware with increased complexity has been Iound intractable with the use oI Iunction-
oriented paradigm. For this, soItware engineers have realized the need oI object-oriented
paradigm. Object oriented paradigm give a better way to solve a problem and maintain the
soItware in eIIective manner by using its basic properties like abstraction, encapsulation,
inheritance, and polymorphism. But at the same time, it has thrown several challenges to the
soItware tester Ior its strange properties like data hiding, run time polymorphism, dynamic
binding, dynamic object creation, and threading. It may be noted that traditional soItware testing
techniques are not suitable Ior testing object-oriented systems because they consider static view
oI code only, which is not suIIicient Ior testing dynamic behavior oI object-oriented system.
Further, use oI code to test an object-oriented system introduces another level oI complexity
because determination oI test inIormation aIter analyzing the code is complex and tedious task.
ith an alternative to code, soItware testers are recently considering model artiIacts oI soItware
because model provides higher level abstraction oI the system compared to the code, thus
helping soItware tester to understand the system better way and hence, Iind test inIormation aIter
simple processing oI model compared to the code. Further, the design model which is developed
much beIore the code is developed in soItware development liIe cycle, allows soItware engineers
to early start oI test case generation and subsequently applying those to detect the Iaults in the
implementation aIter the coding phase is over.
This allows carrying out testing activity parallel to other activities and thus reducing the soItware
development time unlike the code-based testing. As a consequence, model-driven testing Ior
object oriented systems has become a standard practice in soItware industries.

1.1Object oriented testing:

Object-Oriented testing basically Iocus on classes and objects. These testing Techniques Iocus
on classes and objects. Features such as class inheritance and InterIaces support polymorphism in
which code manipulates objects without their exact class being known. Testers must ensure that
the code works no matter what the exact class oI such objects might be. Features that support
data hiding Complicate testing because operations must be added to a class interIace by the
Developer just to support testing. categories oI object oriented testing:
Model testing
Class testing instead oI unit testing
Class interaction testing instead oI integration testing
System and subsystem testing
Acceptance testing
SelI-testing

UML esign Based Testing

The UniIied Modeling Language (UML) is a standard language Ior speciIying, visualizing,
constructing, and documenting the artiIacts oI soItware systems, as well as Ior business modeling
and other non-soItware systems. The UML represents a collection oI best engineering practices
that have proven successIul in the modeling oI large and complex systems. The UML is very
important Ior developing object oriented soItware. The UML uses mostly graphical notations to
express the design oI soItware projects. Use oI UML helps project teams communicate, explore
potential designs, and validate the architectural design oI the soItware.
Testing generally divided into two kinds:
VeriIication
Validation
So design based testing mainly Iocus on veriIication testing. The promising alternative Ior testing
object-oriented soItware`s is use oI UML based designs.UML based designs give detailed
speciIications oI expected Iunctionality. UML diagrams may be used Ior generating test cases
automatically. As class diagram elaborate the static behavior oI soItware, main Iocuses is on
classes and relationships like generalization and dependency. Sequence diagram elaborate the
dynamic behavior oI soItware. In sequence diagram we Iocus on message calling between object
and class with diIIerent relationships like calling message, calling return etc.

1.2Motivation & Objective:

Testing is very important part oI soItware development process. It takes halI oI the time oI the
soItware development. Testing is perIormed on the requirements, code and design with diIIerent
methodologies. But still Iailure rate oI the soItware project is about 80. The reason Ior Iailure
is because the testing perIormed on the code is not suIIicient to detect various types oI errors in
the soItware. Generally practitioners consider code testing as most important. As the behavior oI
the executable code can be tested and practitioners consider only Iaults in code as soItware
Iailure. So testing only code and ignoring all other artiIacts may result in catastrophic type oI
Iailure. Design phase is very important part because whole coding part depends on this phase.
But generally testing oI soItware design is avoided or done partially. Because design is not
executable part. So testing oI a design becomes very cumbersome.

Another reason, now a day`s soItware is very large and complex and developer has minimal lead
time to assure the quality oI soItware. Several challenges are thereIore arisen to meet the current
need oI Iaster soItware development without compromise in soItware quality. The main
challenge is: generation oI test cases at an early stage oI the soItware development process so
that test cases are ready beIore the code is developed and thus allowing testing (test case
generation) and coding activities to be carried out in parallel, and to Iocus the testing oI those
parts in the code, which are oI higher priority in view oI criticalness or complexity so that better
quality soItware is developed with limited testing eIIort (instead oI exhaustive testing). To
address this challenge that is generation oI test cases at an early phase oI the soItware
development, soItware engineers consider UML design models.

UML deals with object oriented design method. UML has diIIerent diagrams that speciIy all
design behaviors like static and dynamic behavior.

Objective:

Following are the objectives in our work.

O Obtain a testable model Irom UML 2.0 diagrams. Testable model is a graph that contains
necessary test inIormation only. There is a need Ior testable model because inIormation
which are encapsulated in UML diagrams is diIIicult to Iully automate and complex to
process. Further all inIormation in design model are usually not necessary Ior testing
point oI view.
O Generate test cases Irom testable model, which means to determine input, expected
system responses satisIying certain coverage criteria and targeting a Iault model.

1.3The framework of our approach:
draw uML sequence dlagram for all
scenarlos of a use case
ConverL all Lhe sequence dlagrams Lo
correspondlng sequence graphs
Merge all sequence graphs lnLo a slngle
sequence graph
CeneraLe paLhs from sequence graph by
uslng paLh coverage crlLerla
CeneraLe LesL cases from paLhs by uslng one
Lo one correspondence beLween sequence
graph and paLhs

Fig 1.1 the framework of approch

SCTIO II :!#OBLM OMI

2.1 UML diagrams

2.2 Introduction to levels oI testing

2.3 Traditional testing methodologies

2.4 Testing related terms

2.1 UML diagrams:
n overview:
UML is a standard language Ior speciIying, visualizing, constructing, and documenting the
artiIacts oI soItware systems.UML was created by Object Management Group (OMG) and UML
1.0 speciIication draIt was proposed to the OMG in January 1997.
O UML stands Ior UniIied Modeling Language.
O UML is diIIerent Irom the other common programming languages like C, Java, and
COBOL etc.
O UML is a pictorial language used to make soItware blue prints.
So UML can be described as a general purpose visual modeling language to visualize, speciIy,
construct and document soItware system. Although UML is generally used to model soItware
systems but it is not limited within this boundary. It is also used to model non soItware systems
as well like process Ilow in a manuIacturing unit etc.
UML is not a programming language but tools can be used to generate code in various languages
using UML diagrams. UML has a direct relation with object oriented analysis and design.
Goals of UML:
Object oriented concepts were introduced much earlier than UML. So at that time there were no
standard methodologies to organize and consolidate the object oriented development. At that
point oI time UML came into picture.
There are a number oI goals Ior developing UML but the most important is to deIine some
general purpose modeling language which all modelers can use and also it needs to be made
simple to understand and use.
UML diagrams are not only made Ior developers but also Ior business users, common people and
anybody interested to understand the system. The system can be a soItware or non soItware. So it
must be clear that UML is not a development method rather it accompanies with processes to
make a successIul system.
At the conclusion the goal oI UML can be deIined as a simple modeling mechanism to model all
possible practical systems in today.s complex environment.
OO nalysis and esign
Object Oriented analysis can be deIined as investigation and to be more speciIic it is the
investigation oI objects. Design means collaboration oI identiIied objects.
So it is important to understand the OO analysis and design concepts. Now the most important
purpose oI OO analysis is to identiIy objects oI a system to be designed. This analysis is also
done Ior an existing system. Now an eIIicient analysis is only possible when we are able to start
thinking in a way where objects can be identiIied. AIter identiIying the objects their relationships
are identiIied and Iinally the design is produced.
So the purpose oI OO analysis and design can described as:
O IdentiIying the objects oI a system.
O IdentiIy their relationships.
O Make a design which can be converted to executables using OO languages.
There are three basic steps where the OO concepts are applied and implemented. The steps can
be deIined as
OO Analysis --~ OO Design --~ OO implementation using OO languages
Now the above three points can be described in details:
O During object oriented analysis the most important purpose is to identiIy objects and
describing them in a proper way. II these objects are identiIied eIIiciently then the next
job oI design is easy. The objects should be identiIied with responsibilities.
Responsibilities are the Iunctions perIormed by the object. Each and every object has
some type oI responsibilities to be perIormed. hen these responsibilities are
collaborated the purpose oI the system is IulIilled.
O The second phase is object oriented design. During this phase emphasis is given upon the
requirements and their IulIillment. In this stage the objects are collaborated according to
their intended association. AIter the association is complete the design is also complete.
O The third phase is object oriented implementation. In this phase the design is
implemented using object oriented languages like Java, C etc.

#ole of UML in OO design:
UML is a modeling language used to model soItware and non soItware systems. Although UML
is used Ior non soItware systems the emphasis is on modeling object oriented soItware
applications. Most oI the UML diagrams discussed so Iar are used to model diIIerent aspects like
static, dynamic etc. Now what ever be the aspect the artiIacts are nothing but objects.
II we look into class diagram, object diagram, collaboration diagram, interaction diagrams all
would basically be designed based on the objects.
So the relation between OO design and UML is very important to understand. The OO design is
transIormed into UML diagrams according to the requirement. BeIore understanding the UML in
details the OO concepts should be learned properly. Once the OO analysis and design is done the
next step is very easy. The input Irom the OO analysis and design is the input to the UML
diagrams.
Modeling types:
DiIIerent diagrams are used Ior diIIerent type oI UML modeling. There are three important type
oI UML modeling`s:
Structural modeling:
Structural modeling captures the static Ieatures oI a system. They consist oI the Iollowings:
O Classes diagrams
O Objects diagrams
O Deployment diagrams
O Package diagrams
O Composite structure diagram
O Component diagram
Structural model represents the Iramework Ior the system and this Iramework is the place where
all other components exist. So the class diagram, component diagram and deployment diagrams
are the part oI structural modeling. They all represent the elements and the mechanism to
assemble them.
But the structural model never describes the dynamic behavior oI the system. Class diagram is
the most widely used structural diagram.
Behavioral Modeling:
Behavioral model describes the interaction in the system. It represents the interaction among the
structural diagrams. Behavioral modeling shows the dynamic nature oI the system. They consist
oI the Iollowing:
O Activity diagrams
O Interaction diagrams
O Use case diagrams
All the above show the dynamic sequence oI Ilow in a system.

rchitectural Modeling:
Architectural model represents the overall Iramework oI the system. It contains both structural
and behavioral elements oI the system. Architectural model can be deIined as the blue print oI
the entire system. Package diagram comes under architectural modeling.
UML Standard iagrams:
@here are Lwo broad caLegorles of dlagrams and Lhen are agaln dlvlded lnLo subcaLegorles
O Structural Diagrams
O Behavioral Diagrams
Structural iagrams:
The structural diagrams represent the static aspect oI the system. These static aspects represent
those parts oI a diagram which Iorms the main structure and thereIore stable.These static parts
are represents by classes, interIaces, objects, components and nodes. The Iour structural
diagrams are:
O Class diagram
O Object diagram
O Component diagram
O Deployment diagram
ass Diagram:
Class diagrams are the most common diagrams used in UML.
Class diagram consists oI classes, interIaces, associations and
collaboration. Class diagrams basically represent the object
oriented view oI a system which is static in nature. Active class is
used in a class diagram to represent the concurrency oI the
system.Class diagram represents the object orientation oI a
system. So it is generally used Ior development purpose. This is
the most widely used diagram at the time oI system construction.

Object Diagram:
Object diagrams can be described as an instance oI
class diagram. So these diagrams are more close to
real liIe scenarios where we implement a system.
Object diagrams are a set oI objects and their
relationships just like class diagrams and also
represent the static view oI the system.
The usage oI object diagrams is similar to class
diagrams but they are used to build prototype oI a system Irom practical perspective.
omponent Diagram:
Component diagrams represent a set oI components and
their relationships. These components consist oI classes,
interIaces or collaborations.
So Component diagrams represent the implementation
view oI a system.
During design phase soItware artiIacts (classes,
interIaces etc) oI a system are arranged in diIIerent
groups depending upon their relationship. Now these
groups are known as components.
Finally, component diagrams are used to visualize the
implementation.

Depoyment Diagram:
Deployment diagrams are a set oI nodes and their
relationships. These nodes are physical entities where the
components are deployed.
Deployment diagrams are used Ior visualizing deployment
view oI a system. This is generally used by the deployment
team.

It is very clear that all the diagrams described above are having some relationship with
one another. Component diagrams are dependent upon the classes, interfaces etc which are
part of class/object diagram. gain the deployment diagram is dependent upon the
components which are used to make a component diagrams.

Behavioral iagrams:
Any system can have two aspects, static and dynamic. So a model is considered as complete
when both the aspects are covered Iully.
Behavioral diagrams basically capture the dynamic aspect oI a system. Dynamic aspect can be
Iurther described as the changing/moving parts oI a system.
UML has the Iollowing Iive types oI behavioral diagrams:
O Use case diagram
O Sequence diagram
O Collaboration diagram
O State chart diagram
O Activity diagram
&se case Diagram:
Use case diagrams are a set oI use cases, actors
and their relationships. They represent the use
case view oI a system.
A use case represents a particular Iunctionality oI
a system.
So use case diagram is used to describe the
relationships among the Iunctionalities and their
internal/external controllers. These controllers
are known as actors.
oaboration Diagram:
Collaboration diagram is another Iorm oI interaction diagram. It represents the structural
organization oI a system and the messages sent/received. Structural organization consists oI
objects and links.

The purpose oI collaboration diagram is similar to sequence diagram. But the speciIic purpose oI
collaboration diagram is to visualize the organization oI objects and their interaction.

$tate chart Diagram:
Any real time system is expected to
be reacted by some kind oI
internal/external events. These events
are responsible Ior state change oI the
system.

State chart diagram is used to
represent the event driven state
change oI a system. It basically
describes the state change oI a class,
interIace etc.

State chart diagram is used to
visualize the reaction oI a system by
internal/external Iactors.
Activity Diagram:
Activity diagram describes the Ilow oI
control in a system. So it consists oI
activities and links. The Ilow can be
sequential, concurrent or branched.
Activities are nothing but the Iunctions oI a
system. Numbers oI activity diagrams are
prepared to capture the entire Ilow in a
system.
Activity diagrams are used to visualize the
Ilow oI controls in a system. This is
prepared to have an idea oI how the system
will work when executed.
S"UC IG#M:
A sequence diagram is an important behavioral diagram. It is generally used Ior modeling
Interaction view oI use case scenario or a use case. This diagram shows the sequence oI message
interactions among diIIerent objects as well as interaction between an external user and objects
involved. e categorize three types oI objects depending on the role they play within the system:
entity objects, controller objects, and boundary Objects. An entity object represents a business
concept and contains useIul inIormation. A Controller object controls services oIIered by
diIIerent entity objects and also encapsulates Business logic. Boundary objects act as interIaces
between a user and the system.An example oI a sequence diagram is shown in Iollowing Iigure:
we see Iour objects a,ss
oundary
a ulsplay
lnLerface
nLlLy
d Message
ConLroller
b Message
ConLroller
nLlLy
c Address ook
user
m1()
m2()
m3
m5
m4
m6
m7
Sequence diagram: an overview
-, c and d participating in the interactions. Here, object a is a boundary object, object - is a
controller object, and objects c and d are the two entity objects (see labels associated with the
objects). Dotted lines Irom the object show liIe lines (means it is live). An arrow connecting two
liIe lines represents message. m1(),m2(), .. , m7() are the seven messages Exchanged among
these objects. e see that upon receipt a message m1 () at the object a Irom the user, object a
sends a message m2() to the controller object -, which in turn sends another messages m3() to an
entity object d and so on. Note that m5() is a message that the object d invokes itselI.

2.2Introduction to levels of testing:

Unit testing:

A unit is smallest testable piece oI soItware which can be compiled, linked, loaded e.g
Iunction/procedure, classes, and interIaces.
Unit testing reIers to tests that veriIy the Iunctionality oI a speciIic section oI code, usually at
the Iunction level. In an object-oriented environment, this is usually at the class level, and the
minimal unit tests include the constructors and destructors.
This testing generally done by programmer as they work on code to ensure that working Iunction
as expected or not. One Iunction might have multiple tests, to catch corner cases or other
branches in the code. Unit testing alone cannot veriIy the Iunctionality oI a piece oI soItware, but
rather is used to assure that the building blocks the soItware uses work independently oI each
other.

Integration testing:

Integration testing seeks to veriIy the interIaces between components against a soItware design.
SoItware components may be integrated in an iterative way or all together (big bang approach).
Normally the Iormer is considered a better practice since it allows interIace issues to be localized
more quickly and Iixed.
This done by developers/testers.Test cases written when detailed speciIication is
Ready. It is used to discover inconsistencies in the combination oI units.

System testing :

System testing oI soItware or hardware is testing conducted on a complete, integrated system to
evaluate the system's compliance with its speciIied requirements. System testing Ialls within the
scope oI black box testing, and as such, should require no knowledge oI the inner design oI the
code or logic.
System testing is perIormed on the entire system in the context oI a Functional Requirement
SpeciIication(s) (FRS) and/or a System Requirement SpeciIication (SRS). System testing tests
not only the design, but also the behavior and even the believed expectations oI the customer. It
is also intended to test up to and beyond the bounds deIined in the soItware/hardware
requirements speciIication. It is generally done by test team. Test cases are written when high
level design speciIication is ready. It is done system test machine usually in a simulated
environment e.g. VMware

cceptance testing:

cceptance testing is a test conducted to determine iI the requirements oI a speciIication or
contract are met. It may involve chemical tests, physical tests, or perIormance tests. It
demonstrates satisIaction oI user and usually merged with system testing.
It is done by test team and customer and in simulated environment/real environment.

#egression testing:
#egression testing is any type oI soItware testing that seeks to uncover new errors, or
regressions, in existing Iunctionality aIter changes have been made to the soItware, such as
Iunctional enhancements, patches or conIiguration changes.
The intent oI regression testing is to assure that a change, such as a bug Iix, did not introduce
new bugs. One oI the main reasons Ior regression testing is that it's oIten extremely diIIicult Ior a
programmer to Iigure out how a change in one part oI the soItware will echo in other parts oI the
soItware.
Common methods oI regression testing include rerunning previously run tests and checking
whether program behavior has changed and whether previously Iixed Iaults have re-emerged.
Regression testing can be used to test a system eIIiciently by systematically selecting the
appropriate minimum set oI tests needed to adequately cover a particular change.

#elationship between SLC and testing:

V- Model involves testing activities parallel to development activities. V-Model illustrates how
testing activities can be integrated into each phase oI soItware development liIe cycle.
V-Model:

In the model shown, leIt side oI the model Iocuses on development activities.
#equirement specification: Capturing oI user requirement to build a product.
Module specification: Module design oI each component identiIied in the Iunctional
speciIication.
!rogram Specification: Detailed design oI each unit to be built to meet requirement.
Middle oI V-Model shows that planning Ior testing should start with each work artiIacts. For an
example, using requirement speciIication, acceptance testing would be planned, right at the start
oI the development.
Coding starts when the program speciIication is completed. Once Coding is completed the test
phase starts with unit testing using the unit test plan created during program speciIication phase.
Right hand side Iocuses on testing activities. For each work artiIact, a testing activity is
identiIied.
Testing against the requirement speciIication takes place at the Acceptance Testing stage.
Testing against the Iunctional speciIication takes place at the System Testing stage.
Testing against the technical speciIication takes place at the Integration Testing stage.
Testing against the program speciIication takes place at the Unit Testing stage.
This allows testing to be concentrated on the detail provided in each work artiIacts, so that
deIects can be identiIied as early as possible in the liIe cycle when the work artiIacts has been
created.

2.3T#ITIOL TSTIG MTHOOLOGIS:
SoItware testing methods are traditionally divided into Iollowing two approches:
O White-box testing (clear box testing, glass box testing, transparent box testing, or
structural testing)
O Black-box testing(Iunctional testing)
These two approaches are used to describe the point oI view to design test cases.

White-box testing:
White-box testing is a method oI testing soItware that tests internal structures or workings oI an
application, as opposed to its Iunctionality (i.e. black-box testing). In white-box testing an
internal perspective oI the system, as well as programming skills, are required and used to design
test cases. The tester chooses inputs to exercise paths through the code and determine the
appropriate outputs.
white-box testing can be applied at the unit, integration and system levels oI the soItware testing
process, it is usually done at the unit level. It can test paths within a unit, paths between units
during integration, and between subsystems during a system level test. Though this method oI
test design can uncover many errors or problems, it might not detect unimplemented parts oI the
speciIication or missing requirements.
White-box test design techniques include:
O Control Ilow testing
O Data Ilow testing
O Branch testing
O Path testing
hite box testing methods can also be used to evaluate the completeness oI a test suite(test
coverage) that was created with black box testing methods. This allows the soItware team to
examine parts oI a system that are rarely tested and ensures that the most important Iunction
points have been tested.
Black box testing:
Black-box testing is a method oI soItware testing that tests the Iunctionality oI an application as
opposed to its internal structures or workings . SpeciIic knowledge oI the application's
code/internal structure and programming knowledge in general is not required. Test cases are
built around speciIications and requirements, i.e., what the application is supposed to do. It uses
external descriptions oI the soItware, including speciIications, requirements, and design to derive
test cases. These tests can be Iunctional or non-Iunctional, though usually Iunctional. The test
designer selects valid and invalid inputs and determines the correct output. There is no
knowledge oI the test object's internal structure.
This method oI test can be applied to all levels oI soItware testing: unit, integration, Iunctional,
system and acceptance. It typically comprises most iI not all testing at higher levels, but can also
dominate unit testing as well.
Typical black-box test design techniques include:
O Decision table testing
O All-pairs testing
O State transition tables
O Equivalence partitioning
O Boundary value analysis
Grey box testing
Grey box testing involves having knowledge oI internal data structures and algorithms Ior
purposes oI designing the test cases, but testing at the user, or black-box level. Manipulating
input data and Iormatting output do not qualiIy as grey box, because the input and output are
clearly outside oI the "black-box" that we are calling the system under test. This distinction is
particularly important when conducting integration testing between two modules oI code written
by two diIIerent developers, where only the interIaces are exposed Ior test. However, modiIying
a data repository does qualiIy as grey box, as the user would not normally be able to change the
data outside oI the system under test. Grey box testing may also include reverse engineering to
determine, Ior instance, boundary values or error messages.

2.4 TSTIG #LT T#MS:
Test cases:
A test or test case is a general soItware artiIact that includes test case input values, expected
outputs Ior the test case, and any inputs that are necessary to put the soItware system into the
state that is appropriate Ior the test input values. A test speciIication language (TSL) is a
language that can be used to describe all components oI a test case. The components that we
consider are test case values, preIix values, veriIy values, exit commands, and expected outputs.
Test case values directly satisIy the test requirements, and the other components supply
supporting values. A test case value is the essential part oI a test case, the values that come Irom
the test requirements. It may be a command, user inputs, or soItware Iunction and values Ior its
parameters.
e.g. State-based soItware, test case values are usually derived directly Irom triggering events and
preconditions Ior transitions. A test case preIix value includes all inputs necessary to reach the
pre-state and to give the triggering event variables their beIore-values. Any inputs that are
necessary to show the results are veriIy values, and exit commands depend on the system being
tested. Expected outputs are created Irom the aIter-values oI the triggering events and any post
conditions that are associated with the transition.
Test suits:
is a collection oI test cases that are intended to be used to test a soItware program to show that it
has some speciIied set oI behaviors. A test suite oIten contains detailed instructions or goals Ior
each collection oI test cases and inIormation on the system conIiguration to be used during
testing. A group oI test cases may also contain prerequisite states or steps, and descriptions oI the
Iollowing tests.
Test oracle:
A test oracle is a mechanism used by soItware testers and soItware engineers Ior determining
whether a test has passed or Iailed .It is used by comparing the output(s) oI the system under test,
Ior a given test case input, to the outputs that the oracle determines that product should have.
Oracles are always separate Irom the system under test
..

Test coverage:
A measure oI the proportion oI a program exercised by a test suite, usually expressed as a
percentage. This will typically involve collecting inIormation about which parts oI a program are
actually executed when running the test suite in order to identiIy which branches oI conditional
statements which have been taken.
The most basic level oI test coverage is code coverage testing and the most methodical is path
coverage testing. Some intermediate levels oI test coverage exist, but are rarely used.
Code coverage:
Code coverage describes the degree to which the source code oI a program has been tested. It is
a Iorm oI testing that inspects the code directly and is thereIore a Iorm oI white box testing.
!ath coverage:
Path coverage is one oI the metrics used in white box testing to check whether each oI the
possible paths in each Iunction have been Iollowed. A path is a unique sequence oI branches
Irom the Iunction entry to the exit.
Coverage criteria
To measure how well the program is exercised by a test suite, one or more coverage criteria are
used
SCTIO II B: #VIW OF !#VIOUS WO#K

IT#OUCTIO
Many researchers have been working in generating optimal test cases based on the
speciIications; still 100 testing is impossibility. Modeling languages are used to get the
speciIication and generate test cases. Since UML (UniIied Modeling Language) is the most
widely used language, many researchers are using UML diagrams such as state-chart diagrams,
use-case diagrams, sequence diagrams, etc to generate test cases and this has led to Model based
test case generation.
UML can be visualized as Iour meta-model architecture with three logical sub packages:
Foundation, Behavioral elements and Model management. UML provides capability to explore
static and dynamic behavior and physical deployment oI a system. The possibility oI using UML
Ior soItware testing was addressed by Clay . Williams 7]. UML models are built
extensively Ior Object Oriented soItware systems. Class diagram, state diagram and OMT
(Object Modeling Technique) and uniIied process are used to test Object Oriented systems
Even though variety oI approaches have been proposed, with the advent oI modeling tools like
Rational Rose, Ior a decade there has been constant research on generating test cases based on
speciIications and design models.
But In this section, we discuss generation oI test cases Irom UML diagrams in general, and
system level testing in particular.
L. C. Briand et al. 8] propose the %% (%0sting -0ct-ori0nt0d syst0ms with th0
unifi0d od0ling languag0 system Ior system level testing. In their approach, all possible
invocation oI use case sequences is captured in the Iorm oI an activity diagram. They consider
sequence diagrams to represent use case scenarios. Further, they propose to derive various test
inIormation, test requirements, test cases and test oracles Irom the detailed design description
embedded in UML diagrams and expressed in Object Constraint Language (OCL).

In 9], 1. Hartmann et al. describe an approach oI system testing using UML activity
diagrams. Their approach takes the textual description oI a use case as input and converts it into
an activity diagram semi- automatically to capture test cases. They also add test requirements to
the test cases with the help oI stereotypes. Test data (a set oI executable test scripts) are then
generated applying category partition method.

In a work on scenario-based testing 11], Xiaoping BI et al. consider a hierarchy
oI activity diagrams where top level activity diagram captures use case dependencies and low
level activity diagram represents behavior oI the use case. They eliminate the hierarchy structure
oI the activity diagrams and convert them into a attend system level activity diagram. Finally, it
is converted into an activity graph by replacing conditional branching into its equivalent
execution paths, and concurrency into serial sequences. This activity graph is a graphic
representation oI the execution called thin-thread tree. A thin thread is basically a usage scenario
in a soItware system Irom the end user's point oI view. Thin threads are Iurther processed to
generate test cases.
Activity diagram is also used Ior gray-box testing and checking consistency between code and
design 22,25]

In 10], Wang Linzhang et al. propose an approach oI gray-box testing using activity
diagram. In gray-box testing approach, test cases are generated based on high level design
models, which represent the expected structure and behavior oI soItware under testing. In their
approach, they consider an activity diagram to model n operation by representing a method oI a
class to an activity and swim lane to a class. Test scenarios are generated Irom this activity
diagram Iollowing basic path coverage criteria which tells that a loop is to be executed at most
once. Basic path coverage criteria help to avoid path explosion Ior the presence oI a loop. Test
scenarios are Iurther processed to derive gray-box test cases.

In 13], Chen Mingsong et al. present an idea to obtain the reduced test suite Ior an
implementation Iollowing an activity diagram. They consider the random generation oI test cases
Ior the Java program. Running the program Iollowing the test cases, they obtain the program
execution traces. Finally, reduced test suite is obtained by comparing the simple paths with
program execution traces. Simple path coverage criteria help to avoid the path explosion due to
the presence oI loop and concurrency.

In 12], Falk Fraikin et al. present a tool called SeDiTeC Ior testing a Java application
using sequence diagrams. For validation oI tests, SeDiTeC captures the inIormation such as
method parameter, return values oI all methods etc. Ior all objects, which are relevant in the
sequence diagrams and with the help oI code instrumentation. This inIormation is then used to
Iorm the observed sequence diagrams. Finally, observed sequence diagrams are compared to the
input sequence diagrams corresponding to the implementation under test. To support testing at
the beginning oI implementation phase, SeDiTeC is also capable to generate test stubs.

In 15], ebasis Kundu and Monalisa Sharma present a approach based on Uml
activity diagram. They consider a test coverage criterion, called activity path coverage criterion.
The test cases generated using our approach is capable oI detecting more Iaults like
synchronization Iaults, loop Iaults unlike the existing approaches.

In 16] ,ebasis Kundu and Monalisha Sharma again proposed a new approach to
generate test cases. Their approach consists oI transIorming a UML sequence diagram into a
graph called the sequence diagram graph (SDG) and augmenting the SDG nodes with diIIerent
inIormation
Necessary to compose test vectors. These inIormation are mined Irom use case templates, class
diagrams and data dictionary. The SDG is then traversed to generate test cases. The test cases
thus generated are suitable Ior system testing and to detect interaction and scenario Iaults.

SCTIO III
Solution Methodology
3.1Conversion oI sequence diagram into a sequence graph

3.2Merging oI sequence graphs

3.4Test case generation

Solution Methodologies
3.1conversion of sequence diagram into sequence graph
Sequence Graph and Some efinition:

e deIine a sequence graph denoted as SG below.
Definition 1: A sequence graph SG is a directed graph G(V,E,S,EN) where

V V1, V2; .. VN) is a Iinite set oI nodes.

E is SUBSET oI V V .

S V* is the start node and V* V
.
EN V1`,V2`....Vp`} is a Iinite set oI end nodes, where Vi`V
i 1,2...p.

$ome notations:

M m1,m2..mn}, set oI all messages received by the boundary objects in the se-
quence diagram.

M1mi/miM , and mi is received Irom any object inside the system except Irom
the user}

M1mj/mjM, and mj is received only Irom the user}
It may be noted that M M1 M2 and M1` M2

e deIine a relation, called the precedence relation, which is deIined below.

Defnition 2 : A precedence relation denoted as , is deIined over M such as, iI mi M
occurs immediately beIore mk M according to the timing order in the sequence diagram
then there exists a precedence relation between mi and mk, and written as mi mk. In
other words, it implies that iI there exists a precedence relation between any two messages
mi and mk in M then there would be no mp M such that, mi mp and mp mk.
This relation satisIies two properties.

II mi mk then, mk mi, where mi,mk M symmetric].

II mi mj and mj mk, then mi mk, where mi,mj ,mk M on-transitive].

Conversion of sequence diagram into sequence graph:

Sequence graph is a directed graph which encapsulates system responses corresponding
to user input. To construct a sequence graph Irom a sequence diagram, we propose the
Following two steps as mentioned below.

O For each miM1` we associate a node Vi V oI SG and label the Vi with the same name
as the message mi. Applying the precedence relation over set oI messages M1`. we obtain
a set say, R1`For each ri R1`where ri mimk and mi,mk M1`.we make a direct edge
Irom Vi V to Vk V , where Vi and Vk in SG have correspondences with the
messages mi and mk in M1`respectively.

O e obtain another set namely, R on applying the precedence relation over a set oI
messages M. e then select a pair (ri, rk) Irom R such that ri mi mj , rk mj mk,
and mj and mi,mk M1` II such a pair ri, rk} exists then we label the edge same as the
parameter (or list oI parameters) oI message mj between two nodes Vi V and V 2 V
in SG, where Vi and Vk in SG have correspondences with the messages mi and mk in
M1` respectively. It can be noted that an edge may be without any level. This may
happen hen there is no messeges.

n example:
e consider the student registration scenario Ior library management system to explain the
construction oI SG Irom a given sequence diagram. In. student registration user Iirst login to the
system by entering id and password then chooses search student options and system then
prompts to enter student name. AIter unsuccessIul search system prompts to enter student roll
number to register the student. Based on login details user`s input diIIerent scenarios may arise.
For example 'student registration use case we can identiIy three scenarios successIul
registration, invalid login and already registered.
in the Iollowing Iigure all messages received by boundary objects Irom any object in the system
are A,B,D,E,G,H,I,J,K. and massages received by user only are a, b, c and d. thus we have
MA,B,D,E,G,H,I,J,K,a,b,c,d} and M1A,B,D,E,G,H,I,J,K} and M2a,b,c}. we have
takenM1 as nodes oI graph and M2 as labels oI edges between two subsequent messages Irom
M1.
boundary
keyboard lnLerface
boundary
ulsplay lnLerface
conLroller
@ransacLlon manager
ulsplay logln screen()
CeL logln (ldpassword)
verlfy logln() ulsplay opLlons
ulsplay
search_unsucessfull()
1Sequence d|agram of "successfu| reg|strat|on" scenar|o for use case " reg|strat|on"
CeL opLlon(search_sLudenL)
Search_sLudenL()
rompL sLudenL name()
CeL sLudenL name(name)
CeL sLudenL name(name)
enLlLy
Llbrary daLabase
Search_sLudenL()
Search_unsuccessfull()
ulsplay reglsLraLlon page()
rompL roll number() CeL sLudenL roll no(roll no)
CeL sLudenL roll no(roll no)
8eglsLer
sLudenL()
ulsplay processlng()
Add_sLudenL() updaLe
daLa base()
ulsplay sLudenL ld)
CeneraLe sLudenL ld()
ulsplay maln screen()
user
10
11
a
c
b
d
1

dlsplay
logln
screen
ulsplay
opLlons
rompL roll
no
Sequence graph of "successfu| reg|strat|on " scenar|o
rompL
name
Search student
name
ulsplay
search
unsuccessful
ulsplay
reglsLraLlon
page
ko|| no
ulsplay
processlng
ulsplay
sLudenL ld
ulsplay
maln
screen
1
11
10
Id and password

boundary~~
Keyboard interIace
boundary~~
Display interIace
controller~
Transaction manager
Display login screen()
Get login (id&password)
Get login (id&password)
VeriIy login() Display options
Display already
registered()
3.3Sequence diagram of ~already resisterd~ scenario for use case ~ registration
Get option(searchstudent)
Searchstudent()
Prompt student name()
Get student name(name)
Get student name(name)
entity~~
Library database
Searchstudent()
SearchsuccessIull()
Display student id()
Display main screen()
user
10
11
a
c
b
1

dlsplay
logln
screen
ulsplay
opLlons
Sequence graph of "a|ready reg|stered" scenar|o
rompL
name
Search sLudenL
name ulsplay
maln
screen
ulsplay
sLudenL ld
ulsplay
already
reglsLered
1
11
10

boundary
keyboard lnLerface
boundary
ulsplay lnLerface
conLroller
@ransacLlon manager
verlfy logln()
ulsplay lnvalld logln()
Sequence d|agram of "|nva||d |og|n " scenar|o
11
a 1

dlsplay logln
screen
ulsplay lnvalld
logln
ulsplay maln
screen
Sequence graph of "|nva||d |og|n " scenar|o
1

3.2M#GIG OF S"UC G#!H:
Once all sequence diagrams Ior all scenarios oI a use case are converted into their corresponding
SGs, we merge them into a single SG. Let us consider the merging oI SG1 and SG2 into an SG.
Initially, we consider that trivially SG1 is the SG. To merge SG2 with SG1, we Iirst Iind a set oI
common edges, let it be denoted as Ec between the two graphs SG1 and SG2. For each edge e 2
Ec, we exclude the edge e Irom SG2. e select an edge Vi,Vj ~ Irom SG2 such that either any
one or both the nodes (Vi and Vj) exist in SG. II so, then we add the edge Vi, Vj ~ into SG,
and exclude the edge Irom the list oI edges oI SG2. e repeat this process oI selection, addition
and exclusion oI edges until all edges oI SG2 are added into SG. e present an algorithm Merge
Sequence Graphs Iormulating our approach oI merging two SGs stated above.

!#VIOUS LGO#ITHM:

lgorithm MergeSequenceGraphs

Input : SG1 , SG2 , ... , SGn ( n sequence graphs)
Output: Single SG
1 SG SG1
2 Set NSG set oI nodes oI SG and ESG set oI edges oI SG
3 Ior i 2 to n do
4 Set Ni set oI nodes oI SGi and Ei set oI edges oI SGi
5 Set Ec Ei intersection ESG /` Obtain set of common edges between two graphs `/
6 Set Ei Ei - Ec /` xclude common edges between two graphs from i `/
7 while Ei ! NULL do
8 /` #epeat loop until all edges are added to I `/
9 Select an edge ni; nj ~ Irom Ei such that either ni NSG or nj NSG
10 Add the edge ni; nj ~ to SG
11 Set Ei Ei - ni; nj ~ /` xclude < ni,nj > from i `/
12 Set NSG NSG nk /` Update set of nodes of SG (SG) `/
13 Set ESG ESG ni; nj ~ /` Update set of edges of SG (SG) `/
14 /` Merging is complete for Graph SGi. Go for next graph `/
15 end
16 end
17 Return SG

SIM!LIFI LGO#ITHM FO# M#GIG:

lgorithm MergeSequenceGraphs

Input : SG1 , SG2 , ... , SGn ( n sequence graphs)
Output: Single SG
1 SG SG1
2 Set NSG set oI nodes oI SG and ESG set oI edges oI SG
3 Ior i 2 to n do
4 Set Ni set oI nodes oI SGi and Ei set oI edges oI SGi
5 /` Obtain set of common edges between two graphs `/
6 Set Ec Ei intersection ESG
7 /` xclude common edges between two graphs from i `/
8 Set Ei Ei - Ec
9 while Ei ! NULL do
10 /` #epeat loop until all remaining edges are added to SG `/
11 Select an edge ni,nj ~ Irom Ei
12 Add the edge ni, nj ~ to SG
13 Set ESG ESG ni; nj ~ /* Update set oI edges oI SG (ESG) */
14 /` Merging is complete for Graph SGi. Go for next graph `/
15 end
16 end
17 Return SG
n example:

e explain our approach oI merging two sequence graphs SG1 and SG2 into SG as shown in
Iollowing Iigure:

A
C
A
u
SC1
SC2
A
C u
A
C u
C u
%a)1wo sequence graphs under merg|ng

%b) Intermed|ate steps of merg|ng
SC SC
SC
l ll lll
3.7 merging of two graphs

Initially, SG1 is the SG. As shown in Fig. 3:7(a), SG1 contains a set oI nodes N1 A,B,C} and
set oI edges E1 AB,BC}. Similarly, in the graph SG2, set oI nodes and edges are N2 A,
B,D,E} and E2 AB,BD,DE,EA}, respectively. Set oI common edges between SG1 and SG2 is
Ec AB}. e exclude Ec Irom E2, and then the set oI edges oI SG2 becomes E2 E2 - Ec
BD, DE, EA}. In Iirst iteration, BD is selected Irom E2 and then added with the node B oI SG
and the resultant SG is shown in Fig. 3.7(b)-i. Similarly, the edge DE and EA oI SG2 are added
into SG in the next two iterations and the resultant SG is shown in Fig. 3.7(b)-ii and Fig. 3.7(b)-
iii, respectively. The graph SG as shown in Fig. 3.7(b)-iii is the single SG aIter the completion oI
merging oI SG1 and SG2.
e are going to take the example oI merged graph oI all scenarios oI use case ~register
student:

C output f||e for merg|ng of sequence graph of a|| scenar|os of use case "reg|ster
student

how many sequence graphs you want:3

insert an edge in graph 1:

enter source node and destination node :1 2

To insert another edge press y:y















To insert another edge press y:
y





To insert another edge press y:n
Graph 1 is:

1-~2-~NULL

2-~4-~NULL

4-~5-~NULL

5-~7-~NULL

7-~8-~NULL

8-~9-~NULL

9-~10-~NULL

10-~11-~NULL

11-~NULL















To insert another edge press y:n

Graph 2 is:
1-~2-~NULL

2-~4-~NULL

6-~10-~NULL

10-~11-~NULL

11-~NULL





enter source node and destination node :
To insert another edge press Y:n

Graph 3 is:

1-~3-~NULL

3-~11-~NULL

11-~NULL
merged graph is->
1-~2-~3-~NULL
2-~4-~NULL
4-~5-~6-~NULL
5-~7-~NULL
7-~8-~NULL
8-~9-~NULL
9-~10-~NULL
10-~11-~NULL
11-~NULL
6-~10-~NULL
3-~11-~

Graphical reperesentation:

dlsplay
logln
screen
ulsplay
lnvalld
logln
rompL
roll no
Id password
Merged sequence graph for use case "reg|strat|on"
rompL
name
ulsplay
search
unsuccessful
ulsplay
reglsLraLlon
page
ko|| no
ulsplay
processlng
ulsplay
sLudenL ld
ulsplay
maln
screen
ulsplay
opLlons
Search student
Id password
name
name
ulsplay
already
reglsLered
1
11
10

3.3TST CS G#TIO:

In this section, we Iirst introduce basic deIinitions that we would use to explain our
Methodology. e then present our test case generation procedure.

Definitions:

Basic !ath:
Basic path is a path Irom the start node to an end node in SG where a
Node in that path may have at most two occurrences. It implies that basic path assumes
Loop to be considered at most one.

Scenario coverage criteria:

Let BP be a set oI basic paths obtained Irom an SG (Sequence graph Ior a given use case U), and
T be a set oI test cases. For any p belongs to BP, there must be at least one test case t belongs to
T such that when the use case U is executed using t, basic path p oI SG is exercised.

Our test case generation procedure consists oI two steps as given below.

$tep 1:

e obtain a set oI basic paths BP Irom SG Ior a use case U. For this, we propose an approach to
generate all basic paths. In our approach, we maintain a stack called ST and two lists:
ListOIPaths which stores the constructed basic paths, and TempListOIPaths, which keeps track
the loop oI a path. e visit the nodes in SG Irom the start node Iollowing the depth-Iirst search
traversal oI graph. e store all the unvisited children oI each node visited during the traversal oI
SG in the stack ST. II the traversal reaches to an end node, then construction oI a basic path
completes. AIter adding this basic path into ListOIPaths, we backtrack to the node whose child is
in the top oI ST. e then resume traversal Irom the backtracked node till an end node is reached
to construct
the next basic path. This basic path is also added into ListOIPaths. Note that during the traversal
oI graph iI we identiIy that a loop has occurred, we then keep track the loop part oI a path by
storing it into TempListOIPaths. e repeat constructing the basic paths, backtracking to a node
whose at least one child still remains unvisited until the stack ST is empty. Finally, we augment
the set oI basic paths, so obtained and stored in ListOIPaths aIter merging each loop part stored
in TempListOIPaths with those basic paths that cover the loop. Above approach oI generating all
basic paths is precisely deIined using pseudo code in Algorithm BasicPathSetGeneration. Once
all the basic paths are generated, we then Iind one-to-one correspondence between a scenario SCi
oI a use case U and a basic path Pi belongs to BP.

$tep 2:
e Iollow scenario coverage criteria Ior test case generation. To do this, we
Iind two set oI labels I I1, I2.., Ip} and O O1,O2...Oq) Ior each basic path
Pi belongs to BP where Pi covers a set oI nodes V V1,V2, V3.. Vm}, and Oi belongs to O
is a label associated with a node Vi belongs to V ; Ii belongs to I is a label with an edge between
two nodes Vi belongs to V and Vj belongs to V . Note that Ii belongs to I and Oi belongs toO is
a user input and system response, respectively. I and O so obtained Ior the basic path Pi belongs
to BP is the test case t Ior the scenario SCi corresponding to the basic path Pi belongs to BP.

Aotations:
e would use the Iollowing notations to present our proposed algorithm
Basic Path Set-Generation.

1. AddPath(P|i|, N) - Add a node N to a path P|i|.
2. CopyPath(P|i|, P|j|)| - Copy the path P|i| to P|j|.
3. Add(P|i|, L) - Add the path P|i| to a list L.
4. DeletePath(P|i|, N) - Delete the node N Irom the path P|i|.
5. Child(N) - Return the child oI node N.
6. LastNode(P|i|) - Return last node oI path P|i|.
7. FindPath(Sk, P|j|) - Return trailing part oI the path P|j| Irom the node Sk.

lgorithm Basic!athSetGeneration:

Input : SG (Sequence graph), S (start node oI SG), EN (set oI end nodes).
Output: List oI basic paths
i 0, curr node S, stack ST NULL, LoopFlag 0, p|| NULL ;
2 while ST ! Empty or curr node ! NULL do
3 AddPath(p|i|, curr node); /` pi] is current basic path `/
4 LoopFlag 0; /` Visit the node in FS traversal and construct basic path pi] `/
5 while curr node EN do
6 Ior each child C oI curr node do
7 iI !Exists(ST,C) then
8 Push(ST,C) /` Store unvisited child of curr node in stack ST `/
9 end
10 end
11 next node Pop(ST)
12 iI Exists(P|i|,next node) then
13 CopyPath(p|i|, Temp); AddPath(Temp, next node); /` There is a loop `/
14 Add(Temp, TempListOIPaths); LoopFlag 1; Break ;
15 end
16 AddPath(p|i|,next node) ; curr node next node
17end
18 iI LoopFlag 0 then
19 Add(p|i|, ListOIBasicPaths);
20 end
21 CopyPath(p|i|, p|i 1|)
22 /* Backtrack to the rst node which has atleast one child remains unvisited */
23 DeletePath(P|i 1|, LastNode(p|i 1|)); /` Final node can not have a child `/
24 while do
25 curr node LastNode(p|i 1|);
26 iI TOP|ST| Child(curr node) or ST NULL then
27 Break ;
28 end
29 DeletePath(P|i 1|,curr node);
30 end
31 i i 1 ; curr node Pop(ST)
32 end
33 Ior each path p|i| TempListOIPaths do
34 t p|i|; Sk LastNode(p|i|);
35 Ior each path p|j| ListOIBasicPaths do
36 iI Sk p|j| then
37 /* Update path pj] with inclusion of loop part contained in path pi] `/
38 p|k| FindPath(Sk,p|j|) /` etermine the trailing path in pj] from Sk `/
39 AddPath(t, p|k|); /` dd pi] with pk] `/
40 Add(t, ListOIBasicPaths);
41 end
42 end

n example:

e now consider an example to illustrate our approach to test case generation Irom an SG. Fig
3.8 shows SG oI registration use case. There are three basic paths BP P1,P2,P3} , generated
Irom above algorithm and in table 4.1. we then Iind correspondence between 3 basic paths and
three scenarios oI 'student registration use case.

Table 3.1 three basis paths of SG
No. Basis path Scenario
P1 1-~2~4~5~7~8-~9-~10-~11

SuccessIul registration
P2 1-~2-~4~6~10-~11

Already registered
P3 1-~3~11

Invalid login

Let us now discuss the test case generation Ior all three scenarios oI 'student registration use
case. According to our test case generation procedure we obtain I and O Ior each three basic
paths BP P1, P2, P3} in SG. here I and O correspond to user input and system responses
respectively. For example we Iind I id & password, search student, student name, roll no} and
ODisplay login screen, display options, prompt student name, Display search unsuccessIul,
display registration page, prompt roll no , Display processing, display student id, display main
screnn } Ior basis pathP1. This I and O are input and system responses.

Table 3.2 test cases for use case register student

Test case Input xpected system responses Scenario
coverage
T1 Display login screen SuccessIul
registration
Id&password Display options
Search student Prompt name
Student name Display search unsuccessIul, display registration page, prompt roll
no
Roll no Display processing, display student id, display main screen
T2 Display login screen
Already
registered
Id& password Display options
search student prompt name
Student name Display already registered, display main screen
T3 Display main screen invalid login
Id& password Display invalid login

SCTIO IV
Results analysis and case study

LYSIS OF TST CS G#TIO !!#OCH:

In this section, we analyze the perIormance oI this test case generation approach. e Iirst
discuss the Iault model considered in this approach. e then state the time complexity
oI this test case generation procedure.

Faut mode:

Every test strategy targets to detect certain categories oI Iaults called its Iault model. Our test
case generation scheme is based on the Iollowing Iault model.

O System interactions (user input or system response) are incorrect. Examples
are the incorrect system response, prompting wrong input, missing oI system
Response and/or user input.

O Individual system interactions are correct but their occurrences are not in
proper order. One example is that given an input to the system, sequence oI
system responses occur in wrong order.

ompexity:

In this test case generation approach, we have used the algorithm BasicPathSetGeneration. This
algorithm is based on depth-Iirrst search traversal oI Graph. this algorithm like depth Iirst
traversal oI graph, visits all nodes in SG, reachable Irom the start node. For a SG with n number
oI nodes and e number oI edges, time complexity oI BasicPathSetGeneration algorithm, T (n,e)
is O(n e) iI adjacency lists are used or O(n*n) iI adjacency matrices are used ..we have used
adjacency list to implement it.

CS STUY:
e have taken 'LIB##Y MGMT SYSTM as a case study to generate test cases
oI its all scenarios. First we have taken all the use cases oI this system. Then draw sequence
diagram Ior all scenarios oI its use case. Earlier we have described ~register student
Use case. To generate test cases. Now giving the test cases and related diagrams Ior all the use
cases oI this system.

USCS2. Search book

boundary
keyboard lnLerface
boundary
ulsplay lnLerface
conLroller
@ransacLlon manager
ulsplay book deLalls()
1Sequence d|agram of "successfu| search " scenar|o for use case " search_book"
Search_sLudenL()
rompL book name()
CeL book name(name)
CeL book name(name)
ent|ty
Llbrary daLabase
Search_book()
Search_successfull()
user
1
a
c

dlsplay
logln
screen
sequence graph for scenar|o" successfu| search" for use case
"search_book"
rompL
book name
ulsplay
opLlons
Search book
Id password
8ook name
ulsplay book
deLalls
1

boundary
keyboard lnLerface
boundary
ulsplay lnLerface
conLroller
@ransacLlon manager
Sequence d|agram of "unsuccessfu| search " scenar|o for use case " search_book"
CeL opLlon(search_book)
Search_book()
rompL book name()
CeL book name(name)
CeL book name(name)
enLlLy
Llbrary daLabase
Search_book()
user
Add ln requlslLlon
llsL
ulsplay added ln llsL()
1
a
c

dlsplay
logln
screen
sequence graph of "unsucessfu|| search "for use case "search_book"
rompL
book name
ulsplay
search
unsuccessful
ulsplay
maln
screen
ulsplay
opLlons
Search book
Id password
name
ulsplay
added ln llsL
1

boundary
keyboard lnLerface
boundary
ulsplay lnLerface
conLroller
@ransacLlon manager
verlfy logln()
ulsplay lnvalld logln()
Sequence d|agram of "|nva||d |og|n " scenar|o
1
a

dlsplay logln
screen
ulsplay lnvalld
logln
ulsplay maln
screen
Sequence graph of "|nva||d |og|n " scenar|o
1

dlsplay
logln
screen
ulsplay
lnvalld
logln
Id password
Merged sequence graph for use case "search_book"
rompL
book name
ulsplay search
unsuccessful
ulsplay
maln
screen
ulsplay
opLlons
Search book
Id password
name
name
ulsplay book
deLalls
ulsplay
added ln llsL
1

Basis paths in SG:

P1 1-~2-~4-~5-~7-~8 UnsuccessIul search and add in
requisition list
P2 1-~2-~4-~6 SuccessIul search
P3 1-~3-~8 Invalid login
Table 4.1

Test Cases:

Test case Input xpected system responses Scenario coverage

UnsuccessIul search
and add in requisition
list
Search book Prompt book name
Book name Display search unsuccessIul, display added
in list , display main screen
SuccessIul search
search book prompt book name
book name Display book details
T3 Display main screen invalid login
Id& password Display invalid login, display main screen

Table 4.2

USCS 3. BO##OW BOOK
boundary
keyboard lnLerface
boundary
ulsplay lnLerface
conLroller
@ransacLlon manager
rompL book ld()
Sequence d|agram of "sucessfu||y borrow_book" scenar|o for use case " borrow_book"
Search_sLudenL()
rompL sLudenL ld()
CeL sLudenL ld(ld )
CeL sLudenL ld(ld)
enLlLy
Llbrary daLabase
Search sLudenL()
Check ln
borrowers llsL()
orrow book()
ulsplay successfully
borrowed
user
CeL book ld(ld )
CeL sLudenL ld(ld)
Search book()
ulsplay avallable()
updaLe borrowers
llsL()
1
b
a
c
L
d
1
10
1

dlsplay
logln
screen
ulsplay
avallable
sequence graph of succesfu|| borrow book for use case "borrow
book"
rompL
sLudenL ld
book ld
ulsplay
processlng
ulsplay
successfully
borrowed
ulsplay
maln
screen
ulsplay
opLlons
Search sLudenL
ld password
SLudenL ld
rompL
book ld
1
10
1
1

boundary
keyboard lnLerface
boundary
ulsplay lnLerface
conLroller
@ransacLlon manager
rompL book ld()
10Sequence d|agram of "book search unuccessfu||" scenar|o for use case " borrow_book"
Search_sLudenL()
rompL sLudenL ld()
CeL sLudenL ld(ld )
CeL sLudenL ld(ld)
enLlLy
Llbrary daLabase
Search sLudenL()
ulsplay add ln llsL()
Add ln requlslLlon llsL)
user
CeL book ld(ld )
CeL sLudenL ld(ld)
Search book()
ulsplay unsuccessful()
b
a
c
d
1
11
1

boundary
keyboard lnLerface
boundary
ulsplay lnLerface
conLroller
@ransacLlon manager
rompL book ld()
11Sequence d|agram of "rereg|ster student" scenar|o for use case " borrow_book"
Search_sLudenL()
rompL sLudenL ld()
CeL sLudenL ld(ld )
CeL sLudenL ld(ld)
enLlLy
Llbrary daLabase
Search sLudenL()
Check ln
borrowers llsL()
orrow book()
orrowed()
user
CeL book ld(ld )
CeL sLudenL ld(ld)
Search book()
ulsplay avallable()
updaLe borrowers
llsL()
ulsplay rereglsLer
sLudenL()
b
a
c
d
1
10
1
1

dlsplay
logln
screen
ulsplay
avallable
1sequence graph of "rereg|ster student" scenar|o for use case "borrow book"
rompL
sLudenL ld
ulsplay
search
unsuccessful
ulsplay
rereglsLer
sLudenL
book ld
ulsplay
processlng
ulsplay
successfully
borrowed
ulsplay
maln
screen
ulsplay
opLlons
Search sLudenL
ld password
ld
ld
rompL
book ld
1
10
1
1

dlsplay
logln
screen
ulsplay
lnvalld
logln
ulsplay
avallable
Id password
1Merged sequence graph for use case "borrow book"
rompL
sLudenL ld
ulsplay
search
unsuccessful
ulsplay
rereglsLer
sLudenL
book |d
ulsplay
processlng
ulsplay
successfully
borrowed
ulsplay
maln
screen
ulsplay
opLlons
Search student
Id password
Student |d
Student |d
rompL
book ld
book |d
ulsplay
search
unsuccessful
ulsplay add
ln llsL
1
10
1
1
11
Basis paths in SG:

P1 A-~B-~D-~I-~J-~L-~M-~N SuccessIully borrowed
P2 A-~B-~D-~I-~K-~O-~N UnsuccessIul book search
P3 A-~B-~D-~E-~H-~I-~J-~L-~M-~N Reregistered student successIully borrowed
p4 A-~B-~D-~E-~H-~I-~K-~O-~N Reregistered student UnsuccessIul book
search
p5 A-~C-~N Invalid login
Test cases:

Test
case
Input xpected system responses Scenario coverage
T1 Display login screen Successfully
borrowed
Search student Prompt student id
Student id Prompt book id
Book id Display available, Display processing,display
successIully borrowed , display main screen
Booksearch
unsuccessful
search student prompt student id
Book id Display search unsuccessIul, display added in
requisition list, display main screen

T3
Display login screen

#eregister student
&
Successfully
borrowed
Student id Display search unsuccessIul, display reregister
student, prompt book id
book id Display available, Display processing, display
successIully borrowed , display main screen

@

ulsplay logln screen #eregister student &
book search
unsuccessful
ldpassword ulsplay opLlons
SLudenL ld ulsplay search unsuccessful dlsplay rereglsLer
sLudenL prompL book ld
book ld ulsplay search unsuccessful dlsplay added ln
requlslLlon llsL dlsplay maln screen

@

ulsplay logln screen Inva||d |og|n
ldpassword ulsplay lnvalld logln dlsplay maln screen

USCS 3. #TU# BOOK
boundary
keyboard lnLerface
boundary
ulsplay lnLerface
conLroller
@ransacLlon manager
rompL book ld()
1Sequence d|agram of "sucessfu||y return_book" scenar|o for use case " return book"
Search_sLudenL()
rompL sLudenL ld()
CeL sLudenL ld(ld )
CeL sLudenL ld(ld)
enLlLy
Llbrary daLabase
Search sLudenL()
Check flne()
reLurn book()
reLurned
user
CeL book ld(ld )
CeL sLudenL ld(ld)
Search book()
ulsplay flne pald()
updaLe borrowers
llsL()
1
10
11
1
1
ulsplay search successful()
a
b
c
d

dlsplay
logln
screen
ulsplay
search
successful
1sequence graph of succesfu||y return book for use case "return book"
rompL
sLudenL ld
book ld
ulsplay
flne pald
ulsplay
processlng
ulsplay
maln
screen
ulsplay
opLlons
Search sLudenL
ld password
SLudenL ld
rompL
book ld
ulsplay
successfully
reLurned
1
2
4
8
6
10
11
12
13

boundary
keyboard lnLerface
boundary
ulsplay lnLerface
conLroller
@ransacLlon manager
rompL book ld()
1Sequence d|agram of "book data not found" scenar|o for use case " return book"
Search_sLudenL()
rompL sLudenL ld()
CeL sLudenL ld(ld )
CeL sLudenL ld(ld)
enLlLy
Llbrary daLabase
Search sLudenL()
user
CeL book ld(ld )
CeL sLudenL ld(ld)
Search book()
ulsplay search
unsuccessful()
1
a
b
c
d

dlsplay
logln
screen
ulsplay
search
sucessfull
1Merged sequence graph for use case "return book"
rompL
sLudenL ld
book |d
ulsplay
calculaLe
flne
ulsplay
processlng
ulsplay
maln
screen
ulsplay
opLlons
Search student
Id password
Student |d
rompL
book ld
ulsplay
successfully
reLurned
ulsplay
search
unsuccessful
ulsplay
rereglsLer
sLudenL
student |d
ulsplay
lnvalld
logln
Id password
book |d
ulsplay
search
unsuccessful
1
2
3
4
5
8
9
6
10
11
12
13
7
Basis path in SG:

P1 1-~2-~4-~6-~8-~10-~11~12-~13 SuccessIully returned
P2 1-~2-~4-~6~9~13 UnsuccessIul book search
P3 1-~2-~4-~5~7-~6-~8-~10-~11-~12-~13 Reregistered student successIully
returned
p4 1-~2-~4-~5-~7-~6-~9-~13 Reregistered student UnsuccessIul book
search
p5 1-~3-~13 Invalid login
TST CSS:

Test
case
Input Expected system responses Scenario
coverage
SuccessIully
returned
Search student Prompt student id
Book id Display available, display Calculate Iine Display
processing, display successIully returned display
main screen
book
search
unsuccessIul
search student prompt student id
Book id Display search unsuccessIul, display main screen

T3
Display login screen Reregister
student &
SuccessIully
returned
book id Display available, display calculate Iine, Display
processing, display successIully returned, display
main screen

T4
Display login screen Reregister
student &
book search
unsuccessIul
book id Display search unsuccessIul, display main screen

T5
Display login screen Invalid
login
Id&password Display invalid login, display main screen

USCS 5. BOOK

boundary
keyboard lnLerface
boundary
ulsplay lnLerface
conLroller
@ransacLlon manager
1Sequence d|agram of "successfu||y added book" scenar|o for use case " add_book"
Search_book()
rompL book name()
CeL book name(name)
CeL book name(name)
enLlLy
Llbrary daLabase
Search_book()
user
check ln
requlslLlon llsL
ulsplay book ld()
ulsplay found _llsL()
Add_book()
add book()
updaLe daLa
base()
CeneraLe book ld()
1
10
11
b
a
c

dlsplay
logln
screen
1sequence graph of "sucessfu||y addded book" scenar|o for use case
"add_book"
rompL
book name
ulsplay search
unsuccessful
ulsplay
maln
screen
ulsplay
opLlons
Search book
ld password
name
ulsplay found
ln llsL
ulsplay
processlng
ulsplay book
ld
1
10
11

boundary
keyboard lnLerface
boundary
ulsplay lnLerface
conLroller
@ransacLlon manager
Sequence d|agram of "not |n requ|s|t|on ||st" scenar|o for use case " add_book"
Search_book()
rompL book name()
CeL book name(name)
CeL book name(name)
enLlLy
Llbrary daLabase
Search_book()
user
ulsplay noL ln llsL()
check ln
requlslLlon llsL()
1
11
a
b
c

dlsplay
logln
screen
sequence graph of "not |n requ|s|on ||st" scenar|o
for use case "add_book"
rompL
book name
ulsplay search
unsuccessful
ulsplay
maln
screen
ulsplay
opLlons
Search book
ld password
name
ulsplay noL
ln llsL
1
11

boundary
keyboard lnLerface
boundary
ulsplay lnLerface
conLroller
@ransacLlon manager
Sequence d|agram of "a|ready added book" scenar|o for use case " add_book"
Search_book()
rompL book name()
CeL book name(name)
CeL book name(name)
enLlLy
Llbrary daLabase
Search_book()
user
ulsplay book ld()
1
10
11
a
b
c

dlsplay
logln
screen
sequence graph of "a|ready added book "for use case "add_book"
rompL
book name
ulsplay
maln
screen
ulsplay
opLlons
Search book
ld password
name
ulsplay
search
successful
ulsplay book
ld
1
10
11

dlsplay
logln
screen
ulsplay
lnvalld
logln
Id password
Merged sequence graph for use case "add_book"
rompL
book name
ulsplay search
unsuccessful
ulsplay
maln
screen
ulsplay
opLlons
Search book
Id password
8ook name
8ook name
ulsplay
search
successful
ulsplay found
ln llsL
ulsplay
processlng
ulsplay book
ld
ulsplay noL
ln llsL
1
10
11

Basis paths:

No. basis path Scenario
P1 1-~2-~4-~5-~7-~9-~10-~11 SuccessIully added
P2 1-~2-~4-~8-~11 Not Iound in requisition list
P3 1-~2-~4-~6-~10-~11 already in data base
p4 1-~3-~11 invalid login
Test cases
Test case Input Expected system responses Scenario
coverage
SuccessIully
added
Book name Display search unsuccessIul, display Iound in list,
display processing ,display book id, display main
screen
not In
requisition
list
Book name Display search unsuccessIul, display not in list,
display main screen

T3
Display login screen Already in
database
Book name Display search successIul, display book id, display
main screen

T4
Display login screen Invalid
login
Id & password Display invalid login, display main screen

USCS 6. #MOV BOOK

boundary
keyboard lnLerface
boundary
ulsplay lnLerface
conLroller
@ransacLlon manager
Sequence d|agram of "successfu||y removed book" scenar|o for use case " add_book"
Search_book()
rompL book name()
CeL book name(name)
CeL book name(name)
enLlLy
Llbrary daLabase
Search_book()
user
check ln
borrowers llsL
ulsplay sucessfully
removed()
ulsplay noL found ln llsL()
remove book()
8emove book()
updaLe daLa
base()
1
10
11
b
a
c

dlsplay
logln
screen
sequence graph of "sucessfu||y addded book" scenar|o for use case
"add_book"
rompL
book name
ulsplay search
unsuccessful
ulsplay
maln
screen
ulsplay
opLlons
Search book
ld password
name
ulsplay found
ln llsL
ulsplay
processlng
ulsplay book
ld
1
10
11

boundary
keyboard lnLerface
boundary
ulsplay lnLerface
conLroller
@ransacLlon manager
Sequence d|agram of "successfu||y removed book" scenar|o for use case " remove_book"
Search_book()
rompL book name()
CeL book name(name)
CeL book name(name)
enLlLy
Llbrary daLabase
Search_book()
user
check ln
borrower_ llsL
removed()
ulsplay noL found lnllsL()
remove_book()
8emove_ book()
updaLe daLa
base()
10
1
1
c
a
b

dlsplay
logln
screen
sequence graph of "succesfu||y removed" scenar|o for use case "remove_book"
rompL
book name
ulsplay search
successful
ulsplay
maln
screen
ulsplay
opLlons
Search book
ld password
name
ulsplay noL
found ln llsL
ulsplay
processlng
ulsplay
successfully
removed
1
10
1
1

boundary
keyboard lnLerface
boundary
ulsplay lnLerface
conLroller
@ransacLlon manager
Sequence d|agram of "found |n borrower_||st" scenar|o for use case " remove_book"
Search_book()
rompL book name()
CeL book name(name)
CeL book name(name)
enLlLy
Llbrary daLabase
Search_book()
user
check ln
borrower_ llsL
ulsplay found ln llsL()
ulsplay unable Lo remove()
1
1
11
c
a
b

dlsplay
logln
screen
sequence graph of "found |n borrower ||st"scenar|o for use case "remove_book"
rompL
book name
ulsplay search
successful
ulsplay
maln
screen
ulsplay
opLlons
Search book
ld password
name
ulsplay
found ln llsL
ulsplay
unable Lo
remove
1
1
11

boundary
keyboard lnLerface
boundary
ulsplay lnLerface
conLroller
@ransacLlon manager
Sequence d|agram of "not |n data base" scenar|o for use case " remove_book"
Search_book()
rompL book name()
CeL book name(name)
CeL book name(name)
enLlLy
Llbrary daLabase
Search_book()
user
ulsplay
1
1
c
a
b

dlsplay
logln
screen
sequence graph of '"not found |n data base" scenar|o for use case "remove book"
rompL
book name
ulsplay
maln
screen
ulsplay
opLlons
Search book
ld password
name
ulsplay search
unsuccessful
1
1

dlsplay
logln
screen
Merged sequence graph for use case "remove book"
rompL
book name
ulsplay search
successful
ulsplay
maln
screen
ulsplay
opLlons
Search book
Id password
book name
ulsplay
found ln
borrowers
llsL
ulsplay
unable Lo
remove
ulsplay noL
found ln
borrowers llsL
ulsplay
processlng
ulsplay
successfully
removed
Id password
dlsplay
lnvalld
logln
book name
ulsplay search
unsuccessful
1
10
1
11

Basis paths in SG:

No. BAsis path Scenario
P1 1-~2-~4-~5-~7-~9-~10-~12 SuccessIully removed
P2 1-~2-~4-~5-~8-~11-~12 Found in borrowers list
P3 1-~2-~4-~6-~12 Book search unsuccessIul

Test cases:
Test
case
Input Expected system responses Scenario coverage
T1 Display login screen SuccessIully
removed
Book name Display search successIul, display not Iound in
borrowers list, display processing ,display
successIully removed display main screen
book search
unsuccessIul
Book name Display search unsuccessIul, display main
screen

T3
Display login screen Iound in
borrowers list
Book name Display search successIul, display Iound in
borrowers list ,display unable to remove
,display main screen

T4
Display login screen Invalid login
Id & password Display invalid login, display main screen

USCS 6. IT BOOK

boundary
keyboard lnLerface
boundary
ulsplay lnLerface
conLroller
@ransacLlon manager
Sequence d|agram of"succesfu||y ed|t book" scenar|o for use case " ed|t_book"
Search_book()
rompL book name()
CeL book name(name)
CeL book name(name)
enLlLy
Llbrary daLabase
Search_book()
user
dlL book
deLalls()
ulsplay book deLalls()
ulsplay modlfled deLalls()
dlL book deLalls()
updaLe u()
c
a
b
1
10

dlsplay
logln
screen
sequence graph of "successfu||y ed|ted book" scenar|o for use case "ed|t_book"
rompL
book name
ulsplay book
deLalls
ulsplay
maln
screen
ulsplay
opLlons
Search book
ld password
name
ulsplay
processlng
ulsplay
modlfled
deLalls
1
10

boundary
keyboard lnLerface
boundary
ulsplay lnLerface
conLroller
@ransacLlon manager
Sequence d|agram of"book search unsuccessfu||" scenar|o for use case " ed|t_book"
Search_book()
rompL book name()
CeL book name(name)
CeL book name(name)
enLlLy
Llbrary daLabase
Search_book()
Search unsuccessful()
user
ulsplay book search
unsuccessful()
ulsplay unable Lo
edlL()
1
10
c
a
b

dlsplay
logln
screen
sequence graph of " book search unsuccessfu|| "for use case "ed|t_book"
rompL
book name
ulsplay
maln
screen
ulsplay
opLlons
Search book
ld password
name
ulsplay
search
unsuccessful
unable Lo edlL
1
10

dlsplay
logln
screen
ulsplay
lnvalld
logln
Id password
Merged sequence graph for use case "ed|t_book"
rompL
book name
ulsplay book
deLalls
ulsplay
maln
screen
ulsplay
opLlons
Search book
Id password
book |d
8ook |d
ulsplay
search
unsuccessful
unable Lo edlL
ulsplay
processlng
ulsplay
modlfled
deLalls
1
10

BSIS !THS I SG:

o. Basis path Scenario
P1 1-~2-~4-~5-~7-~8~10 SuccessIully edited
P3 1-~2-~4-~6-~9-~10 Book search unsuccessIul

Test cases

Test case Input Expected system responses Scenario coverage
T1 Display login screen SuccessIully
edited
Search book Prompt book id
Book name Display book details, display processing
,display modiIied details, display main screen
book search
unsuccessIul
search book prompt book id
Book name Display search unsuccessIul, display unable
to edit, display main screen

T3
Display login screen Invalid login
Id &
password
Display invalid login, display main screen

Section V
Conclusion and Iuture scope:

COCLUSIO:

This method proposes a Iramework to generate test cases Irom UML sequence diagram. The test
cases generated according to this approach satisIy the scenario coverage criteria and suitable Ior
system level testing.

For test case generation, we have Iollowed basic path coverage criteria. ith the basic path
coverage criteria, we cover all possible expected sequences oI system interactions (one possible
sequence oI system interactions corresponds to one basic path) to veriIy whether sequence oI
system interactions is correct or not. e know that path coverage criteria (here, basic path) are
stronger coverage criteria than the state coverage and transition coverage criteria ThereIore,
covering all possible expected sequences oI system interactions, we ensure that all user inputs
(that can be covered solely by transition coverage criteria), and all system responses (That can be
covered solely by state coverage criteria) are also covered. It conIirms the adequacy oI this test
case generation procedure.

Future scope:

e can extend our work by doing test case prioritization. Test case prioritization means
scheduling or ordering oI test cases based on certain coverage criteria.
For prioritization oI test cases a prioritization metric is considered based on certain coverage
criteria such as number oI statements, Iunctions etc. problem oI test case prioritization is deIined
as Iollows:
Test case prioritization problem:

iven: T, a test suite; PT, the set oI permutations oI T; I, a Iunction Irom PT to the real numbers.

!robem: Iind T` PT such that ( T`` PT)

(T`` T`) |I(T`) I(T``)|

In this deIinition, PT represents he set oI all possible prioritization (orderings) oI T, and I is a
Iunction that, applied to any such ordering, yields an award value Ior that ordering.
It may be noted that Iunction I as mentioned in the problem oI test case prioritization measures
the eIIectiveness oI prioritization technique.

The Iramework Ior test case prioritization problem is given as Iollows:

The framework of test case prioritization approach:

uraw uML sequence dlagram for all
scenarlos of a use case
ConverL all Lhe sequence dlagrams Lo
correspondlng sequence graphs
Merge all sequence graphs lnLo a slngle
sequence graph
CeneraLe paLhs from sequence graph by
uslng paLh coverage crlLerla
CeneraLe LesL cases from paLhs by uslng one
Lo one correspondence beLween sequence
graph and paLhs
rlorlLlze LesL cases
SG

SCTIO VI
ReIerences and source code

#eferences:

|1| Pankaj Jalote , An Integrated approach to SoItware Engineering,3
rd

Edition,7.1,7.4,10.1,10.2,10.3,10.4,10.5,10.6
|2| Brooch G., Rumbaugh J., and Jacobson I., Addison esley, 2002. 1.3, 3.2
|3| Dan Pilone and Neil Pitman, UML 2.0 in a Nutshell, O'Reilly, June 2005. 1.3, 3.2.
|4|Craig Larman, Applying UML and Patterns: An Introduction to Object-Oriented
Analysis and Design and the UniIied Process, 2nd edition. 3.2
|5| Ellis Horowitz, Sartaj Sahani, and Sanguthevar Raja Sekaran, Fundamentals oI
Computer Algorithms, Golgotha Publications Pvt. Ltd. 7.2
6| JeII OIIutt, Aynur Abdurazik, October 1999, "Generating Tests Irom UML speciIications",
Second International ConIerence on the UniIied Modeling Language (UML99), pp. 416-429,
Fort Collins, CO.

|7| Clay E. illiams, November 1999, "SoItware testing and the UML", International
Symposium on SoItware Reliability Engineering (ISSRE`99), Boca, Raton
|8| L. C. Briand and Y. Labiche, 'A uml-based approach to system testing," SoItware and
Systems Modeling (Springer), vol. 1, no. 1, pp. 10-42, 2002.

|9| Jean Hartmann, Marlon Vieira, Herbert Foster, and Axel Ruder, 'A uml-based approach to
system testing," Innovations in Systems and SoItware Engineering, vol.
1, no. 1, pp. 12-24, April 2005.

|10| ang Linsang, Yuan Jason, Yu XiaoIeng, Hu Jun, Li Xuandong, and Zheng Guoliang,
'Generating test cases Irom uml activity diagram based on gray-box
BIBLIOGRAPHY 114 method," in Asia-PaciIic SoItware Engineering ConIerence (APSEC04),
2004, pp.284 - 291.

|11| Peter Frohlich and Johannes Link, 'Automated test case generation Irom dynamic
models," in European ConIerence on Object-Oriented Programming, 2000, pp. 472-492.

|12| Falk Fraikin and Thomas Leonhardt, 'Seditec - testing based on sequence diagrams," in
IEEE International ConIerence on Automated SoItware Engineering (ASE02), 2002, pp. 261-
266.
|13| Xiaoqing BAI, C. Peng LAM, and Huaizhong LI, \An approach to generate the thin-threads
Irom the uml diagrams," in Annual International Computer SoItware
and Applications ConIerence (COMPSAC04), 2004, pp. 546 -552.

|14| Chen Mingsong, Qiu Xiaokang, and Li Xuandong, 'Automatic test case generation
Ior uml activity diagrams," in International ConIerence on SoItware Engineering,
2006, pp. 2-8.

|15| Monalisa Sarma, Debasish Kundu, Rajib Mall, Automatic Test Case Generation
From UML Sequence Diagram, 15th International ConIerence on Advanced Comput-
ing Communication (ADCOM), Indian Institute oI Technology Guwahati, India,
2007.
|16| Debasish Kundu, Debasis Samanta, An Improved Approach to Generating Test
Cases Irom UML Activity Diagram, 18th Australian ConIerence on SoItware En-gingering
(ASEC 2007), 2007.

|17|Debasish Kundu, Monalisa Sarma, Debasis Samanta, Test Case Prioritization Tech-
nique Ior Testing Object-Oriented System using Sequence Diagrams, 30th Interna-
tional ConIerence oI SoItware Engineering (ICSE), Germany, 2008. (Communicated)

|18| Jean Hartmann, Claudio ImoberdorI, and Michael Meisinger, 'Uml-based integration
Testing," ACM SIGSOFT SoItware Engineering Notes, vol. 25, no. 5, pp. 60-70,
September 2000.

|19| http://my.saIaribooksonline.com/book/soItware-engineering-and-development/uml/
|20| http://books.google.co.in/
|21| http://www.inIormit.com/articles/article.aspx?p360441&seqNum5
|22| http://www.visual-paradigm.com/VPGallery/diagrams/Sequence.html
|23| http://www.ibm.com/developerworks/rational/library/3101.html
|24| www.ieee.org/
|25| http://www.springer.com/computer?SGID0-146-0-0-0
|26| http://portal.acm.org/

Source code

Project Report

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Project Report

Uploaded by

Copyright:

Available Formats

/ o]c.

%a)1wo sequence graphs under merg|ng

You might also like