Tests above the component test level are performed by simulating the actual use of a software system or a component by the potential user. From a purely technical point of view, the process of carrying out the test is limited to manipulating the SUT by using tools in the same way as would be done by a human actor. Thus, the workflow has to be supported by a suitable simulation technology to provide corresponding inputs. Such technology is often called a test driver (see Patton [32]) in the terminology of software testing.
In the fourth step of the ITERA methodology the test cases that have been created from the activity diagram are executed. This is realized through application specific implementations of the classes from the ITERA meta model, so called test drivers, which are used in combi- nation with a technical solution to stimulate and evaluate the SUT. As already pointed out, the test automation examined here does not make any concrete assumptions regarding the tar- get technology and offers extension points, that allow other technologies to be used. The only requirement is that the test back-end technology to be used (such as Rifidi, AutoIt, SQlite) provides entry points in the meta model in form of subclasses of <<TestAction>>, explicitly <<ActorInteraction>> or <<SystemAssertion>>. If these requirements are met, they can be integrated into the automation tool during test execution.
In practice the test automation is of great importance, since the effort of testing is determined by the efficiency of the test execution to a large extent. In order to ensure automatic test execution, executable semantics have already been emphasized during the modelling of the test cases. All information necessary for the execution of test cases is already contained inside the test model in the form of stereotyped activities. Each <<TestAction>> represents one test step and contains test driver specific parameters to create the test environment, execute the different test steps or evaluate the results after their execution.
It is not a prerequisite that the test cases have been generated from a UML activity diagram. Therefore, manually created abstract tests (test scripts) can also be used as valid input for the test execution framework.
During the transformation of the activity diagram to test cases, the procedure discussed in Sec- tion 4.5.3, a set of execution paths were generated for each activity diagram. These paths consist of sequences of TestAction elements, each containing an executable method that allows the test execution module to execute the test step. The source code listing 5.1, shown below, shows the abstract test case generated during the example library “rental process” used throughout the introduction of the ITERA Method in Chapter 4.
Listing 5.1: Abstract TestCase 1 - Example Library “rental process”
1 @SetUp 2 TestData:
3 userId1 = {type="RifidiTag", tagtype="EPCG1C2" id="3074257bf7194e4000001a85"} 4 book1 = {type="RifidiTag", tagtype="EPCG1C2" id="6056257bf8194e4000011b99"} 5 TestEnvironment:
6 RFIDReaderConfig1 = {type="RifidiReader",name="UserIDReader",config="reader1.config"} 7 RFIDReaderConfig2 = {type="RifidiReader",name="LibraryShelfReader",config="reader2.config"} 8 AppplicationConfig1 = {type="AutoIT",name="LibraryGUI",config="libraryApp.config"}
9 DatabaseConfig1 = {type="SQLLite",name="LibraryDBConnector",config="libraryDB.config"} 10
11 @Test diagram="ad_rentalprocess" name="tc1_rentalprocess" 12 TestAction GUIInputAction("rent books")
13 TestAction RFIDAddAction([userId1]) 14 TestAction RFIDRemoveAction([userId1]) 15 TestAction RFIDAddAction([book1])
16 TestAssertion DataBaseAssertion("[book1].status = rented AND [book1].rentals.user = [userId1]") 17 TestAction GUIInputAction("finish")
18 TestAction GUIInputAction("OK") 19 TestAction RFIDRemoveAction([book1])
The ITERA test execution framework is divided into three components, namely the TestPre- processor, the TestEngine and several TestDrivers. The TestPreprocessor and TestEngine are essential parts of the ITERA test methodology and thus must not be customized. In contrast to the TestDrivers, which might be very application specific as they are build on a concrete technology like Rifidi or a SQL Library.
ITERA Test Preprocessor - The TestPreprocessor does not execute the test cases them selves, but translates the abstract test case description into an executable form for the test engine. For each stereotype defined in the ITERA meta model it creates an appropriate instance of an object, which can then be executed by the ITERA test engine. In the prototype implementation this functionality is realized by using reflections1.The generated test cases (see: source code listing 5.1) are provided as input and parsed to create instances of the classes for each stereotyped test step accordingly.
ITERA Test Engine - The TestEngine is the actual execution part of the test automation framework of ITERA. It uses the results of the TestPreprocessor and executes each test step by calling either the method ActorInteraction.execute() or SystemAssertion.assert(). Each test step is implemented as a TestDriver in an application specific test automation technology, like “Rifidi” or “SQL”. This way the TestEngine is kept simple and does not need to know application specific details. Furthermore, it is independent from the actual tests and can be used for various test scenarios.
Test Driver - The TestDriver is a concrete implementation of of either a ActorInteraction or SystemAssertion. Each class provides an entry point, where functionality of the test automa- tion technology can be realized. The ITERA methodology does not restrict the test execution to predefined interfaces, therefore, several TestDrivers can be used. Each is executing a certain
1
Reflections are the ability of an programming language, like Java, to inspect classes during runtime, which can be used to dynamically create instances of these. This way not all details of the program need to be available during compile time.
test action and utilizes application specific simulation toolkits, e.g. “AutoIT” or “Rifidi”. The evaluation of the test is handled similar by including specific interfaces to the SUT, like “SQL”. Some concrete implementation examples of these TestDriver’s are shown in Section 5.4.