Test clients can be generated from interface and component models. A test client generates on-the-fly test sequences of events based on the used model (interface or component) and sends these events to a system under test. An adapter is used as intermediary between the test client and the system under test. The adapter receives events from the test client and translates them to calls understandable by the system under test. It also receives the responses from the system under test and translates them to events understandable by the test client.

If the used interfaces contain triggers with parameters, replies and notifications with variables or any (*) value then one or more parameters file are required.

In order to generate a test client, add a new task to the .prj file similarly to the example:

import "Camera.interface"

Project Camera {

	Generate TestClient {
		// For components, use "for component" instead
	    Testclient_ICamera for interface ICamera
	    {
            // Input parameters for the interface (only required when the interface has commands/signals with input parameters and replies/notifications with variables or any (*) expression)
	        params: "ICamera.params"
	    }
	}
}

To generate the test client, run the .prj (right click on the .prj file → Run AsRun generators). The client can be started by executing the generated .bat/.sh in the src-gen/testclient folder.

Once the test client is started you will see a window like below:

image

The path to the executable file for the adapter has to be given in the field to the left of the 'Start' button. Pressing this button will start the adapter and the test client. The label of the button changes to 'Stop'. The events sent to and received from the system under test are shown in the window. The test process can be stopped by pressing the button 'Stop'. The process may also stop of its own if no further events can be generated based on the model or if an error is detected. Pressing 'Save Coverage Info' creates a file with information about the visited model states and the transitions that were traversed.

The test client works as follows:

  • In case of an interface model, the test client selects commands and signals that are allowed at the current state of the interface model and sends them to the system under test via the adapter. The system under test may respond with reply or notifications. The test client checks if the received events are allowed in the current state and if the parameter values conform to the ones given in the model.

  • In case of a component model, the test client selects one of the allowed commands or signals on a provided port or one of the allowed reply or notifications on a required port. The chosen event is sent to the system under test. It in turn may respond with reply/notifications on a provided port or a command/signal on a required port. The received event is checked against the component model.

The adapter plays a crucial role in the described communication. It is usually implemented manually, the implementation reflects the specifics of the system under test.

The interaction between the test client and the adapter is as follows:

  • The test client starts the adapter, which in turn may need to initialize and start the system under test.

  • The test client and the adapter communicate via the standard input/output. The events are in JSON format following the structure described on the JSON events file page.

  • The adapter reads events from the standard input, translates the event and the parameter data (in JSON) to a call with parameter values specific to the system under test.

  • The adapter converts the input from the system under test to a JSON event and sends it to the test client.

The values in parameters files are used by the test client depending on the scenario:

  • In case of interface model, the parameters for commands are signals are used.

  • In case of component model, the parameters for commands and signals on provided ports are used as well as the parameters for replies and notifications on required ports.

Limitations:

  • Test client for component models:

    • Currently, usage of variables of type id that are used to identify the communication party of a component are not supported

    • Component models with parts are not supported (compound components)

  • Time and data constraints are not supported

Structure of transition coverage files

Transition coverage files contain comma-separated value data. For example:

Port,Interface,Clause,SourceLine
vmUserPort,IUser,C_AcceptUserCommands_0_InsertCoin()_0_0,18
vmUserPort,IUser,C_AcceptUserCommands_4_OrderProduct()_1_0,56
vmServicePort,IService,C_Operational_ias0.0_NonTriggered_0_0,11

Clauses in the transitions are identified by the following naming scheme. For easier tracing back to the original source file, the line number is given.

For transitions with a trigger:

C_<stateName>_<indexOfTransitionInState>_<TriggerName>_<indexOfClause>_0

For transitions without a trigger:

C_<stateName>_<indexOfTransitionInState>_NonTriggered_<indexOfClause>_0

Observe 'NonTriggered' in the example.

The following example shows that the transition is defined in 'in all states' block (observe the 'ias' part).

C_<stateName>_ias<indexInAllStates>.<indexTransition>_<TriggerName>_<indexClause>_0