An Model Based Test Case Generation Technique Using Genetic Algorithms

Transcription

1 Volume 1, No. 9, November 2012 ISSN The International Journal of Computer Science & Applications (TIJCSA) RESEARCH PAPER Available Online at An Model Based Test Case Generation Technique Using Genetic Algorithms V.Mary Sumalatha Research Scholar Gitam University, Visakhapatnam Andhra Pradesh, India Dr G.S.V.P.Raju Professor Andhra University, Visakhapatnam Andhra Pradesh, India Abstract Software testing is one of the main activities to be carried out in the software development life cycle. It consumes more money and time, which leads to automation that reduces the human effort in finding bugs and errors. Automation in the last phase of system development is similar to manual testing. In both cases bugs are detected only after code has been complete. So rectifications and modification of the code takes lot of time. So testing process should be started from the beginning phase of software development life cycle and should continue till the last phase. Three approaches in testing are code based testing, specification testing and model based approach. So we focus on Model Based Approach for automatic test case generation. For this we generate test cases for object oriented software using UML diagrams like Activity diagram. We try to optimize the number of test cases using evolutionary algorithms like genetic algorithm. Keywords- UML, Activity diagrams, Genetic Algorithms, Evolutionary Algorithm, Software Testing, Test case Generation. I. INTRODUCTION TO SOFTWARE TESTING Software testing is a process that is used to validate and verify the developed program to ensure that it satisfies the customers and developers requirements. Software testing is divided into three approaches: blackbox testing, white-box testing and grey box testing. Black-box testing is a testing technique built around the software specifications. Testers determine whether the software functions as defined by the software specifications. On the other hand, white-box testing is a testing technique using source code. It focuses on testing as many parts of the code as possible. Grey-box testing uses a behavioral specification as a source of test data. The behavioral specification is a specification which not only describes what users want from the software, but also defines how to achieve the requirements. Software testing is a verification process which promises the 46

2 software quality assurance. Testing is done to guarantee that developed software is meets customer requirements. Customer requirements are divided into two categories: functional requirements and nonfunctional requirements. Functional requirements concentrate on correctness of software, such as whether software can respond to input properly. Non-functional requirements are concerned with other issues like performance of software, software availability, reliability etc. Functional testing provides a test for functional requirements. Testers must generate data for testing called Test data. Testers can test each requirement of the software using a Test case. A Test case contains its own identification, which is test data for a case or conditions to test, and the expected response, which is called the expected output. A set of test cases is called Test suite. 1.1 Black box testing Black box testing is mainly used for functional testing. Functional testing evaluates the correctness of the program by comparing the needs of users without any knowledge of how the software is implemented. In black box testing, testers test software through user interfaces or the application programming interfaces. The software is successful if the program executes the test cases and returns the expected output. The expected results are stated in the user requirements. In the analysis phase of the software development life cycle, software architects must elicit requirements and transform them into program features that meet customers needs. In the design phase developers receive these requirements and produce design documents for their programmers. A design document is a set of guidelines for testers to create their test cases and the expected results in black box testing. 1.2 White box testing White box testing is testing for all possible coverage paths; i.e. all paths of the program must be tested through some criteria. White box testing aims to qualify a quality of a source code. It qualifies the test suite by coverage criteria. Code coverage criteria is defined using segment coverage, branch coverage, node testing, condition coverage, basis path testing, data flow testing, path testing and loop testing. The test procedure attempts to execute every part of the source code using the test data. The more test cases are generated, the more coverage is gained. 1.3 Grey box testing Grey-box testing is a combination of black box-testing and white box-testing. As with black-box testing, greybox testing uses a specification for creating test cases. The specification used in grey-box testing does not specify only the requirements of a system, but it also describes the behavior of the system. Grey-box testing is similar to white-box testing in this sense. The behavioral information embedded in a specification is also used for generating test cases. 1.4 Software testing approaches. There are mainly three types of testing approaches namely Model based testing, Specification based testing and code based testing. In specification-based techniques test cases are derived directly from the specification or from some other kind of model of what the system should do. The principle of code based testing is to have each and every statement in the program executed at least once during the test. Code based testing attempts to test all reachable elements in the software under the cost and time constraints. The testing process begins by first identifying areas in the program not being exercised by the current set of test cases, follow by creating additional test cases to increase the coverage. Methods proposed for structural code based testing include statement coverage, decision coverage and condition coverage. Model-based testing is an approach that bases common testing tasks such as test case generation and test result evaluation of a model. A model of software is a depiction of its behavior where behavior can be described in terms of the input sequences accepted by the system, the set of actions, conditions, the flow of data through the application s modules and routines. There are numerous such models, and each describes different aspects of software behavior. For example, control flow, data flow, and program dependency graphs express how the implementation behaves by representing its source code structure. Decision tables and state machines, on the other hand, are used to describe external so-called black box behavior. Examples of some software testing models are finite state machines, state charts, the unified modeling language (UML), Markov chains and grammars. In our paper we concentrate on model based 47

3 approach. Activities in MBT are building a model, generating expected inputs and outputs, running the tests, comparing the actual outputs with expected outputs and stop testing after a criterion is reached. II. RELATED WORK Typically three types of techniques have been proposed in the literature to generate test cases. These are Model based, Specification based and Code based techniques. Model based techniques [1][4][5] takes UML and using the requirement specifications as input, and design/architectural information is used to generate test cases. These techniques generate functional tests [1][5] and also integration tests [3]. Ravi etc [1] proposed a technique that presents a relationship between the structure of the UCAD and generated functional test cases. They used the Behavioral slicing using unit of behavior concept in structuring a UCAD similar to the concept introduced in [6]. Specification Based Testing refers to the process of testing a program based on what its specification says its behavior should be. In particular, we can develop test cases based on the specification of the program's behavior, without seeing an implementation of the program. Furthermore, we can develop test cases before the program even exists. Several techniques have been proposed to automatically generate test cases from software specifications of the envisaged systems such as Z [7] and ADL [8] etc. Hall proposed a test case generation technique based on the Z specification language. The proposed technique used partition analysis strategy to divide the input space into partitions, for test generation purposes. Liu, Miao and Zhan further extended the work of Stocks and Carrington for object-oriented specifications. It is based on Object-Z notation, and can be partially automated. The proposed framework in generates a valid input space (VIS) for class methods, and applies a strategy on VIS to generate test data. Legeard and Peureux present a case study on generating test sequences for Smart Card GSM standard to evaluate the effectiveness of B Testing Tools testing environment on a large real-life application. Miao and Liu extended the work of Stocks and Carrington and Liu et al. They proposed a test class framework for object-oriented class testing using Object-Z specification. Their proposed framework is partially automatable. It generates a valid input space for class methods, and applies a testing strategy on VIS to generate test data. Code--based techniques use code analysis techniques [9][10] to build the control and data paths and thus generate test cases by traversing these paths. These techniques also use the symbolic execution to generate test cases for glass--box testing. The research being done on code based test case generation techniques is mainly for white--box testing. Basically, test cases for black box testing are generated using the specifications or the model based approaches. Test case generation using activity has been an area of much attention these days. Chen at al 2010 and 2009[11,12], Samanta at al, 2009 and 2011[13,14], Kundu and Samantha in 2009[17], Kim, Kang, Baik & Ko, 2007[15], Linzhang at al, 2004[16], proposed their approached on activity diagrams. III. GENETIC ALGORITHM Artificial intelligence can be viewed as a process of search through the space of possible solutions. The set of possible solutions define the state space of the problem. Mathematics can be viewed as a process of optimization. The problems are first formulated as models and expressed in terms of functions and then we find a solution and discover a set of parameters that optimize the model and produce an optimal solution to the given problem. Genetic algorithms are a combination of search space and optimization and are good at large search spaces and optimization. Optimization is a process that finds a best solution for the problem. 48

4 3.1 Different types of search optimization algorithms Figure 1. Optimization Techniques. This paper uses evolutionary algorithms so we concentrate only on evolutionary algorithms. EA s describe the process of search, and allows us to carry out the search and they allow us to find optimal solution. 3.2 Evolutionary algorithms EA is a subset of evolutionary computation which is a subfield of Artificial intelligence. Evolutionary computation is a general term for several computational techniques. EC represents powerful search and optimization influenced by biological mechanisms of evolution. EAs refer to evolutionary computation models using randomness and genetic inspired operations. EAs involve selection, recombination, random variation and competition of the individuals in a population of adequately represented potential solutions. The potential solutions are referred as chromosomes or individuals. The evolutionary algorithms include a. Genetic algorithms b. Genetic programming. Genetic algorithm represents the main paradigm of evolutionary computation. GAs simulates natural evolution by mimicking processes that the nature uses, like selection, crossover and mutation. GA is inspired by Darwin s theory about evolution. GAs simulates the survival of the fittest among individuals over generations for solving a problem. In nature competition among individuals results in the fittest individuals dominating the weaker ones. Genetic algorithm operates on an initial population by applying the principle of survival of the fittest. It produces either a better or better approximation to a solution. From the initial population a new set of approximations are generated by selecting some individuals basing on their fitness. Once the individuals are assigned a fitness value, they can be chosen from the population, with a probability according to their relative 49

5 fitness, and crossed to produce the next generation. Genetic operators manipulate the characters of the chromosomes. The crossover operator is used to exchange genetic information between pairs, or larger groups, of individuals. A further genetic operator, called mutation, is then applied to the new chromosomes. Mutation causes the individual genetic representation to be changed according to some probabilistic rule. In the binary string representation, mutation will cause a single bit to change its state. After crossover and mutation, the individual strings are then, if necessary, decoded, the objective function is evaluated, a fitness value is assigned to each individual and individuals are selected for mating according to their fitness, and so the process continues through subsequent generations. In this way, the average performance of individuals in a population is expected to increase, as good individuals are preserved and breed with one another and the less fit individuals die out. The GA is terminated when some criteria are satisfied, e.g. a certain number of generations, a mean deviation in the population, or when a particular point in the search space is encountered. procedure GA begin end. t = 0; initialize P(t); evaluate P(t); while not finished do begin t = t + 1; select P(t) from P(t-1); reproduce pairs in P(t); evaluate P(t); end A Simple Genetic Algorithm IV. UML DIAGRAMS The Unified Modeling Language (UML) is a specification defined by the Object Management Group in the year UML is widely used for object-oriented analysis and design. UML consists of diagrams which describe structures and behavior of a system. The structural diagrams declare components of a system and how each component is connected to one another. Examples of a structural diagram are the class diagram, the component diagram, the composite structure diagram, and the deployment diagram. The behavioral diagrams depict the behavior of a system in different ways. Examples of behavioral diagrams are the activity diagram, interaction diagram, state machine diagram, and use case diagram. Software designers use a combination of structural diagrams and behavioural diagrams to specify the system. 4.1 UML activity diagram Activity diagram is another important diagram in UML to describe dynamic aspects of the system. Activity is a particular operation of the system. Activity diagrams are not only used for visualizing dynamic nature of a system but they are also used to construct the executable system by using forward and reverse engineering techniques. It does not show any message flow from one activity to another. Activity diagram is basically a flow chart to represent the flow form one activity to another activity. The activity can be described as an operation of the system. So the control flow is drawn from one operation to another. This flow can be sequential, branched or concurrent. Activity diagrams deals with all type of flow control by using different elements like fork, join etc. 4.2 Basic notation used in activity diagram a. Initial node. The filled in circle is the starting point of the diagram. b. Activity final node. The filled circle with a border is the ending point. An activity diagram can have zero or more activity final nodes. c. Activity. The rounded rectangles represent activities that occur. 50

6 d. Flow/edge. The arrows on the diagram. e. Fork. A black bar with one flow going into it and several leaving it. This denotes the beginning of parallel activity. f. Join. A black bar with several flows entering it and one leaving it. All flows going into the join must reach it before processing may continue. This denotes the end of parallel processing. g. Condition. Text such as correct or incorrect, yes or no on a flow, defining a guard which must evaluate to true in order to traverse the node. h. Decision. A diamond with one flow entering and several leaving. i. Merge. A diamond with several flows entering and one leaving. The implication is that one or more incoming flows must reach this point until processing continues, based on any guards on the outgoing flow. j. Swimlanes. Swimlanes, indicate who/what is performing the activities. k. Flow final. The circle with the X through it. This indicates that the process stops at this point. 5.1 Activity graph Figure 2. Activity Diagram Notations V. PROPOSED METHODOLOGY To generate test cases from an activity diagram we convert the activity diagram to an intermediate form known as activity graph. Activity graph is a directed graph that contains start node, end node, decision nodes guard condition node, join node, fork node. The edges represent the flow in the activity diagram. The activity graph generated has been proposed by Kundu and Samantha. They proposed a set of rules for mapping an activity diagram to activity graph. 51

7 Table 1. Rules for mapping an activity diagram to activity graph. S.NO. Constructs of Activity Diagram Node of Activity Graph 1 Initial Node Node of type S with no incoming edge 2 Activity Final Node Node of type E with no outgoing edge 3 Flow Final Node Node of type E with no outgoing edge 4 Decision Node Node of type D 5 Guard Condition associated decision Node of type C and associated with condition string. Its parent node is of type D node 6 Merge Node Node of type M and having single outgoing edge 7 Fork Node Node of type F with single incoming edge 8 Guard condition associated with Node of type C and its parent node is of type F fork node 9 Join Node Node of type J and will have one outgoing edge. 10 An object 'OB' at input/output pin of an activity 'AC' Node of type O and associated object name is 'OB'. Its parent node will be of type 'A' and associated activity name 'AC'. If same object 'OB' is in both input and output pin of the activity 'AC', then only one node is to be used. 11 Object state 'S' of an object 'OB' Node of type OS. If 'OB' is at input of an activity, then this node is left child of node of type O and associated object name is 'OB' otherwise this node is right child of parent node associated object name with 'OB'. 12 Activity Node Node of type A. Its associated string is activity name. To generate paths from a graph we have two control strategies DFS and BFS. But both of them cannot completely generate paths when there are still unprocessed edges while all nodes are visited. So we use queue operations to generate all unique paths from the graph. After finding all paths we apply genetic algorithm operations to obtain the best test case. 5.2 Algorithm to generate test cases 1. Draw the activity diagram. 2. Convert the activity diagram to an activity graph using the set of rules described in table1. 3. Apply Genetic Algorithm, assigning weights to all the edges in the activity graph. Start the process with the start edge, assign the value as one. Using the node number find the next edge. Increment the value and go to the next node. Else if the node is decision, then Ø Increment the value and assign it to the true side of the decision and continue until the path completes. Ø And also for the false side of the decision assign the numbers until the path is complete. 4. Choose the source and destination node to generate all unique paths between the desired nodes. 5. To calculate fitness value For each path calculate the cost of the path, here the path s cost will be the sum of all the costs assigned to each link in the path Apply the fitness functions as F(X)=X*X Calculate the probability of the individual as p(i)= F(x)/ F(x) 6. To select the individuals from large initial population produce a new generation of solutions by picking from the existing pool of solutions with a preference for solutions which are better suited than others. Generate a random number 52

8 We divide the probability range into bins, sized according to the relative fitness of the solution which they represent. By generating uniform random values and seeing which bin they fall into we pick the individuals that will form the basis of the next generation. 7. To perform crossover, mate the first two strings together and the second two strings together and so on. Within each pair swap parts of the member solutions to create offspring which are a mixture of the parents. 8. Randomly mutate a very small fraction of genes in the population. 9. Reevaluate fitness of the new generation. 10. Repeat this process until the fitness value minimizes or all the paths have been covered or maximum number of generations is reached 11. Best Test path generated. 12. End. VI. CASE STUDY: LOGIN SCREEN Login screen initially displays a message Login here using your Username and Password. The user enters the username and password and the system checks if the entered username and password are valid or not. If they are valid it displays the main page if wrongly entered it checks the number of times login has been tried. If the number of times the login is less than the number of times feed in the system it displays Invalid Login Please Try again or it displays Sorry you have exceeded the allowed number of login attempts. A. The activity diagram for the above case study is Display "Login using your Username and password" Display "Invalid Login Please try again" <Username, Password are Valid> <Username and password are Invalid> Launch Main Page Number of Times <= 10 Yes No Display "Sorry You have exceeded the allowed number of login attempts" Figure 2. The Activity Diagram for the Login screen B. The activity diagram is converted to activity graph and the graph is as follows. 53

9 Fig 3. The activity Graph for the Login screen C. The Possible unique paths generated from the above graph are src node : 1 => 2 => 3 => 4 => 5 => 6 : dst node. src node : 1 => 2 => 3 => 7 => 7 => 9 => 10 => 6 : dst node. src node : 1 => 2 => 3 => 7 => 8 => 11 => 12 => 2 => 3 => 4 => 5 => 6: dst node. src node : 1 => 2 => 3 => 7 => 8 => 11 => 12 => 2 => 3 => 7 => 7 => 9 => 10 => 6 : dst node. Number of all possible and unique routes = 4 P1: Input: Valid Username and Password, Output: Display Login here using your Username and Password, Launch Main Page. P2: Input: Invalid Username or Password, Try again = NO, Output: Display Login here using your Username and Password, Display Sorry you have exceeded the allowed number of login attempts. P3: Input: Invalid Username or Password, Try again = YES, Valid Username or Password Output: Display Login here using your Username and Password, Display Invalid Login, Please try again, Display Login here using your Username and Password, Launch Main Page. P4: Input: Invalid Username or Password, Try again = YES, Invalid Username or Password, Try again = NO Output: Display Login here using your Username and Password, Display Invalid Login, Please try again, Display Login here using your Username and Password, Display Sorry you have exceeded the allowed number of login attempts. D. Devise a means to represent a solution to the problem. Assume, we represent x with 8 digit unsigned binary numbers. 54

10 a. Devise a heuristic for evaluating the fitness of any particular solution. The function f(x) is simple so it is easy to use. b. GAS often processes binary representations of solutions. This works well because crossover and mutation can be clearly defined for binary values. We use 8 bit binary number. c. Randomly generate a set of solutions. Here we have a population of 4 paths so they are considered. For large population randomly select a path. These are chromosomes. d. Evaluate the fitness of each member of the population. The calculated fitness values for each individual are Ø Decode the cost to binary value. Ø Evaluate the fitness according to F(X)=X2. The evaluation of the population is summarized in the following table. Table2. Initial Population and its fitness. String no Chromosome X(cost) F(X)=X*X Probability P P P P Total String number 1 has maximum chances of selection. a. Produce a new generation of solutions by picking from the existing pool of solutions with a preference for solutions which are better suited than others. b. We divide the range into four bins, sized according to the relative fitness of the solution which they represent Table3. Associating bins for the initial population. Strings Probability Associated bin P P P P By generating 4 uniform random values and seeing which bin they fall into we pick the four strings that will form the basis of the next generation. Table4. Selection of chromosomes Random no Falls into bin Chosen string Randomly number generator decides for us to mate the first two strings together and the second two strings together. E. Within each pair swap parts of the member solutions to create offspring which are a mixture of the parents. For the first pair of strings, we randomly select the crossover point to be after the fourth digit. Before Crossover After Crossover

11 For the second pair of strings we randomly select the crossover point to be after the second digit Crossing these two points yields F. Reevaluate fitness of the new generation. This would be the first step in generating a new generation of solutions. However it is also useful in showing the way that a single iteration of the genetic algorithm has improved the sample. Table 5. New generation String no New population X X2 Probability P P P P Total After evaluation of new generation we observe that: a. Initial population at the beginning were p1, p2, p3, p4 b. After one cycle new populations to act as initial population are p5, p6, p7, p8 c. The total fitness has gone from to in a single generation d. The algorithm has come up with the string as a possible solution. G. Randomly mutate a very small fraction of genes in the population. As the above generated new individuals are not part of the generated paths Path 1 is the best node that is selected. So the problem doesn t require mutation. VII. CONCLUSION In this paper we presented the test case generation by means of UML activity diagram using Genetic Algorithm from which best test cases can be optimized. Moreover our method for test case generation inspires the developers to improve the design quality. In future, it is possible to build an automatic tool using this approach. This automatic tool will reduce cost of software development and improve quality of the software. REFERENCES [1]. Ravi Gorthi and Kailash KP Chanduka, Model--Based Automated Test Case Generation, SETLabs Briefings, Vol. 6, No 1, 2008, pp [2]. Hartmann Jean, Imoberdorf C., Meisinger M., UML--Based Integration Testing, ACM International Symposium on Software Testing and Analysis, August, 2000, pp [3]. Basanieri F and Bertolino A, A Practical approach to UML--based Derivation of Integration Tests, 4th International Quality Week Europe, Nov , [4]. Lionel Briand and Yvan Labiche, A UML Based Approach to System Testing, Lecture Notes In Computer Science;; Springer- -Verlag, Vol. 2185, [5]. Wang Linzhang et al., Generating Test Cases from UML Activity Diagram based on Gray--Box Method, Asia--Pacific Software Engineering Conference, Nov--Dec, 2004, pp [6]. Gerrard P, Testing Requirements, EuroSTAR, Belgium [7]. Donat M R, Automating formal specification based testing, conference on theory and practice of software development, Lecture notes in CS, Vol. 1214, pp , [8]. Gargantini A and Heitmeyer C, Using model checking to generate tests from requirements specifications, Lecture notes in computer science, Vol. 1687, pp , [9]. Sarfraz Khurshid et al, Generalized symbolic execution for model checking and testing, 9 th Int. Con. on Tools and Algorithms for Construction and Analysis of Systems, [10]. Jenny Li J and Howell Yee, Code--coverage guided prioritized test generation, international computer software and applications conference (COMSAC 04), Sep., 2004, pp

12 [11]. Mingsong Chen, Prabhat Mishra and Dhrubajyoti Kalita. Efficient Automatic Test Generation for Validation of UML Activity Diagram. International journal of Design Automation for Embedded Systems, 29(3): , Springer, [12]. Mingsong Chen, Xiaokang Qiu, Wei Xu, Linzhang Wang, Jianhua Zhao, Xuandong Li. UML Activity Diagram Based Automatic Test Case Generation for Java Programs. In The Computer Journal, Vol. 52, No 5, Oxford Press, [13]. Linzhang Wang, Jiesong Yuan, Xiaofeng Yu, Jun Hu, Xuandong Li, Guoliang Zheng: Generating Test Cases from UML Activity Diagram based on Gray-Box Method. APSEC 2004: [14]. Synthesis of Test Scenarios using UML Activity Diagrams by Ashalatha Nayak, Debasis Samanta Journal of Software and System Modeling (SoSyM), Vol. 43, (2009) [15]. Synthesis of Test Scenarios using UML Activity Diagrams by Ashalatha Nayak, Debasis Samanta Journal of Software and System Modeling (SoSyM), pp , Vol. 10, (2011) [16]. Hyungchoul Kim, Sungwon Kang, Jongmoon Baik, Inyoung Ko, "Test Cases Generation from UMLActivity Diagrams ", Eighth ACIS International Conference on Software Engineering, Artificial Intelligence, Networking, and Parallel/Distributed Computing, Pages [17]. Debasish Kundu, Debasis Samanta: "A Novel Approach to Generate Test Cases from UML Activity Diagrams", in Journal of Object Technology, vol. 8, no. 3, May-June 2009, pp