Application of the ITERA Meta Model

In Section 4.3.2, the UML profile for test case modelling was introduced and the individual stereotypes have been discussed. Here the application of the UML profile is explained in detail using the previous example.

The second phase of the ITERA method (see Section 4.1.1) is concerned with the refinement of UML models with test-specific data before they are transformed to abstract test cases. This refinement manifests itself by specifying actions using elements of the Action type defined in the meta model.

Figure 4.11 shows a rudimentary activity diagram for the rental process of a RFID equipped self-checkout terminal in the running example library. The ITERA profile has been applied to the Activity Diagram and each activity has been stereotyped successively.

The first action (1) in the control flow of the activity diagram describes the user’s actions, in particular the selection of books and a movement. There is no direct interaction with the system. However, it is important to note that time passes in each of these activities. Basically, these activities represent the flow of RFID tags through the business process. As already explained, timing events can have an influence on the capturing of RFID tags. Therefore, they are marked as <<ContextActivity>> in the test model. However, the actual flow of RFID tags does not have to be realized, as all RFID tags are globally available in the subsequent simulation environment. Step 2 is the user’s first interaction with the system. Here, the rental process is started by pressing the “rent books” button. As the user’s interaction happens with the graphical user interface of the SUT it is marked with the stereotype <<GUIInputAction>>.

After the rental process has been started, the system prompts the user to identify themselves. Since all outputs of the system are test relevant, as they are part of the test evaluation process for black-box testing techniques, an assertion of type GUIOutput (<<GUIOutputAssertion>>) is used in step 3.

The authentication of the user (4) is carried out, by means of an user-id-card equipped with a RFID chip, so here the first interchange via a RFID reader takes place. The placement of an RFID tag in the reading zone of a RFID reader can be described by the stereotype <<RFIDAddAction>>.

The RFID tag read by the RFID system is then assigned to a user and the status of the user account is checked. Step 5 is therefore a system rule and can be specified by the type <<SystemRule>> as defined in the meta-model. Depending on the evaluation of this system rule, a case distinction is made. Either the user has a valid account and the system prompts the user to place the books to be borrowed on the corresponding area (7 - <<GUIOutputAssociation>>) or the transaction is acknowledged by displaying an error message (6 - <<GUIOutputAssertion>>). In step 6, the user takes the user id-card, which is of type <<RFIDRemoveAction>>. As a side-note, a <<RFIDAddAction>> always has to be followed by an <<RFIDRemoveAction>> or

Figure 4.11: Application of the ITERA Profile on the example library “rental process”

an UML end node of type FinalNode (21,22), eventually. Once the user has been successfully identified, he can start borrowing books by placing the them on the designated area. The books

are detected by an antenna of a RFID reader integrated in the shelf compartment. Hence, stereotype <<RFIDAddAction>> (9) is used for the test parametrization.

The detected books are now processed by the system. This is done by two checks (10,12). Two business rules are applied for validation: check user authorisation for ensuring the user has the right to borrow books and check book authorisation to ensure the book can be borrowed. Since these are system decisions, both are stereotyped by <<SystemRule>>. Depending on the outcome of each check, different paths are selected in the activity diagram.

In action 12, if the preceding checks were successful, the books are marked as borrowed and the corresponding entries are made in the library software database. Since the database can be used as an interface to check the test output, the type <<DatabaseAssertion>> is used here. The approach to testing RFID applications presented in this thesis presupposes the verifiability based on databases. This requirement is based on the fact that RFID applications can be used without user interactions. Therefore, a testability is only given if an appropriate interface (here the database) is available.

The successfully borrowed books are now also displayed via the output of the software at the input terminal (15). The use of the <<GUIOutputAssertion>> stereotype makes sense here as for the previous outputs.

The user now has the possibility to borrow further books (16), whether or not this is a decision that the user has to make now. Since it is a decision that is independent of the system, this action is marked as <<ContextAction>>.

The following steps are similar to the ones used before. Therefore, it should be obvious which stereotypes can be applied to these.

4.5 Automatic Test Case Generation

In the previous sections, the method for model-based test case specification was presented. For this purpose, a meta model has been introduced that allows test relevant aspects to be considered during the modelling of RFID specific test cases and to encapsulate test data in the activity diagram.

In this section the fundamental steps of the ITERA test methodology, that allow for the deriva- tion of test cases are described. In particular how transformation is used to convert activity diagrams to a graph in a first step and how the test cases or potential execution paths of the activity diagrams are computed.

The central tool for transferring models between different abstraction levels is the model trans- formation, which uses specific transformation rules to map a source model to a target model. Model transformation is a process that removes or adapts elements of the source model or creates elements in the target model that might be aggregated from elements of several source models.

The aim of model transformation is to preserve those aspects of the system that are particularly relevant in the target model while irrelevant aspects are removed.

Test cases are ordered sequences of individual actions that are processed during the execution of tests. Since activity diagrams may contain cyclic and concurrent control flow structures, direct application of deep-first or breadth-first search algorithms is not suitable for calculating such ordered sequences of test-relevant actions. To avoid this problem, the approach to generate test cases from UML activity diagrams investigated in this thesis follows the path of modifying the breadth-first search algorithm so that valid paths are also generated from activity diagrams with concurrent and cyclic structures.

A particular challenge when testing software is to find suitable test cases. Test case determi- nation should therefore be performed through a systematic and structured process. For this reason, this section introduces a procedure that allows to extract them directly from the activ- ity diagram created in the previous section. In order to ensure adequate coverage of the RFID application by tests, different coverage criteria for activity diagrams are also defined in this section.

The procedure for determining the test case is carried out in three steps: At first, the UML activity diagram is transformed into an intermediate representation (activity graph). In a further step, a search algorithm is then applied in such a way that the previously defined coverage criterion is fulfilled. Subsequently, test cases are created based on these paths, including test parameters from the meta-model. The obtained test cases also provide the starting point for the test data determination in the next section.