Zum modellbasierten funktionalen Test reaktiver Systeme

4. Testfallgenerierung
D zugleich Testdaten für E auf ie1 dar und die Ausgaben von E auf oe1 Testdaten
für D auf id2 . Nach Berechnung der entsprechenden Eingaben ergeben
sich erweiterte Testsuiten T
D ′ ∪ T D und T
E ′ ∪ T E.
Umgekehrt können die Eingaben aus T D auf id2 als putative Ausgaben von
E auf oe1 und die Eingaben aus T E auf ie1 als putative Ausgaben von D auf
od2 aufgefaßt werden. Mit der symbolischen Ausführung können so die fehlenden
Ein- und Ausgaben berechnet werden, um erweiterte Testsuiten T
D ′′ ∪ T D
′
und T
E ′′ ∪T E ′ zu erhalten. Wenn beispielsweise Eingaben auf ie1 zur Testfallgenerierung
für D verwendet werden soll, dann müssen entsprechende Eingabewerte
für id1 und id2 sowie Ausgaben für od1 berechnet werden. Offenbar liefern die
erweiterten Testsuiten T
D ′′ und T
′′
E
auch neue Testfälle für die übergeordnete
Komponente C.
Das ist die Grundidee der kompositionalen Testfallerzeugung. Dieses einfache
Verfahren funktioniert in der Allgemeinheit nicht immer. Wenn beispielsweise
T ′′
D auf der Grundlage von ie1 aus T E berechnet wird, dann muß gleichzeitig
auf eine Übereinstimmung von oe1 und id2 geachtet werden. Unter Umständen
ist das gar nicht möglich, weil die Verschaltung von C und D bestimmte Abläufe
von C oder D allein gar nicht zuläßt.
Umweltannahmen Ein einfaches Beispiel illustriert den Zusammenhang. Wenn
D eine Timer-Komponente ist, die in periodischen Abständen auf od2 einen
Timeout sendet, dann kann es bei der Generierung von Testfällen für E in Isolation
durchaus passieren, daß diese Testfälle Timeouts in nicht periodischen
Abständen verlangen. Das kann dann eintreten, wenn die Information über die
Periodizität der Timeouts nicht explizit in E codiert ist. Das Verhalten einer
isolierten Komponenten ist üblicherweise eine Erweiterung der entsprechenden
Projektion eines integrierten Systems (die tatsächlich ausführbare Tracemenge
wird erweitert). Komposition mit anderen Komponenten führt dann zu einer
Konkretisierung. Dieses Phänomen wird bei der Verwendung von Testmodellen
(Abschnitt 2.3.1) zur Reduktion des Suchraums ausgenutzt.
Der Sachverhalt ist Instanz eines übergeordneten Problems. Komponenten
sind wie Prozeduren insofern unterspezifiziert, als sie normalerweise stets implizite
Annahmen an die Eingabeparameter (und in reaktiven Systemen an deren
Reihenfolge) beinhalten. Es ist u.a. genau diese Beobachtung, die
• zu Assumption-Commitment-artigen Spezifikationstechniken,
• zur Einführung von Kontrakten (Meyer, 1992) (insb. des – beliebig schwachen
– requires-Teils) in Sprachen wie Eiffel oder von Annotationen in
Spark-Ada oder statischen Analysetools wie ESC und
• zur Erweiterung von Schnittstellenspezifikationen mit Verhalten (Nierstrasz
und Papathomas, 1990; Nierstrasz, 1995) – Typen als partielle Verhaltensspezifikation
–, die insbesondere in dynamischen Dienstarchitekturen
eine Rolle spielt,
geführt hat (vgl. auch de Alfaro und Henzinger (2001) zur legalen Komposition
bzgl. einer vs. aller möglichen Umgebungen). AutoFocus gestattet bei der
128