Generating test cases from sequences of use cases

GENERATING TEST CASES FROM SEQUENCES OF USE CASES Javier J. Gutiérrez, María J. Escalona, Manuel Mejías, Jesús Torres Department of Computer Languages and Systems. University of Seville. Spain Keywords: System testing, automatic generation of test cases, use case. Abstract: An important task in a development process is to test that functionality of the system under development satisfied its requirements. Test cases have to verify real behaviour of the system when it will in production. This paper shows a systematic approach to generate test cases that exercises several sequences of use cases over web applications. 1 INTRODUCTION Software testing can be performed at several levels. This paper is focused in system testing level. System test cases are mainly obtained from functional requirements of system under test (Bertolino 04). It is possible to derive test cases in a systematic way from functional requirements. Nowadays, there are several approaches to drive the derivation process from requirement to test cases. A list of references can be found in (Denger 03) and (Gutierrez 04), (Gutierrez 05). However, many approaches to derive functional system test cases are focused over functional requirements in isolation and do not studies web applications (Gutierrez 05). These approaches can derive a set of test cases for every functional requirement but does not considerate dependences among several requirements. An example of derivation of test cases from each use case of a web application can be found in (Gutierrez 05(2)). Main contributions of this paper are: first, introducing an approach to derive sequences of use cases; second, showing a practical case over a simple but not trivial web system. 2 GENERATION OF TEST CASES Main goal is to derive valid sequences of use cases to be implemented as test cases. Our approach is composed of 6 activities described in points below. 2.1 Identify Use Case Variables The idea of use case variable is similar to operational variables defined in the Extended Use Case Test pattern (Binder 00). We define a use case variable as a piece of information that a use case needs to perform its task. Use case variables are classified into three groups listed in table 1. More groups can be added if needed. Table 1: Types of use case variables. Gro up Description Inner The variable stores information that the use case needs. That information does not depends on any other use case. In The variable stores information that the use case must receive from another use case. Out The variable stores information that other use cases needs. Generally, in and out variables are included in the precondition and post condition of a use case (Nebut 03). Inner variables can be identified studying all scenarios defined into a use case. We have also to identify the domain for every variable. Complex domains can be described with store requirements, defined in (Escalona 04), or with class diagrams (Labiche 02). Use case variables help to identify and define the precedence of use cases. Inner variables are not relevant in sequences derivation process. However, at the time to implement test cases, we have to assign values to all variables, even inner variables. 473 J. Gutiérrez J., J. Escalona M., Mejías M. and Torres J. (2006). GENERATING TEST CASES FROM SEQUENCES OF USE CASES. In Proceedings of WEBIST 2006 - Second International Conference on Web Information Systems and Technologies - Internet Technology / Web Interface and Applications, pages 473-476 DOI: 10.5220/0001245804730476 Copyright c SciTePress 2.2 Build Behavioural Model Behavioural model is composed by one or several UML activity diagrams for each actor that interacts with the system. Every activity diagram has only the use cases accessible to that actor. Steps to build an activity diagram from use cases are enumerated in table 2. Table 2: Steps to build a behavioural model. Step 1 Identify start and end points. 2 Draw an activity for every use case. In and out variables are added into the name of the activity. 3 If use case B can only be executed after executing use case A, a transition among activity A and B is added. 4 Annotate the diagram with preconditions, post conditions and invariants. A behavioural model is not a navigation model. Navigation models describe the pages and information and how a user might navigate among them. However, behavioural model describe the functionality that a user might exercise. 2.3 Identify Loops A loop is a sequence of use cases that might be executed a number of times, or infinite. Loops are very common in behaviour models described in point before. For example, when introducing data, the system validate that information and, if there are errors, asks for correct invalid values several times. Table 3: Notation for canonical path. Notation Description A -> B Use case B can only be executed after use case A is executed. A -> {B | C} After execution of use case A, sequence B of use cases or sequence C of use cases might be executed, but not both at same time. Selection can involved more than two sequences. (A)b Sequence A of use cases is executed b times. To manage loops, we assign a variable to every loop. That loop variable will have a range of values that indicates the number of times that the loop can be repeated. The way to obtain the values (the times a loop is traverse) are: the functional specification indicates the number of times, deductible from the working environment or final user experience. 2.4 Derive Canonical Paths A canonical path is an expression that describes a set of possible paths over a behaviour model. Notation for canonical path is similar to regular expressions and it is described in table 3. 2.5 GenerateSequence of Uses Cases Sequences of use cases are generated from canonical paths. A sequence of use cases is a path through the behavioural model that begins in the start point, finish in the end point, and has concrete values to all variables implied. There are several criteria to generate sequences from canonical paths. Criterion selected in our approach is all use cases criterion. All use cases must be covered in, at least, one path. We propose two different criteria to determine the number of repetitions of loops. First criterion is to select a random number for each loop variable in every path that traverse the loop. Second criterion is to generate a different path for each value in the range of loop variable. We propose the same criteria used in loops to determine a concrete sequence from a selection. 2.6 Identify Conditions Over Test Values Some sequences of use cases can be only executed if variables have concrete values. Those conditions are identified and expressed as boolean conditions or OCL expressions. Test values generated for each sequence must satisfied all conditions associate to that sequence. 3 CASE STUDY System under test is a simplified version of a web application to manage a link catalogue on-line. Figure 1: Use case diagram. Use cases of user actor are showed in figure 1 and described in tables from 4 to 6. Use cases “search link by category” and “Search recent link” have been omitted due it is similar to other uses cases. WEBIST 2006 - WEB INTERFACES AND APPLICATIONS 474 . Table 4: Use case “add new link”. Name UC-01. Add new link Preconditio n No Main sequence 1. System select “top” category and shows the form to introduce the information of a link (SR-02). 2. If the user selects a different category, system changes the category and shows the form again. 3. User introduces information of the new link and press insert button. 4. System stores the new link. Errors 2. At any time, user can press cancel button and exit of the form. 4. If link name or link URL is empty, system shows an error message and ask the information again Table 5: Use case “search link by description”. Name UC-02. Search link by description Preconditio n No Main sequence 1. System shows a form to introduce the description. 2. User writes the description and press search button. 3. System searches all links with description that coincides with description of the user and executes UC-05. Errors No. Table 6: Use case “show results”. Name UC-05. Show results Preconditio n A search have been made Main sequence 1. System shows a table with all information about the links found (SR-02). Errors 1. If search returns empty values, system show a “no links” message Post condition No. First activity is to identify variables of use cases. Use case 01 needs information about the new link to add, however, there are no other use cases that depends of the new link. Thus, new link is an inner variable. Use case 05 needs the results to show. Those results are provided by use case 02 or 03 or 04. Thus, one of those use cases must be executed before execution of use case 05. Domain, in table 7, references to a store requirement which define the information that system manages for each link. Table 8 shows the store requirement. A description in depth of store requirements and their templates can be found in (Escalona 04). Table 7: Use case variables. UC Name Type Domain UC-01 New link Inner SR-01 UC-01, 04 Category Inner String UC-02 Description Inner String UC-02, 03, 04, 05 Result Out Array of SR-01 Table 8: Store requirement. Name SR-01. Link. Use cases UC-01, UC-02, UC-03, UC-04, UC05 Specific data Name Domain Identifier Integer Name String Category Integer URL String Description String Date Date and time Restrictions Identifier must be unique. Parent category must be an exiting category. Second activity is to build the behaviour model. Variables in table 7 allow identifying the precedence of each use case. Start and end points are easy to identify due there is one use case to begin and another one to exit the system. Behaviour model from use cases has been building using steps described in point 2.3 and is showed in figure 2. A new use case has been added in figure 4. This use case is executed when user access to the system and shows a GUI to execute use cases from 01 to 04. Next, we identify loops and assign a loop variable to each one. Model in figure 4 has only one loop, which represent several operations that a user performs over the system. This loop has a variable called “loop”. It range is from 1 to infinite. However, it is impossible and unrealistic to test infinite operations, so we set the variable in a range from 1 to 4 operations. Next activity is the derivation of canonical paths. Due the simplicity of the system, only one canonical path is enough to cover all possible paths. The canonical path is showed in table 9. Table 9: Canonical path. (UC-00->{UC-01|{UC-02|UC-03|UC-04}->UC-05} )loop In activity 5, the canonical paths are instantiated to generate sequences of use cases. Concrete values to each variable and loop are assigned to each path and a concrete use case is chosen in every selections. We generate a different path for every different value in the range of a loop variable. We also generate a different path for every possible option in GENERATING TEST CASES FROM SEQUENCES OF USE CASES 475 a selection. The number of possible paths is 20. Examples are listed in table 10. Table 10: Paths example. Id Loop = 1 1 00 -> 01-> 00 2 00 -> 02 -> 05 -> 00 3 00 -> 03 -> 05 -> 00 4 00 -> 04 -> 05 -> 00 Finally, conditions over test values to traverse concrete paths are identified. However, in this practical case, there is not any variable that have to get a concrete value to execute any of the path obtained. Test values that satisfied conditions have to be generated for each variable to implement test cases. This one can be done applying specific techniques like Category-Partition method (Ostrand 88) or boundary values technique, or capturing real data from user sessions (Elbaum 05). 4 CONCLUSIONS Deriving sequence of use cases is a valuable technique to build realistic system test cases. This process do not need that system under test is build (due it is based on its functional specification, nor in code), so it might begin at early phases of development process, avoiding the lack of time to testing and allowing the detection of faults, ambiguities and inconsistencies in requirements. The best improvement is obtained combining sequence of use cases with test cases derived for each use case. This one allows to test a sequence of different scenarios instead be limited for main scenario. This approach can be applied in addition to other approaches focused in deriving test cases from use cases in isolation like (Ruder 04). REFERENCES Bertolino, A., Gnesi, S. 2004. PLUTO: A Test Methodology for Product Families. Lecture Notes in Computer Science. Springer-Verlag Heidelberg. 3014 / 2004. pp 181-197. Binder R.V. 2000. Testing Object-Oriented Systems. Addison-Wesley. USA. Denger C., Medina M. 2003. Test Case Derived from Requirement Specifications. Fraunhofer IESE Report. Elbaum S., et-al. 2005. Leveraging User Session Data to Support Web Application Testing. Inner Report. Department of computer Science and Engineering. University of Nebraska. USA. Escalona M.J. 2004. Modelos y técnicas para la especificación y el análisis de la Navegación en Sistemas Software. Ph. European Thesis. University of Seville. Spain. Gutierrez J.J., Escalona M.J., Mejías M., Torres J., Álvarez J.A. 2004. Comparative Analysis of Methodological Proposes to Systematic Generation of System Test Cases from System Requirements. SV05. pp. 151-160. Paris, France. Gutierrez J. 2005. Gutiérrez, J.J., Escalona M.J., Mejías M., Torres, J. 2005. Analysis of Proposals to Generate System Test Cases From System Requirements. CAiSE’05 Forum. Porto. Portugal. Gutiérrez J.J., Escalona M.J., Mejías M., Torres J. 2005 (2). A practical approach of Web System Testing. Advances in Information Systems Development. pp. 659-680. Ed. Springer Verlag Sweeden. August. Labiche Y., Briand, L.C. 2002. A UML-Based Approach to System Testing, Journal of Software and Systems Modelling (SoSyM) Vol. 1 No.1 pp. 10-42. Nebut, C. F., et-al. 2003. Requirements by contract allow automated system testing. Proceedings of the 14th International Symposium of Software Reliability Engineering (ISSRE'03). Denver, Colorado. USA. Ostrand, T.J, Balcer, M.J. 1988. Category-Partition Method. Communications of the ACM. 676-686. Ruder A. et-al. 2004. A Model-based Approach to Improve System Testing of Interactive Applications. ISSTA’04. Boston, USA. Figure 2: Behaviour model. WEBIST 2006 - WEB INTERFACES AND APPLICATIONS 476