Test case design techniques

State Chart

Prepared by:
Introduction:
Software testing plays a major role in software development because it accounts for
a large part of the development cost. Moreover, manual testing technique always
makes a problem. Consequently, this paper proposes the automatic testing technique
to solve partially the testing process. This technique can automatically generate and
select test cases from UML state chart diagrams. Firstly, we transform this diagram
into intermediate diagram, called Testing Flow Graph (TFG), explicitly identify flows of
UML state chart diagrams and enhance for testing. Secondly, from TFG we generate
test case using the testing criteria that is the coverage of the state and transition of
diagrams. Finally, the evaluation is performed using mutation analysis to assess the
fault revealing power of our test cases.

1. INTRODUCTION

Specification-based testing uses information derived from a specification to assist

testing as well as to develop program. Testing activities consist of designing test
cases that are a sequence of inputs, executing the program with test cases, and
examining the results produced by this execution. Testing can be created earlier in
the development process so the developer will often find inconsistency and
ambiguity in the specification and so the specification can be improved before the
program is written.
The Unified Modeling Language (UML) [Booch, Rumbaugh and Jacobson 1998] is a
visual modeling language that comprises nine types of graphics, called diagrams.
Nowadays, there are many studies that are focused on test cases generation from
UML specification can be found in [Basanieri el al. 2001; Hartmann el al. 2000; Briand
el al. 2001; Basanieri el al. 2002; Offutt and Abdurazik 2000]. This paper presents a
test case that is automatically generated from the specification based on UML
statechart diagrams. UML statechart diagrams are widely used to represent the
dynamic behavior of entities by specifying its response to the receipt of event
instances. Our approach is also similar to some recent works [Offutt and Abdurazik
1999 and Kim el al. 1999].
Offutt and Abdurazik presented:

An approach that generates test cases from UML statechart diagrams without
transformation. However, their approach only focuses on enabled transitions and
change events. Kim el al. proposed:

The method transforms state diagrams into extended finite state machines (EFSMs).
Then data flow is identified by transforming EFSMs into flow graphs to which
convention data flow analysis techniques can be applied. Their paper discusses a
method for the generation of test cases only and thus an automated environment
would be needed to support the total process.

We automatically generate test cases from UML specification with the aid of the
Rational Software Corporation’s Rational Rose tool. The first step, we create state
chart diagrams from this tool and use it to transform into intermediate diagrams,
called Testing Flow Graph (TFG). It reduces the complexity of UML state chart
diagrams. The TFG is a clearly flow and simple structure diagram. Then, the TFG is
used to generate test sequences by parsing to coverage the state and transition.

This paper is organized as follows. Section 2, we couch about UML statechart

diagrams. Section 3 describes our testing technique using UML statechart diagrams
based on TFG. Then, section 4 we present mutation testing for evaluation our test
cases. Finally, conclusion and future directions are discussed in section 5.

2. UML STATECHART DIAGRAMS

Statechart diagrams in UML are used to model the dynamic aspects of a system. A
statechart diagram consists of states, transitions, events and actions [Booch,
Rumbaugh and Jacobson 1998] and it shows a state machine emphasizing the flow of
control from state to state. State charts are finite state machines extended with
hierarchy and orthogonality. This paper interests only in hierarchy. In statecharts ,
the basic elements are rounded rectangles representing the states and labeled
arrows indicating the
transitions. The syntax for transition is:

Event [guard condition] / action

Where an event is a message that is sent. A guard condition is a Boolean expression

of attribute values that allows a state transition only if the condition is true. An action
is the behavior that occurs when the state transition occurs. Figure 1 shows details of
state.

The internal activity section has standard events named as follows; entry, exit and
do. We perform internal activities as in Figure 2 before transforming into
intermediate diagram (TFG). Any states in the statechart can either be simple states
or composite states which themselves contain other statecharts. Figure 3 shows a
Statechart for stack.
Simple states mean empty, not full and full state. Composite states mean not empty
state that contains not full and full state. The initial state in a statechart is marked by
•

3. GENERATING TEST CASES BASED ON TFG

3.1 Construction algorithm of a TFG

This technique firstly transforms behaviors of system from UML statechart diagrams
to Testing Flow Graph (TFG) which is the flatten hierarchy structure of state before
being able to generate test cases. Figure 4 shows the TFG which is a graph consists
of transitions and nodes. Two kinds of node are s-node which is drawn by fulfill circle
and g-node which is drawn by space circle. Two kinds of transition starting from s-
node and g-node are called s-transition and g-transition, respectively.

This algorithm will consider each state by starting from initial state of statecharts
that is a root node of TFG.Each state in statechart is considered as following steps :

1. The state in statechart is replaced by s-node and departing transitions of this state
are grouped by events. Each group of events represents s-transition labeled by the
event name. In Figure 5, for example, the state A is a s-node named A. Departing
transitions of state A are considered to group the event so it has two transitions
labeled e1 and e2 as illustrated in Figure 6.
2. G-nodes are created in the end of s-transitions from previous step. Each g-node is
source node of transitions labeled by guard condition to target nodes. This transition
is called g-transition. The target node can be a s - node for other states. Example
from Figure 5, we add two g-nodes A1 and A2 for s-transitions e1 and e2,
respectively. Two guard conditions g1 and g2 of event e1 represent g-transitions
from A1 and the g3 guard condition of event e2 represents g-transition from A2.
Figure 6 shows a TFG of Figure 5.

To cover every testing from composite states, we transform state B into TFG by
giving transitions from any
states of composite states that contain S and T state. This can be illustrated in Figure
7.

Example in Figure 8, for each state of composite states as shown in Figure 7 is g-

nodes, S and T. The g-node has s-transitions labeled the same event that is named e.
G-node, named ST, is added for being center of transitions and for starting of g-
transition

3.2 Test cases generation

The TFG is explored by parsing the branches from root node to each leaf node to
coverage the node and the transition at least once. In this section the TFG for stack,
as shown in Figure 9 that is transformed from a Statechart in Figure 3, is used for
example to consider test case generation. We generate events that are not in all s-
transitions for exercise s-node and generate some events for exercise s-transitions
that the target node is s-node.
For example the push(num) event is generated for s-transition between EM and NF.
The not push(num) event is generated for exercise EM s-node that is next from INT.
The NF s-node which has departing push(num) and pop() transitions generates the
not push(num) and not pop() event for exercise itself.

In case that g-node appears between s-node, the test case is defined as the
sequence of events and predicates. The predicates on every g-transition from a g-
node are combined in the conjunctive form. Every predicates in this form is
generated to be false value for exercise g-node. Each g-transition is exercised by
generating all predicates in the conjunctive form started from false value and vary
each one to be true value in turn. In this specific example, there are two predicates
from a NF1 g-node. The sequence, push(num);;top≠max-2 and top≥max-2, is used to
exercise this g-node. The top=max-2 and top<max-2 transitions from NF1 are
exercised by the sequence, push(num);;top=max-2 and push(num);;top<max-2,
respectively. The test sequences generated by above algorithm for stack are listed in
Figure 10.

Test Sequence #1
not push(num)
push(num)
not push(num) and not pop()
push(num);; top≠max-2 and top≥ max-2
push(num);; top=max-2
 not pop()
pop()
Test Sequence #2
Push(num)
pop();; top≤ 1 and top≠1
pop();; top> 1
Test Sequence #3
push(num)
push(num);; top< max-2
Test Sequence #4
push(num)
pop();; top=1

4. MUTATION TESTING
We have evaluated the effectiveness of our test cases using fault injection technique
called mutation analysis [Demillo, Lipton and Sayward 1978]. Mutation analysis is a
fault-based testing strategy that starts with a program to be tested and makes
numerous small syntactic changes into the original program (or the specification).
Program (or specification) with injected faults are called mutants. If a test case set is
capable of causing behavioral differences between original program (specification)
and mutant, mutant is considered as killed by the test. The product of the mutation
analysis is a measure called mutation score, which indicates the percentage of
mutants killed by a test set. If the mutation score is 100% or near, it indicates the
adequacy of the test cases. Mutants are obtained by applying mutation operators
that introduce the simple changes into the original program (or specification). For
example , it is changed arithmetic operator from plus to minus. We have created a
set of mutation operators in our technique for UML statechart diagrams that are
shown in Table 1.

For example the UML statechart diagrams of Figure 3, we create 26 mutants that use
mutation operator in Table
1. The summary of these mutants are shown in Table 2. The results obtained by
executing the mutants are Compared to the results obtained by executing the
original program. The 25 mutants are killed by using the test sequences in Figure 10.
The results indicate the adequacy of our test cases.
5. CONCLUSION AND FUTURE DIRECTIONS

We have proposed a transformation method from UML statechart diagrams into

intermediate diagrams that used to generate test sequences. The test cases are
generated automatically from UML statechart diagrams created by the Rational Rose
tool. The testing criterion is used to guide the generation of test cases that is the
coverage of the state and transition of TFG. Our test cases are measured the
effectiveness on the basis of their fault detection abilities. Results of simple test
experiments are high effectiveness of the generated test cases. However, extensive
experiments are needed to have more confidence of the testing technique and to
compare it with other techniques in term of cost and effectiveness.

In the future, more works need to be done in order to make this approach to be the
really useful technique by modeling concurrent states. Moreover, we plan to include
other diagrams of UML to generate test cases.

REFERENCES

BOOCH, G., RUMBAUGH, J., AND JACOBSON, I. 1998. The Unified Modeling Language
User Guide. Object Technology Series. Addison
Weysley Longman, Inc.
BASANIERI, F., BERTOLINO, A.,MARCHETTI, E., RIBOLINI, A., LOMBARDI, G., AND
NUCERA, G. 2001. An Automated Test Strategy Based on
UML Diagrams. In Proceeding of the Ericsson Rational User Conference, October 10-
11, 2001, Upplands Vasby Sweden.
HARTMANN, J., IMOBERDOF, C., AND MEISENGER,M. 2000. UML-Based Integration
Testing. In ISSTA 2000, Portland, August 2000.
BRIAND, L., AND LABICHE, Y. 2001. A UML-Based Approach to System Testing. In
Proceeding of the 4th International Conference on the
Unified Modeling Language (UML), Toronto (Ontario, Canada), pp. 194-208, October
1-5, 2001.
BASANIERI, F., BERTOLINO, A., AND MARCHETTI, E. 2002. The Cow_Suite Approach to
Planning and Deriving test Suites in UML Projects.
In Proceeding of the. 5th International Conference on the Unified Modeling Language
- the Language and its applications UML 2002,
LNCS 2460, Dresden, Germany, September 30 - October 4, 2002, p. 383-397.
OFFUTT, J., AND ABDURAZIK, A. 2000. Using UML collaboration Diagrams for Static
Checking and Test Generation. In UML 2000,
University of York, UK, 2-6 October 2000.
OFFUTT, J., AND ABDURAZIK, A. 1999. Generating test cases from UML specifications.
In Proceeding of the 2nd International Conference
on the Unified Modeling Language (UML99) , Fort Collins, CO, October, 1999.
KIM, Y.G., HONG, H.S., CHO, S.M., BAE, D.H., AND CHA, S.D. 1999. Test cases
generation from UML state diagrams. In IEEE Software,
146(4): 187–192, 1999.
DEMILLO, R.A., LIPTON, R.J., AND SAYWARD, R.G. 1978. Hints on test data selection:
Help for the Practitioner Programmer. In IEEE
Computer, 34-43, 1978.