Chinese Journal of Electronics

Vol.25, No.2, Mar. 2016

A Test Case Generation Approach Based on

Sequence Diagram and Automata Models∗
ZHANG Chen1,2 , DUAN Zhenhua1,2 , YU Bin2 , TIAN Cong1,2 and DING Ming3,4
(1. Institute of Computing Theory and Technology, Xidian University, Xi’an 710071, China)
(2. School of Computer Science and Technology, Xidian University, Xi’an 710071, China)
(3. School of Information and Technology, Northwest University, Xi’an 710127, China)
(4. Xi’an Aeronautics Computing Technique Research Institute, AVIC, Xi’an 710119, China)

Abstract — To improve the test automation in software
development process, following the researches on test cases
generation technology from models, an incremental test
case generation approach is proposed based on finite au-
tomata, and Event deterministic finite automata (ETDFA)
are employed to describe the sequence diagram models
of system interaction. By model checked with Proposi-
tional projection temporal logic (PPTL), the correctness
of ETDFA is verified. Then we can get the composed au-
tomata by synthesis rules, and generate the test cases in-
crementally by test cases generation algorithm. Case stud-
ies are presented to show that this approach enables to
improve test cases correctness, and reduce the complexity
of test cases generation process.
Key words — Test model, Model based testing, Test
scenario, Test cases.
I. Introduction
Software testing plays a crucial role in assuring soft-
ware quality. As the complexity and size of software grow,
the time and effort required to do effective testing in-
crease. Unified modeling language (UML) is a standard
for object-oriented modeling that has gain widespread use
in the software industry. Using UML, developers model
large, complex systems and produce variety of different
diagrams presenting different views of the system model.
With the increasing use of the UML to model object-
oriented software, researchers have begun investigating
how the UML can be used in the testing phase of the
software development process.
In software testing process, test case selection deter-
mines the validity of the testing, and the selection proce-
dure is the difficulty and key point in testing. Y.G. Kim
∗ Manuscript Received Apr. 23, 2014; Accepted Oct. 10, 2014. This work is supported by the National Natural Science Foundation
et al. discussed the application of state diagrams in UML
to class testing[1] . A set of coverage criteria is proposed
based on control and data flow in UML state diagrams
and it is shown how to generate test cases satisfying these
criteria from UML state diagrams. This method is not
suitable for integration and system testing. H. Miao et al.
presented an approach to generating test cases from UML
statecharts[2]. First, the statecharts were transformed into
Flattened regular expression (FREE) model diagrams.
Afterwards, test cases of class were generated based on
FREE model. Finally, it gives the coverage criteria of
FREE model and an algorithm that generates transition
sequence from a FREE model. M. Sarma et al. proposed
a technique for generating test cases from UML design
diagrams[3]. This approach consists of transforming a se-
quence diagram into a graph called the Sequence diagram
graph (SDG) and augmenting the SDG nodes with differ-
ent information necessary to compose test vectors. The
SDG is then traversed to generate test cases. The test
cases thus generated are suitable for system testing and
to detect interaction and scenario faults. S.K. Swain et al.
presented a comprehensive test case generation technique
from UML models[4] . Test cases are derived from analysis
artifacts such as use cases, their corresponding sequence
diagrams and constraints specified across all these arti-
facts. This test case generation technique can be used for
integration and system testing accommodating the ob-
ject message and condition information associated with
the use case scenarios. Sequence and collaboration dia-
grams are used to describe the interaction between ob-
jects. Sequence diagrams focus on the message sequence,

of China (No.61420106004, No.61322202, No.61303031, No.61272117, No.61202177, No.61133001, No.61172147) and the Fundamental
Research Funds for the Central Universities (No.K5051303005).
c 2016 Chinese Institute of Electronics. DOI:10.1049/cje.2016.03.007
 A Test Case Generation Approach Based on Sequence Diagram and Automata Models
while collaboration diagrams emphasize the space. There-
fore, the generated test cases based on sequence diagrams
are more suitable for detecting system interaction faults,
operational and scenario faults. However, there may be
some faults in sequence diagrams, such as the correct ob-
jects cannot be created and messages are passed between
the unrelated senders and receivers. C. Zhang et al. in-
troduced a method based on UML2.0 sequence diagrams
with use case description, and ETDFA are employed to
describe system interaction[5] . By the model checked with
PPTL, the correctness of ETDFA is verified[6,7] . The
achieved accurate ETDFA models and use case descrip-
tion are regarded as the origin of test cases. However,
due to a large number of states and the complex migra-
tion paths, this approach brings on a certain complexity
for generating test cases and reduces the efficiency of test
cases generation. A. Nayak et al. proposed an approach to
identify all scenarios from activity diagrams and use them
to test use cases[8] . The proposed approach is based on the
classification of control constructs followed by a transfor-
mation approach which takes into account any combina-
tion of nested structures and transforms an activity di-
agram into a model called intermediate testable model.
It simplifies the structure of activity diagrams and real-
izes test cases generation for control flow constructs and
their nested combinations. In this paper, we have pro-
posed a novel technique, which generates the test cases
from the UML use case model, sequence diagram and au-
tomata.This method is able to handle complex system in-
teraction, while simplifying the test cases generation pro-
cess and improving the efficiency of generating test cases.
II. Test Models
In model based testing[9−11] , models can be used to
automatically generate full or partial test cases. They usu-
ally refer to the function description of the System under
test (SUT), and can abstract the expected behaviors and
actions of SUT. To get software test cases based on test
models can improve the efficiency of automated testing. In
UML models, use case model provides detailed informa-
tion about the behaviors of system and sequence diagram
describes the various types of interaction among objects
during system operation. So test cases generated by use
case model and sequence diagram can find possible faults
caused by method calls and message delivery order. Each
use case in use case model presents a functional module,
and there is a corresponding sequence diagram. Formal
methods have the good description and analysis capabil-
ities in aspects of model design and attribute analysis.
So they are important means to improve software design
quality.
1. Use case model
235
Use case model contains use case diagram and descrip-
tion. Use case diagram usually depicts the relationships
between use cases and actors. However, use case descrip-
tion provides more detail for system design, including the
name of use case, preconditions and end conditions of use
case execution, primary, main flows, and so on. Object
constraint language (OCL) supplements UML by provid-
ing expressions that have neither the ambiguities of nat-
ural language nor the inherent difficulty of using complex
mathematics. In this paper, OCL is used to describe ex-
pressions on test models. We give the definition of use
case diagram and use case description.
Definition 1 Use case diagram is a 5-tuple: U C =
(Ac, U s, auc, uur, aar), where,
• Ac is a set of actors. Each actor has a unique name
that describes the role of user who interacts with system;
• U s is a set of use cases. Each use case describes a
particular goal for the user and how the user interacts
with the system to achieve that goal;
• auc is a function from Ac to U s, auc(us)∈Ac;
• uur is a function from U s to U s. uur(us, us)=
{include, extend, generalization, ε}, it can be
also empty, denoted by ε;
• aar is a function from Ac to Ac. aar(ac, ac)=
{generalization, ε}, it can be also empty, denoted by
ε.
Definition 2 Use case description is a 11-tuple:
U D = (un, rr, gc, pr, sc, f c, pa, sa, tr, mf , ex), where,
• un is the name of use case;
• rr is a set of related requirements;
• gc is the goal in context;
• pr is a set of preconditions, what needs to happen
before the use case can be executed;
OCL expressions:
context Typename::operationName(param1: T ype1,
...): ReturnType
pre: parameterOk
• sc is a set of successful end conditions;
OCL expressions:
context Typename::operationName(param1: T ype1,
...): ReturnType
post: Successful result is Ok
• f c is a set of failed end conditions;
OCL expressions:
context Typename::operationName(param1: T ype1,
...): ReturnType
post: Failed result is Ok
• pa is a set of primary actors;
• sa is a set of secondary actors;
• tr is a set of triggers, the event triggered by an actor
that causes the use case to execute;
• mf is the main flow, the place to describe each
of the important steps in a use case’s normal execution,
236 Chinese Journal of Electronics
mf ={step1, ..., stepi , ..., stepn }, 1≤i≤n;
• ex is the extensions, a description of any alter-
native steps from the ones described in the main flow,
ex={stepi.1 , ..., stepi.i , ..., stepi.n }.
2. Sequence diagram
In Ref.[7], sequence diagram is a 13-tuple: SD = (P ,
E, S, R, M , F G, OP , C, msg, obj, f rag, →, ≺). E, S
and C are defined as follows:
• E is a finite non-empty set of events;
• S is a set of sending events;
• C is a finite set of guard conditions of fragments, a
guard condition can be empty, denoted by ε;
OCL is adopted to describe the preconditions, end
conditions and constraints for event execution. Con-
straints are the guard conditions of fragments.
OCL expressions for preconditions:
context Typename::operationName(param1: T ype1,
...): ReturnType
pre: parameterOk
OCL expressions for end conditions:
context Typename::operationName(param1: T ype1,
...): ReturnType
post: ResultOk
OCL expressions for constraints:
context Typename inv: c where, c∈C
Event deterministic finite automata[7] are a 7-tuple:
M = (Q, CM , EM , Σ, δ, q0 , F ), where,
• Q is a finite non-empty set of states, ∀q∈Q, q is
called a state of M ;
• CM is a finite set of guard conditions of fragments in
sequence diagrams, a guard condition can be also empty,
denoted by ε;
• EM is a finite set of events;
• Σ is a finite set of symbols, Σ={(c, e)|c∈CM ,
e∈EM };
• δ is the transition function, δ: Q×(CM ×EM )→Q;
• q0 is the starting state of M , q0 ∈Q;
• F is a finite set of final states of M, F ⊆Q.
In Refs.[6,7], an efficient mechanism for verifying se-
quence diagrams is provided. The proposed method cre-
ates an ETDFA-based model from UML interactions ex-
pressed in sequence diagrams for a system, and specifies a
property written in PPTL. A model checker[12−14] is used
to verify the property. The verified ETDFA are equivalent
to the abstract description of requirements, so they can
be used to generate test cases.
III. Automata Synthesis
Due to the continually increasing software size, se-
quence diagrams that describe the interaction behavior
become more and more complex. According to the method
in Refs.[6,7], automata are used to describe the formal
models of a sequence diagram. Meanwhile an automaton
2016
will have massive states with complex migration paths,
which increase the difficulty of analysis and affect the ef-
ficiency and coverage of test cases generation. In order to
simplify the control flow and test cases generation pro-
cess, handle the control and nested structure, this paper
presents a simplification method based on automata syn-
thesis rules to achieve the test cases incrementally.
1. Composite automata
Before synthesizing and simplifying the ETDFA used
to describe sequence diagram, we give the definition of
composite automata.
Definition 3 Composite automata are a 9-tuple:
A = (Q*, X, B, L, P , Σ*, δ*, q0 *, F *), where,
• Q* is a finite non-empty set of atomic states;
• X is a finite set of composite states of sequential
execution structure;
• B is a finite set of composite states of select execu-
tion structure;
• L is a finite set of composite states of loop execution
structure;
• P is a finite set of composite states of concurrent
execution structure;
• Σ* is a input alphabet, Σ*={(c, e)|c∈CM , e∈EM },
CM is a set of execution condition of combined fragment,
EM is a set of finite events in sequence diagram;
• δ* is the transition function;
• q0 * is the starting state of A, q0 *∈Q*;
• F * is a finite set of final states of A.
2. Synthesis rules
In order to simplify the automata structures, we trans-
form the ETDFA into composite automata through syn-
thesis rules to realize the test scenarios and test cases
generation.
Definition 4 Synthesis rules for automata. ETDFA
M = (Q, CM , EM , Σ, δ, q0 , F ), composite automata
A=(Q*, X, B, L, P , Σ*, δ*, q0 *, F *).
Rule 1: Merger of sequential execution structure.
If the relationships among adjacent states are sequen-
tial execution, the adjacent states can be merged into a
composite state, represented by X, as shown in Fig.1.
Fig. 1. The merger of sequential structure
Description: In Fig.1, (a) shows an automaton of
states sequential execution; (b) shows a composite au-
tomaton after merger; (c) shows the composite structure,
where X1 is a composite state consists of states q1 , q2 and
q3 .
 A Test Case Generation Approach Based on Sequence Diagram and Automata Models 237

Rule 2: Merger of select execution structure. If there is

select branch among states, the states can be merged into
a composite state, represented by B, as shown in Fig.2.

Fig. 4. The merger of concurrent structure

The procedure of automata synthesis is shown in Al-

gorithm 1.

Algorithm 1 Synthesis algorithm for automata

Input: ETDFA M =(Q, CM , EM , Σ, δ, q0 , F ), sequence
diagram SD=(P , E, S, R, M , F G, OP , C, msg, obj, f rag,
→, ≺).
Output: Composite automata A=(Q*, X, B, L, P , Σ*, δ*,
q0 *, F *).
1: q0 *=q0
2: for i=0 to n-1, j=1 to n, k=1
Fig. 2. The merger of select structure 3: {while δ(qi , (c, ej ))=qi+1 , i++, j++ do
4: {if frag(ej )=frag(ej+1 )=par
Description: In Fig.2, (a) and (d) show two types of 5: create Xk , k=k+1 (Rule 1 in Definition 4)
automata with select branches respectively. (b) and (e) S
6: } X=X Xk }
give the composite automata corresponding to (a), (d) af- 7: for opt, alt, loop, par, x=1, y=1, z=1
ter merger; (c) and (f ) are the composite structures, B1 8: {{while fragment is unnested do
in (b) is a composite state consists of q2 and q3 in (c), B1 9: {create Bx , x=x+1 (Rule 2 in Definition 4)
in (e) is a composite state consists of q2 and q3 in (f ). 10: create Ly , y=y+1 (Rule 3 in Definition 4)
By analogy, we could get multi-branch automata merger 11: create Pz , z=z+1 (Rule 4 in Definition 4)
S S S
methods. 12: }B=B Bx , L=L Ly , P =P Pz }
Rule 3: Merger of loop execution structure. If there is 13: {while fragment is nested do
a loop structure among states, the states can be merged 14: {from the innermost fragment
15: create Bx , x=x+1 (Rule 2 in Definition 4)
into a composite state, represented by L, as shown in
16: create Ly , y=y+1 (Rule 3 in Definition 4)
Fig.3.
17: create Pz , z=z+1 (Rule 4 in Definition 4)
S S S
18: }B=B Bx , L=L Ly , P =P Pz }}
S S S
19: Q*=Q-{qi }, qi ∈Xk Bx Ly Pz
20: Σ*=Σ
21: δ*=δ
22: if ∀qi ∈F and qi ∈Xk , Xk ∈F *
23: if ∀qi ∈F and qi ∈Bx , Bx ∈F *
Fig. 3. The merger of loop structure
24: if ∀qi ∈F and qi ∈Ly , Ly ∈F *
Description: In Fig.3, (a) shows an automaton with 25: if ∀qi ∈F and qi ∈Pz , Pz ∈F *
26: if ∀qi ∈F and qi ∈Q*, qi ∈F *
loop structure; (b) shows the composite automaton cor-
27: end
responding to (a) after merger; (c) shows the composite
structure, where L1 is a composite state consists of states
q1 , q2 and q3 .
IV. Test Cases Generation
Rule 4: Merger of concurrent execution structure. If
there is a concurrent structure among states, the states ETDFA which are equivalent to sequence diagram
can be merged into a composite state, represented by P , have some defects. For example, it has a large number
as shown in Fig.4. of states and complex migration paths. So we first use
Description: In Fig.4, (a) shows an automaton with automata synthesis rules to simplify ETDFA, and then
concurrent structure; (b) shows the composite automaton traverse the composite automata to get the test scenar-
corresponding to (a) after merger; (c) shows the compos- ios, lastly generate test cases set by the basic paths and
ite structure, where P1 is a composite state consists of internal paths.
states q1 , q2 , q3 , q4 and q5 . 1. Coverage criteria
238 Chinese Journal of Electronics 2016

Composite automata contain all the control structures Algorithm 2 Test cases set generation algorithm
in the form of composite states. Each composite state Input: ETDFA M =(Q, CM , EM , Σ, δ, q0 , F ).
could be mapped to a single control structure, while a Output: Test cases set T .
composite state can be nested zero or multiple times. 1: Use the synthesis algorithm for automata (Algorithm
Paths in composite automata are defined as the basic 1) to obtain the composite automata A which is corre-
spond to ETDFA;
paths. A basic path is a sequence containing atomic states
2: Use the rules for test scenarios generation (Definition
and composite states. Paths in composite states are de-
6) to obtain S which is the set of test scenarios;
fined as the internal paths. For the internal path and the
3: For any scenario sn , a test case ti =preconditions,
basic path, we proposed four coverage criteria: select cov- events, event constraints, end conditions, desired
erage, loop coverage, concurrent coverage and all-paths S
outputs, the set of test cases T = ti ;
coverage. 4: For each test case, the preconditions and end condi-
Definition 5 Path coverage criteria. tions of scenarios, and the desired outputs come from
use case description. Events and event constraints are
1) Select coverage criteria Given a test set T , for any
correspond to the events on each state and the execu-
select branch in composite state B which expresses the
tion conditions of combined fragments.
selection structures in composite automata, there must
be a corresponding scenario in T . V. Case Study
2) Loop coverage criteria Given a test set T , for cycle
paths in composite state L which expresses the loop struc- This section takes the Movie tickets booking system
tures in composite automata, there must be a scenario in (MTBS) as an example to show the test cases generation.
T executing at least once. 1. Modeling and verification of MTBS
3) Concurrent coverage criteria Given a test set T , The sequence diagram in Fig.5 describes several states
for any effective concurrent sequence in composite state of MTBS. User requests booking, Box office shows the
P which expresses the concurrent structures in composite available seats. After User selects seats, judge whether
automata, there must be a corresponding scenario in T . the number of selected seats m is less than the number
of expected seats n. If it is true, continue to select seats
4) All-paths coverage criteria Given a test set T and
until it meets the demand, and lastly insert the card for
sequence diagram SD, making T satisfied with the mes-
payment. Card service verifies the card information. The
sage paths sequence generated by SD which execute at
ETDFA of object Box office are shown in Fig.6. Model
least once.
Under the premise of meeting the above coverage cri-
teria, we discuss the generation of test scenarios and test
cases.
2. Test scenarios generation
Test scenario is an action sequence of objects during
the interaction. Each scenario represents a trace of system
performs, and therefore it can be mapped as test cases.
The rules of test scenarios generation are as follows.
Definition 6 Rules for test scenarios generation.
Rule 1: Traversing composite automata to obtain the
basic paths from an initial state to a final state;
Rule 2: Each composite state has a corresponding set
of internal paths;
Rule 3: According to the order of composite states in
the basic path, these states are replaced with the internal
paths which correspond to the composite states. At last,
all the paths only have atomic states. The set of paths is
the set of test scenarios.
3. Test cases generation
Test scenarios can be considered as abstract test cases.
For every abstract test case, supplementary information
comes from use case description. The procedure of test
cases generation is shown in Algorithm 2. Fig. 5. MTBS sequence diagram
 A Test Case Generation Approach Based on Sequence Diagram and Automata Models
Fig. 6. ETDFA of object Box office
checker is used to check the satisfiability of PPTL formu-
las with ETDFA. After merging the confirmed automata
model, we could get the composite automata.
2. Automata synthesis of Box office
Adopting rules for automata synthesis, we can get
the merged automata model, the process is shown in
Figs.7(a)–(h). Fig.7(a) shows an automaton generated
by merging the sequential structure. The structures of
composite states X1 , X2 , X3 are respectively shown in
Figs.7(b)–(d). The automaton in Fig.7(e) can be obtained
by further synthesizing the loop structure in Fig.7(a). The
structure of composite state L1 is shown in Fig.7(f ). Fi-
nally, to get the composite automaton in Fig.7(g), the
select branch in Fig.7(e) is merged, where the structure
of composite state B1 is shown in Fig.7(h).
Fig. 7. Automata synthesis process. (a) Merging sequential
structure; (b) X1 ; (c) X2 ; (d) X3 ; (e) Merging loop
structure; (f ) L1 ; (g) Merging select structure; (h) B1
3. Test scenarios of Box office
Using the rules for test scenarios generation, we get the
test scenarios set shown in Table 1. In basic paths, under-
lined states are unexpanded composite states. Expanding
these states, four scenarios can be obtained, among which
loop structures are processed in accordance with execut-
ing “0” times and “1” times respectively.
239
Table 1. Test scenarios generation of Box office
No. Basic paths set
1 {q0 , L1 , X1 , B1 , q11 }
2 {q0 , X1 , B1 , q11 , q0 , q1 , q2 , q3 , X1 , B1 , q11 }
3 {q0 , q4 , q5 , q6 , B1 , q11 ,q0 , q1 , q2 , q3 , q4 , q5 , q6 , B1 ,
q11 }
4 {q0 , q4 , q5 , q6 , X2 , q11 ,q0 , q4 , q5 , q6 , X3 , q11 , q0 ,
q1 , q2 , q3 , q4 , q5 , q6 , X2 , q11 ,q0 , q1 , q2 , q3 , q4 , q5 , q6 ,
X3 , q11 }
No. Test scenarios set
5 {q0 , q4 , q5 , q6 , q7 , q8 , q11 , q0 , q4 , q5 , q6 , q9 , q10 ,
q11 ,q0 , q1 , q2 , q3 , q4 , q5 , q6 , q7 , q8 , q11 ,q0 , q1 , q2 ,
q3 , q4 , q5 , q6 , q9 , q10 , q11 }
4. Test cases of Box office
In the basic paths set and the test scenarios set shown
in Table 1, take test scenarios q0 , q1 , q2 , q3 , q4 , q5 , q6 ,
q7 , q8 , q11  as an example to illustrate the corresponding
test cases.
Preconditions: user has not bought a ticket; Event:
(receive) user requests the ticket; Event constraints: the
number of selected seats is less than the number of ex-
pected seats; Event: (send) information of available seats;
(receive) select seats; Event constraints: the end of select-
ing seats; Event: (send) demand payment; (receive) insert
the card; (send) charge; Event constraints: card is OK;
Event: (receive) authorized tickets; (send) print tickets;
(send) exit the card; End conditions: buy tickets success-
fully; Desired outputs: exit the card successfully.
5. Results analysis
The interaction process expressed in UML2.0 sequence
diagrams for a system contains the complex control flow
structure and nested structure. So its automata models
become complicated correspondingly. This brings some
difficulty to traverse all the paths correctly and to obtain
the test scenarios meet the coverage criteria. In this case,
we adopt an incremental test cases generation method,
merging sequential structure, loop structure and branch
structure which are in automata in an orderly manner,
and eventually get a basic path. When the basic path is
refined, the composite states are replaced by their internal
paths. Gradually, we get the full test scenarios.
VI. Conclusion
Analyzing, verifying and testing software system by
formal methods and techniques is an important way to
construct high confidence software. In this paper, an ap-
proach for test cases generation is presented. We construct
use case model and sequence diagrams of the SUT. The
ETDFA from sequence diagrams which describe the inter-
action process of a system are verified. The automaton is
simplified by the synthesis rules. Test scenarios and test
cases are extracted from the basic and internal paths. This
technique improves the accuracy of the test cases genera-
tion by means of verification, and enhances the efficiency
of test cases generation by the way of model combination
and incremental description of test scenarios.
240 Chinese Journal of Electronics
References
[1] Y.G. Kim, H.S. Hong, et al., “Test cases generation from UML
state diagrams”, IEE Proceedings-Software, Vol.146, No.4,
pp.187–192, 1999.
[2] H. Miao, X. Zhan and L. Liu, “Generating test case based
on UML statecharts”, Journal of Chinese Computer Systems,
Vol.26, No.4, pp.662–666, 2005. (in Chinese)
[3] M. Sarma, D. Kundu and R. Mall, “Automatic test case gen-
eration from UML sequence diagrams”, Proceedings of the 15th
International Conference on Advanced Computing and Com-
munications, IEEE Computer Society, Piscataway, NJ, USA,
pp.60–65, 2007.
[4] S.K. Swain, D.P. Mohapatra and R. Mall, “Test case genera-
tion based on use case and sequence diagram”, International
Journal of Software Engineering, Vol.3, No.2, pp.21–52, 2010.
[5] C. Zhang and Z. Duan, “Test case generation based on UML2.0
models”, Journal of Xi’an Jiaotong University, Vol.45, No.8,
pp.18–23, 2011. (in Chinese)
[6] C. Zhang and Z. Duan, “Specification and verification of
UML2.0 sequence diagrams using event deterministic finite au-
tomata”, Proceedings of the 5th International Conference on
Secure Software Integration and Reliability Improvement, IEEE
Computer Society, Piscataway, NJ, USA, pp.41–46, 2011.
[7] C. Zhang, Z. Duan and C. Tian, “Specification and verification
of UML2.0 sequence diagrams based on event deterministic fi-
nite automata”, Journal of Software, Vol.22, No.11, pp.2625–
2638, 2011. (in Chinese)
[8] A. Nayak and D. Samanta, “Synthesis of test scenarios us-
ing UML activity diagrams”, Software and Systems Modeling,
Vol.10, No.1, pp.63–89, 2011.
[9] J. Dick and A. Faivre, “Automating the generation and sequenc-
ing of test cases from model-based specifications”, Proceedings
of FME ’93: Industrial-Strength Formal Methods, Springer-
Verlag, Berlin, Germany, pp.268–284, 1993.
[10] S. Liu and S. Nakajima, “A decompositional approach to au-
tomatic test case generation based on formal specifications”,
Proceedings of the 4th International Conference on Secure Soft-
ware Integration and Reliability Improvement, IEEE Computer
Society, Los Alamitos, CA, pp.147–155, 2010.
[11] M. Utting and B. Legeard, Practical Model-Based Testing: A
Tools Approach, Morgan Kaufmann, USA, 2007.
[12] C. Yang and Z. Duan, “A key technique to develop the model
checker for propositional projection temporal logic”, Journal of
Xi’an Jiaotong University, Vol.44, No.10, pp.24–29, 2010. (in
Chinese)
[13] G.J. Holzmann, “The model checker spin”, IEEE Transactions
on Software Engineering, Vol.23, No.5, pp.279–295, 1997.
[14] H. Lin and W. Zhang, “Model checking: Theories, techniques
and applications”, Acta Electronica Sinica, Vol.30, No.12A,
pp.1907–1912, 2002. (in Chinese)
2016
[15] C. Tian, S. Liu and Z. Duan, “Test case generation from con-
junctions of predicates with model checking”, Chinese Journal
of Electronics, Vol.23, No.2, pp.271–277, 2014.
ZHANG Chen is a lecturer of com-
puter science at the Xidian University,
Xi’an, China. She received the Ph.D. de-
gree in computer science from Xidian Uni-
versity, in 2012. Her research interests in-
clude formal verification of software sys-
tems, model checking, and software engi-
neering. She is a member of China Com-
puter Federation. (zhangc@xidian.edu.cn)
DUAN Zhenhua is a professor of
computer science at the Xidian Univer-
sity, Xi’an, China. He received the Ph.D.
degree from the University of Newcastle
upon Tyne, United Kingdom, in 1996.
His research interests include concurrent,
realtime, and hybrid systems, temporal
logic programming, formal languages and
automata, and formal semantics. (zhhd-
uan@mail.xidian.edu.cn)
YU Bin is a professor of computer
science at the Xidian University, Xi’an,
China. He received the Ph.D. degree in
computer science from Northwest Univer-
sity, in 2003. His research interests include
formal method and software engineering.
(yubin@mail.xidian.edu.cn)
TIAN Cong is a professor of com-
puter science at the Xidian University,
Xi’an, China. She received the Ph.D. de-
gree in computer science from Xidian Uni-
versity, in 2009. Her research interests in-
clude theories in model checking, tempo-
ral logics and automata, formal verification
of software systems, and software engineer-
ing. (ctian@mail.xidian.edu.cn)
DING Ming is a Ph.D. candidate
of computer science at the Northwest Uni-
versity, Xi’an, China. His research interests
include model checking and software engi-
neering.