Environment

This section introduces the environment in which this case study has been performed. This includes the test setup consisting of the SUT and the test execution environment. Model-based testing strongly depends on tools that support the process of test case generation and execution. We created such a tool for TTask: Task-GEN. Task-GEN is a modeling environment and test case generator for task models.

9.1.1 Test Setup

The targeted system comprises all ECUs of the infotainment system due to the regarded features. For testing, these ECUs are integrated in a test rack where they are connected via the MOST and the CAN busses. Test scripts are executed from a test host that is connected to the MOST and CAN networks. In order to receive and make phone calls, the AIS is connected to a mobile phone via Bluetooth. In order to stimulate and receive these phone calls, the test host is connected to another mobile phone. Figure 9.1 depicts the testing environment. Test Rack Head Unit Phone Navigation Amplifier DVD Player MOST Bus CAN Bus Test Host MOST Adapter

Fig. 9.1. Testing environment.

9.1.2 Test Execution Environment

Model-based test case generation results in a potentially large number of test cases. In order to execute such a large number of test cases, the execution of them must be automated. However, the automated execution of test cases requires an environment that enables the automated stimulation of the SUT as well as automated test oracles. At BMW Group, test cases for infotainment systems are written in Python1 _{and use the BMW Test Automation Frame-}

work (TAF). TAF provides dierent test drivers which encapsulate function- alities to trigger and observe the system. An example is the ZBEService2_that

provides a simple application programming interface (API) to trigger joystick inputs via bus messages:

ZBE.Right() # send joystick turn right signal ZBE.Press() # send joystick press signal 1 _{http://www.python.org}

2 _{ZBE stands for zentrales Bedienelement which is German for central control} unit.

9.1 Environment 125 Test oracles are dened using test drivers that observe the system. For exam- ple, the following test oracle checks whether the screen change is fast enough:

MMI.WaitForText("Enter Destination", 1000) except TimeOut:

log(ERROR, "Timeout enter destination")

The MMIService enables the monitoring of the GUI using a screen grabber and OCR. The call to the WaitForText functions waits until the specied text occurs in the cursor or a timeout occurs. If a timeout occurs, a corresponding error is logged.

9.1.3 Task Modeling Environment - Task-GEN

Task-GEN is a graphical modeling environment for TTask models. A modeler can use Task-GEN to create task models with the graphical syntax that is described in Chapter 4.3. Furthermore with Task-GEN the modeler can de- ne multiple views on the same task model. This is advantageous for models with a large number of tasks, as the tasks can be distributed across multiple diagrams. The concept of dierent views on the same task model is depicted in Figure 9.2. This enables the separation of feature-specic behavior from feature interactions. We use the following task modeling procedure for our case study. First, all features are described in separate views. Then, the in- teractions between these features are described in additional views.

Task-GEN can automatically transform task models into Promela. There are two dierent modes for the transformation: one for the simulation of TTask models, and one for test case generation from TTask models. In order to simulate a TTask model, Task-GEN creates an open Promela model in which the start and stop of a task can be triggered by the modeler. The modeler can simulate the execution of tasks and Task-GEN provides visual feedback about the current task model state. Figure 9.3 shows a screen shot from Task-GEN in simulation mode. The left part of the screen shot shows the simulated task model. The task modes are represented by dierent colors during simulation. The right part shows the control view where the modeler can start and stop

Check Control Navigation

Navigation Check Control Check Control_Navigation

interaction

describes describes describes

Models Views

Fig. 9.3. Task-GEN.

the execution of a task. The actual simulation of the task model is performed with SPIN which runs in the background.

In order to generate test cases from a task model, Task-GEN supports the generation of closed Promela models. Based on these closed Promela models, Task-GEN can generate task sequences using the test selection criteria that were introduced in Chapter 5.4. Test case generation is performed in multiple steps. These steps are dened in the form of openArchitectureWare (OAW)3

workows.

Figure 9.4 shows the complete workow for the generation of test scripts from a task model. We use TTask to depict the workow. Each task represents a step in the workow. However, the actual workow is specied in XML. First, a task model is loaded and transformed into Promela code. The Promela code is then compiled into an executable model checker program. In the next step, a set of LTL formulas are generated for a given test selection criterion. Each LTL formula describes a trap property. For each generated LTL for- mula a task sequence is generated. This is performed by using SPIN to check the LTL formula against the model checker program. When SPIN nds no counter-example for the trap property, the task sequence generation is n- ished. Otherwise, SPIN creates a trail for the counter-example. Task-GEN parses the trail le and transforms it into a task sequence model. This task sequence model is then transformed into test scripts with AspectT. For each test focus, AspectT is invoked by loading a test focus specic aspect setup and by weaving it into the generated task sequence.

In the remainder of this chapter, we describe this workow on the basis of a real world example.

9.2 The Task Model 127