The target model for test cases is precisely specified using a modeling language named Test Case Specification Language TCSL.. Comparing with current approaches, generated test cases withi
Trang 1A Transformation-Based Method for Test Case
Automatic Generation from Use Cases
Department of Software Engineering, VNU University of Engineering and Technology, Hanoi, Vietnam
{huectm.di12, hanhdd, nnbinh}@vnu.edu.vn
Abstract—This paper proposes a method to automatically
generate system test cases from use cases Within our method, we
take use cases as source model that are represented by the use
case modeling language USL The target model for test cases
is precisely specified using a modeling language named Test
Case Specification Language (TCSL) Comparing with current
approaches, generated test cases within our approach contain
more detailed information including test steps, test objects within
steps, actions of test objects, and test data We focus on defining
a transformation between the USL source model and the TCSL
target model We realized our method with a support tool
based on the OCL solver of USE and the model transformation
framework in Eclipse.
Index Terms—modeling-based testing, transformation, system
test case, use case, USL, USLTG, TCSL
I INTRODUCTION Software testing is an important activity to ensure the quality
of software It accounts for a large part of the development
effort A way to reduce testing effort and ensure the
effective-ness of testing is to generate system test cases from functional
requirements during requirement engineering, an early phase
of software development However the software requirements
often change during the software development process, so
related system test cases have to be rebuilt and executed again
Moreover, functional requirements are often represented and
captured by use cases Hence, the effort required to identify,
maintain, and execute test cases for use cases is very big
Automatically generating and executing test cases help save
much time and effort as well as reduce the number of errors
and faults in the testing activity
Among current automated testing execution processes, the
keyword-driven/data-driven automated testing process [1] aims
to tackle the maintenance problems of low-level test scripts by
raising the abstraction level of the test cases The basic idea
is to express each test case as abstractly as possible while
making it precise enough to be executed or interpreted by
a test execution tool [1] The basic working principles of the
Keyword-Driven Testing Framework (KDTF) are to divide the
test case into four different parts: test steps, test objects of each
test step, actions within test objects, and test data [2] Hence,
the KDTFs can run tests directly from test cases and it is no
need to update low-level test scripts as test cases are changed
To this end, a considerable number of works, including [3]–
[9], have attempted to introduce system test cases automatic
generation approaches from use cases These works proposed
system test case automatic generation methods from use case specifications in a template with restricted rules and keywords
as in [3], [4], or use case models in UML activity and sequence diagrams as in [5], [6], or UML diagrams with contracts as in [7], or use case models in a Domain Specify Language (DSL)
as in [8], [9]
However, within the current works mentioned above, the relevant informations of test cases including concurrent test steps, test object name, action, and test data values are often not captured Furthermore, these works also lack a test case specification language capable of capturing reusable system test cases These specifications are understandable to
non-technical stakeholders and precise enough for KDTFs.
In this paper, we propose a method to generate test cases
from use cases named Test Generation from a USL model (USLTG) Firstly, use cases are specified by models in Use
Case Specification Language (USL) [10] Secondly, USLTG
generates test scenarios and test data suites from these models Finally, USLTG transforms generated test scenarios and test
data suites into a model in Test Case Specification Language
(TCSL) by model transformations
To summarise, the main contributions of this paper are:
generation from use cases;
model capturing generated system test cases;
• a support tool to realize the USLTG method
The rest of this paper is organized as follows Section III introduces the background and motivation for developing USLTG Section IV overviews the our method Section V presents the languages USL and TCSL to specify use cases and test cases, repspectively Section VI explains how to generate system test cases in the USLTG method Section VII briefly discusses the tool support of USLTG Section II comments on related work The paper is closed with a conclusion and future works
We position our work in system test cases automatic gen-eration from use cases Within this context, test cases are often generated by Model-Based Testing (MBT) techniques
In order to automatically generate system test cases from use cases, several approaches as in [3]–[9] have been proposed
Trang 2According to our knowledge, these approaches can be grouped
into three groups
In the first group, system test cases are automatically
gener-ated from specifications in a template with restricted rules and
keywords For example, Wang et al [3], Sarmiento et al [4]
follow this approach However, these works must use a Natural
Language Processing(NLP) technique to extract behavioural
information and constraints This technique is often difficult
and limited in some natural languages (eg, English) Moreover,
extracted constraints are presented in natural language Hence,
to automatically generate test data, these constraints must
be presented again in another precise constraint specification
language, such as OCL (as in [3]) Another limitation of these
works is that they do not handle test scenarios containing
concurrent test steps
In the second group, system test cases are automatically
generated from UML diagrams modeling use cases, such as
activity and sequence diagram Examples of such this approach
can be found in works by Gutierrez et al [5] and Tiwari et al.
[6] Nebut et al [7] enhances UML diagrams with contracts to
automatically generate system test cases However, works that
generate test cases from activity diagrams mostly concentrated
on generating test scenarios In order to generate test data, the
activity diagram must be combined with other models, such
as state chart, sequence diagrams Furthermore, type of test
steps in these works was not identified concretely
In the third group, system test cases are automatically
generated from use case models which are modelled by a DSL,
such as Gutierrez et al [8], Straszak et al [9] However, these
work did not mention test cases containing concurrent test
steps In addition, test data in [8], [9] is identified as condition
sentences instead of concrete values
Use cases are widely used to capture and structure the
functional requirements of a software system They were first
defined by Jacobson in 1987 and presented in a plain text
paragraph style format [11] Use cases are a centric artifact in
the software development They are used as input to generate
other software artifacts, such as system test cases In this
paper, we use a simplified use case Lend book taken from
our previous work in [10] as input to generate system test
cases and also to motivate and illustrate for this research
A test case is defined “a specification of inputs, execution
conditions, testing procedure, and expected results” It defines
a single test to be executed to achieve a particular software
testing objective, such as to traverse a particular program path
or to verify compliance with a specific requirement [12]
According to Jim [13] to build test cases from a use case,
it includes three steps In the first step, use case scenarios
will be identified A use case scenario is an instance of, or
a complete path through, a use case In the second step, test
scenarios will be built from corresponding use case scenarios
In the final step, test data suites of each test scenario will be
identified A test case results from combining a test scenario
and a test data suite Namely, a test scenario describes steps
of a testing procedure, execution conditions A test data suite
includes values of test inputs and expected outputs
A test step can be an action that is executed by a primary actor or a checkpoint (a system action that compares a current value for a specified property with expected value for that property [14]) Moreover, a test step also can be related to other test cases of another use case that is included in the use case or extended from the use case This test step is called
Invoking Step [9].
The test scenario can also contain a precondition and a postcondition which present the conditions that the system must be satisfied before and after executing the test scenario, respectively [9]
According to Raghavendra [2] to use the system test cases
as input for KDTFs, test cases must contain four different parts: test steps, test objects of each test step, actions within test objects and test data
TABLE I
T WO TEST CASES OF THE USE CASELend book
Num Step Object Action Data 1 Data 2
1 Librarian selects the Lend-book function lendbookF select
2 Librarian enters a book copy id bcid enter “bc_01” “bc_03”
3 Librarian enters a borrower id bid enter “” “b_03”
4 Librarian enters a borrower id bid enter “b_02” “b_02”
5 Librarian clicks the save-book-loan button SaveBLoan click
6 The system save the book loan record BookLoan verify a Book loan is recorded
7 the system shows a complete message message verify “Book loan save complete”
8 the system prints the borrowing bill bBill verify “Book loan receipt is printed”
For example, Table I shows two test cases to test for an
execution path of the use case Lend book They are combined
from a test scenario and two test data suites Lines 1 to 8 describe the test steps of the test scenario and two test data
suites of the test cases In particular, the columns Num, Step,
Object, Action, Data 1, and Data 2 present the order of each
test step, the description of each test step, the test object name
of each test step, the action name on the test object of each test step, and two test data suites, respectively
In order to transform use cases into test cases, we identify several challenges as following:
Test scenario generation Generated test scenarios contains complete information of test steps, such as execution con-ditions, descriptions of test steps, test objects within steps, actions on test objects, and type of test steps
Test data generation Generated test data suites contain concrete values of inputs and expected outputs
Test case precise specification To reuse test cases or to automatically transform test cases into different forms, the generated test cases should be precisely specified
Figure 1 shows the main steps of our USLTG approach USLTG aims to automatically generate test cases from use cases Our goal is to address the challenges listed in Sect III
In our approach, a use case is captured by a USL model We take as input the USL model, a UML class model capturing domain concepts of the system, and the internal states of the system as inputs to automatically generate the system test cases These generated test cases are represented by a TCSL model The languages TCSL and USL are explained in Sect V
USLTG includes three main steps: Step 1 to generate use case scenarios and constraints, Step 2 to generate test input data suites for each test scenario, and Step 3 to generate
Trang 3a TCSL model capturing identified test cases with TCSL.
A more detailed explanation of these steps is presented in
Sect VI
Fig 1 Overview of the USLTG Approach
V REPRESENTINGUSECASES ANDTEST CASES
This section briefly describes use case specifications with
USL and system test case specifications with TCSL by two
example models, the USL model as shown in Fig 2 for the
use case Lend book and the TCSL model shown in Fig 3 for
generated test cases
A Representing Use Cases with USL
USL is a DSL which we proposed in [10] to specify
described different information aspects in each textual use case
description (See [10] for a more detail) The purpose of USL
is to precisely specify a use case description by a model The
model is used to automatically generate other software artifacts
by model transformations and to be easily understood by
non-technical stakeholders
The basis for system test cases automatic generation from
use cases is the precise specifications of use cases As
men-tioned above, our solution is based on use case specifications
created with USL
In this section, we briefly introduce USL by an example
USL model Figure 2 shows a USL model of the use case
Lend book It presents described different information aspects
in the use case Lend book, including overview information
elements, one basic flow (including steps from s1 to s11), four
alternate flows (4a, 6a, 8a and E1), actions in steps (being a1
a18), guard constraints to select between flows (g1 g6),
and postcondition constraints of actions (p1 p6).
B Representing Test Cases with TCSL
TCSL is a DSL that we developed to precisely specify
system test cases and to automatically transform from a USL
model to system test cases We define this language by a
metamodel with meta-concepts identified from the domain of
system test case presentation task Due to limited space, a
detailed explanation of the TCSL metamodel is not mentioned
in this paper Instead of that, we explain it by means of the
example
Figure 3 shows a TCSL model that specifies generated
test cases from the use case Lend book It focuses on
dis-playing test cases in Table I Particularly, System object
captures the system that test cases are defined to against
it, UseCase object captures the use case of defined test
cases, TestScenario object captures a test scenario which can include TestSteps, CheckPoints or InvokeSteps,
output data values of each TestStep or CheckPoint in test data suites
In the next section, we present the details of our method to automatically transform a USL model into a TCSL
Fig 2 The USL model of the use case Lend Book
This section presents the details of three steps of USLTG
as shown in Fig 1 to generate test cases from use cases
A Generation of Use Case Scenarios and Constraints
We implemented a scenario generation algorithm named
GenScenarios to generate a set of constrained use case
scenar-ios from a USL mode through a Depth First Traversal (DFT),
as shown in Algorithm 1 Each use case scenario corresponds
to a path in the USL model from the initial node to a final node The following describes this algorithm in detail
Trang 4Fig 3 Test cases in Table I are captured by a TCSL model
GenScenarios takes as input: D, a USL model Its
out-put is a set of paths which correspond to constrained use
case scenarios The derived paths cover all FlowEdges
and USLNodes Constraints of FlowEdges are
com-bined with Constraints pre of actions and moved
into Constraints pre of actions A path includes a
InitialNode, a FinalNode, Actions, ForkNodes,
JoinNodes, and subpaths (Each subpath includes a sequence
of Actions)
In particular, the InitialNode and the FinalNode
identify the initial point and the final point of the use case
scenario, Actions are actions which are executed
sequen-tially, each sequence of subpaths are started and finished by
a pair of ForkNode and JoinNode to present subpaths
which are executed concurrently Each Action can have two
Constraints being the precondition and the postcondition
of the Action
Procedure GenerateScenarios calls some functions:
outGo-ing(x) returning a set of out-going FlowEdges from the
USLNodex, targetNode(e) returning a target USLNode of the
with the pre Constraint of the Action a and then moving
into the pre Constraint of the Action a, guardE(e)
returning the guard Constraint of the FlowEdge e.
Additionally, procedure VisitSubpath(allsubSteps, allsubPaths,
subSteps, subPaths, targetNode(e), jn) is called to generate
sets of all subpaths and all subSteps starting from different
USLNodes, target USLNodes of out-going FlowEdges from
the ForkNode x, to a JoinNode jn.
Example VI.1 Algorithm GenScenarios identified five
con-strained use case scenarios from the use case Lend book as
below We use two symbols “<” and “>” to denote relations
between an action with its precondition and postcondition,
respectively The use case scenarios sc1 to sc4 contain two
ac-tions that are executed concurrently: {a12>p2} and {a13>p3}.
1 GenScenarios(D) Input: D is a USL model Output: paths is a set of constrained use case scenarios returning from D
2 BEGIN pt← ∅; sc ← ∅; x ← the InitialNode of D; GenerateScenarios(pt,sc,x); END.
3 Procedure GenerateScenarios (pt,sc,x)
4 prex = the last node in pt; push(pt,x) ;
5 if x is FinalNode then sc ← sc ∪ x; paths ← paths ∪ sc; exit ;
6 if x is DecisionNode then
7 if∀ e ∈ outGoing(x) was visited then
8 bf← the BasicFlowEdge in outGoing(x);
9 if∃ bf then GenerateScenarios(pt, sc, targetNode(bf));
10 else exit ;
11 else
12 foreach t in outGoing(x) that was not visited do
13 ptn← copy objects from pt; scn ← copy objects from sc;
14 GenerateScenarios(ptn, scn, targetNode(e));
15 else if x is ForkNode then
16 sc← sc ∪ x; jn ← null; allsubSteps ← ∅; allsubpaths ← ∅ ;
17 foreach t in outGoing(x) do
18 subSteps← null; subPaths ← null;
19 //subSteps, a set of USLNode sequences,
20 //subpaths, a set of Action sequences and jn, a JoinNode
21 VisitSubpath(allsubSteps, allsubPaths, subSteps, subPaths, targetNode(e), jn)
22 //maxLength(allsubSteps) returns the max size of subpaths in allsubSteps
23 for i=0; i<maxLength(allsubSteps); i++ do
24 ptn← copy objects from pt; scn ← copy objects from sc;
25 for j=0;j <allsubSteps.size();j++ do
26 vt← 0;
27 if allsubSteps[j].size()<i then vt=i ;
28 else vt← random form 0 to allsubSteps[j].size()-1;
29 ptn← ptn ∪ allsubSteps[j][vt]; scn ← scn ∪ allsubpaths[j][vt];
30 GenerateScenarios(ptn,scn,jn);
31 else if x is FlowStep then
32 if prex is DecisionNode then
33 act← copy the object actions(x)[0] ;
34 act.setPre(defGuard(guardE(prex, x),act)); sc← sc ∪ act;
35 else sc← sc ∪ actions(x)[0] ;
36 for i=1; i<actions(x).zise(); i++ do sc ← sc ∪ actions(x)[i] ;
37 GenerateScenarios(pt, sc, targetNode(outGoing(x)[0])) ;
38 else sc← sc ∪ x; GenerateScenarios(pt, sc, targetNode(outGoing(x)[0])) ;
39 End;
sc1 = {a1, a2, a3, a4, a5, a6, g1<a7, a8, g3<a9, a10, g5<a11>p1, c4, {a12>p2}, {a13>p3},
c5, c7};
sc2 = {a1, a2, a3, a4, a5, a6, g2<a14 >p4, a5, a6, g1<a7, a8, g3<a9, a10, g5<a11>p1, c4,
{a12>p2}, {a13>p3}, c5, c7};
sc3 = {a1, a2, a3, a4, a5, a6, g2<a14 >p4, a15, a16, a5, a6, g1<a7, a8, g3<a9, a10,
g5<a11>p1, c4, {a12>p2}, {a13>p3}, c5, c7};
sc4 = {a1, a2, a3, a4, a5, a6, g1<a7, a8, g4<a17, a7, a8, g3<a9, a10, g5<a11 >p1, c4,
{a12 >p2}, {a13 >p3}, c5, c7};
sc5 = {a1, a2, a3, a4, a5, a6, g1<a7, a8, g3<a9, a10, g6<a18>p6, c8};
B Generation of Test Input Data Suites
Test input data suites of each test scenario are generated
by solving constraints in the corresponding use case scenario
A test input data suite of a test scenario is a set of input variable values which actors send to the system We model input variables of a test scenario by properties of a class named
EV An action sending input data to the system can be executed many times At different execution times, input variables are modelled by different properties of EV The name’s these properties includes two parts: prefix and suffix Their prefixes have the same value and are the input name Their suffixes are the repeat number of the action For example, in the use
case scenario sc4, the class EV includes properties as follows:
bcid, bid1, and bid2.
To automatically generate test input data suites for scenar-ios, we implemented a test input data generation algorithm
named GenTestInputData as depicted in Algorithm 2 The following describes in details of GenTestInputData.
GenTestInputData takes as input: paths, the set of
con-strained use case scenarios, CD, a UML class model which models domain concepts of the system, CONF, a configuration file that contains internal states of the system, OMp, an object diagram of CD which captures internal states of the system be-fore the use case is executed The output of GenTestInputData
Trang 5Algorithm 2: GENTESTINPUTDATA
1 GenTestInputData(paths, CD, CONF, OMp)
Input: paths, a set of use case scenarios;
CD, the class diagram of system domain concept;
CONF, the configuration file; OMp, objects of internal system states;
Output: TCs, a list of pairs <scenario, EVObjects>
2 BEGIN
3 foreach sc in paths do
4 EV← processScenario(sc); CM ← combine from EV and CD;
5 INVs←all Preconditions of actions in sc;
6 OMf← OCLSolver(CM, CONF, INVs, OMp);
7 a← finds the first action in sc that is SystemState or SystemInclude or SystemExtend and has
PostCondition
8 while (a <>null) and ( ∃ an action affter a that has preconditon) do
9 OMp← Combine values of inputs that are entered before a from OMf and new internal states
of the system ;
10 OMf← OCLSolver(EV, CD, INVs, OMp);
11 a← finds the next action in sc that is SystemState or SystemInclude or SystemExtend and
has PostCondition ;
12 TCs← TCs ∪ <sc, get Objects of EV from OMf>;
13 END.
14 Function processScenario(sc)
15 Output: EV, a class captures test input variables in test steps of a scenario
16 sc, its OCL expressions was replaced by new variable names.
17 foreach a in sc do
18 Create class EV;
19 if a is ActorAction then processAction(a, EV) ;
20 else if a is SubSenario then
21 foreach sa in a do
22 if sa is ActorAction then processAction(sa, EV);
23 return EV
24 End;
25 Procedure processAction(a, EV)
26 ord← the iteration order of a in sc ;
27 if ord >0 then
28 for p in a.getParameter() do
29 if isOutParam(p) then
30 CreateAttributeEV(p,ord, EV); na← a ;
31 ReplaceOCL(na,p,ord,"post");
32 while true do
34 if !isEqual(na,a) then ReplaceOCL(na,p,ord,"all");
35 else ReplaceOCL(na,p,ord,"pre"); break;
36 if isFinalNode(na) then break;
37 else
38 for p in a.getParameter() do
39 if isOutParam(p) then CreateAttributeEV(p,ord, EV);
40 End;
is a list of pairs <scenario, EVObjects> Each pair includes a
constrained use case scenario scenario and objects of EV Each
object of EV is a test input data suite of scenario.
GenTestInputData browses scenarios in paths and generates
test input data suites for each scenario With each scenario,
GenTestInputData creates a class EV and replaces input
variable names in Constraints’ OCL expressions of the
scenario, combines EV with CD to generate class model CM,
derives and combines all precondition of actions to create the
file INVs, and then calls procedure OCLSolver(CM, CONF,
INVs, OMp) to solve constraints It brings out a object diagram
OMf which includes objects of OMp and identified new
objects of EV Returned OMf satisfies constraints in INVs.
However, the use case scenario sc can have some actions
which change the internal states of the system Hence, the
values of inputs which are entered after these actions must
be reidentified These values depend on new internal states of
the system and values of inputs that were entered before each
action The While loop at line 8 executes to resolve constraints
in INVs for each action that changes the internal states of the
system It finds new values for input variables that are entered
after the action changing the internal states of the system
These new values of input variables combine with values of
inputs that are entered before the action and new internal states
of the system to satisfy constraints in INVs.
Each object of EV in OMf corresponds to a test input data
suite of the scenario Identified objects of EV from the object
diagram OMf and the use case scenario sc are then pushed in the list TCs.
Example VI.2 When algorithm GenTestInputData generates test input data suites for the use case scenario sc4, results are
returned as follows
The created class EV is EV(bcid, bid1, bid2).
The created file INVs includes constraints as follows:
context EV inv g1: BookCopy.allInstances()->exists(b:BookCopy|b.bcid=bcid) inv g4: (bid1=”) or (Borrower.allInstances()->exists(b:Borrower|b.bid=bid1)=false) inv g3: Borrower.allInstances()->exists(b:Borrower|b.bid=bid2)
inv g5:BookLoan.allInstances()->exists(l:BookLoan|(l.bid=bid2)and(l.payed=0))=false
Two objects of EV can be identified: ev1(‘bc_01’, ‘’,
‘b_02’), ev2(‘bc_03’, ‘b_03’, ‘b_02’)
C Generation of a TCSL model
The main purpose of the TCSL is to provide notations for reusable test cases, that are understandable for non-technical stakeholders and precise enough for the system testing Hence, USLTG transforms the generated use case scenarios and test data suites into a TCSL model
1 GenTCSLModel(TCs) Input: TCs, a list of pairs <scenario, EVObjects>
Output: TCSL, a TCSL model
2 BEGIN
3 Create a TCSL model;
4 for sc in TCs do
5 Create a Test scenario;
6 Transform sc[0].preCondition to precondition of the test scenario ;
7 Transfrom sc[size()-1].postCondition to postcondition of the test scenario;
8 a=sc[1];
9 while a is not FinalNode do
10 if a is Action then MapAction(a) ;
11 else if a is ForkNode then
12 Create StepConection CF; CF.type← fork; CF.source ← Step was created before a;
13 Create StepConection CJ; CJ.type← join; a ← next a;
14 while a is not JoinNode do
15 foreach sa in a do MapAction(sa) ;
16 CF.target← CF.Taget ∪ the firt step is created from sa;
17 CJ.source← CJ.source ∪ the last step is created from sa; a ← next a;
18 CJ.Target← the first step is created after JoinNode;
19 a← next a;
20 END.
21 Procedure MapAction (sc, a)
22 if a is ActorAction then
23 Create TestSteps from a;
24 for i=0; i<TC[sc].size();i++ do Create DataCase from TC[sc][i] ;
25 if a is SystemAction then
26 if a is SystemExtend or SystemInclude then Create InvokeStep from a ;
27 else if a has postCondition then
28 Create checkPoints from a;
29 for i=0; i<TC[sc].size();i++ do
30 pc← a.postCondition that its input variables is replaced by values in TC[sc][i];
31 Create DataCase from pc;
Algorithm 3 shows algorithm GenTCSLModel to transform
generated use case scenarios and test data suites into a TCSL mode Particularly, a use case scenario is mapped to a test scenario The Constraints of the InitialNode and the
postcon-dition of the test scenario, respectively An ActorAction
is mapped to TestSteps which correspond to parameters
of the ActorAction Values of input variables which are
entered by the ActorAction in Objects of EV are mapped
to DataCases of the TestSteps A SystemAction that
is a SystemInclude or a SystemExtend is mapped
to an InvokeStep A SystemAction that is not a
post-condition is mapped to a CheckPoint With each
ob-ject EV, input variables in the SystemAction’s
Trang 6postcon-dition expression are replaced by their values in the
ob-ject EV, then the postcondition expression is mapped to
a DataCase of the CheckPoint as an expected
out-put Each pair of a ForkNode and a JoinNode are
mapped to a StepConection that its type is fork and a
StepConectionthat its type is join, respectively.
TCSL model that contains two test cases corresponding to
the scenario sc4.
Figure 4 shows the architecture of a USLTG tool that
realises our method The input of the USLTG tool is a USL
model, a conceptual class model, and current states of the
system The output of the USLTG tool is a TCSL model To
develop USLTG tool, we implement two Modules (1) and (2)
and use Module (3) Module (1) is implemented by an Acceleo
project Acceleo is a model transformation language M2T of
the Eclipse framework [15] Module (2) is implemented by a
Java class Module (3) is an OCL solver which USLTG uses
to solver OCL constraints This solver is the use case partial
solution completion of the OCL Analysis tool It is a plugin on
the tool USE and was developed by Gogolla and Hilken [16]
Fig 4 The architecture of USLTG
The test case generation with the tool is carried out as
follows Module (1) reads the USL model and the UML class
model then it passes these models for Module (2) Next, two
algorithms GenScenarios and GenTestInputData in Module (2)
generate constrained use case scenarios and test input data
suites To generate test input data suites, algorithm
GenTestIn-putData reads the current internal states of the system and
calls Module (3) to solve OCL constraints The results of
Module (2) are returned for Module (1) Finally, algorithm
GenTCSLModel in Module (1) transforms the returned results
from Module (2) into a TCSL model
DISCUSSION
We used the tool to generate system test cases for the use
case Lend book It generated eight test cases from the USL
model of this use case These test cases are combined from
five generated test scenarios and eight generated test input data
suites The generated test cases contain concurrent actions, test
steps performed by actors, checkpoints and a relation extend
with test cases of the use case Search book These test cases
reached an activity path coverage criterion which is used for
both loop testing and concurrency among activities of activity
diagrams [17] However, this tool exists some limitations, such
as the configuration file, and new internal states of the system are given manually In the future, we will additionally develop
a feature that allows updating new internal states based on postcondition of actions
In this paper, we have introduced a method to automatically generate the executable system test cases from use cases which are captured by USL models The generated system test cases are precisely specified by a TCSL model and contain necessary information for a KDTF which can run case tests directly We also developed a support tool to realize our method
As a part of our future work, we will focus on perfecting our proposal and presenting details of our method evaluations with larger case studies
REFERENCES
[1] M Utting and B Legeard, Practical Model-Based Testing: A Tools
Approach. San Francisco, CA, USA: Morgan Kaufmann Publishers Inc., 2007.
[2] R Prasad MG, Learning Selenium Testing Tools - Third Edition:
Raghavendra Prasad MG: 9781784396497: Amazon.com: Books Packt
Publishing Ltd, 2015, no 3rd.
[3] C Wang, F Pastore, A Goknil, L Briand, and Z Iqbal, “Automatic
Generation of System Test Cases from Use Case Specifications,” in Proc.
Int Symposium Conf Software Testing and Analysis (ISSTA). ACM,
2015, pp 385–396.
[4] E Sarmiento, J C S do Prado Leite, E Almentero, and G S Alzamora, “Test scenario generation from natural language requirements
descriptions based on petri-nets,” Electr Notes Theor Comput Sci., vol.
329, pp 123–148, 2016.
[5] J J Gutiérrez, M J Escalona, M Mejías, and J Torres, “An approach
to generate test cases from use cases,” in Proc 6th Int Conf Web
Engineering (ICWE). ACM, 2006, pp 113–114.
[6] S Tiwari and A Gupta, “An approach of generating test requirements
for agile software development,” in Proc 8th India conf Software
Engineering (ISEC). ACM, 2015, pp 186–195.
[7] C Nebut, F Fleurey, Y Le Traon, and J.-M Jezequel, “Automatic Test
Generation: A Use Case Driven Approach,” IEEE Trans Softw Eng.,
vol 32, no 3, pp 140–155, 2006.
[8] J Gutiérrez, G Aragón, M Mejías, F J D Mayo, and C M R Cutilla, “Automatic Test Case Generation from Functional Requirements
in NDT,” in Proc Int Conf Current Trends in Web Engineering (LNCS
7703 ). Springer, Berlin, Heidelberg, 2012, pp 176–185.
[9] T Straszak and M ´Smialek, “Automating acceptance testing with tool
support,” in Proc Federated Conf Computer Science and Information
Systems, 2014, pp 1569–1574.
[10] M.-H Chu, D.-H Dang, N.-B Nguyen, M.-D Le, and T.-H Nguyen,
“USL: Towards Precise Specification of Use Cases for Model-Driven
Development,” in Proc 8th Int Conf Information and Communication
Technology (SoICT), 2017, pp 401–408.
[11] I Jacobson, “Object-oriented Development in an Industrial
Environ-ment,” in Proc Conf Object-oriented Programming Systems, Languages
and Applications (OOPSLA). ACM, 1987, pp 183–191.
[12] “ISO/IEC/IEEE International Standard - Systems and software
engineer-ing – Vocabulary,” ISO/IEC/IEEE 24765:2010(E), pp 1–418, 2010.
[13] J Heumann, “Generating test cases from use cases,” Rational Software, Tech Rep., 2001.
[14] Mercury, QuickTest Professional User’s Guide, ser 6.5. Sunnyvale,
CA 94089 USA: Mercury Interactive Corporation, 2003.
[15] C Guindon (Webdev), “Eclipse Acceleo,” 2013 [Online] Available: projects.eclipse.org
[16] M Gogolla and F Hilken, “Model validation and verification options in
a contemporary uml and ocl analysis tool,” in Proc Modellierung, 2.-4.
März 2016, Karlsruhe.
[17] P E Patel and N N Patil, “Testcases Formation Using UML Activity
Diagram,” in Proc Int Conf Communication Systems and Network
Technologies, 2013, pp 884–889.