A Novel Approach for Test Case Generation Using Activity Diagram

International Journal Of Computer Science And Applications Vol. 1, No. 1, June 2008 ISSN 0974-1003 A Novel Approach for Test Case Generation Using Activity Diagram Pragyan Nanda Baikuntha Narayan Biswal Durga Prassad Mohapatra Department of Computer Science Department of Computer Science Department of Computer Science and Engineering, National Institute of and Engineering, National Institute of and Engineering, National Institute of Technology, Rourkela Technology, Rourkela Technology, Rourkela [email protected] [email protected] [email protected] ABSTRACT 1 INTRODUCTION Testing is an important part of quality assurance in the software Testing remains, the most important part of quality assurance in development life cycle. As the complexity and size of software the practice of software development. Quality of the end product grow, more and more time and man power are required for testing and effective reuse of software depend to a large extent on testing. the software. Manual testing is very much labor-intensive and Developers therefore spend considerable amount of time and error-prone. So there is a pressing need to develop the automatic effort to achieve through testing. It is well known that software testing strategy. Test case generation is the most important part of testing is a time-consuming, error-prone and costly process [3] the testing efforts. Test cases can be designed based on source [9]. Therefore, techniques that support the automation of software code but this makes test case generation difficult for testing at testing will result in significant cost and time savings for the cluster level. Therefore, it is required to generate test cases software industry. Automatic generation of the test cases is automatically from the design documents. Also this approach essential for the automation of software testing. Once the test holds an added advantage of obtaining test cases early in the cases are generated automatically, a software product can even be software development life cycle (SDLC), there by making test tested fully automatically through a test execution module to planning more effective. Our approach first constructs the activity realize an integrated automated test environment. diagram for the given problem and then randomly generates initial Generally test cases are designed from program source code [4]. test cases, for a program under testing (PUT). Then, by running This makes test case generation difficult especially for testing at the program with the generated test cases, we can get the cluster levels. Further this approach proves to be inadequate in corresponding program execution traces (PET). Next, we compare component–based software development, where the source code these traces with the constructed activity diagram according to the may not be available with the developers. Therefore generation of specific coverage criteria. We use a rule based frame work to test cases automatically from the software design documents are generate a reduced test case set, which meets the test adequacy essential rather, than code or code-based specifications. It also criteria. Advantage of our approach is that it achieves maximum holds the added advantages of allowing test cases to be available path coverage. early in the software development life cycle (SDLC) there by making test planning more effective. Again, design oriented Categories and Subject Descriptors approach tests the generated test data which is independent of any D.2.5 [Software Engineering]: Testing and debugging-Testing particular implementation of the design. tools. In this paper, we use UML activity diagrams as design specifications and consider the automatic approach to test case General Terms generation by extending [1]. Classification of UML diagrams, Reliability depending on whether they are intended to describe the structural or behavior aspects of systems. UML activity diagrams [11, 12] Keywords describe the sequential or concurrent control flow of activities. UML Activity diagram, Test case, Program under testing, They can be used to model the dynamic aspects of a group of program execution traces, Software testing, Rule based frame objects, or the control flow of an operation. Our approach first work. constructs the activity diagram for the given problem and then randomly generates the initial test cases for a program under testing (PUT) [6]. The approach is to develop a technique that will automatically generate test cases with maximal path coverage. Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are The rest of the paper is organized as follows. Section 2 illustrates not made or distributed for profit or commercial advantage and that copies the UML activity diagram. Various test adequacy criteria are bear this notice and the full citation on the first page. To copy otherwise, described in section 3. Section 4 presents our approach to or republish, to post on servers or to redistribute to lists, requires prior generate test cases from the activity diagram using a rule based specific permission and/or a fee. frame work. Section 5 presents the Future work and conclusion. © Copyright 2008 Research Publications, Chikhli, India Published by Research Publications, Chikhli, India 60 International Journal Of Computer Science And Applications Vol. 1, No. 1, June 2008 ISSN 0974-1003 2 ACTIVITY DIAGRAM marked in the activity diagram, we mark all the UML provides a number of diagrams to describe particular corresponding unmarked transitions of pet and record aspects of software artifacts. These diagrams can be classified the test case t. So, the value of transition coverage is the depending on whether they are intended to describe structural or ratio of the marked transitions to all transitions in the behavioral aspects of systems. Activity diagrams also describe the activity diagram. sequence of activities among the objects involved in the control x Path coverage: All paths in the activity diagram must flow during implementation. Activity diagrams are similar to be covered. For any t  tcs, we can obtain the program procedural flow charts. But the major difference between them is execution trace pet. If there exists any function in pet that activity diagrams support description of parallel activities and whose corresponding path is not marked in the activity synchronization aspects involved in different activities. Before diagram, we mark all the corresponding unmarked path presenting the detailed procedure to generate test cases using of pet and record the test case t. So, the value of path UML activity diagram, we need to define the activity diagram. coverage is the ratio of the marked paths to all paths in Definition. An activity diagram is a eight-tuple ACD = (A, B, F, the activity diagram. J, K, T, C, a0), where x . A = {a1, a2, …, an} is a finite set of activity states. x . B = {b1, b2,..., bm} is a finite set of branches. x . F = {f1, f2, …, fq} a finite set of forks. x . J = {j1, j2, ..., jr} a finite set of joins. x . K = {k1, k2, ..., kp} a finite set of final states and end flows. x . T = {t1, t2, ..., ts} a finite set of transitions and ts T x . C = {c1, c2, ..., cv} is a finite set of guard conditions. x . a0 is the only initial state and a0.  A The above descriptions are shown in figure.1. 3 TEST ADEQUACY CRITERIA FOR ACTIVITY DIAGRAMS Problem specification is the key factor to get the result accurate, which is very much important. Therefore, there is a pressing need for specification of test adequacy criteria, before going to follow the software testing procedure. The adequacy criteria of activity diagrams are based on the matching between the paths of activity diagrams and program execution traces of the implementation codes. Figure.1 Activity diagram The description about test adequacy is given in [5, 6] as a measurement function. Suppose the p is a program, and tcs be the test cases set. The test adequacy criteria, to generate test cases for 4 HEURISTIC METHOD an activity diagram are given below: In this section we discuss our work to generate test cases automatically from UML activity diagram. First, we construct the x Activity coverage: According to this, all activity states activity diagram for the given problem. Though, we are using in the activity diagram should be covered. For any t  UML activity diagram to generate the test cases, but not directly. tcs, we can get the program execution trace pet. If there An indirect approach is being used for automatic generation of exists any function in pet whose corresponding activity test cases. Next, we use a randomly generated test case [8] as the is not marked in the activity diagram, we mark all the initial test case is to get the program execution traces for a corresponding unmarked activities of pet and record the program under testing (PUT). Then by applying a. “heuristic test case t. So, the value of activity coverage is the ratio rule” we get the best test case. At last, by comparing the of the marked activities to all activities in the activity execution traces with the constructed activity diagram satisfying diagram. some specification criteria, we get the reduced test cases which meet the test adequacy criteria. x Transition coverage: All transitions in the activity diagram must be covered. For any t  tcs, we can get the program execution trace pet. If there exists any 4.1 Frame work function in pet whose corresponding transition is not The schematic outline of the automatic test case generation strategy is described in figure.2. Published by Research Publications, Chikhli, India 61 International Journal Of Computer Science And Applications Vol. 1, No. 1, June 2008 ISSN 0974-1003 start <a0>, <a1>, < a1 > < a2 >, < a2 > <a3 >, < a2 > <a4 >, < a3> <a8 >, <a8 > <a9 >, <a4 > <a5, a6 >, < a5, a6 > <a7 >, <a7 > <a9 > end We have considered simple path to avoid the complexity due to loops and concurrency, which is beyond the scope of the discussion. 4.3 Test case generation strategy We use the heuristic rule to achieve the maximal branch coverage. A branch coverage analysis is required to get the best test case (BCASE). The path coverage analysis follows the path prefix strategy of Prather and Myers [7]. When a path is found, we should delete this path from the path coverage set. So the matching process is getting stopped, when the path coverage set is empty. The branch coverage status of the code is recorded in a Figure 2: System model coverage table. When a branch is covered by any test case, the corresponding entry in the table is marked with a “”. The target 4.1.1 MODEL PARSER/ SCANNER of the test case generation is to mark all entries in the table. The purpose of the model parser is to keep the path traversal Therefore, the partially covered transitions are the main targets details of the activity diagram. for modification, to cover all paths. The uncovered conditions will not be targeted for new test case generation. Earlier test cases can 4.1.2 TEST CASE GENERATOR be used as models for new cases, because, no test case model yet The test case generator test case generator produces new test exists that can be used for modification. cases that would cover the target branches/conditions in the code The main problem arises to select a model test case when, more from the structure file and determines what conditions/branches than one test case drives the same path. So it is very essential to should be targeted for new case generation identify the goodness of a test case. We define the goodness of a test case as 4.1.3 TEST CASE ANALYZER Test case analyzer evaluates by running each test case in the 1 ^   ` LHS (t1 )  RHS (t1 ) y 2 max LHS (t1 ) , RHS (t1 ) (1) program and maintains a track of condition and branch coverage. n If the test case satisfies the coverage criteria it generates a report where, t1 is a test case, LHS (t1) and RHS (t1) represent the otherwise the analysis result is used by test case generator for evaluated value of LHS and RHS, respectively, when t1 is used as further test case generation. the input data and n is the number of branches covered. Here, we have considered a typical format of an IF-THEN statement where 4.1.4 REPORT GENERATOR: the expression (exp) can be expressed in the form of: The report generator prints the result which includes the generated LHS<op>RHS. The goodness of a test case, t1, relative to a given test cases, condition and branch coverage and percentage of path condition can be calculated using the above formula. This coverage. measures the closeness between LHS and RHS [2]. When this measure is small, it is generally true that a slight modification of t1 may change the truth value of exp, thus covering the other 4.2 Paths in the Activity diagram branch. The measurement of (1) provides the goodness of a test The selection of path coverage in test case generation is a very case which ranges from 0 to 1. A test case that yields the smallest complex task. When a path in the activity diagram is matched, we measurement is considered to be the best test case of the condition delete this path from the path coverage set. Hence the matching under consideration. In the following, we present our algorithm to process for activity diagram will terminate when the path get the reduced test case, which is given in figure.3. coverage set is empty. The algorithm for simple path searching is given in [13]. The complexity in path selection is due to the presence of synchronization, concurrency and loops. Our approach only considers the paths for selecting the program execution traces, which satisfies the semantics of the synchronization such as the join and fork in the activity diagram. Loops in an activity diagram may result in a path with infinite activities. From figure 1, we derived the following paths: Published by Research Publications, Chikhli, India 62 International Journal Of Computer Science And Applications Vol. 1, No. 1, June 2008 ISSN 0974-1003 begin UML, Lecture Notes in Computer Science, Springer-Verlag BCASE = F; //A Boolean variable. GmbH, York, UK, vol.93, 2000, pp. 383-395. Supply AD & RTC to TCG as an I/P; /* RTC is [2] A. Kleppe, J. Warmer, and W. Bast. 2003. MDA Explained: randomly generated test case, AD is activity The Model Driven Architecture–practice and promise. diagram, TCG is test case generator. */ Addison-Wesley, 2003 Execute PUT with RTC to give PET; /* PET is [3] C. Mingsong, Q. Xiaokang, and L. Xuandong. 2006. program execution traces. */ Automatic Test Case Generation for UML Activity Apply heuristic rule to TCG to generate best test Diagrams. AST’06, May 23, 2006, Shanghai, China case; While (Path  empty && BCASE T) { [4] C. Oriat. Jartege. 2005. A Tool for Random Generation of Run TCG}; Unit Tests for Java Classes. In QoSA/SOQUA, pages end; 242–256, 2005. [5] F. Basanieri, A. Bertolino, and E. Marchetti. 2001. CoWTeSt: A Cost Weighted Test Strategy, Proc. Escom- Scope 2001, London, 2001 Figure.3: The Algorithm for Reduced Test Case Generation. [6] Grade Booch, James Rambaugh, Ivar Jacobson. 2001. The Unified Modeling Language User Guide, Addison-Wesley, 5 CONCLUSION AND FUTURE WORK 2001. We have proposed an approach to generate the test cases for object oriented programs from the UML activity diagrams. We [7] H. Zhu, P. Hall, and J. May. 1997. Software Unit Test have used a heuristic rule to obtain the reduced test cases, which Coverage and Adequacy. ACM Computing Surveys, satisfy the test case adequacy criteria. In this paper we have 29(4):366–427, December 1997 considered only the path (simple) for automatic test case [8] H. Zhu and X. He. A Methodology of Testing High-level generation. Our approach achieves the maximum path coverage, Petri Nets.2002. Information and Software Technology, which is an added advantage. Currently, we are working on 44(8):473–489, 2002. developing test cases involving nested fork -joins and branch nested fork-joins. Also it sees very similarity for Model Driven [9] K. H. Chang, W. Homer Carlisle, James H. Cross II, and Architecture (MDA) [10], which is our next prospective. To the David B. Brown. 1991 A heuristic approach for test case best of our knowledge no other paper has discussed the use of generation. ACM. heuristic rule for generating test cases from activity diagram. [10] L. Briand and Y. Labiche. 2002. A UML based approach to system testing. Software and Systems modeling, 1 (1), 2002. 6 ACKNOWLEDGMENTS [11] Object Management Group, UML specification 1.5, We would like to acknowledge the anonymous reviewers for their available at http://www.omg.org/uml, 2003. constructive comments that helped us to improve the quality of [12] R.E. Prather and P. Myers, Jr. 1987. The Path Prefix this paper. Software Testing Strategy, IEEE Trans. on Software Engineering, Vol. SE-13, No. 7, July 1987 7 REFERENCES [13] W. H. Deason, D. B. Brown, K.-H.Chang, and J. H. Cross II. [1] A. Abdurazik, J. Offutt. 2000. Using UML collaboration 1991. A Rule-based Software Test Data Generator, IEEE diagrams for static checking and test generation, in: Trans. on Knowledge and Data Engineering, March 1991. proceedings of the third International Conference on the Published by Research Publications, Chikhli, India 63