28.12.2013 Aufrufe

Zum modellbasierten funktionalen Test reaktiver Systeme

Zum modellbasierten funktionalen Test reaktiver Systeme

Zum modellbasierten funktionalen Test reaktiver Systeme

MEHR ANZEIGEN
WENIGER ANZEIGEN

Erfolgreiche ePaper selbst erstellen

Machen Sie aus Ihren PDF Publikationen ein blätterbares Flipbook mit unserer einzigartigen Google optimierten e-Paper Software.

4. <strong>Test</strong>fallgenerierung<br />

findet sich in Abb. 4.16 (i). Für diese Formel existieren zwei MC/DC-<strong>Test</strong>suiten,<br />

nämlich S 1 = {1, 5, 6, 8} und S 2 = {4, 5, 6, 8}. In S 1 ändern die Fälle 1 und 5<br />

den Wert von a und den von F , (5, 6) ändern c, und (6, 8) ändern b. In S 2<br />

ändern (4, 8) den Wert von a anstelle von (1, 5) in S 1 (Abb. 4.16 (v)).<br />

MC/DC-<strong>Test</strong>suiten existieren nicht immer (Tautologien oder direkte Abhängigkeit<br />

eines Literals von einem anderen):<br />

Beispiel 21 (Nichtexistenz einer MC/DC-Belegung). Die EFSM der<br />

Komponente WIMPre verteilt das Kommando zur Berechnung der digitalen Signatur<br />

an die Komponenten CardholderVerification und SecurityOperations.<br />

Alle anderen Kommandos, die von CardholderVerification bearbeitet<br />

werden, werden ausschließlich von dieser Komponente bearbeitet. Demzufolge<br />

gibt es in WIMPre eine Transition<br />

c?Cmd: isVerificationCommand(Cmd)&&not(is PSOComputeDigSig(Cmd)):<br />

cv!Cmd.<br />

Für das Kommando PSOComputeDigSig(X ) gilt nun<br />

isVerificationCommand(PSOComputeDigSig(X)) und zugleich (ausschließlich)<br />

is PSOComputeDigSig(PSOComputeDigSig(X)). Offenbar kann es für den<br />

Wächter der Transition keine MC/DC-Suite geben. Es gilt nämlich<br />

is PSOComputeDigSig(PSOComputeDigSig(X)) ⇒<br />

isVerificationCommand(PSOComputeDigSig(X)).<br />

Bedingungen Um automatisiert MC/DC-<strong>Test</strong>suites für Modelle <strong>reaktiver</strong> <strong>Systeme</strong><br />

berechnen zu können, besteht ein erster Schritt darin, eine MC/DC-<br />

<strong>Test</strong>suite für Bedingungen F zu berechnen. Der folgende Algorithmus erledigt<br />

das.<br />

Für n Variablen seien alle Belegungen durch mit 1 beginnende aufeinanderfolgende<br />

Zahlen benannt. In einem ersten Schritt wird jeder <strong>Test</strong>fall i für<br />

1 ≤ i < 2 n mit allen folgenden <strong>Test</strong>fällen j, i < j ≤ 2 n verglichen, und wenn ein<br />

Paar (⃗v, ⃗w) = ((v 1 , . . . , v n ), (w 1 , . . . , w n )) von Variablenbelegungen die MC/DC-<br />

Bedingung erfüllt, d.h.<br />

∃k • ¬(F (⃗v) ↔ F ( ⃗w)) ∧<br />

n∧<br />

v i ↔ w i ∧ ¬(v k ↔ w k )<br />

i=1<br />

i≠k<br />

gilt, wird diese Information abgespeichert (Abb. 4.16 (ii)). Kanten repräsentieren<br />

Variablen, Knoten repräsentieren <strong>Test</strong>fälle. Wenn eine MC/DC-<strong>Test</strong>suite<br />

existiert, muß also eine Kantenabdeckung des Graphen gefunden werden, so<br />

daß jede Kantenbeschriftung genau einmal vorkommt. Dualisiert man den Graphen<br />

(Abb. 4.16 (iii)), so muß offenbar eine minimale Knotenabdeckung gefunden<br />

werden, so daß der Teil der Beschriftung, der eine Variable repräsentiert,<br />

genau einmal vorkommt. Da nun bekannt ist, daß im Fall der Existenz einer<br />

MC/DC <strong>Test</strong>suite diese aus n + 1 <strong>Test</strong>fällen besteht, so reduziert sich die Suche<br />

auf zusammenhängende Pfade. Tatsächlich ist die explizite Graphenbildung gar<br />

nicht nötig, sondern die Information kann direkt aus der Gruppenbildung des<br />

ersten Schritts entnommen werden (Abb. 4.16 (iv)). Die <strong>Test</strong>fälle müssen dann<br />

134

Hurra! Ihre Datei wurde hochgeladen und ist bereit für die Veröffentlichung.

Erfolgreich gespeichert!

Leider ist etwas schief gelaufen!