Techniques to Generate UTP-based Test Cases from Sequence Diagrams Using M2M (Model-to-Model) Transformation

Transcription

1 Techniques to Generate UTP-based Test Cases from Sequence Diagrams Using M2M (Model-to-Model) Transformation Yongjin Seo Dept. of Computer Science & Engineering Chungnam National University Eun Young Cheon Dept. of Computer Science & Engineering Chungnam National University Jin-A Kim Satreci Abstract In order to conduct model based testing of sequence diagrams, test cases should be automatically generated from sequence diagrams. To this end, the scenarios expressed by the sequence diagrams are identified and paths that satisfy the test coverage are extracted to generate test information. However, since sequence diagrams express loop, optional, and alternative information using combined fragments, an automatic generation of test cases from sequence diagram is complicated. To solve this problem, in this paper, a model transformation process that transforms from sequence diagrams into activity diagrams is defined, the scenarios of sequence diagrams are represented in the form of control flows by the transform process. Next, test coverage is applied to generate test cases. The process to generate test cases from sequence diagrams is shown through case studies. Keywords model-based testing; model transformation; test case; UML testing profile I. INTRODUCTION Model-based testing is a testing technique that automatically generates test cases from behavioral models derived from requirements to verify whether a system operates in compliance with the requirements[1]. Model-based testing has advantages such as flexibility in the generation of test cases and easiness in the management of traceability between test cases and requirements. Meanwhile, behavioral models used in modelbased testing are those that show the intended behavior of systems under test (SUT) in standardized forms such as sequence diagrams, state diagrams, and Petri-nets[2]. However, if diverse behavioral models are used, the advantages of model-based testing cannot be magnified because each behavioral model uses a different generation method of test cases and the different method generates a different form of test cases. The biggest problem is that to express various viewpoint of software, diverse behavioral models should be used in general. For this reason, the advantages of model-based testing Hyeon Soo Kim Dept. of Computer Science & Engineering Chungnam National University hskim401@cnu.ac.kr enumerated above cannot be easily realized. To solve this problem, the same test case generation procedure and form should be provided regardless of the types of tests. In this paper, to provide such a method, UTP (UML Testing Profile)[3] based test cases are generated. UTP is intended to express test related information in the same method as UML (Unified Modeling Language)[4] and enables expressing test cases as models. Generating UTP-based test cases enables the application of methods of generating output models (UTP-based test cases) from input models (behavioral model). That is, we have the same test case generation procedure and form by using model transformation techniques[5]. In this study, a method of generating test cases from sequence diagrams is presented. A sequence diagram is a model that can effectively express an individual scenario and is utilized to realize a use case specification[4]. Sequence diagrams provide methods of describing the forms of interactions and information exchanges between objects. That is, sequence diagrams include information such as system operation scenarios and the kinds of information exchanged at each operation. These information are useful in the generation of system-level test cases. For this reason, in this study, test cases will be generated from sequence diagrams. Since multiple scenarios can be expressed by the combined fragments added in UML 2.0, a process to extract unit paths is additionally necessary. However, scenarios expressed by the combined fragments are not appropriate forms to extract paths. To solve this problem, in this study, a method is suggested that generates test cases after conducting an intermediate transformation from a sequence diagram to an activity diagram. Since this process is also implemented through a model transformation technique, the entire test generation procedure is not affected by this process. The process has advantages such as /16/$31.00 copyright 2016 IEEE ICIS 2016, June 26-29, 2016, Okayama, Japan

2 enabling the automation of test case generation, making test case preparation easy, and increasing the reusability of test cases. II. RELATED STUDIES Papers [6] and [7] suggest ways to derive the scenarios of sequence diagrams and to generate test cases from the scenarios in order to generate scenario-based test cases from UML sequence diagrams. Paper [6] defines Concurrent Control Flow Graphs that reflect parallelism in order to identify the scenarios of sequence diagrams. Based on the foregoing, the grammar necessary to extract possible paths is defined to derive the subsets of CCFGs that correspond to individual paths. Although this method has an advantage of being capable of deriving the scenarios of sequence diagrams considering the parallelism of sequence diagrams, it has a disadvantage that many overlapping paths may occur in one test case as a results so that test cases may become complicated. In addition, since test cases appear in the form of CCFGs, information applied to actual test cases should be additionally derived. Meanwhile, paper [7] defines Sequence Diagram Graphs (SDGs) in the form of state diagrams to express the scenarios of sequence diagrams. SDGs define each state as a set of messages, objects that sent messages, and objects that receive the messages. Based on the foregoing, test algorithms are presented to derive test cases from SDGs. This method has a disadvantage of determining iterative flows and branching flows with only messages constraints without considering the combined fragments of sequence diagrams. In addition, papers [6] and [7] require efforts to additionally prepare individual scenario expression models in order to generate scenario based test cases from sequence diagrams. Unlike the existing methods, in this study, the activity diagram in UML 2.0 is used to express the scenarios of sequence diagrams and the scenarios are automatically expressed as activity diagrams through M2M transformation. In addition, test cases are expressed as UTP models so that the entire process to generate test cases is implemented through M2M transformation. III. MODEL TRANSFORMATION FOR THE GENERATION OF TEST CASES FROM SEQUENCE DIAGRAMS In this paper, a model transformation process as shown in Fig. 1 is proposed to automatically generate test cases from sequence diagrams. Fig. 1. Model Transformation Process for Test Case Generation A sequence diagram is transformed into an activity diagram. The activity diagram expresses scenarios included in the sequence diagram. The activity diagram is fragmented so that the fragmented activity diagram has a unit activity. Each fragmented activity diagram is utilized as a test scenario. The fragmented activity diagram is transformed into UTP-based test cases. To implement the above process, the model transformation rules necessary in each stage should be defined. In the case of the first and third stages, the rules can be defined by mapping between model elements, and in the case of the second stage the transformation rules are defined by fragmentation algorithms. A. Sequence diagram activity diagram transformation In this section, the rules for transforming a sequence diagram into an activity diagram are presented. The reason why sequence diagrams are transformed into activity diagrams is that extracting single paths from a sequence diagram is not easy. The rules for transformation of a sequence diagram into an activity diagram are as shown in Table 1. TABLE I. TRANSFORMATION RULES FROM SEQUENCE DIAGRAM TO ACTIVITY DIAGRAM # Source Target R1 InteractionFragment Activity R2 R3 R4 Incoming Message (from Actor) Outgoing Message (to Actor) SendEvent & RecieveEvent <<Control>> <<Observe>> ControlFlow R5 CombinedFrament (loop) Decision R6 CombinedFrament (alt/opt) Decision Table 1 shows the mapping relationships between the elements of sequence diagrams as source models and the elements of activity diagrams as target models. Fig. 2 shows how each element is mapped in actual diagrams. In addition, the diagram shown in Fig. 2(a) is transformed into the diagram shown in Fig. 2(b) through the transformation rules. On reviewing Fig. 2, it can be seen that the combined fragments of the sequence diagram are transformed into the DecisionNodes (R5, R6) of the activity diagram and that the control flow of the activity diagram is determined by the kinds of combined fragments. In addition, not all the messages of the sequence diagram were expressed in the activity diagram but only useful messages were represented as the nodes of the activity diagram (R2, R3). That is, only those messages that occurred between system under test (SUT) and external elements (user, external systems, etc.) were expressed in the activity diagram. In addition, messages were represented as stereotypes according to their directions. Messages coming in from external elements can be utilized as test data (R2). Messages going out to external elements can be utilized as log messages and test verdicts for identifying test results (R3). B. Activity diagram fragmentation This section performs the process that fragments the activity diagram so that the fragmented activity diagram has a single path. The reasons why activity diagrams are fragmented are as follows. First, a test case can verify only single behavior. Therefore, in order to generate such a test case, the complicated execution paths of software should be separated into multiple unit paths. Second reason is to simplify the test case generation process. The second and third stages in Fig. 1 are stages for test cases generation. As mentioned earlier, the two stages have

3 different forms of transformation rules. Combining different forms of transformation rules into one and implementing it is very difficult problem. Since the fragmented diagram has only sequential flows, this makes the test case generation process simpler. For such reasons, the unit paths of an activity diagram are derived through the fragmentation. Fig 3 shows a fragmentation method for an activity diagram. Fig. 2. Activity Diagram Fragmentation Algorithm The algorithm shown in Fig. 3 generates activity diagrams that have unit paths by pruning some paths in activity diagrams. That is, this algorithm removes the and ControlFlow of remaining paths so that only one path is left out of many paths. By using this method, unit paths can be extracted using only those DecisionNodes that constitute activity diagrams. Therefore, to implement this method, prospective paths to be removed should be derived first from all DecisionNodes of activity diagrams. Since prospective paths to be removed vary with the activities of DecisionNodes, the activities of DecisionNodes should be identified before extracting the prospective paths to be removed. Lines 7~17 are subjected to this process when their DecisionNodes have branching flows. In the case of DecisionNodes that have branching flows, each path that contains the OutgoingEdge of them becomes a prospective path to be removed. Line 5 is subjected to this process when its DecisionNode has iterative flows. In cases where a DecisionNode has iterative flows, the paths are divided into those that circulate in the iterative statement (TrueEdge) and those that do not do so (FalseEdge). However, since the paths should pass the FalseEdge even when they circulate in the iterative statement, paths that include any False Edge are not included in prospective paths to be removed. Since the number of paths is derived through combinations with other DecisionNodes instead, empty sets are included in prospective paths to be removed in order to meet the number of cases. Based on the foregoing, individual DecisionNode D can be expressed as shown by Eq. 1. (1) Where, n refers to the kinds of DecisionNodes. Selection refers to branching and iteration refers to repetition. Path refers to a set of prospective paths to be removed. refers to the ControlFlow where a prospective path to be removed begins and refers to the ControlFlow where the prospective path ends. Lines 5 and 17 indicate the addition of prospective paths to be removed derived from individual DecisionNodes based on the above contents. When all prospective paths to be removed have been extracted from all DecisionNodes, sets of prospective paths to be removed are composed through the content of line 20. The on line 20 operates in the following manner. (2) In Eq. 2, refers to sets consisting of subsets of Paths of size k. The reason why prospective paths to be removed are derived in a separate method when DecisionNodes have branching flows is that those DecisionNodes may have two or more OutgoingEdges. If a DecisionNode has three Outgoing Edges, two prospective paths to be removed should be removed at a time. If simply calculated with, accurate results cannot be obtained in situations mentioned above. Therefore, the method as shown by Eq. 2 is used. Fragmented activity diagrams can be obtained by applying the sets of prospective paths to be removed obtained through line 20 to activity diagrams. To help the understanding of the algorithm operation, the fragmentation process is explained through the activity diagram in Fig. 4. First, two DecisionNodes exist in the relevant activity diagram and this can be expressed by Eq. 1 as follows: Since the first DecisionNode has iterative flows and is included in the TrueEdge, prospective paths to be removed are. Since the second DecisionNode has branching flows, paths that include OutgoingEdges were included in prospective paths to be removed. Thereafter, combinations of prospective paths to be removed are composed. By Eq. 2, the example in Fig. 4 is calculated as follows: By applying the derived results to the activity diagram shown in Fig. 4, four paths can be obtained. The paths can be expressed as follows in the order of ControlFlows:

4 Since and out of the above results have the same path, it can be seen that three paths are finally derived. In this way, fragmented activity diagrams can be obtained through the algorithm shown in Fig. 3. Fig. 3. Example Activity Diagram Since test cases are expressed as TestContext Operations in UTP, the number of test cases can be expressed through the number of Operations in the TestContext. Since those test cases that are generated through sequence diagrams are mainly used in tests in the system-level, the SUT are systems or single applications. Since this is equally applied to all applications, the transformation rules were defined in the form such as R10. TABLE III. TRANSFORMATION RULE FROM ACTIVITY DIAGRAM TO TEST CASE # Source Target R7 Activity InteractionFragment R8 R9 <<Control>> <<Observe>> Incoming Message (from TestContext) Outgoing Message (to TestContext) R10 - TestContext SUT C. Activity diagram UTP test case transformation In this section, model transformation rules for generation of test cases from the fragmented activity diagrams generated as explained in section B are presented. The test cases generated here conform to UTP. To prepare UTP-based test cases, the UTP elements listed in Table 2 are used. UTP Element TABLE II. TEST CASE ELEMENTS OF UTP Description The behavioral models are prepared based on the Test Behavior package of UTP and the operations of test cases as the Operations of TestContext are described. The model on the bottom of Fig. 5(b) corresponds to behavioral models. This model should include the time point of test data inputs and contents for test judgment. The behavioral models are composed in sequence diagrams mainly with interactions between TestContext and SUT. Among the nodes of activity diagrams, <<Control>> stereotyped nodes correspond input values and are expressed as messages from TestContext to SUT (R8). Among the nodes of activity diagrams, <<Observe>> stereotyped nodes correspond output values and are expressed as messages from SUT to TestContext (R9). Based on the contents as such, transformation rules for generation of UTP-based test cases from activity diagrams can be expressed as shown in Table 3 and examples of transformation can be seen through Fig. 5. Fig. 4. Transformation Example from Activity Diagram to Test Case TestContext SUT A test context acts as a grouping mechanism for a set of test cases The system under test (SUT) is a part of a test context. It refers to a system, subsystem, or component that is being tested. TestCase A specification of one specific case to test the system UTP-based test cases are described through structural models and behavioral models. The structural models are prepared based on the Test Architecture package of UTP and the following information are described; the number of test cases, Systems Under Tests (SUT), the form of test data, etc. The model on the top of Fig. 5(b) corresponds to structural models. IV. APPLICATION EXAMPLES In this section, examples of generation of test cases from actual cases through the transformation rules presented in section III are introduced. The target application [8] is a system that has functions to monitor and control the distributed entities. The target system has a total of 64 sequence diagrams and a total of 160 test cases were derived from the sequence diagrams. In this study, the behavior of the system that must be identified to

5 conduct system tests with the derived test cases were figured out and test environments for the tests were constructed. The environments where the tests were conducted are as shown in Fig. 6. Among diverse test cases, those test cases that were derived from the sequence diagram in Fig. 7 are as shown in Fig. 9. Fig. 7 shows a sequence diagram related to the control function to execute the entities and the activity diagrams derived from the sequence diagram are as shown in Fig. 8. A UTP-based test case derived through one path in the activity diagram in Fig. 8. V. CONCLUSION In this study, model transformation processes to generate test cases from sequence diagrams and model transformation rules for execution of model transformation were proposed. Unlike the existing studies, the complication of test case generation was reduced through intermediate transformation from sequence diagrams into activity diagrams and test case generation through model transformation was enabled by using test cases in the form of UTP. In this study, the fact that test cases were generated through the presented model transformation rules was identified through case studies. Future studies are to present transformation rules for application of diverse test coverages to activity diagrams and implement tools to automate the generation of test cases from sequence diagrams. Fig. 5. Sequence Diagram of Target System (Execution managed object)

6 Fig. 6. Activity Diagram of Target System Fig. 7. Test Case of Target System ACKNOWLEDGMENT This research was supported by Basic Science Research Program through the National Research Foundation of Korea(NRF) funded by the Ministry of Education, Science and Technology(No. NRF-2013R1A1A ). This research was supported by NSL(National Space Lab) program through the National Research Foundation of Korea funded by the Ministry of Education, Science and Technology ( ). REFERENCES [1] M. Utting, B. Legeard, Practical model-based testing: a tools approach, Morgan Kaufmann, [2] H. S. Chae, "Model-based Test - Concepts and Issues, Communications of KIISE, Vol. 31, No. 4, pp , Apr [3] OMG, UML Testing Profile (UTP), /1.2/PDF, [4] OMG, Unified Modeling Language (UML), UML/2.5/PDF, [5] T. Mens, P. V. Gorp, "A taxonomy of model transformation," Electronic Notes in Theoretical Computer Science, Vol. 152, pp , Mar [6] V. Garousi, L.C. Briand, Y. Labiche, "Control flow analysis of UML 2.0 sequence diagrams," Model Driven Architecture Foundations and Applications, Springer Berlin Heidelberg, [7] M. Sarma, D. Kundu, R. Mall, "Automatic Test Case Generation from UML Sequence Diagrams," Proc. of the 15th International Conference on Advanced Computing and Communications, pp , [8] B. Min, H. S. Kim, S. Kuk, S. W. Park, C. Kim, Dynamic Reconfigurable Integrated Management and Monitoring System for Heterogeneous Distributed Computing Systems, 2012 IEEE International Symposium on Signal Processing and Information Technology (ISSPIT), pp , 2012.