Professional Documents
Culture Documents
Niclone 2010
2
A. MODELLING EVENTS like ‘and’, ‘or’, ‘xor’, and in terms of join and split operators.
These relationships among events are described as event-flow
Event-flow model is the basis of event-based generation of interdependency. Event Flow interdependency is captured
test scenarios. The basis of Event-Flow model has come from from the Causative events and Trigger vector section of
the ent-based OOA work described in [11, 12]. In the above Event
work, Elementary events are extracted and documented in an Templates. Thus, these two are used for modeling event
Event Templates. The important components of an Event interactions using event operators. Different possible event
Template are Event ID, Event name, Event description, interactions using event operators are described in Fig 1.
Initiator, Facilitator, Affecter, Causative events, Trigger
Vector, Change-event, Timestamp, Inputs/Outputs and Count (a)Causative events based event interactions: Causative
[12]. events can be a single event or a set of events related using
Event-join operators. We have defined three types of Event
Event ID: It is a unique alphanumeric value given to each join operators: (i) event-and join (i.e. join) (ii) event-or join
event identified either directly or indirectly from the (iii) event-xor join. Event following event-and join, starts its
requirements. Event Name: It is a simple name as extracted execution when all the causative events are executed (Fig
from the requirements given in the natural language. Event 1(f)). So, it the most complex event interaction. Event
Description: It is a sentence from the requirements that following event-or join, starts its execution when any one or
describes the event identified in Subject-Verb-Object (SVO) more causative events are executed (Fig 1(g)). Event
pattern. . (e.g. customer places an order) Initiator, following event-xor join, starts its execution when exactly
Facilitator or Affecter: Initiator starts an event. Facilitator one causative event is executed (Fig 1(h))
facilitates in the occurrence of an event and Affecter gets (b)Trigger Vector events based event interactions: An event
affected as a result of execution of an event. Causative can trigger either a single event or a set of events that can be
Events: Causative events of an event are those events that executed independently or in parallel. Single event triggered
are reasons behind occurrence of that event. Trigger Vector: can also be a non-event event. Non-event event is triggered
It represents a set of events that are triggered as a result of through Event-not operator (Fig 1(b)). It indicates
occurrence of an event. For example ‘Customer register concoccurrence (negation) of an event as described in [13].
with TA software’, triggers an event ‘Travel agency The manner in which events in Trigger vector are executed is
provides user id and password to Customer’. An event can determined on basis of event-split operators. We have
trigger either a single event, set of events that can be defined
executed independently or in parallel. Change-event (state three types of event-split operators: (i) event-or split (ii)
changes): Every event triggered may initiate algorithmically event- and- split (iii) event-xor split. Event-and split indicate
simple or complex methods in an object which model the that all events have to be triggered in parallel (Fig 1(e)). So,
behavioral changes in the object. These changes are it the most complex event interaction. Event-or split indicate
described in Event Template as Change-event. Timestamp: that either none, one or more than one events can be
Events occur at some point of time. Timestamp records time triggered (Fig 1(d)). Event-xor split indicates any one event
when a particular event has happened or likely to happen in can be triggered (Fig 1(c)). AND-split activities are
the system. Inputs/Outputs: Inputs reflect the data needed represented with a ‘fork’, OR split with an ‘or’, and XOR-
for change event whereas output is the data produced from split activities with a ‘xor’ in our event-flow model.
the change event. Input / Output can contribute to describe
attributes for an object. B. Event Flow Graph as Event-Flow Model
Unlike the above work, this paper uses Event Templates for
Event-flow model represents events and event interactions.
MBT. Causative events and Trigger Vector components of
In much the same way as a control-flow model represents all
Event Templates are used for generating Event-flow model
possible execution paths in a program [14], and a data-flow
from which test scenarios are generated. An event happens in
model represents all possible definitions and uses of a
a system due to occurrence of some events called Causative
memory location [15], the event-flow model represents all
events. Once an event has occurred in a system, it can trigger
possible sequences of events that can be executed in a
the execution of some other events. Such events constitute
system. The event flow model contains two parts. The first
the
part refers to events that are causes in terms of causative
Trigger Vector of an event. Specific order in which events
events, and the second part refers to effects, i.e. the events
are
that are triggered after an event has been executed. Both of
executed in a system constitutes an event-flow. Event-flow
these parts play an important role constructing Event-flow
model represents events and event interactions. Event-flow
Model.
model represents all possible sequences of events that can be
executed in a system. The event-flow is the basis for model
Our major objective is to generate test scenarios based on
based testing. The next sub-section describes the possibilities
events and their interdependencies. In any system, especially
of modeling event flow using event operators.
in Web based systems, there is plethora of events happening
in background, so event interdependency of all the events
B. MODELING EVENT INTERACTIONS USING EVENT
happening in the system is represented collectively using
OPERATORS
Event-flow Model. Our Event-Flow Model is represented as
Two or more events are related with each other using event
Event-flow Graph. Event-flow graph represents events, their
operators. Event operators are expressed as Boolean
interaction in terms of causative events and trigger vector. It
operators
3
has one event designated as start event and another new event appears on the path, that path is not considered.
designated as exit event. Start event indicates the This process is continued to generate many test scenarios.
initialization of the system i.e. once a system is turned on all We have used deep breath first technique to automate
other events can get executed. Exit event indicates the traversal. The order in which the events are covered will
completion of functionality. In Event-flow graph, events are yield different types of test scenarios. Every Event sequence
represented using circles, and dependencies between retrieved is defined as follows:
activities Event sequence: A test sequence, denoted by t, is a finite
are represented using arrows. Formally, Event-flow Graph is sequence of events,
defined as: < Se, μ1, μ2, . . . μn, Ee>
where μi, μi+1 Є E, 1<i<=n (n is the total number of events
An EFG is a 3-tuple <E, T, C> where in the system) and Se and Ee indicate the start and exit event
• E is a nonempty finite set of vertices representing all the as
events in a system with two events designated as Start (S) described in event flow graph. With our proposed event-flow
and Exit (E) to indicate the system startup and exit events. model, numerous graph-traversal techniques can be used to
• T is a nonempty finite set of transitions. T Í E * E . We say automate it. The order in which the events are covered will
that event ei causes event ej iff ei is a causative event of ej. yield different types of test scenarios. After applying deep
Similarly event ei triggers event ej iff event ei is triggers breath first traversal on [10], some of the identified paths are
event of ej. An edge (vx,vy) Є E if the events vx and vy are shown below:
interdependent either due to causes or triggers relationship.
•C is a finite set of vertices representing connector nodes
{OR , XOR, FORK, JOIN, NOT} IV. CONCLUSION
Not surprisingly, there are no software testing technique
A connector node with more than one outgoing transition today that fit all intents and purposes. Consequently, for each
can be classified as an Event-AND split (fork), Event-OR situation decisions need to be made as to what techniques are
split, Event-XOR split. A connector node with more than one most suitable. There are some guidelines to be considered
incoming transitions can be classified as an AND-join (or that are derived from earlier experiences. The choice of a
simply join), OR-join, or XOR-join. Only OR and XOR- system also depends on aspects of the system under test and
splits skills of user. However, there is little or no data published
and joins introduce non-determinism. On the other hand, that conclusively suggests that one technique outstands others
AND splits and joins are deterministic. when more than one technique intuitively appropriate.
The construction of the event-flow graphs is based on the
identification of causative events and trigger vector of all
event templates and, hence, the identification of causes and
triggers relationships among events is essential. A set of
causes and triggers for each event is analyzed. These sets are
then used to create the edges of the event-flow graph. Event-
flow graph of Case study is shown in Fig 2.
REFERENCES
[1] ABDURAZIK, AYNUR. AND OFFUTT, JEFF. USING UML COLLABORATION
DIAGRAMS FOR STATIC CHECKING AND TEST GENERATION, IN PROCEEDINGS OF THE
3RD INTERNATIONAL CONFERENCE ON UNIFIED MODELING LANGUAGE, UK, 383-
395, OCTOBER 2000.
[2] HONG, HYOUNG SEOK., KIM, YOUNG GON., CHA, SUNG DEOK., BAE,
DOOHWAN., AND URAL, HASAN. A TEST SEQUENCE SELECTION METHOD FOR
STATECHARTS, THE JOURNAL OF SOFTWARE TESTING, VERIFICATION AND
RELIABILITY, 10(4):203–227, DECEMBER 2000. 227, DECEMBER 2000.
[3] SKELTON, G., STEENKAMP, A., AND BURGE, C. UTILIZING UML DIAGRAMS FOR
INTEGRATION TESTING OF OBJECT-ORIENTED SOFTWARE. SOFTWARE QUALITY
PROFESSIONAL, JUNE 2000.
[4] GRONAU ,ILAN. , HARTMAN,ALAN. , KIRSHIN, ANDREI., NAGIN, KENNETH., AND
OLVOVSKY ,SERGEY. A METHODOLOGY AND ARCHITECTURE FOR AUTOMATED
SOFTWARE TESTING. HAIFA TECHNICAL REPORT, IBM RESEARCH
LABORATORY,MATAM ADVANCED TECHNOLOGY CENTER, HAIFA 31905, ISRAEL,
2000
[5] ROSARIA, S. AND ROBINSON, H. APPLYING MODELS IN YOUR TESTING PROCESS,
INFORMATION AND SOFTWARE TECHNOLOGY, 42(12):815–824, DECEMBER 2000.
[6] LINZHANG, WANG., JIESONG, YUAN., XIAOFENG ,YU., JUN , HU., XUANDONG, LI.
AND GUOLIANG, ZHENG. GENERATING TEST CASES FROM UML ACTIVITY
DIAGRAM BASED ON GRAY-BOX METHOD. IN PROCEEDINGS OF THE 11TH ASIA-
PACIFIC SOFTWARE ENGINEERING CONFERENCE (APSEC), IEEE COMPUTER
SOCIETY, 2004
[7] SAMUEL, PHILIP. AND MALL, RAJIB. A NOVEL TEST CASE DESIGN
TECHNIQUEUSING DYNAMIC SLICING OF UML SEQUENCE DIAGRAMS. E-
INFORMATICA SOFTWARE ENGINEERING JOURNAL, VOLUME 2, ISSUE 1, 2008.
[8] KIM, Y.G., HONG, H.S., CHO, S.M., BAE, D.H. AND CHA, S.D. TEST CASES
GENERATION FROM UML STATE DIAGRAM. IEE PROCEEDINGS –SOFTWARE, VOL.
146, NO. 4, PP. 187-92, AUG. 1999.
[9] SAMUEL, P., MALL, R. AND BOTHRA, A.K. AUTOMATIC TEST CASE GENERATION
USING UNIFIED MODELLING LANGUAGE(UML) STATE DIAGRAMS. IET SOFTW.,VOL.
2, NO. 2, PP. 79–93, 2008.
[10] WWW.TYROASIA.COM. AN ONLINE ASSIGNMENT WEBSITE.
[11] SINGH, K.,SANDEEP, SABHARWAL, SANGEETA, AND GUPTA, J.P. EVENT PATTERNS
FOR OBJECT ORIENTED REQUIREMENT ANALYSIS. IN PROCEEDINGS OF IASTED
INTERNATIONAL CONFERENCES ON ADVANCES IN COMPUTER SCIENCE AND
TECHNOLOGY, APRIL 2 - 4 , 2008, PAGE 115-120.
[12] SINGH, K.,SANDEEP, SABHARWAL, SANGEETA, AND GUPTA, J.P.,"EVENTS-AN
ALTERNATIVE TO USE CASE AS STARTING POINT IN OBJECT-ORIENTED ANALYSIS",
ICETET 2009: 1004-1010..
[13] WARD, PAUL T. AND MELLOR, STEPHEN J. STRUCTURED DEVELOPMENT FOR REAL-
TIME SYSTEMS: VOLUME 2, ESSENTIAL MODELING TECHNIQUES. PRENTICE-HALL
(YOURDON PRESS). ISBN 0138547874.(ISBN 978-0138547875) 2009 .
[14] ALLEN, FE. CONTROL FLOW ANALYSIS. PROCEEDINGS OF A SYMPOSIUM ON
COMPILER OPTIMIZATION. ACM PRESS: NEW YORK, 1970; 1–19.
[15] ROSEN, B.K. DATA FLOW ANALYSIS FOR PROCEDURAL LANGUAGES. JOURNAL OF THE
ACM 1979; 26(2):322–344.
[16] R. HELM, I. M. HOLLAND, AND D.GANGOPADHYAY. CONTRACTS: SPECIFYING
BEHAVIORAL COMPOSITIONS IN OBJECT-ORIENTED SYSTEMS. IN PROCEEDINGS OF THE
5TH ANNUAL CONFERENCE ON OBJECT-ORIENTED PROGRAMMING SYSTEMS,
LANGUAGES, AND APPLICATIONS (OOPSLA ’ 90), ACM SIGPLAN NOTICES,
25(10):169–180, 1990.