Zum modellbasierten funktionalen Test reaktiver Systeme

2.2. Testen
Beispiel 3 (Testziel, Testfallspezifikation, Testfall). Im Fall der Chipkarte
ist eine relevante Eigenschaft E die, daß eine Signatur nur dann berechnet
werden kann, wenn die zugehörige PIN verifiziert ist. Bei intuitivem Verständnis
der Zustandsprädikate lautet die zugehörige Formel
E ′ ≡ AG(CardResponse = SignatureComputed ⇒ PINStatus = Verified). 4
E und E ′ sind das Testziel. Eine zugehörige Testfallspezifikation beschreibt dann
eine endliche Menge endlicher Kommandofolgen, die schließlich das Kommando
zur Berechnung der digitalen Signatur enthalten.
• Das können z.B. alle Traces des zugehörigen Modells bis zur Länge 5
sein, die vom zugehörigen Testfallgenerator mit einem Kommando der
Art ”
computeAllTracesUpToLength(5)“ berechnet werden. Da diese Tracemenge
sehr groß ist, wird in der Praxis ein weiteres Selektionskriterium
angewendet, z.B. ”
zufällig ausgewählte 2% aller Traces der Länge 5“. Die
berechneten Traces sind dann die Testfälle.
• Da der Status der PIN in der tatsächlichen Karte nun noch nicht überprüft
wurde, muß an jeden dieser Traces eine Kommandosequenz angehängt
werden, die den Zustand der PIN überprüft. Dazu kann das Kommando
VerifyCheck“ verwendet werden, das für eine gegebene PIN deren Status
liefert. In der Testfallspezifikation muß also spezifiziert werden, daß
”
an jeden erzeugten Trace der Länge 5 das Kommando VerifyCheck“ angehängt
”
wird.
Offenbar stellt die Einschränkung auf Traces der Länge 5 eine Approximation
der ursprünglichen Eigenschaft E ′ dar, die für alle Traces spezifiziert wurde.
Darüberhinaus ist nicht gewährleistet, daß das Kommando ”
VerifyCheck“ auch
tatsächlich den in der Karte vorhandenen Status der PIN ausgibt. Das kann
durch weitere Kommandos überprüft werden, auf die die Karte in Abhängigkeit
vom tatsächlichen internen PIN-Zustand unterschiedliche Antworten liefert.
Dieses Beispiel wird in Beispiel 13 auf den Seiten 77 ff. weiter ausgeführt.
Die Unterscheidung ist nicht trennscharf: Testziele können bereits Testfallspezifikationen
oder sogar Testfälle sein.
Intuitiv ergibt sich eine ungefähre Analogie, wenn
• Testziele mit Lasten- oder Pflichtenheften,
• Testfallspezifikationen mit Spezifikationsdokumenten und
• Testfälle mit (Maschinen-)Implementierungen
verglichen werden. Der Übergang von Testziel zu Testfallspezifikation kann,
wenn ersteres formalisiert vorliegt, als Verhaltensverfeinerung verstanden werden.
Dasselbe gilt für den Übergang von Testfallspezifikationen zu Testfällen.
4 Dabei wird der Einfachheit halber davon abstrahiert, daß in der WIM die Berechnung der
Signatur die PIN wieder in einen nicht-verifizierten Zustand versetzt, vgl. Beispiel 13 auf
S. 77 ff.
29