METHOD AND SYSTEM FOR TEST CASE GENERATION
FIELD OF THE INVENTION
The invention relates to test case generation. In particular, the invention relates to generating test cases for testing of computer applications .
BACKGROUND OF THE INVENTION
The interest in statistical testing has increased in recent years for two main reasons: the growing complexity and non -determinism of the environments i n which modern software is expected to operate (the Internet being the most popular example) and the higher levels of reliability required for some applications. Indeed, reliability assessment is crucial for systems with safety and fault -tolerance requirements. Such demands are difficult to address with traditional testing techniques. The complexity of the software itself and its interface may require that a test engineer develop test cases from a complex model describing the application. The use of automated tools is inevitable as such applications are simply too complex to test using manual tests.
This poses further problem s: how to create test scripts with hundreds or thousands of tests in an effective way and how to update such scripts efficiently when there is a change in the product.
A usage model characterises the operational use of a software system, where the software is used in a specific environment and the user may be a person, a hardware device, other software, or a group of users. A software use may be a working session, transaction or any service unit limited by start and finish events .
The model structure is composed of a state set and the transitions between the states, constituting a graph. The graph nodes represent the model states, and the graph arcs represent transitions between states. The structure describes the possible uses of the software. A probability distribution associated with the model describes the expected use of the software.
Statistical testing with usage models is mostly based in Markov chains. However, a Markov chain for a complex application can easily reach hundreds or t housands of states, making modelling and maintenance a difficult task. Moreover, in order to generate the test script, it is necessary to add implementation related information to the usage model.
Accounts of usage models based on Markov chains are giv en by Tramell [Trammell, C. "Quantifying the Reliability of Software: Statistical Testing Based on a Usage Model," 208-218. Proceedings of the Second IEEE International Symposium on Software Engineering Standards. Montreal, Quebec, Canada, August 21 -25, 1995.] and Kallepalli [C. Kallepalli and J. Tian, "Measuring and Modeling Usage and Reliability for Statistical Web Testing", IEEE Trans, on Software Engineering , Vol.27, No.11 , pp.1023 -1036, Nov., 2001.].
A simple Markov chain usage model is shown in Figur e 1. The system has four states, Start, Error Message, Menu and Termination. From the 'Start' state, a user enters a password. If the password is incorrect, the Error Message is displayed. This occurs with a probability of 0.2. From the Error Message, the system always reverts to Start. If the password is correct, the system proceeds to the Menu state. This occurs with a probability of 0.8. From the menu the user can only terminate the program.
The evolution of the system is represented by transi tions from one state to another and these transitions are assumed to happen in an instantaneous way.
The probabilities of transition of Markov chains are often represented by matrices. A transition matrix for the system of Figure 1 is shown in Table 1 below.
Start Error Message Menu Termination
Start 0 0.2 0.8 0
Error Message 1 0 0 0
Menu 0 0 0 1
Termination 1 0 0 0
Table 1
In general, the time and memory worst -case complexity of test case generation with a Markov chain usage model is proportional to the size of the transition matrix used to represent the model, i.e. proportional to the square of the number of states. This number grows very fast with the number of states.
A SAN consists of a number of individual stochastic automat a that operate in a somewhat independent way. 1 Each automaton is represented by a certain number of states, along with rules or probability functions that rule the movements from one state of the automaton to another. The state of the automata network is determined by the states that each one of the constituent automata occupies at a time t.
More formally, given a set S of states (local states), let A = (A1, A2, ... An} be a set of automata, wherein each automaton A i is a subset of S. Then a SAN is a stru cture (G, E, Pe1 Pt, I), where:
G = {Gi, G2, ...Gm} is a set of global states, such that each G i is an element of Ai X A2 X ... X An. In other words, each global state is a combination of local states of the automata.
E = {Ei, E2, ...Ek} is a set of events. Each event is a function E j : G— >P(G). In other words, each event maps global states into sets of global states. When the event is applied, the SAN can go to any element of the set specified by the function, depending on the probabilities assigned to the event. Since a global state is a list of local states, the function describes for each automaton in the network what happens in that automaton when the event is fired . Events can be classified as local or synchronising. A local events changes the state of only one automaton; a synchro nising event changes the states of two or more automata.
Pe = {Pi, P2, ...Pk} is a set of event probability functions, one for each event. Each function Pi : G→R describes the probability of occurrence of the event at each global state.
Pt = -[Pt1, Pt2,...Ptkni} is a (possibly empty) set of transition probability functions, one for each pair (event, global state). As described above, when a SAN is in a global state S and an event i is applied, the SAN goes to a state S', which must be an_element of Ei(S). The transition probability functions describe the probabilities of the different elements of Ei(S) being selected. Usually Ei(S) has only one state , in which case these probabilities are not required.
I is a set of initial global states, so is a subset of G . In some definitions, SANs do not have initial states, hence the set I may be empty.
It can be shown that SANs have a number of advantages over Markov chains in modelling complex systems. However, SANs have not yet been applied in testing systems or test case generation .
1 A. G. Farina, F. M. Oliveira. Research Report no . 23, CPPGCC -PUCRS, Porto Alegre, Brazil, March 2002.
SUMMARY OF THE INVENTION
In a first aspect the invention provides a method of generating a test case for an application modelled using a St ochastic Automata Network model including a plurality of automata, including the steps of: a) setting an initial global state as the current global state, wherein a global state comprises a set of local states each corresponding to one of the automata; b) creating a record of the initial global state; c) selecting an event from a set of events that can be applied to the current global state; d) creating a record of the selected event; e) identifying those of the automata affected by the selected event and u pdating the current global state by updating the states of the affected automata; f) creating a record of the current global state; and repeating steps c) to f) until a termination condition is satisfied.
In a second aspect the invention provides a metho d of generating a predetermined number of test cases, including: g) determining a target number of test cases;
h) generating a test case by the method described above ; and j) repeating step h) until the target number of test cases is reached.
In a third aspect the invention provides a method of generating a test case for a system, including: creating a model of the system using a Stochastic Automata Network; and generating a test case by the method described above.
In a fourth aspect the invention provid es an apparatus for generating a test case for an application modelled using a Stochastic Automata Network including a plurality of automata, the apparatus including a processor and memory, the memory being configured to store data related to the Stochasti c Automata Network and the processor being configured to: a) select an initial global state from a set of possible initial global states stored in the memory, each global state comprising a set of local states each corresponding to one of the automata, b) set the selected initial global state as the current global state; c) store a record of the current global state in the memory; d) select an event from a set of events that can be applied to the current global state, from a set of possible events stored i n the memory; e) store a record of the selected event in the memory; f) identify those of the automata affected by the selected event and update the current global state by updating the local states of the affected automata; and g) store a record of the up dated current global state in the memory.
In a fifth aspect the invention provides a testing apparatus including a processor and memory, the memory being configured to store data related to a Stochastic Automata Network based model of an application, the Stochastic Automata Network including a plurality of automata, and the processor being configured to: a) select an initial global state from a set of possible initial global states stored in the memory, each global state comprising a set of local states ea ch corresponding to one of the automata, b) setthe selected initial global state as the current global state; c) store a record of the current global state in the memory;
d) select an event from a set of events that can be applied to the current global s tate, from a set of possible events stored in the memory; e) store a record of the selected event in the memory; f) identify those of the automata affected by the selected event and update the current global state by updating the local states of the affect ed automata; and g) store a record of the updated current global state in the memory.
BRIEF DESCRIPTION OF THE DRAWINGS
The invention will now be described by way of example with reference to the accompanying drawings, in which:
Figure 1 shows a simple Markov chain ;
Figure 2 is a flow chart showing a method of generating a test case according to one embodiment of the invention;
Figure 3a shows a simple application;
Figure 3b shows a SAN -based model of the application of Figure 3a;
Figure 4 is a flow cha rt showing a method of generatin g a target number of test cases; and Figure 5 is a schematic diagram of the testing apparatus of the invention.
DESCRIPTION OF THE INVENTION
A usage model based on a Stochastic Automata Network (SAN) is a data structure co mposed of a list of automata and a list of events.
Where a model is described in relation to an application or system, this means a model of any part of or the whole of the application or system.
In the list of automata, each automaton has a list of its respective local states. Each state has a list of pointers to its possible events and the transitions triggered or "fired" by the events. In the list of events, each event has an attribute with its type (local, synchronising, initial, termination). The complexity problem described above in relation
to Markov chains is minimised in models using SANs because, instead of the creation of a large transition matrix, one smaller matrix is created for each automaton.
Referring now to Figure 2, test case generation begins at step 100 with setting of the initial global state. At step 101, a record is create d of the initial global state. Records are created at various stages of the test case generation and together form the "test case description".
Where there are a number of possible initial global states, an initial state must be selected from the set of possible initial states. The initial global state may be selected randomly or based on the relative probabilities of the possible initial global states. This step may also include enumerating the set of possible initial states before selecting an initial state. Preferably the step of enumerating the set of possible initial states is performed before test case generation, so that it does not need to be repeated f or each test case where many test cases are to be generated for a single application.
At step 102, the set of events that may be applied to the current global state is enumerated by analysing the model and the list of pointers to possible events for each automaton. An event is then chosen from the set at step 103 either randomly or based on the relative probabilities of the events. At step 104 a record is created of the selected event.
At step 105, all automata that are affected by the event are locate d. Firstly it is established whether the event is local or synchronising. If local, then that automaton is the only one affected. If synchronising, then the system looks for all automata affected by the event. The system then computes the next state of each affected automaton, updates the current global state at step 106 by updating the s tate of each affected automaton and creates a record of the updated global state at step 107.
If a termination condition has been satisfied, the m ethod is terminated at steps 108, 109. Otherwise the method re turns to step 102 and continues. A termination condition may be satisfied when a termination event is applied or when a certain number of events or global states have been added to the test case description. Other termination conditions may also be used.
Example 1
Modelling and test case generation for a simple application will now be des cribed with reference to Figures 3 a and 3b. The application consists of two dialogues, shown in Figure 3 a. The first is a login dialogue, in which the user is prompted for a username and password. If the user name or password is incor rect, the application issues an error message. If the username and p assword are correct, the user i s passed to the second dialogue which is a menu, w here the user can only terminate the application.
The application of Figure 3 a can be described by the SAN shown in Figure 3 b with the structure shown in Table 2.
Table 2
The list of events for the model is:
ST (initial, synchronising, probability = 1 , transition probability = 1 ) QT (termination, synchronising, probability = 1 , transition probability = ϊ ) S (synchronising, probability = 0.5 , transition probability = 1 ) f (local, probability = 1 , transition probability = 1 ) g (local, probability = 0.5 , transition probability = 1 )
Note that the initial and termination events are classified as synchronising, even if they occur in only one automaton.
Thus, the Login automaton consists of the three local states : Start, Passw and Menu. The Password automaton consists of the Wait, POK and PNotOK local states. The set of events E = {ST, QT, S, f, g}. The state of an automaton will be indicated by the not ation Automaton.State, so the global state of this simple application can be indicated by [Login.Statel , Password.State2].
The test case generation method will now be described with re ference to this application. It is assumed that there is no termination condition other than the fact that QT is a termination event.
In this example there is only one possible initial global state, [Login.Start, Password.Wait]. As is apparent from Tabl e 2, not all events can be applied to a given global state. In the example, the only event applicable to the global state [Login.Start, Password.Wait] is ST. Event ST, when applied to the two automata, updates the global state to: [Login.Passw, Password. Wait]. As ST is not a termination event, the test case generation continues.
The current global state is now [Login.Passw, Password.Wait]. The set of possible events is {g, S}. One of the events is chosen based on the relative probabilities of the events, say event g. Event g updates the global state to: [Login.Passw, Password.PNotOK]. Event g is not a termination event, so the test case generation continues.
The current global state is now [Login.Passw, Password.PNotOK]. the only possible event is f, which updates the global state to [Login.Passw, Password.Wait]. Event f is not a termination event, so the test case generation continues.
Again, one of the events is chosen based on the relative probabilities of the events, say event S. Event S updates t he global state to: [Login.Menu, Password.POK]. S is not a termination event, so the test case generation continues.
The current global state is now [Login.Menu, Password.POK]. The only possible event is QT, which updates the global state to [Login.Start, Password.Wait]. As QT is a termination event, the test case generation is complete.
For this example the test case description would read:
[Login.Start, Password.Wait] ST
[Login.Passw, Password.Wait]
9
[Login.Passw, Password.PNotOK] f [Login.Passw, Password.Wait]
S
[Login. Menu, Password.POKJ
QT
[Login.Start, Password.Wait].
Figure 4 shows a method for generating a target number of test cases. At step 201 the target number of test cases is determined, such that testing will be statistically meaningful.
At step 202 the set of possible initial global states of the application is enumerated. This step is performed by analysing the usage model. At steps 203 and 204 a test ca se is generated by the method illustrated in Figure 2 and is then added to a list o f test cases. Test cases continue to be generated and added to the list until the target number of test cases is reached (step 205), when the method ends (step 206).
Figure 5 is a schematic drawing of the testing apparatus of the invention. The apparatu s includes a processor 210, primary memory 211, secondary memory 212, a n input device 213 and an output unit 214. The processor performs the steps described above to generate test cases. The primary and secondary memory stores details of the SAN model, as well as storing records of the global states and events as they are added to the test case description. Once a test case has been generated, the steps in the test case are applied to the application by the testing apparatus. Data may be output from the system at any stage via output unit 214, which may be a screen or printer. In particular, results of the test case generation or the results of a test may be output.
The input device 213 may be a keyboard, mouse or voice recognition device. This allows the user to prompt the testing apparatus to begin test case generation or testing. The input device also allows the user to assist the testing apparatus in preparation of a Stochastic Automata Network based model for an application or system. Once preparation of such a model is complete, it can be stored in primary or secondary memory 211, 212 and testing can be performed using the model.
While the present invention has been illustrated by the description of the embodiments thereof, and while the embodim ents have been described in detail, it is not the intention of the Applicant to restrict or in any way limit the scope of the appended claims to such detail. Additional advantages and modifications will readily appear to those skilled in the art. Therefore, the invention in its broader aspects is not limited to the specific details, representative apparatus and method, and illustrative example s shown and described. Accordingly, departures may be made from such details without departure from the spirit or scope of the Applicant's general inventive concept.