towards integration testing of software components
TRANSCRIPT
Towards Integration Testing Of Software Components
A Thesis
Submitted in partial fulfillment of the requirement for the Award of the Degree of
Master of Technology IN
COMPUTER SCIENCE & ENGINEERING (2006-2008)
Under the Supervision of
Ms. Gagandeep
SSuubbmmiitttteedd BByy HHaarrpprreeeett KKaauurr
DDeeppaarrttmmeenntt ooff CCoommppuutteerr SScciieennccee PPuunnjjaabbii UUnniivveerrssiittyy,, PPaattiiaallaa..
Acknowledgement
Nothing concrete can be achieved without an optimal combination of inspiration and
perspiration. The real spirit of achieving a goal is through the way of excellence and
discipline. I would have never succeeded in completing my task without the cooperation,
encouragement and help provided to me by various personalities
I owe my special thanks to Ms. Gagandeep, Lecturer, Department of Computer Science
Punjabi University, Patiala, who helped and guided me for this work. Her encouraging
remarks from time to time greatly helped me in improving my skills.
I am also thankful to Dr.Gupreet Singh Lehal, Professor and Head, Department of
Computer Science, Punjabi University, Patiala, for providing necessary facilities in the
Department, to work. I wish to place on record my gratitude for all those who have been
instrument in bringing my work to this stage.
Above all I render my gratitude to the ALMIGHTY who bestowed me self-confidence,
ability and strength to complete this work. I also owe sincere thanks to my parents for
their support and encouragement.
Harpreet Kaur
2
Abstract
The use of third-party components in software system development is rapidly increasing.
It allows rapid development of applications with the help of prefabricated and pre-tested
components thus allowing more reliability and credibility. Component-based software
engineering not only requires focus on system specification and development, but also
requires additional consideration for overall system context, individual components
properties, and component acquisition and integration process. To ensure the delivery of
quality component based software, effective and efficient testing is the key process in
software development. Since 40% of software errors are revealed during integration
testing. Adequate integration of reusable components is the key to the success of a
component-based software system.
Integration testing is an important part of the testing process in which individual
software modules are combined and tested as a group. It ensure correct interaction and
interfacing between the units in a software system. Interfaces must be tested because they
could have been specified incorrectly, defined incorrectly and implemented incorrectly. it
is also used to find faults that could not have been found in the component testing
because they only become apparent when the components are integrated.
Currently, components delivered by component providers only include
specifications of the interfaces. Without source code many testing techniques are not
applicable to component-based systems. Improvements in software testing techniques are
needed to address the increasingly complex applications that are implemented by today’s
software systems. The Unified Modeling Language (UML) is gaining wide acceptance in
industry. UML diagrams can be used as the basis for functional testing. The UML and its
diagrams are widely used to visually depict the static structure and more importantly for
us, the dynamic behavior of such applications. For integration level testing, we can derive
tests from UML Sequence diagrams, which embody the behavioral description of each
component of interest and more importantly, the interactions or events between them.
3
In this thesis the focus has been on developing a technique to enhance testing of
interactions among classes. In this we present a novel approach of generating test cases
from UML design diagrams. We consider sequence diagram in our test case generation
scheme. Our approach consists of transforming a UML sequence diagram into a graph
called the graph of sequence diagram (GOSD). Sequence diagrams are drawn with
StarUml tool.The GOSD is then traversed to generate test cases. The test cases thus
generated are suitable for Integration testing and to detect dependency and interaction
related faults.
4
Table of Contents
Topic
Page No.
List of Figures
vi
List of Tables viiChapter 1 – Introduction
1-3
Chapter 2 – Objective
4
Chapter 3 – Component Based Integration Testing 3.1 Introduction
3.2 Objectives of Integration testing 3.3 Component Integration Testing Vs Module Testing 3.4 Integration Testing Strategies 3.5 Different issues in component integration 3.6 Features to be tested 3.7 Integration Faults 3.8 A test Model for integration testing of components based software
5
5-66
6-77-88-9
910-1111-12
Chapter 4 – Literature Survey
13-15
Chapter 5 – Implementation 5.1 UML-based Integration Testing for Component-Based Software 5.2 Integration Testing Based on Data Flow Specification
16-2223-28
Chapter 6-Introduction to UML 6.1 Introduction 6.2 Goals of UML 6.3 The Building Blocks of UML 6.4 Model View of UML
29 29-30 30-31 31-32 32-34
Chapter 7 –Related Work
35-36
5
Chapter 8 - A Systematic Approach for Integration Testing from
Sequence Diagram
8.1 Introduction 8.2 Integration Testing and Sequence diagram 8.3 UML’s Sequence Diagram 8.4 The Proposed Approach
37
37-38 38 39-41 41-46
Chapter 9 - Implementation and Experiment 9.1 Implementation with PIN Authentication Component 9.2 Implementation with Ticket selling Component 9.3 Implementation with Registration System Component
47
47-5152-5657-61
Chapter 10- Conclusions and Future Work 10.1 Evaluation of Experiment 10.2 Summary of the contribution
62 62-64 64-65
References66-68
6
List of Figures
Figure 5.1.1: Collaboration diagram of Bank Server Component……………………….16
Figure 5.1.2: Sequence diagram of Bank Server Component………………………….. 16
Figure 5.1.3: Collaboration diagram of Bank Transaction Component………………....18
Figure 5.1.4: state chart diagram of exit event………………………………………… 18
Figure 5.1.5: Collaboration diagram of Bank Component……………………………... 19
Figure 5.1.6: State Chart diagram showing dependence relationship……………....…...20
Figure 5.2.1: The CDFD of Do operation Module…………………………………….. 23
Figure 5.2.2: CDFD of division operation……………………………………………… 25
Figure 6.1.1: Model view of UML………………………………………………………32
Figure 8.3.1: Segment of sequence diagram showing message passing…………………39
Figure 8.3.2: A segment of a sequence diagram in which the addStudent message has a
guard……………………………………………………………………………………..40
Figure 8.4.1: Schematic representation of our approach………………………………...42
Figure 9.1.1: Sequence Diagram of ATM PIN Validation Component…………………49
Figure 9.2.1 :Class Diagram of Box office application………………………………….53 Figure 9.2.2: Sequence Diagram of Ticket selling component…………………………..54 Figure 9.3.1: Sequence diagram of Automated Registration System……………………59
Figure 10.1.1: Bar chart of total number of test cases and execution time for ATM
component………………………………………………………………………………..62
Figure 10.1.2: Bar chart of total number of test cases and execution time for Ticket
Selling component……………………………………………………………………….63
Figure 10.1.3 Bar chart of total number of test cases and execution time for Registration
component……………………………………………………………………………….64
7
List of Tables
Table 5.1.1: Table to generate test cases for context collaboration diagram………….. 17
Table 5.1.2: Table to generate test cases for context Statechart diagram……………… 19
Table 5.1.3: Table to generate test cases for content collaboration diagram………….. 20
Table 5.1.4: Table to generate test cases for content Statechart diagram……………… 21
Table 5.2.1: Process decomposition Table ….……………......……………………… 24
Table 5.2.2: Table to generate test cases for CDFD...………………………………..25-26
Table 6.1.1: Testing Phases and UML diagrams ….……......…………………………..34
Table 9.1.1 : Five operation scenarios represented in the form of quadruples…………..50
Table 9.1.2: Test Run with sequence Diagram of ATM PIN Validation………………..52
Table9.2.1 Three operation scenarios represented in the form of quadruples…………...55
Table 9.2.2 Test Run with sequence Diagram of Ticket Selling………………………...57
Table9.3.1: Two operation scenarios represented in the form of quadruples……………60
Table 9.3.2: Test Run with sequence Diagram of Registration system………………….62
8
Chapter 1
Introduction 1.1 Problem
Component-Based Software Engineering (CBSE) is a software development
methodology based on the reuse of existing, often pre-compiled, modules of software.
Third-party built components are regularly referred to as COTS (Commercial off-The
Shelf) components. CBSE not only requires focus on system specification and
development, but also requires additional consideration for overall system context,
individual components properties and component acquisition and integration process
[10].
Components-based software systems are becoming prevalent as an engineering
approach that empowers rapid development with fewer resources. The major goals of
CBSE are the provision of support for the development of systems as assemblies of
components, the development of components as reusable entities, and the maintenance
and upgrading of systems by customizing and replacing their components. Component-
Based Development (CBD) offers a radically new approach to the design, construction,
implementation and evolution of software applications. Software applications are
assembled from components from a variety of sources; the components themselves may
be written in several different programming languages and run on several different
platforms. Conventional development is a special case of CBD, which lacks some of the
techniques and opportunities (and of course the benefits) that characterize full CBD.
To ensure the delivery of quality9 component based software, effective and
efficient testing is the key process in software development. Component Based Software
has implementation transparency property and its frequent heterogeneity raise some
difficulties when the software is to be tested. Since components are intended to be reused
across various products and product-families, components must be tested adequately.
Since 40% of software errors are revealed during integration testing. Adequate
integration of reusable components is the key to the success of a component-based
software system [8].
9
Integration testing is an important part of the testing process in which individual software
modules are combined and tested as a group. Integration Testing is performed after unit
testing and before system testing. Its objective is to identify defects in the interfaces and
interactions between components. When the integration errors appear, then error location
and cause analysis is done during the integration testing. There could be functional
problems, which means errors caused by missing or wrong functionality. Non-functional
problems can be a consequence of non-matching requirements, such as reliability,
maintainability and usability. In addition, Problems could be architectural, which may
require changing the whole architectural structure. There could also be conflicts between
components in the systems – for instance, deadlocks. Furthermore, there could be
interface problems, which are caused by syntax or semantic software and hardware
incompatibilities.
Different component features such as source code unavailability, component
heterogeneity and continuously changing nature, may cause difficulties in Component
integration testing. Thus mechanisms for component integration testing demand that
additional information must be packaged with the component for the reliable use of
component applications, which is necessary for effectively utilizing the reuse benefit of
component [7].
We use Unified Modeling Language (UML) and its sequence diagram for
Integration Test case generation.UML design Model consist of Variety of diagrams. Each
diagram describes a view of design. For Example, a class diagram describes a structural
view and sequence and activity diagrams describe behavioral views.
1.2 Overview of the Solution and the research challenges
Quality of end product and effective reuse of software depend on large extent on testing.
Developers therefore spend considerable time and efforts to achieve thorough testing.
Regardless of the test strategy being used, large systems are inherently complex to test
and require large number of test cases to be designed. There is an increasing need for
10
effective testing of software for complex safety-critical applications, such as avionics,
medical, and other control systems.
For Integration testing, we can derive tests from UML Sequence diagrams, which
embody the behavioral description of each component of interest and more importantly,
the interactions or events between them. UML, the Unified Modeling Language, is the
emerging graphical notation to model, document and specify all phases of the software
process. An approach of generating inputs for testing UML design requires mechanism
that combines information from both the structural and behavioral views of design.
We conducted the case studies to investigate the effectiveness of our testing
approach. The studies include the effective way of generating the UML Integration test
case selection based on UML sequence diagram. The work described in this thesis
includes storage of information that we are getting from sequence diagrams in a graph
called graph of sequence diagram (GOSD).Sequence diagrams are drawn with the help of
UML drawing tool StarUml.The graph is generated in c++, and the structure is decided
so that it can dynamically store any number of links and any amount of information .We
consider depth-first traversal algorithm to traverse graph. After that the Graph is
traversed to generate test cases for integration testing. For the specification of test case,
we consider the test case specification language. The practical approach for generating
the integration test suite will provide more accuracy as compared to the manually
generating the test suite.
1.3 Organization of the Report.
The Project is organized as follows:
Chapter 2 Presents Objective
Chapter 3 Describes Overview of Integration testing.
Chapter 4 Discusses Literature Survey
Chapter 5 Implementation of Component Integration testing Techniques like UML
based, data-flow specification.
Chapter 6 Describes UML
Chapter 7 Provides related work in UML
Chapter 8 Provides an overview of our approach.
11
Chapter 9 Describes Implementation of our approach
Chapter 10 Discusses results and Future work of our Implementation.
12
Chapter 2
Objectives
Building high quality and reusable software components is very important for
component-based software development projects. The testability of software components
is one of the important factors determining the quality of components. Building programs
and components with good testability always simplifies test operations, reduces test cost,
and increases software quality. The testing process proceeds from testing individual
modules, through to integration and system testing.
As individual modules are built unit testing occurs on these. Unit testing is done
primarily by developers. As the system grows, tests are conducted as the modules are
combined together. This type of testing may be done by testing teams, and may no longer
involve the original developers. This is called integration testing. The challenge in
component based testing is the integration testing because individual components have
already been tested. Integration testing is often the most time consuming and expensive
part of testing. Commercially available software components are generally packaged
without source code and this may cause difficulties in component integration testing.
The objectives include:
• To study existing component based integration testing techniques and their impact
on component based software product.
• Implementation of some of the existing techniques and to verify their results.
• Improving the exiting component based integration testing methods.
• Implementing a systematic approach to automate Integration Testing.
Chapter 3
13
Component-Based Integration Testing
3.1 Introduction
Testing is essential in the development of any software system. Testing is required to
assess a system’s functionality and quality of operation in its final environment. This is
especially of importance for system being assembled from any self-contained software
components. Basically testing is done to reveal faults and after detecting failures,
debugging techniques are applied to isolate and remove faults.
To ensure the delivery of quality software, effective and efficient testing is the
key process in software development. Testing may be viewed as structural (or white box)
or it may be viewed as functional (or black box). White box tests are designed using
knowledge of the data structures and algorithms within the program, while black box
testing uses only system specifications. The testing process proceeds from testing
individual modules, through to integration and system testing. As individual modules are
built unit testing occurs on these. Unit testing is done primarily by developers. At this
point a combination of white and black box testing can occur. As the system grows, tests
are conducted as the modules are combined together. This type of testing may be done by
testing teams, and may no longer involve the original developers. This is called
integration testing. Testing of the entire integrated system is called system testing.
Integration and system testing are commonly restricted to black box testing. They rely
heavily on documentation of system specifications.
Integration testing has always been a challenge especially if the system under
test is large with many subsystems and interfaces. According to Li et al., approximately
40% of software errors are revealed during integration testing [8].
IEEE defines integration testing as “testing in which software components are
combined and tested to evaluate the interaction between them”. Indeed, unit testing
cannot confirm the reliable behavior of components in a new system; hence another
testing is essential to attain an acceptable reliability level [7].
The beginning of integration testing assumes a reliable and complete set of unit tests. At
this stage we begin to combine the different tested units or components to conform a
14
working subsystem. Despite the fact that a unit has been through a successful unit test, it
might still behave unpredictable when interacting with other components in a system.
Therefore testing at the integration level is dependent on the quality of the unit tests and
on the complexity of interactions that occur between components.
3.2 Objectives of Integration Testing
Component integration testing is an indispensable phase. Main reasons to conduct
integration testing include:
1) Determine if the commercial components will work properly together.
2) To find faults that could not have been found in the component testing because
they only become apparent when the components are integrated.
3) To generate credible information about the software under test, so that technical
and business decisions can be made.
4) Confirm that as the system grows risk of failure is being diminished.
3.3 Component Integration Testing Vs Module Testing
The emphasis on modularity in software design has influenced designers master the
complexity of software systems by dividing them into components. One of the benefits of
modularity is that the software components can be tested independently, which is usually
done by programmers during unit and module testing. Although much is known about
unit and module testing and many techniques and tools are available, the integrated
components also need to be tested.
Unit testing techniques are sometimes applied during integration, but using these
techniques for integration testing suffers from two problems.
1) The unit testing techniques are usually too expensive to be practically applied
during integration
2) There is no reason to believe that they will find the kinds of faults that appear
during integration. Some software faults cannot be detected during unit testing;
These are often faults in the interfaces between units. Thus, we must specifically test
for integration faults.
15
3) During module testing, we concentrate on analyzing the implemented algorithms
and their data usage. These are determined by items such as statements, sequences
of statements, and values of variables and expressions. Thus, we use the well-
known test data selection criteria. These are well suited since modules usually are
relatively small. For integration testing we could, of course, use the same criteria
as for module testing. However, on the one hand this could lead to many test
cases and on the other; we would not consider that each module has already been
tested. This is why during integration testing we concentrate on analyzing another
aspect, namely the relations and the interfaces between the modules [15].
3.4 Integration Testing Strategies There are two common ways to conduct integration testing.
• Non-incremental integration: It uses a Big-bang approach to integration; it is
a very simple approach as there is no need of stubs and drivers. In addition
little planning and resources are needed for big-bang approach. It involves
combining all the tested units and performing tests on the combined system as
a whole. The usual problem with this approach is the level of complexity
involved in locating the sources of errors when unexpected events occur.
• Incremental integration: In this approach the program is constructed and
tested in small increments by adding a minimum number of components at
each interval. Therefore, the errors are easier to isolate and correct, and the
interfaces are more likely to be tested completely.
Two different approaches have been identified as means of performing
incremental integration testing: Top-Down integration and Bottom-up integration
1) Top-Down integration: In this modules are integrated from the main module
(main program) to the subordinate modules either in the depth-first or breadth-
first manner. Test the top layer of the controlling subsystem first. Then combine
All the subsystems that are called by the tested subsystems and test the resulting
collection of Subsystems. Do this until all subsystems are incorporated into the test. In
16
this approach Test Stubs are used to simulate the components of lower layers that have
not yet been integrated. Drivers are not needed in this. The advantage of this approach is
that faults can easily be identified. Drawback of this approach is the extra coding
involved in writing stubs.
2) Bottom-Up integration: In this lowest level sub-modules integrated and tested first
then the successively superior level components are added and tested, transiting
the hierarchy from the bottom, upwards. Only Test Drivers are used to simulate
the components of higher layers. No stubs are required in this approach. An
advantage of this approach is that Interface faults can be more easily found.
Disadvantages of this approach are Components of the User Interface are tested
last and Faults found in the top layer may lead to changes in the subsystems of
lower layers, invalidating previous tests.
3.5 Different issues in component integration In a component-based software product line, programs are built based on a set of
software components. There are two factors, which affect the complexity of component
integration. The first is the number of involved components. The other is the
customization capability of components. Several issues in component integration are
listed below:
Difficulty to form integration test suites based on component test suites: There are two
reasons. Constructing test suites in an ad-hoc manner is the first one, which causes
inconsistent test information format, diverse access mechanism, and different data store
technology. These affect the reuse of test suites for component integration. The other
cause is the lack of test selection methods to build integration test suites based on
component test suites. Most existing techniques focus on the selection of white-box tests
based on program structures, such as control flow or data flow. However, they are not
applicable for selecting black-box tests for component integration and re-integration due
to the following facts.
• Component integration focuses on a) the interactions between components at the
component level, b) the integrated structures of components, and c) the integrated
17
functions based on customized components. Thus, test generation and test
selection methods must address their integrated functional features at the
component level.
• The interactions and relationships between components are much more
complicated than the interactions between procedures when communications and
multithreading are involved.
Therefore, we need new systematic methods a) to identify and select tests from
black-box component test suites to form integration test suites, and b) to select
tests from an integration test suite for regression testing.
High cost on building integration environments. In the component engineering
paradigm, a product is constructed based a number of components. Each product is the
integration result of a set of customized components according to the given requirements.
Therefore, as the number of components increases, the number of component integrates
also increases. Building an integration environment for a component-based software
system is difficult and expansive due to the ad hoc construction of component test drivers
and stubs.
3.6 Features to be tested
Integration testing should be concerned only about interfaces Thus, to design test cases effectively and efficiently; we need a detailed description of the internal interfaces of the system. Needed Interface information can be obtained from:
• Communication protocols
• Subsystem definitions
• Sequence and collaboration diagrams
• Call-pairs and their argument lists
• Lists of events to be processed by the system
• Definition, use, and flow of global data
18
• Failure handling and recovery processing in components. For example special
cases at interfaces (data not available, data in improper format, empty files,
network unavailable, etc.)
3.7 Integration Faults The interaction-related faults can be classified into programming-related faults, which
are intercomponent faults, and nonprogramming-related faults, which are interoperability
faults. Faults that are overlooked during unit testing can be identified during integration
testing and are classified as traditional faults.
• Intercomponent faults: Even when the individual components have been
evaluated separately, there can still be faults in the interactions between them.
Programming-related faults that are associated with more than one component are
considered to be intercomponent faults.
• Interoperability faults: Many characteristics of component-based systems, such
as heterogeneity, source code unavailability, and reusability, will lead to different
types of interoperability problems. These interoperability problems can be
classified into system-level, programming-language level, and specification-level
interoperability faults.
1) System-level interoperability faults: In a component-based system, different
components can have been built under different infrastructures, and the
infrastructures may not be 100% compatible. For example, incompatibility
between different CORBA products can affect the interaction between CORBA
components.
2) Programming-level interoperability faults: When components are written in
different programming languages, incompatibility between the languages may
cause problems. For instance, Microsoft supports the integration of VC and VB
components. But the floating-point incompatibility may cause interoperability
faults.
19
3) Specification-level interoperability faults: Specifications may be misinterpreted
by developers, and there are many different ways that specifications may be
Misunderstood. This type of fault can be caused by the data that pass through the
interfaces or the patterns of the component interactions
• Traditional faults and other faults: Traditional testing and maintenance
techniques can be adopted for those faults that can be isolated within one
component. These faults will be identified as traditional faults. Other faults, such
as faults related to special-input or special-execution environments, also fall into
this category.
3.8 A test Model for integration testing of components based software To test component-based software adequately and effectively a test model is described. In
test Model there are different test elements that are likely to reveal integration faults.
Given a test element a family of test adequacy criteria is then provided.
Test elements: During integration testing, test model emphasizes interaction between
components. A component may interact with other components directly, through an
invocation of interfaces exposed by those components, an exception or a user action that
triggers an event. A component may also interact with other components indirectly
through a sequence of events. The elements that need to be taken into account in
component-based testing are:
Interfaces: Interfaces are the most common ways to activate components. Therefore, it is
necessary during integration and system testing to test each interface in the integrated
environment at least once.
Events: Testing interfaces provides confidence that every interface that is possibly
invoked during run time has been exercised at least once. This scenario is similar to the
traditional test criterion that requires every function or procedure to be tested at least
once. However, an interface invoked by different components within different contexts
may have different outcomes. Thus, to observe possible behaviors of each interface
20
during runtime, every invocation of the interface needs to be tested at least once.
Moreover, some events that are not triggered via interfaces may have an impact on the
Components, which need to be tested as well. Therefore, every event in the system
regardless of its type needs to be covered by some test.
Context-dependence Relationships: Interface and event testing ensure that every
interaction between two components, the client and the server, is exercised. However,
when execution of a component-based software system involves interactions among a
group of components, the sequence of event triggering may produce unexpected
outcomes. To capture the inter-relationships among events, we define a context
dependence relationship that is similar to the control flow dependence relationship in
traditional programs.
Context-sensitive dependence relationships include not only direct interactions, but also
the indirect collaboration relationships among interfaces and events occurring through
other interfaces and events as well. Therefore, testing context-sensitive dependence
relationships may serve to identify interoperability faults caused by improper interactions
among different components.
Content-dependence Relationships: An invocation of an interface of a component is in
fact an invocation of a function implemented by the component. Therefore, when a
function declared in an interface v1 has data dependence relationship with another
function declared in another interface v2, the order of invocation of v1 and v2 could
impact the results. A content-dependence relationship exists between two interfaces v1
and v2 if the two interfaces have a data-dependence relationship.
21
Chapter 4
Literature Survey
Component based technology is increasingly adopted to speed up the development of
complex software through component reuse. Yet, improved reuse and reduced cost
benefits from software components can only be achieved in practice if the components
provide reliable services, which makes component analysis and testing a key activity. The
crucial problem is the lack of information for analysis and testing of components. Several
component integration-testing techniques have been proposed to provide a solution for
these issues.
Ye Wu1 and Mei-Hwa Chen2 and Jeff Offutt suggested UML-based Integration
Testing for Component-based Software UML, a modeling language, has been widely
adopted in component-based software development process as a tool for capturing
component relationships. Many of its useful tools, such as Collaboration diagrams,
statechart diagrams, and Sequence diagrams, characterize the behavior of a component in
various aspects, and thus can be used in testing component-based systems. In the UML,
Collaboration diagrams and Sequence diagrams are used to represent interaction among
different objects in a component.Statechart diagrams are used to characterize internal
behaviors of objects in a component. There are several advantages to adopting the
UML.First, the UML provides high-level information that characterizes the internal
behavior of components, which can be processed efficiently and used effectively when
testing. Second, the UML has emerged as the industry standard for software modeling
notations and various diagrams are available from many component providers. Third, the
UML includes a set of models that can provide different levels of capacity and accuracy
for component modeling, and thus can be used to satisfy various needs in the real world.
But the main Drawback of this approach is that the diagrams in the UML do not describe
the precise semantics of a system, and therefore the corresponding test cases are less
22
rigorously generated. The activity diagrams in UML do not support nondeterministic
mechanism useful for modeling of systems either [11].
Sami Beydeda and Volker Gruhn.et al proposes an approach for “integration testing” that
explicitly takes into account the testing relevant features of component based software
and thus allows more rigorous testing. The basic constituent of this approach is graphical
representation combining black and white box information from specification and
implementation. The graphical representation can then be used for test case generation.
But this technique has one flaw that is very time consuming approach and there is no
provision of automatic test case generation [9].
Yuting Chen, Shaoying LIU and Fumiko Nagoya suggested an approach to testing
programs based on Data Flow Specification by analyzing data flow paths and discussing
criteria for test case generation. This approach suggests a specific Way to generate test
cases directly from formalized data flow diagrams and the associated textual
specifications. A path oriented approach is used for integration testing of programs based
on a conditional data flow diagram (CDFD).CDFD are adopted to describe the
architecture of specification. The idea in this approach is to select path from CDFD to
cover all branches of the control structures and process functions and then to generate test
cases using the constraints defined by textual specifications. Drawback of this technique
is that it is extremely difficult to correctly select data flow paths and to generate test cases
based on data flow diagrams [12].
Different kind of approach, self-testing was suggested by Fevzi Belli et.al . It is widely
accepted that conventional test methods are not necessarily adequate for testing of
component-based software. Also conventional test tools cause same problem for the
automation of the test automation of CBS, because the knowledge about the
implementation of the CBS are essential to run the tests. The component manufacturer on
the other hand is not willing to provide the component source code. This technique
23
introduces the framework for the automation of user oriented component testing that
significantly reduces the test cost and it is based on black box testing and utilizes
common features of commercial capture / playback tools.
The novelty of this approach is the framework that enables automatic generation of test
cases and test scripts without involving domain knowledge and knowledge about object
code. However it also reveals a weakness, if the CBSUT is changed, e.g., produce a new
release, the test frame, i.e., the test case, and consequently, the test script might become
obsolete. So component model needs to be automatically updated [3].
Another technique that is given by Zhenyi Jin and A. Jefferson Offutt is based on
software- coupling. Coupling between two units reflects the interconnection between
units; faults in one unit may affect the coupled unit. Coupling is ordered into eight
different levels according to their effects on the understandability, maintainability,
modifiability, and reusability of the coupled units. The coupling-based testing criteria are
based on the design and data structures of the program and on the data flow between the
program units. The underlying premise of the coupling-based testing criteria is that to
achieve confidence in the interfaces between integrated program units, we must ensure
that variables defined in caller units be appropriately used in called units [13].
Antonia Bertolino, Paola Inverardi, Henry Muccini, Andrea Rosetti proposed An
Approach to Integration Testing Based on Architectural Descriptions. Descriptions of the
software architecture can be useful to drive integration testing, since they supply
information about how the software is structured in parts and how those parts interact.
Therefore a formal architectural description is used to model the “interesting” behavior of
the system. Starting from a formal description of the software architecture, A graph of all
the possible behaviors of the system in terms of the interactions between its components
is shown. This graph contains altogether the information we need for the planning of
integration testing. On this comprehensive model, we then identify a suitable set of
reduced graphs, each highlighting specific architectural properties of the system. These
24
Reduced graphs can be used for the generation of integration tests [2].
25
Chapter 5
Implementation of Component Based Testing Techniques 5.1 UML-based Integration Testing for Component-Based Software UML (Unified Modeling Language) is a tool for capturing component relationships.
Without source code, we can obtain the specifications of interfaces and events; however,
context-dependence relationships and content- dependence relationships would be
difficult to derive without a sophisticate mechanism. These two elements are much more
effective than others in detecting component integration faults. Therefore, it is important
to develop a methodology to obtain these two elements from the available resources other
than the source code. UML, a modeling language, has been widely adopted in
component-based software development process. Many of its useful tools, such as
interaction diagrams, state chart diagrams, and component diagrams, characterize the
behavior of a component in various aspects, and thus can be used in testing component-
based systems.
Component
Bank server component is used in which different interfaces and events are described.
We have described context-dependence and content dependence relationships of different
transactions and account validation.
Implementation:
Context-dependence relationships: Context-dependence relationships, which model how
interfaces and events interact, can be derived through one of the following different
approaches:
Collaboration/sequence diagram based approach: The sequence diagram only shows one
of the possible scenarios ordered by time while the collaboration combines all scenarios
in numbered order. Collaboration diagram and one sequence diagram of a Bank sever
component can be described as:
26
W1
Choice
Accou Log
W4AW4A.1
W5 W5A
W5A.1
W6
W3 W3A
W3b
W2
W4
Figure 5.1.1 Collaboration diagram of Bank Server Component
W1- main menu W5- available balance response W2- Enter ID and Password W5A- Insufficient Balance W3-Valid Account data W5A1- Withdrawal response (insufficient balance) W3A- Invalid Id W6- Withdrawn successful message W3B- ID/ Password doesn’t match W4 Enter amount to withdraw (ID, Password) W4A- Log Transaction W4A 1-Update Balance
USER
Choice Menu Account Transaction Log Entry
W6
W4A,w4A.1
W5
W4
W3
W2
W1
27
Figure 5.1.2 Sequence diagram of Bank Server Component
Test case ID
Module Interface
Test Case Title
Test case Objective
Test steps Test data Expected Results
W1 Main Display Menu To Check menu Is Displayed properly
Run program Menu Function
Choice menu is displayed correctly and accepting the input correct way
W2 Account Accept ID /pwd
Check accepting Id/pwd
Call account interface which accept Id/pwd
Id/pwd field
Id/pwd entered without any problem
W3 Account Validate ID/pwd
Validate accepted Id/pwd
Verify Id/pwd Id/pwd field
If the id/pwd match found it return success and go to next step otherwise it will go back to choice menu
W4 Transact-ion
Accept Transaction
Accept the transaction type and perform the operation accordingly
Accept Input choice ‘W’ for withdraw, ‘d’for deposit’s’ to view account summary and amount in case of selected choice is w/d
Choice amt Accept the input choice and amount for successful transaction
W5 Transact -ion
Insufficient Balance
If the balance is less than amount entered give an error msg
Compare amount entered with available balance
Available amt
If wdl amt is more than available then prompt a msg insufficient balance
W6 Log Log Transaction
Record the transaction
Write account id, Transaction id, Time, amount withdrawn, available balance in log file
Account id, transaction id, time, amt withdrawn, available balance
Data written successfully and a msg will be displayed for Successful transaction
Table 5.1.1 Test cases for context collaboration diagram
Statechart based approach: The behavior of component more precisely modeled by
combining the collaboration diagram with the statechart diagrams which are used to
describe state-dependent control objects in components. With the help of statechart
diagram we can see exit sequence needs to be validated in four different scenarios 1)
28
Waiting for user choice 2) Waiting for A/c & PWD 3) Valid A/c & PWD 4) Waiting for
Transaction Type.
1 Display Menu
Choic
e
Input
Accoun
Displ
Trans
action
Entry
Log 2.6 Update Balance
2.5 Transaction Successful
1.1 B Exit
1.1Enter Input 2.3 A Exit chosen
2.1A/C No and Password
2.1 A Invalid A/c Pwd
2.4* Enter Transaction Type wdl/dep
2. 3 Valid A/C choice
1.1 A Exit chosen
2.4.1A insufficient funds 2.4.1 B Display Msg
2.5A Display Message
Figure 5.1.3 Collaboration diagram of Bank Transaction Component
29
Choice
2.4
2.3
Waiting for
Waiting for
Valid A/c &
Waiting for Transaction Type
2.1A
2.1
1.1A, 1.1B
2.3A
1, 1.1
Test Case ID
Module/Interface
Test Case Title
Test Case Objective
Test steps Test data Expected Result
W1 Main display menu User can exit from program
waiting for user choice- Press exit key
escape key Control will come out from program
W2 Account invalid ID/Password
ID/Password match not found exit from transaction
enter wrong Id or password
Id,password field
user id/password accepted & verfied they are entered wrongly, exit to main menu
W3 Transaction
cancel transaction
user can cacel the transaction & move to main choice menu
accept choice to cancel transaction
choice will exit from transaction interface & control will move back to main menu
Figure 5.1.4 State Chart of Exit Event
Table 5.1.2 Test cases for context Statechart diagram
Content-Dependence relationship: Context dependence relationships may depict the
interactions within each of the interfaces, but the content-dependence relationships across
the interfaces cannot be obtained. The component includes two interfaces-withdraw and
deposit interface. For instance, the withdrawal interface depends on deposit interface
because deposit transaction will modify the account entity, while withdrawal transaction
will use that entity to verify whether there is enough money in that account. it can be
obtained through:
a) Collaboration diagram approach: collaboration diagram can demonstrate the
dependence relationships between two interactions.
30
Collaboration Diagram Withdraw
Bj+ 1 Ai+1
Deposit
Test Case ID
Module/ Interface
Test Case Title
Test Case Objective
Test steps Test data Expected Result
Ai Withdraw Update Balance
Withdraw interface depends on deposit interface. If there is sufficient balance then only we can withdraw
Choose the withdraw transaction type. And available balance accordingly
Available,amt Balance field updated successfully only if there is sufficient balance
Bi Deposit Update balance
deposit available balance will be updated
Choose deposit Transaction type
amt Balance field updated successfully
Bj
Ai
Figure 5.1.5 Collaboration diagram of Bank Component
Table 5.1.3 Test cases for Content collaboration diagram
Statechart Diagram approach Statechart diagrams are able to demonstrate content dependence relationships from a state
transition point of view. The rationale lies in the fact that if interface I1 depends on I2,
the state of the component is S1 after the execution of I1.When executing interface I2, the
state transitions from S1 to S2 depend on state S1 and the invocation I1.
State Chart Diagram showing dependence relationship (in transaction interface I2 the state of available balance changed to S2 from S1 in interface I1) (i t ti i t f I th t t f il bl b l i t h d it t t t S f S i i t f I it
Available balance
Update
AvailableDisplay available
I1:: Account Interface
I2::Transaction Interface
Withdrawal/ Deposit
S1 S2
S2
Display A/c 31
S1
Test Case ID
Module/ Interface
Test Case Title
Test Case Objective
Test steps Test data Expected Result
T1 Account/ Transaction
Update Balance
if entered amount for withdraw transaction is less than available and valid the available balance field value will be changed from state s1 to s2
Perform Valid Transaction
Available,amt
Available balance field value changed
T2 Account/ Transaction
No change in Balance
If display summary is chosen then there won’t be any effect on available balance it will remain in the same state
Choose display summary
Transaction type, Available
Available Balance field does not change its state
Figure 5.1.6 Statechart diagram
Table 5.1.4 Test cases for Content State chart diagram
Results UML provides high-level information that characterizes the internal behavior of
components, which can be processed efficiently and used effectively when testing. The
activity diagrams in UML do not support nondeterministic mechanism useful for
modeling of systems either. With the Use of UML based integration testing it is very
difficult to draw diagrams manually.
32
Chapter 6
Unified Modeling Language (UML)
6.1 Introduction
Unified Modeling Language (UML) is used by number of software developers as a basis
for design and implementation of their component-based applications. The Unified
Modeling Language (UML) is a standard language for specifying, visualizing,
constructing, and documenting the artifacts of software systems, as well as for business
modeling and other non-software systems. The UML is very important part of developing
objects oriented software and the software development process.
However, only little part of UML is used for Testing. This is an important issue,
because in many software development organizations, the cost of testing can account for
more than 40% of the total development cost for a software system. UML models offer a
lot of information that should not be ignored in testing. By combining different UML
components, different views of the program under test are used.
We address UML-based testing specifically; we address this under two guidelines:
1) We aim at a test method that is entirely based on UML, so that it can be easily
adopted by industries already using UML.
2) We refer to high level descriptions of the system: we want to address test planning
for the integration test phase starting from the very first stages of system design.
Modeling languages are used to get the specification and generate test cases. Since UML
(Unified 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.
The UML
• Is a Language: it is not simply notation for drawing diagrams, but a complete
language for capturing knowledge about a subject and expressing knowledge
regarding the subject for the purpose of communication.
33
• Applies to Modeling the systems: Modeling involves a focus on understanding
(knowing) a subject (system) and capturing and being able to communicate this
knowledge.
• Is used for specifying, visualizing, constructing and documenting systems.
• Is based on the object oriented paradigm.
• Is an evolutionary general purpose, broadly applicable, tool supported, industry-
standardized modeling language.
• Applies to a multitude of different types of systems, Domains and methods or
processes.
6.2 Goals of UML
If we are working on a software development team, we need to have a specific standard.
If we don't have a standard for your software development, it is very likely that our final
product will be riddled with problems. This is something that a team must avoid at all
costs if we wish to be successful. Primary goals of UML are:
• When a team uses a specific standard, they will have high levels of
communication. UML is a tool that can allow you to maintain (tool to maintain)
this standard. It is the tool of choice for those who work in the software
development industry, and it doesn't matter if the team is separated by thousands
of miles. UML will give them the platform which will allow the team to build a
powerful application.
• Provide users with a ready-to-use, expressive visual modeling language so they
can develop and exchange meaningful models.
• Be independent of particular programming languages and development
processes.
• Support higher-level development concepts such as collaborations, frameworks,
patterns and components.
• Encourage the growth of the OO tools market.
• Provide extensibility and specialization mechanisms to extend the core concepts.
34
• The UML diagrams are designed in such a way that they can be used for strong
communication. In addition to communication between the development team,
applications designed with UML will more efficient for the end user.
6.3 The Building Blocks of UML
Each UML diagram is designed to let developers and customers view a software system
from a different perspective and in varying degrees of abstraction. UML diagrams
commonly created in visual modeling tools include:
Use Case Diagram: Displays the relationship among actors and use cases.
Class Diagram: Models class structure and contents using design elements such as
classes, packages and objects. It also displays relationships such as containment,
inheritance, associations and others.
Interaction Diagrams
• Sequence Diagram displays the time sequence of the objects participating in the
interaction. This consists of the vertical dimension (time) and horizontal
dimension (different objects).
• Collaboration Diagram displays an interaction organized around the objects and
their links to one another. Numbers are used to show the sequence of messages.
State Diagram displays the sequences of states that an object of an interaction goes
through during its life in response to received stimuli, together with its responses and
actions.
Activity Diagram displays a special state diagram where most of the states are action
states and most of the transitions are triggered by completion of the actions in the source
states. This diagram focuses on flows driven by internal processing.
Physical Diagrams
• Component Diagram displays the high level packaged structure of the code
itself. Dependencies among components are shown, including source code
components, binary code components, and executable components. Some
Components exist at compile time, at link time, at run times well as at more than
one time.
35
• Deployment Diagram displays the configuration of run-time processing elements
and the software components, processes, and objects that live on them. Software
component instances represent run-time manifestations of code units
6.4 Model View of UML—put it below the model
Class / Object Diagrams
Structural View
Sequence / Collaboration / Statechart / Activity Diagrams Environmental View
Component Diagrams
Implementation View
Use Case Diagrams
Deployment Diagrams Behavioral View
Figure 6.1.1 Model view of UML
• The Use Case View of a system encompasses the use cases that describe the
behavior of the system as seen by its end users, analysts and testers. With the
UML, the static aspects of this view are captured in use case diagrams.
• The Structural View of the system encompasses Class and Object Diagrams.
These diagrams depict all the classes and objects that will be used in the
development of the application.
36
• The Behavioral View of the system encompasses the dynamism of the Classes and
Objects. The dynamism of classes and objects are captured in Sequence,
Collaboration, Statechart and Activity Diagrams.
• The Implementation View of a system encompasses the components and files that
are used to assemble and release the physical system. This view primarily
addresses the configuration management of the system’s releases, made up of
somewhat independent components and files that can be assembled in various
ways to produce a running system.
• The Environmental View of a system encompasses the nodes that form the
system’s hardware topology on which the system executes. This view primarily
addresses the distribution, delivery and installation of the parts that make up the
physical system.
6.5 Software Testing and UML
Testing often accounts for more than 50% of the required effort during system
development. However, testing is often not well integrated with other development
phases. One reason for this is that designers, developers and testers all use different
languages and tools, making it difficult to communicate with each other and to exchange
documents. The UML Testing Profile bridges the gap between designers and testers by
providing a means to use UML for test specification and modeling. This allows the reuse
of UML design documents for testing and enables test development in an early system
development phase.
UML is basically used to model the interaction of various components and code
in the whole system we can check the UML diagrams to understand the various types of
information gathering like third party interaction etc and then form the test plan
accordingly. This way we can minimize the efforts to write the test plans.
When using UML in the software testing process, we will focus primarily on the
diagrams in the Behavioral Elements package. This is because most of the activities in
software testing seek to discover defects that arise during the execution of software
37
System and these defects are generally dynamic (behavioral) in nature. However, there
are cases where the behavioral information will need to be augmented with static
information typically found in the Foundation package.
There are many phases in the testing process, including unit, function, system, regression
testing.
The following table illustrates the differences between these phases, as well as the
potential UML diagram for use in the phase.
Test Type Coverage Criteria Fault Model UML Diagram
Unit Code Correctness,error
handling,pre/post
conditions,invariants
Class and state diagrams
Function Functional Functional and API
behavior,integration issues
Interaction and class
diagrams
System Operational Scenarios Workload
contention,recovery
Use case, activity and
interaction diagrams
Regression Functional Unexpected behavior from
new changed function Same as Function
Table 6.1.1 Testing phases and UML Diagrams
UML is a language that has a number of potential industry applications. In addition to
those who work in the software development field, UML is also beneficial to engineers. It
is an excellent language for architects and designers as well. While UML may seem
amazingly simple on the outside, it is very rich, and it has a large number of visual
elements. It is virtually impossible to memorize all the elements of UML.
38
Chapter 7
Related Work
The integration testing of OO software is concerned with testing the interactions between
units. Traditional testing strategies for procedural programs, such as control flow analysis
cannot be directly applied to OO programs. In object-oriented software development,
Unified Modeling Language (UML) provides the possibility to describe systems from
different perspectives e.g. static view by class diagram; dynamic by interaction and state
chart diagrams, etc. The combination of expressiveness and versatility of UML has
enabled the Paradigm to become very popular recently. Testing UML design models is
challenging because a design model consists of many models that describe different
design views. An approach to generating inputs for testing UML design requires a
mechanism that combines information from both the structural and behavioral views of a
design. Various approaches relating to integration testing of software have been
proposed.
Basanieri and Bertolino used a User Interaction Testing (UIT) model to perform
integration testing. A UIT is generated from use cases and UML sequence diagrams. It
basically aims at integration testing to verify that the pre-tested system components
interact correctly. They use category partition method and generate test cases manually
following the sequences of messages between components over the Sequence Diagram.
Use case diagrams are used to identify the suitable steps of an incremental test strategy.
For each identified sub Use Case, sequence diagrams are used to identify relevant
components or “Test Units”. For each Test Unit, relevant interactions and settings (could
be parameters, variables) are identified. After that test cases are generated whereby each
test case is characterized by a combination of all suitable choices of the involved settings
and Interactions. This approach is very simple and easy portable to industrial contexts.
since in this approach only UML diagrams are used the methods does not require
specialized expertise and analysis, and so generation of test cases can be done with
project development, at no or little extra cost. However method is manual therefore
requires lots of efforts and time for testing. Also exclusive use of UML diagrams can be
considered a limit to
39
this method, because as known UML semantic is not very precise, therefore diagrams can
have different interpretations from different users [6].
Trung T. Dinh-Trong, Sudipto Ghosh, Robert B. France proposed an approach to
generating inputs to test UML design models that are produced in the detailed design
phase of an Model driven development (MDD) project. A symbolic execution based
approach is used to derive test input constraints from the paths of a Variable Assignment
Graph, which integrates information from UML class and sequence diagrams. The VAG
is used to derive test input constraints that are then solved by the constraint solver, Alloy.
Model Driven Development (MDD) approaches tackle the complexity of developing
large software systems. In MDD, abstract logical models are systematically transformed
to detailed design models. If a detailed design model contains faults, those faults are
passed to the code if not detected and corrected before the transformation. The novelty of
this approach is that it considers both constraints on variables with primitive datatypes
and constraints on object configurations characterized by the class diagram view of a
system. In this Testing begins when a tester provides a UML design model under test
(DUT). A DUT consists of (1) a class model specifying structural aspects of the system,
(2) sequence diagrams that each models the interaction between objects when a system
operation is executed, and (3) activity diagrams that specify the behavior of operations. A
system operation is an operation of the system that executes in response to an external
input event generated by an actor to the system. Test inputs are derived from DUT class
and sequence diagrams, and used to test an executable form of the DUT.During test
execution, a set of failure conditions are checked. The transformation of the UML
diagrams into VAGs, the transformation of the constraints into Alloy, and the generation
of the path constraints are based on systematic rules, and thus are potentially
automatable. But it is very complex approach to generate test inputs [17].
40
41
Chapter 8
A Systematic Approach for Integration Testing from Sequence Diagram
8.1 Introduction
In a typical software development project, more than 50% of the software development
effort is being spent on testing. Quality of the end product and effective reuse of software
depend to a large extent on testing. Correct functioning of object-oriented software
depends upon the successful integration of classes. While individual classes may function
correctly, several new faults can arise when these classes are integrated together.
Developers therefore spend considerable time and effort to achieve thorough
testing. Creation of test cases is possibly the most difficult step in testing. Therefore,
designing a large number of test cases and carrying out the tests turn out to be very labor-
intensive and time consuming. To reduce the testing cost and effort and to achieve better
quality software, automatic testing has become an urgent necessity.
UML models can be interpreted differently depending on application. Many
UML design artifacts have been used in different ways to perform different kinds of
testing. For Instance testing of OO systems focuses on the use of class, Interaction or
state diagrams. Class diagrams provide information about the public interface of classes,
method signatures, and important relationships between classes. Interaction diagrams
(collaboration and sequence diagrams) have been used to test class interactions. State
diagrams provide information about the behavior of a class (or set of classes.).Modularity
aims at encapsulating related functionalities in classes. However, complete system-level
functionality (use case) is usually implemented through the interaction of objects.
Typically, the complexity of an OO system lies in its object interactions. As a result,
complex behaviors are observed when related classes are integrated and several kinds of
faults can arise during integration: interface faults, conflicting functions, missing
functions. Thus testing each class independently does not eliminate the need for
integration testing. A large number of possible interactions between collaborating classes
may need to be tested to ensure the correct functionality of the system.
42
UML models offer a lot of information that should not be ignored in testing. One of the
main problems in testing different components is test case selection. A pragmatic
approach is to concentrate on typical message sequences as modeled using the sequence
diagram. Testing based on sequence diagrams seems to be intuitive. Each sequence
diagram specifies one test case or set of test cases. Each sequence diagram is considered
as a set of test cases.
In this we present our approach for UML-based Integration Testing that uses Interaction
diagrams Specifically the Sequence diagram.
8.2 Integration Testing and Sequence diagrams
Ensuring high object interoperability is a goal of integration testing for object-oriented
(OO) software. When messages are sent, objects that receive them should respond as
intended. Ensuring this is especially difficult when software uses components that are
developed by different vendors, in different languages, and the implementation sources
are not all available. This essentially attempts to validate that classes, implemented and
tested individually, provide the intended functionality when made to interact with each
other. The focus at this level is on testing interactions between classes through method
calls or asynchronous signals, as well as interactions with databases or hardware.
Adequate unit-level testing of individual classes supports but does not produce a reliable
integration of group of interacting classes. This is because some of the bugs remain
dormant during unit testing and pop-up only after integration for a specific state of the
cluster. Hence the need of integration testing is necessary.
A sequence diagram describes how groups of objects collaborate in
accomplishing some system behavior. This collaboration is implemented as a series of
messages between objects. Sequence diagrams are good at showing which objects
communicate with which other objects; and what messages trigger those
communications. Sequence diagrams are not intended for showing complex procedural
logic. Such diagrams capture important aspects of object interactions, and can be
naturally used to define testing goals that must be achieved during Integration testing.
43
8.3 UML’s Sequence Diagram
A sequence diagram is a form of interaction diagram which shows objects as lifelines
running down the page, with their interactions over time represented as messages drawn
as arrows from the source lifeline to the target lifeline.
Sequence diagrams are good at showing which objects communicate with which other
objects; and what messages trigger those communications. Sequence diagrams are not
intended for showing complex procedural logic.
Lifelines
A lifeline represents an individual participant in a sequence diagram. A lifeline will
usually have a rectangle containing its object name.
Messages
Messages are displayed as arrows. Messages can be complete, synchronous or
asynchronous. In the following diagram, the first message is a synchronous message
(denoted by the solid arrowhead) complete with an implicit return message; the second
message is asynchronous (denoted by line arrowhead), and the third is the asynchronous
return message (denoted by the dashed line).
Figure 8.3.1: Segment of sequence diagram showing message passing
44
Guards
When modeling object interactions, there will be times when a condition must be met for
a message to be sent to the object. Guards are used throughout UML diagrams to control
flow. Figure 7 shows a fragment of a sequence diagram with a guard on the message
addStudent method
Figure 8.3.2: A segment of a sequence diagram in which the addStudent message has a guard
Combined fragments (alternatives, options, and loops)
A combined fragment is used to group sets of messages together to show conditional flow
in a sequence diagram.
Alternatives
Alternatives are used to designate a mutually exclusive choice between two or more
message sequences. Alternatives allow the modeling of the classic "if then else" logic
an alternative combination fragment element is drawn using a frame. The word "alt" is
placed inside the frame's namebox.
Option
The option combination fragment is used to model a sequence that, given a certain
condition, will occur; otherwise, the sequence does not occur. An option is used to model
a simple "if then" statement.Option combination is represented as a frame. The text "opt"
45
is placed inside the frame's namebox. and in the frames content area the option's guard is
placed towards the top left corner on top of a lifeline.
Loops
Modeling a repeating sequence is done with the addition of the loop combination
fragment.The loop combination fragment is very similar in appearance to the option
combination fragment. You draw a frame, and in the frame's namebox the text "loop" is
placed. Inside the frame's content area the loop's guard is placed towards the top left
corner, on top of a lifeline. Then the loop's sequence of messages is placed in the
remainder of the frame's content area.
8.4 The Proposed Approach
We have proposed a novel approach of generating test cases from UML design diagrams.
Our approach consists of transforming a UML sequence diagram into a graph called the
graph of sequence diagram (GOSD) and which consists of nodes and edges. Each node
stores information necessary for testing. This information can be taken from class
diagrams. We construct the storage graph using C++. The GOSD is then traversed
according to generate test cases. The test cases thus generated are suitable for integration
testing and to detect interaction faults.
Sequence diagrams are drawn with the help of StarUml tool. StarUML is an
open source project to develop fast, flexible, extensible, featureful, and freely-available
UML/MDA platform running on Win32 platform. The goal of the StarUML project is to
build a software modeling tool and also platform that is a compelling replacement of
commercial UML tools such as Rational Rose, Together and so on. StarUML supports
most of the diagram types specified in UML 2.0.
The run-time behavior of an object-oriented system is modeled by well-defined
sequences of messages passed among collaborating objects. In the context of UML, this
is usually modeled as interaction diagrams (collaboration or sequence).
We have proposed an integration testing technique that is based on the idea that
the interactions between objects should ideally be exercised while generation of test
cases. The main advantage with this approach is that test cases can be generated early in
46
the development process and thus it helps in finding out many problems in design if any
even before the program is implemented. A test case consists of a test input values, its
expected output and the constraints, that is the pre- and post condition for that input
values. This information may not be readily available in the design artifacts. As a way out
to this problem we propose an automatic test case generation method using UML models.
We use sequence diagram as a source of test case generation.
The proposed technique can be applied during the integration test phase, right after the
completion of class testing.
It consists of the following steps:
1) Converting Sequence diagram into a GOSD: A graph for sequence diagram is
constructed from sequence diagram. It stores all necessary information for
integration testing.
2) Test Case Generation: Graph (GOSD) is traversed to generate all possible paths.
Test paths are executed by using manually-generated test data .
3) Result Evaluation: The object states are compared with the expected object
states in the test paths generation. If any state of any object after execution of a
test path is not in the required resultant state, then the corresponding test case is
considered to have failed.
47
Sequence Diagram Graph of
SEQUENCE Diagram (GOSD)
Test Paths Generator Result
Evaluator
Pass/Fail
Figure 8.4.1 Schematic representation of our approach 1. Converting Sequence diagram into a GOSD: In this part of our approach we construct the GOSD using the C++. The minimum
requirement for the storage graph is window 98 or higher version and minimum 32 MB
RAM.
A sequence Diagram can be Represented as a Graph. The graph models all possible
Interaction among the different objects in diagram.
Definition of GOSD: Graph of Sequence diagram consists of states each state is assumed
to be vertex of graph. Transition from one state to another depending on the
input/applicable method with signatures is given by an edge of graph.
Two way list is used to implement the graph with linked representation.
GOSD :{ V, E} where
1) V is Vertex of graph. Vertex node consists of following info:
State id ISinitial ISfinal Pointer Next
vertex(Next
vertex)
Pointer to first
edge(edge root)
Initial and Isfinal are treated as Boolean types which gives the information about the state
whether it can be initial and /or final.
Stateid is correct state id and this vertex store the address of next vertex in the list.
Pointer to first edge store the address of first node in the edge list.
Each vertex is provided a separate edge list. Which store the outgoing edges from that vertex.
48
2) The Edge node is as follows:
Message
Name
Sender(from
object)
Receiver(to
object)
Attributes condition
Algorithm of graph Construction: Adding State: A new State can be added in a graph .create new state let it be Newstate.
Input the state parameters .Set pointer toedge=NULL .Set Next State pointer = NULL tmp =ROOT // temp be a pointer to vertex If ROOT=NULL
ROOT=New State Else { While tmp->Next Vertex#NULL Tmp=tmp->NextVertex Temp->NextVertex=NewVertex }
End if
ADDITION EDGE/TRANSITION Create a new edge let it be Newedge. Input edge parameter and pre condition. Input
method and method parameter with sender Receiver. Input source vertex. Let tmp be a
State and temp=root
While tmp->stateid#sourcevertex.stateid and tmp#NULL { Tmp=tmp->NextVertex } If (tmp=NULL)
49
Display message “Source Vertex not found” Else { If (tmp->edgeRoot=Null) Tmp->edgeRoot=NewEdge Else { Tmpedge=edgeRoot; While (tmpedge->NextEdge#NULL) Tmpedge=tmpedge->NextEdge tmpEdge->Nextedge=NewEdge } }
End if 2. Integration test case Generation A sequence diagram represents various interactions possible among different objects .A
test set is therefore necessary to detect faults if any when an object invokes a method of
another object and whether the right sequence of message passing is followed. From the
GOSD we can cover all paths from the start node to a final node and it can cover all
interactions as well as all message sequence paths. Given a test set T and a sequence
diagram D; T must cause each sequence of message path exercise at least once.To
generate test cases that satisfy the criteria, we first enumerate all possible paths from the
start node to a final node in the GOSD. Each path then would be visited to generate test
cases.
Test Strategy is used to detect Interaction faults. Several faults such as incorrect
response to a message, correct message passed to a wrong object or incorrect message
passed to the right object, message invocation with improper or incorrect arguments may
occur in an interaction.
50
Algorithm: TestSetGeneration
Let T be the test case input and S be a set of states. Let ‘TRANS’ be the set of transition
in sequence diagram. Now, to undergo integration testing we will have to match the test
input T’s attributes and test case is declared as PASS if all the attribute, of any transition
in ‘TRANS’.
For each s1 state in S // loop that will traverse each sate in
Sequence diagram
For each transition t1 in TRANS // loop that will traverse each
transition of current state
If t1.attributes= T.attributes then // condition that compares the attributes of test
Case input and transition of sequence diagram
Result = “Test is passed”
Else
Result= “Test Failed”
CheckReason (t, T) // to find the reason of failing test
Endif
// CheckReason function to check the integration faults
CheckReason (TRANS t1, testinput T)
If (t1.sender <> T.sender) then
Display “wrong sender”
Elseif (t1.receiver <> T.receiver) then
Display “wrong receiver”
Else if (t1.argumenttyrpes <> T.values) then
Display “invalid arguments/message”
Else if t1.returntype <> T.returntype then
Display “invalid response”
Endif.
51
52
Chapter 9 Implementation and Experiment
þ Ç Æ_ÒYÆ_É&¾«¿_×&×_¾ËÆ_¿_ÌqÎ2_
We performed three pilot studies to 1) demonstrate the interaction related faults using our
approach and 2) explore the performance of our approach. We applied our design testing
approach to ATM PIN validation component, Ticket selling System and automatic
Registration Component. In order to validate the effectiveness of our proposed approach,
we implemented a c++ program to store sequence diagram into a graph called graph of
sequence diagram and after that using Test case generation algorithm test cases are
generated to find out integration faults. The minimum requirement for the storage graph
is window 98 or higher version and minimum 32 MB RAM.
9.1 Implementation with PIN Authentication Component:
PIN Authentication component of ATM card is taken. In this component ATM card is
checked if card is valid then PIN is verified after that user will get Display message. If
card is not valid then it is ejected.
Step by Step Implementation of PIN Authentication Component is as follow:
1. Draw Sequence diagram of PIN Authentication Component: Sequence
diagram associated with PIN Authentication in a usual ATM System is drawn
with StarUml tool. Sequence diagram shows the interaction between different
objects like cardreader, sessionmgr, displaymgr, key reader and abank. Also
sequence diagram shows the order in which messages are transferred between
different objects.
This sequence diagram consists of five operation scenarios as shown on next page.
53
Figure 9.1.1 Sequence Diagram of ATM PIN Validation Component
2) Transformation of SD into a GOSD
In order to formulate a methodology, we define an operation scenario as a quadruple,
aOpnScn: <ScnId; StartState; MessageSet; NextState>.
ScnID identifies each operation scenario.
StartState is a starting point of the ScnId, that is, where a scenario starts.
MessageSet denotes the set of all events that occur in an operation scenario.
NextState is the state that a system enters after the completion of a scenario. This is the
end state of an activity or a use case.GOSD has a single start state and one or more end
state depending on different operation scenarios.
An event in a MessageSet is denoted by a tuple, aEvent: <messageName; fromObject;
toObject
54
[/guard]> Where,
messageName is the name of the message with its signature
fromObject is the sender of the message
toObject is the receiver of the message and the optional part
/guard is the guard condition subject to which the aEvent will take place.
An aEvent with * indicates it is an iterative event.
Individual aOpnScn of above sequence diagram is shown below: <Scn1 StateX S1:(cardinfo(int cardNo),cardreader,sessionMgr) S2:(eject(),sessionMgr,Cardreader)|[!validAtmCard] State Y>
<Scn2 State X S1:(cardinfo(int cardNo),cardreader,sessionMgr) S3:(checkcard(int cardNo,int AccountNo),sessionMgr,aBank) S4:(retain(),sessionMgr,cardReader)|[status Stolen] State Y>
<scn 3 S1:(cardinfo(int cardNo),cardreader,sessionMgr) S3:(checkcard(int cardNo,int AccountNo),sessionMgr,aBank) S5: :(eject(),sessionMgr,Cardreader)|[Status close Account] State Y> <scn4 State X S1:(cardinfo(int cardNo),cardreader,sessionMgr) S3:(checkcard(int cardNo,int AccountNo),sessionMgr,aBank) S6:(requestPIN(int PinNo),sessionMgr,DisplayMgr)|[!validPIN &&try<4] S7:(readPIN(int PinNo),sessionMgr,KeyReader)|[!validPIN &&try<4] S8:(verifyPIN(int PinNO),sessionMgr,ebank)||[!validPIN &&try<4] S9:(eject(),sessionMgr,cardReader)|[!validPIN] State Y>
<scn5 State X S1:(cardinfo(int cardNo),cardreader,sessionMgr) S3:(checkcard(int cardNo,int AccountNo),sessionMgr,aBank) S6:(requestPIN(int PinNo),sessionMgr,DisplayMgr)|[!validPIN &&try<4] S7:(readPIN(int PinNo),sessionMgr,KeyReader)|[!validPIN &&try<4] S8:(verifyPIN(int PinNO),sessionMgr,ebank)||[!validPIN &&try<4] S10:(displayHello(),sessionMgr,displayMgr)
Table 9.1.1 Five operation scenarios represented in the form of quadruples
State Z)
55
Initially GOSD contains only the StartState.We then add each aEvent of all aOpnScn
followed by its corresponding NextState, and remove duplicates, if any. C++ program is
used to Store all the information from UML Sequence diagram to GOSD.
3) Integration Test Case Generation:
A test case, t, is generated using information from the sequence diagram, sd. The test case
t is used to test one of the scenarios that is specified by sd.The set of all inputs generated
from sd is used to test a variety of scenarios specified by sd.In order to produce test Input
GOSD needs to contain information as shown above 1) the order in which messages are
sent 2) how variables are changed when sequence diagram messages are received and
handled 3) what objects and links need to exist for messages to be sent.
In order to generate Test cases for Integration testing c++ program is used that will
traverse the graph using depth-first traversal to enumerate all paths in a GOSD.
Test cases that are generated for ATM PIN Validation component are shown below. Test
cases can be passed or failed by comparing the values that are entered by user and the
values that are traversed from GOSD. TEST ID
OBJECTIVE METHOD NAME
Parameters SENDER RECEIVER Pre-Condition
EXPECTED STATE
Status
Test1
To chekc Card Info
CardInfo
47115 CardReader
SessionMgr s3 TEST PASSED SUCCESSFULLY
Test2
to check card info
CardInfo
47.471
CardReader
SessionMgr S3 TEST FAILED : parameter type mismatch
Test3 to check valid atm card
Eject
SessionMgr
CardReader !ValidAtmCard
Y TEST PASSED SUCCESSFULLY
Test4 to check card validity
Eject CardReader
SessionMgr
!ValidAtmCard
Y Sender/Receiver mismatch
Test5
to verify Pin VerifyPin
48557 SessionMgr
aBank !ValidPin & Try<4
s9 TEST PASSED SUCCESSFULLY
TEST ID
OBJECTIVE METHOD NAME
Parameters SENDER RECEIVER Pre-Condition
EXPECTED STATE
Status
Test6
to Read the pin
ReadPinCode
47778 SessionMgr
KeyReader !ValidPin & Try<4
s8 Test fail method not found
Test7
to read pin ReadPin 4788
SessionMgr
KeyReader !ValidPin & Try<4
s10
TEST FAILED : destination
56
state mismatch Test8
to retain card
Retain SessionMgr
CardReader StatusStolen
y TEST PASSED SUCCESSFULLY
Test9
To retain card Retain SessionMgr
CardReader
!ValidPin Y TEST FAILED : condition nto matched
Test 10
to check logion sucess
DisplayHello
47.655 SessionMgr
DisplayMgr Z TEST FAILED : parameter mismatch
Test 11
To check login success
DispHello hello SessionMgr
DisplayMgr
Z TEST FAILED: METHOD NOT FOUND
Test 12
to request for pin
RequestPin
7444
SessionMgr
keyreader !ValidPin & Try<4
s7
TEST FAILED : Sender/Receiver mismatch
Test 13 To request for pin
RequestPin
74484 SessionMgr
DisplayMgr !ValidPin & Try<4
s7 TEST PASSED SUCCESSFULLY
Test 14 to check login success
DisplayHello
SessionMgr
DisplayMgr Z TEST FAILED : parameter mismatch
Table 9.1.2 Test Run with sequence Diagram of ATM PIN Validation
9.2 Implementation with Ticket selling Component:
In this we have taken part of a ticket selling domain model. In which customer may have
many reservations, but each reservation is made by one customer .Reservations are of
two kinds: subscription series and individual reservation. Both reserve tickets: In one
case, only one ticket; in the other case several tickets. Every ticket is part of a
subscription series or an individual reservation, but not both. Every performance has
many tickets available, each with a unique seat number. A performance can be identified
by a show, date and time.
Class diagram for above specification is shown as:
57
Figure 9.2.1 Class Diagram of Box office application
Above class diagram shows several imp classes such as Customer, Reservation, Ticket
and Performance
After that sequence diagram of ticket selling component is drawn with the help of
StarUml tool.
58
Figure 9.2.2 Sequence Diagram of Ticket selling component
2) Transformation of SD into a GOSD In above sequence Diagram we have three different objects. Kiosk, box office, Credit
card service. Different messages that are passed between objects and their parameters are
shown in Sequence diagram.
Similar to previous component In order to formulate a methodology, we define an
operation scenario as a quadruple, aOpnScn: <ScnId; StartState; MessageSet; NextState>
and
59
MessageSet is denoted by a tuple, aEvent: <messageName; fromObject; toObject
[/guard]>
Individual aOpnScn of above sequence diagram is shown below: <Scn1 StateX S1:(Request(int count,string perform),Kiosk,boxoffice) S2:(showavailability(string seat-list) ,boxoffice,Kiosk)|[!Available] State Y>
<Scn2 State X S1:( Request(int count,string perform) ,Kiosk,boxoffice) S2: :(showavailability(string seat-list) ,boxoffice,Kiosk) S3:(select(int seats),Kiosk,boxoffice) S4:(Demandpayment(int cost),kiosk,boxoffice) S5:(InsertCard(int Cardno) ,kiosk,boxoffice) S6:(charge(int cardno,int cost),boxoffice,Creditcardservice)|[!authorised]
<Scn3 S7:(reject(),boxoffice,Kiosk) StateX State Y> S1:( Request(int count,string perform) ,Kiosk,boxoffice) S2: :(showavailability(string seat-list) ,boxoffice,Kiosk) S3:(select(int seats),Kiosk,boxoffice) S4:(Demandpayment(int cost),kiosk,boxoffice) S5:(InsertCard(int Cardno) ,kiosk,boxoffice) S6:(charge(int cardno,int cost ) ,boxoffice, Creditcardservice) S7:PrintTicket(String Perform,int Seat),boxoffice,kiosk) State Z>
Table9.2.1 Three operation scenarios represented in the form of quadruples
Initially GOSD contains only the StartState.We then add each aEvent of all aOpnScn
followed by its corresponding NextState, and remove duplicates, if any. C++ program is
used to Store all the information from UML Sequence diagram to GOSD.
3) Integration Test Case Generation:
A test case, t, is generated using information from the sequence diagram, sd. The test case
t is used to test one of the scenarios that is specified by sd.The set of all inputs generated
from sd is used to test a variety of scenarios specified by sd.In order to produce test Input
GOSD needs to contain information as shown above 1) the order in which messages are
sent 2) how variables are changed when sequence diagram messages are received and
handled 3) what objects and links need to exist for messages to be sent.
60
In order to generate Test cases For Integration testing c++ program is used that will
traverse the graph using depth-first traversal to enumerate all paths in a GOSD.
Test cases that are generated for Ticket Selling component are shown below.Test cases
can be passed or failed by comparing the values that are entered by user and the values
that are Traversed from GOSD.
Test ID Objective Method Name paramet
ers sender Receiver Pre-
condition
Expected State
Status
Test1 test seats available
ShowAvailability
“LB 53 B4”
BoxOffice Kiosk S3 TEST PASSED SUCCESSFULLY
Test 2 Request to Box Office
Request 3,”26-07-08”,4pm
Kiosk BoxOffice
s2
TEST PASSED SUCCESSFULLY
Test3 check card insertion
InsertCard 456.35 Kiosk BoxOffice S6 TEST FAILED : parameter type mismatch
Test ID Objective Method Name paramete
rs sender Receiver Pre-
condition Expected State
Status
Test4 payment demand
DemandPayment
450 Kiosk BoxOffice
S5 TEST FAILED : Sender/Receiver mismatch
Test5 print the tickets
PrintTicket
“26-07-08”,”4pm”,3
BoxOffice Kiosk
z TEST PASSED SUCCESSFULLY
Test6
check rejection Reject BoxOffice CreditCardService
Y Sender/Receiver mismatch
61
Test7 check rejection
Detect BoxOffice
Kiosk Y TEST FAILED : method not found
Test8 charge money
Charge 6544 300 BoxOffice
CreditCardService
Authorized
S7 TEST PASSED SUCCESSFULLY
Test 9 Insert card insertcard 4567 boxoffice kiosk S6 TEST FAILED
:
Sender/Receive
r mismatch
Test 10 Select seats select 7 kiosk boxoffice S4 TEST
FAILED:
CAN SELECT
MAXIMUM 6
TICKETS
Table 9.2.2 Test Run with sequence Diagram of Ticket Selling
9.3 Implementation with Registration System Component:
Step by Step Implementation of Registration System Component is as follows:
In this we have taken a part of Automated Registration System. A student registers for a
class through a web Interface. If student is having logged in then he can directly go for
registration procedure but if Student is not already logged in then he has to perform user
login procedure. And new student ID is generated. After registration, registered
information is given back to student.
Sequence diagram associated with Automated Registration system is drawn
with StarUml tool. Different Objects and Actors associated with this specification are
shown in sequence diagram. In Figure 9.3.1 we have shown Browser, Web Server and
DB different objects and student as an actor. Web server further consists of web server,
Registration, aStudent, aCourse. Different messages that are passed between different
62
objects of sequence diagrams are shown in diagram. Also parameters that are passed are
shown.
Sequence diagram also represent the Sequence in which messages are
transformed. Sequence diagrams are Interaction diagrams that are used to test class
interactions. Typically the complexity of component based system lies in its object
interactions, not within class methods which tend to be small and simple. As a result
complex behaviors are observed when related classes are integrated and several kinds of
faults can arise during integration: interface faults, conflicting functions, missing
functions. Thus testing each class independently does not eliminate the need for
integration testing. A large number of possible interactions between collaborating classes
may need to be tested to ensure the correct functionality of system.
Sequence Diagram for above Specification is shown on next page.
63
Figure 9.3.1: Sequence diagram of Automated Registration System
64
2) Transformation of SD into a GOSD Similar to previous component In order to formulate a methodology, we define an
operation scenario as a quadruple, aOpnScn: <ScnId; StartState; MessageSet; NextState>
and MessageSet is denoted by a tuple, aEvent: <messageName; fromObject; toObject
[/guard]>
Individual aOpnScn of above sequence diagram is shown below:
<scn1 State X S1:(BrowseHome(String URL),Student,Browser) S2:(RequestHome(string URL),Browser, webserver) S3:(Response(string URL),webserver, Browser) S4:(select Registerationpage(string URL) ,student,Browser) S5:(RequestRegisterationpage(string URL) ,Browser,webserver) S6:(Userlogin(String ID,String Pass) ,Student,DB)|[!logged in) State Y>
<scn2 State X S1:(BrowseHome(String URL),Student,Browser) S2:(RequestHome(string URL),Browser, webserver) S3:(Response(string URL),webserver, Browser) S4:(select Registerationpage(string URL) ,student,Browser) S5:(RequestRegisterationpage(string URL) ,Browser,webserver) S6:(newpage(),webserver,Registerationpage) S7:(Prepare(),webserver,Registerationpage) S8:(Intialize(),webserver,Registerationpage) S9:(new(int studentID), Registerationpage,astudent) S10:(GetRegisterationInfo(),Registerationpage,astudent) S11:(GetstudentRegisteration(int studentID),astudent,DB) S12:(return(string data),DB,aStudent) S13:(return(string registerationdata) ,astudent,registerationpage) S14:(response(String data),registerationpage,Browser) State z>
Table 9.3.1 Two operation scenarios represented in the form of quadruples
3) Integration Test Case Generation:
A test case, t, is generated using information from the sequence diagram, sd. The test case
t is used to test one of the scenarios that is specified by sd.The set of all inputs generated
from sd is used to test a variety of scenarios specified by sd.In order to produce test Input
GOSD needs to contain information as shown above 1) the order in which messages are
sent 2) how variables are changed when sequence diagram messages are received and
handled 3) what objects and links need to exist for messages to be sent.
65
In order to generate Test cases For Integration testing c++ program is used that will
traverse the graph using depth-first traversal to enumerate all paths in a GOSD.
Test cases that are generated for Automated Registration component are shown below.
Test cases can be passed or failed by comparing the values that are entered by user and
the values that are traversed from GOSD. Test ID
Objective Method Name
parameters sender Receiver Pre-condition
Expected State
Status
Test1
to browse home page
BrowseHo
me
www.home.com
Student Browser
S2 TEST PASSED SUCCESSFULLY
Test2 To request
home Page
RequestHo
mePage
www.home.com
Browser
WebServer s3 TEST PASSED
SUCCESSFULLY
Test3 to request home page
Requestpag
e
www.home.com Browser
WebServer S3 method not found
Test4 Initialize page
Initialize WebServer RegPage S9 TEST PASSED SUCCESSFULLY
Test5
to register student
GetStudent
Register
103 aStudent DB S12 method not found
Test6
to register student
GetStudentRegisteration
346 aStudent DB S12 TEST PASSED SUCCESSFULLY
Test7
to open new page
NewPage
RegPage
WebServer
S7 TEST FAILED : Sender/Receiver mismatch
Test8 Browse home page
BrowseHome
1447 Student Browser S2 TEST FAILED : parameter type mismatch
Test 9 Extract data
return Rich,M.Tech,340,70%.
DB aStudent S13 TEST PASSED SUCCESSFULLY
Test ID Objective Method
Name parameters sender Receiver Pre-
condition
Expected State
Status
Test10 Response
from server
Response www.regiter.co
m
WebServer
astudent S4 TEST FAILED
: destination
state mismatch
Test11 Get
Response
Response www.regiter.co
m WebServer
Browser S2 TEST PASSED
SUCCESSFUL
66
LY
Test12 get
registration
info
Getregist
erationin
fo
astudent
RegPage
S11 TEST FAILED
:
Sender/Receive
r mismatch
Test 13 To check
user login
userlogin Rich,pass astudent DB !logge
d in
Y TEST PASSED
SUCCESSFUL
LY Test 14 New
student
NewStuden
t
4558 Registratio
n page
DB S10 TEST
FAILED :
destination
state mismatch
Test15 New
student
NewStuden
t
4558 Registratio
n page
aStudent S10 TEST PASSED
SUCCESSFUL
LY
Test16 Select page selectregist
erationpage
www.register.c
om
student Registration
page
S5 TEST FAILED
: destination
state mismatch
Table 9.3.2 Test Run with sequence Diagram of Registration system
67
Chapter 10 Conclusions and Future Work
This chapter first starts with evaluation of the Implementation and the chapter ends with
the directions for future work.
10.1 Evaluation of Experiment:
a) Evaluation of ATM PIN validation Component:
We can check the running time of the ATM PIN validation component for producing the
final regression test suite. This can be checked with the help of the bar chart.
Component ATM PIN validation
Total Passed Test Failed Test 14 5 9
14
5
9
0
24
6
8
1012
14
16
Series1 14 5 9
Total Passed Test Failed Test
Execution time: 0.0031
Figure 10.1.1 Bar chart of total number of test cases and execution time for ATM
component
The bar chart shows the total number of the test cases and the shows how many test cases are passed and failed.
b) Evaluation of the Ticket-Selling component We can check the running time of the Ticket-Selling component for producing the final
regression test suite. This can be check with the help of the bar chart.
Component: Ticket-Selling
Total Passed Test Failed Test 10 5 5
68
10
5 5
0
5
10
15
Series1 10 5 5
Total Passed Test Failed Test
Execution Time: 0.0030
Figure 10.1.2 Bar chart of total number of test cases and execution time for Ticket Selling
component
c) Evaluation of the Student Registeration component
We can check the running time of the Ticket-Selling component for producing the final
regression test suite. This can be check with the help of the bar chart.
Component: Student Registeration component
Total Passed Test Failed Test 10 5 5
16
79
0
5
10
15
20
Series1 16 7 9
Total Passed Test Failed Test
Execution Time:0.0032
Figure 10.1.3 Bar chart of total number of test cases and execution time for Registration
component
10.2 Summary of the contribution
69
In this paper, we have presented a new strategy for integration testing that is based on a
storing test information from Sequence diagrams into the form of a graph. The motivation
is to exercise interactions between different components. Therefore, it takes into account
the states of all objects involved in a sequence diagram to exercise class interactions in
the context of integration testing. UML, a Modeling language used as a tool for capturing
component relationships. It provides the whole structure of a system with the help of
different diagrams The information those are required for the specification of
input,output,pre and post conditions etc. of a test case are retrieved from class diagram
and Sequence diagram. Diagrams are drawn with the help of StarUML tool. After that
graph is traversed and all information is used to generate integration test cases. Thesis
describes three Implementations of different software components .The results shows
efficiency and less time to generate test cases as compared to manual approach.
Future Work
Since Integration testing is the most time consuming and expensive part of testing.
Commercially available software components are generally packaged without source
code and this may cause difficulties in component integration testing. So far we are able
to automatic generate test cases from UML sequence diagrams. In a next step the
efficiency can be increased by optimizing the number of test cases.
As another activity, the case study presented in this paper, though far from
simple, may not be representative of an industrial system. Therefore Industrial case
studies are required to carefully analyze. So we can further add functionality to our
approach by converting diagrams to XML format.
.
70