This article explains how sinelaboreRT helps you to test your state based software.

In the first part of this article we have seen how SinelaboreRT helps you to generate test cases to reach 100% transition coverage. But sinelaboreRT can do more. You can connect your running target with an automatically generated visualization, show the present state of the state machine, show possible triggers etc. - all visually. And finally it shows the actually reached transition coverage.

This article uses the microwave oven from the manual as example. Code is available in the examples folder of the code generator.

The first step is to close the link between the state machine running on the target with the sinelaboreRT visualization running on the PC. In this article we assume that the state machine was created with the built-in editor. If you have used another UML tool used just convert your model file into the sinelaboreRT internal format by using -l ssc as output format on the command line. The following example shows how to convert a cadifra model into the internal scc representation:

java -jar codegen.jar -p CADIFRA -l ssc -o oven.xml oven.cdd

To generate trace code use the -Trace command line switch. An example is shown as follows:

java -jar codegen.jar -c -Trace -p ssc -l cx -o oven oven.xml 

The trace function itself has to be provided by yourself because it is typically very system dependent. Within the trace function trace data can be sent to the monitoring PC. As the trace function is in your hand you can use whatever hardware interface is feasible to send the trace events. In most cases it might be a kind of serial uart interface. If you have a target with TCP/IP capabilities the use of UDP is recommended. The following code shows the trace function we use in this example.

void ovenTraceEvent(int evt){
    if (sendto(s,ovenTraceEvents[evt],
            strlen(ovenTraceEvents[evt]), 0,(const struct sockaddr *)&si_other,slen)==-1){
        perror("sendto\n");
        exit(1);
    }
}

To actually display the state diagram call the code generator with the -S command line switch. The window as shown in figure 1 pops up. The status of the state machine in its initial state is displayed.

java -jar codegen.jar -S -p ssc -o oven oven.xml

Figure 1: The example here is the microwave oven state machine used in the manual. It is available in the examples folders of the SinelaboreRT download.

he main window shows the automatically generated state diagram. Events that can be handled at that moment are shown in blue. They are also listed in left tree view. The output field on the bottom of the window shows the so far executed action code.

You can now send events to the machine by clicking on an event in the tree view. The display is updated accordingly and shows the new status.

But as we want to trace the real machine we need the connection between the target and the visualization. Therefore the code generator is able to receive events via UPD. This is what was shown in the code snipped above. Most embedded systems will not offer an Ethernet connection directly. In this case send the trace data e.g. via a serial interface to the PC and forward them from there via UDP to the visualization. This can be done in a view lines of code. This has been realized in the Asuro Mobile Robot example.

Now we have prepared the visualization. So let’s start the microwave oven example. To make it simple for you to follow this example the microwave oven code was compiled as a simple console program. This program allows you to set the cooking time, cooking power and to open and close the door via keyboard commands. When a cooking time was set and the door is closed the cooking starts. The console application prints out some debug messages e.g. how much cooking time is left. When the time is zero the microwave generator is switched off and the door must be opened before the next cooking cycle can start. The following figure shows just this situation. Cooking has ended. The actual state is “Completed”. As you can see only a transition coverage of 57% was reached during this test run.

Figure 2: While testing available transitions are displayed in blue and the active states in red. The presently achieved transition coverage is shown as progress bar below the event list.

The transitions not yet taken can be displayed as tooltip of the progress bar. As you can see we have not yet changed the cooking power nor have we opened the door while cooking.

With this information at hand it is easy to add the missing transitions to the test script to reach the 100% transition coverage. Be aware that 100% transition coverage also means 100% state coverage!

So far we have interactively tested the device i.e. the console application in our case. To avoid this manual interaction (which is really annoying for large machines) it is highly recommended to create a test environment that can be fed with the test routes generated from the code generator (see first part of this article series). This pays back quickly if extensions or bug fixes are necessary and regression tests must be performed.

Even with 100% transition coverage you have only tested what was modeled. Often transitions that do not lead to a state change are omitted during the initial design. But from a testing point of view it is highly recommended to model such transitions too. Then the test route automatically include steps that check if the machine reacts correctly to transitions that do not change state!

Of course also perform boundary tests of used variables. For the microwave oven machine check for example what happens if the cooking time is zero and you still decrement it, or if it has reached its maximum and you still increment it etc. See the two recommended books listed in the first part of the article for many more practical hints.

We close this article with citing again Martin Gomez who wrote “ … require a fair amount of patience and coffee, because even a mid-size state machine can have 100 different transitions. However, the number of transitions is an excellent measure of the system's complexity. The complexity is driven by the user's requirements: the state machine makes it blindingly obvious how much you have to test. With a less-organized approach, the amount of testing required might be equally large-you just won't know it.”

This article has shown how sinelaboreRT helps you in testing your state based software. Therefore the different steps of testing were presented and how the sinelaboreRT code-generator supports you during the different test steps was discussed in detail.

We hope you enjoyed these two articles. Your feedback is very welcome!