2018 10TH INTERNATIONAL CONFERENCE ON KNOWLEDGE AND SYSTEMS ENGINEERING (KSE) A Transformation-Based Method for Test Case Automatic Generation from Use Cases Chu Thi Minh Hue , Dang Duc Hanh, Nguyen Ngoc Binh Department of Software Engineering, VNU University of Engineering and Technology, Hanoi, Vietnam Hung Yen University of Technology and Education, Visiting professor, Hosei University, Japan {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 I NTRODUCTION 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 effectiveness 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 978-1-5386-6113-0/18/$31.00 ©2018 IEEE 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 nontechnical 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: • • • the USLTG method to the system test case automatic generation from use cases; three algorithms to transform use cases into a TCSL 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 II R ELATED WORK We position our work in system test cases automatic generation 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 252 2018 10TH INTERNATIONAL CONFERENCE ON KNOWLEDGE AND SYSTEMS ENGINEERING (KSE) According to our knowledge, these approaches can be grouped into three groups In the first group, system test cases are automatically generated 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 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 III M OTIVATING E XAMPLE AND BACKGROUND 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 CASE Lend book Num Step Librarian selects the Lend-book function Librarian enters a book copy id Librarian enters a borrower id Librarian enters a borrower id Librarian clicks the save-book-loan button The system save the book loan record the system shows a complete message the system prints the borrowing bill Object lendbookF bcid bid bid SaveBLoan BookLoan message bBill Action select enter enter enter click verify verify verify Data “bc_01” “” “b_02” Data “bc_03” “b_03” “b_02” a Book loan is recorded “Book loan save complete” “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 to 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 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 conditions, 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 IV OVERVIEW OF OUR A PPROACH Figure 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 to generate use case scenarios and constraints, Step to generate test input data suites for each test scenario, and Step to generate 253 2018 10TH INTERNATIONAL CONFERENCE ON KNOWLEDGE AND SYSTEMS ENGINEERING (KSE) a TCSL model capturing identified test cases with TCSL A more detailed explanation of these steps is presented in Sect VI cases, TestScenario object captures a test scenario which can include TestSteps, CheckPoints or InvokeSteps, DataCase object captures input data values or expected 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 Overview of the USLTG Approach V R EPRESENTING U SE C ASES AND T EST 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 for the use case Lend book and the TCSL model shown in Fig 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 nontechnical stakeholders The basis for system test cases automatic generation from use cases is the precise specifications of use cases As mentioned 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 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 shows a TCSL model that specifies generated test cases from the use case Lend book It focuses on displaying 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 Fig The USL model of the use case Lend Book VI T RANSFORMING U SE C ASES INTO T EST C ASES This section presents the details of three steps of USLTG as shown in Fig 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 scenarios from a USL mode through a Depth First Traversal (DFT), as shown in Algorithm 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 254 2018 10TH INTERNATIONAL CONFERENCE ON KNOWLEDGE AND SYSTEMS ENGINEERING (KSE) Algorithm 1: G EN S CENARIOS 10 11 12 13 14 GenScenarios(D) Input: D is a USL model Output: paths is a set of constrained use case scenarios returning from D BEGIN pt ← ∅; sc ← ∅; x ← the InitialNode of D; GenerateScenarios(pt,sc,x); Procedure GenerateScenarios (pt,sc,x) prex = the last node in pt; push(pt,x) ; if x is FinalNode then sc ← sc ∪ x; paths ← paths ∪ sc; exit ; if x is DecisionNode then if ∀ e ∈ outGoing(x) was visited then bf ← the BasicFlowEdge in outGoing(x); if ∃ bf then GenerateScenarios(pt, sc, targetNode(bf)); else exit ; else foreach t in outGoing(x) that was not visited ptn ← copy objects from pt; scn ← copy objects from sc; GenerateScenarios(ptn, scn, targetNode(e)); END 15 else if x is ForkNode then 16 sc ← sc ∪ x; jn ← null; allsubSteps ← ∅; allsubpaths ← ∅ ; 17 foreach t in outGoing(x) 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 23 24 25 26 27 28 29 //maxLength(allsubSteps) returns the max size of subpaths in allsubSteps for i=0; iexists(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 Algorithm 3: G EN TCSLM ODEL for p in a.getParameter() if isOutParam(p) then CreateAttributeEV(p,ord, EV); End; is a list of pairs 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 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 10 11 12 13 14 15 16 17 18 19 GenTCSLModel(TCs) Input: TCs, a list of pairs Output: TCSL, a TCSL model BEGIN Create a TCSL model; for sc in TCs Create a Test scenario; Transform sc[0].preCondition to precondition of the test scenario ; Transfrom sc[size()-1].postCondition to postcondition of the test scenario; a=sc[1]; while a is not FinalNode if a is Action then MapAction(a) ; else if a is ForkNode then Create StepConection CF; CF.type ← fork; CF.source ← Step was created before a; Create StepConection CJ; CJ.type ← join; a ← next a; while a is not JoinNode foreach sa in a MapAction(sa) ; CF.target ← CF.Taget ∪ the firt step is created from sa; CJ.source ← CJ.source ∪ the last step is created from sa; a ← next a; CJ.Target ← the first step is created after JoinNode; 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