Testabdeckung für Prozessmodelle

Wer ein Modell nur anschaut, findet formale Fehler – eine Sackgasse, ein Gateway ohne Bedingung. Ob das Modell das Richtige tut, zeigt erst ein Durchlauf mit echten Werten. Ein solcher Durchlauf mit Eingabe und erwartetem Ergebnis ist ein Testfall. Und wie bei Software lässt sich messen, wie viel vom Modell die Testfälle durchlaufen haben.

Das Beispiel: VinoPur

Ein Kunde bestellt ein bis sieben Liter Wein. Der Weinhändler hat nur zwei Karaffen, eine mit 5 und eine mit 7 Litern Fassungsvermögen. Der Weinhändler misst die Menge durch Umfüllen ab: ungerade Mengen von der kleinen in die große Karaffe, gerade Mengen von der großen in die kleine. Im Modell stecken zwei Teilprozesse mit Schleifen – klein, aber mit vielen Wegen: 46 Knoten, 49 Sequenzflüsse und 14 Ausgänge an verzweigenden Gateways.

Kollaboration Kunde, Weinverkäufer und Weinhändler mit den Teilprozessen „Wein abfüllen ungerade“ und „Wein abfüllen gerade“ — **VinoPur.** Kunde, Verkauf und der Weinhändler mit den beiden Abfüll-Teilprozessen. Jede Schleife prüft, ob die Zielmenge erreicht ist.

Drei Maße für Abdeckung

Knoten (entspricht der Anweisungsüberdeckung C0): Jede Aktivität, jedes Ereignis und jedes Gateway wurde mindestens einmal erreicht.
Sequenzflüsse (entspricht der Zweigüberdeckung C1): Jeder Fluss wurde mindestens einmal durchlaufen – auch ein Zweig, auf dem gar keine Aufgabe liegt. Das ist strenger als Knoten.
Entscheidungen: Jeder Ausgang jedes verzweigenden Gateways wurde mindestens einmal genommen. Das zeigt, ob jede fachliche Alternative einmal vorkam.

Welche Fälle braucht man?

Wir haben die Bestellmengen in der Simulation abgespielt und die Abdeckung gemessen:

Testfälle (Liter)	Sequenzflüsse	Bemerkung
{2}	30 / 49	nur der gerade Teilprozess, ohne Leeren einer Karaffe
{1}	33 / 49	ungerade, mit „große Karaffe leeren“
{4}	33 / 49	gerade, mit „kleine Karaffe leeren“
{1, 4}	49 / 49	dazu 46 / 46 Knoten und 14 / 14 Entscheidungen
{1 … 7}	49 / 49	sieben Fälle, kein Weg mehr als mit zwei

Zwei gut gewählte Fälle reichen also für volle Abdeckung, sieben bringen keinen weiteren Weg. Die Grenzwerte 1 und 7 sind fachlich trotzdem sinnvoll – aber die Frage beim Testentwurf lautet „welche Fälle?“, nicht „wie viele?“.

Ein Testfall braucht eine Erwartung

Abdeckung allein sagt nur, welche Wege durchlaufen wurden – nicht, ob das Ergebnis stimmt. Zu jedem Testfall gehört deshalb das erwartete Ergebnis, bei VinoPur die Füllstände am Ende und der Preis:

Menge	Endstand klein / groß (l)	Preis
1	1 / 7	7 €
2	5 / 2	14 €
3	3 / 7	21 €
4	5 / 4	28 €
5	0 / 5	35 €
6	5 / 6	42 €
7	3 / 7	49 €

Der Regressionstest

Jetzt bauen wir einen Fehler ein: Die große Karaffe fasst im Modell nur noch 6 statt 7 Liter, die Beschriftung sagt weiter „7 l“. Die statische Prüfung findet nichts – das Modell ist formal korrekt. Die gespeicherten Testfälle dagegen schlagen an: Die Fälle 1 und 3 werden rot, 6 und 7 kommen nicht mehr zu Ende, weil die Schleife die Zielmenge nie erreicht. Die Fälle 2, 4 und 5 bleiben grün.

Die Menge {1, 4} mit voller Abdeckung findet den Fehler über Fall 1. Wer nur den naheliegenden Fall 2 getestet hätte, hätte ihn übersehen. Umgekehrt gilt aber auch: Hätte der Fehler nur die Mengen 6 und 7 betroffen, hätte {1, 4} trotz 100 % Abdeckung nichts gefunden. Abdeckung zeigt Lücken im Test, sie beweist nicht, dass das Modell stimmt.

Faustregeln

Zuerst statisch prüfen, dann mit Fällen testen – beides findet unterschiedliche Fehler.
Fälle nach Wegen wählen: jeder Sequenzfluss mindestens einmal.
Grenzwerte dazunehmen, auch wenn sie keine neuen Wege bringen.
Jeder Fall mit Erwartung, sonst ist es nur ein Durchlauf.
Fälle beim Modell speichern und nach jeder Änderung alle wieder laufen lassen.

Das Beispiel stammt aus dem Seminar Große Modelle, klarer Kopf; gemessen mit der Testabdeckung in Synixx.