Fußnoten Kap. 1

Fußnoten Kap. 2

Fußnoten Kap. 3

Fußnoten Kap. 4

Fußnoten Kap. 5

Fußnoten Kap. 6

Fußnoten Kap. 7

Fußnoten Kap. 8

Fußnoten Kap. 9

Fußnoten Kap. 10

Fußnoten Kap. 11

Fußnoten zu Kapitel 6

1 Gemessen in LOC auf Java-Basis = Lines-Of-Code inklusive Kommentare. Dennoch wurden nur zirka 20% des Gesamtaufwands und damit vergleichsweise wenig in die Entwicklung und Wartung der Testfälle gesteckt.

2 Der englische Begriff bug stammt von [Hop81], in dem beschrieben wird, wie eine Motte sich in einem Relay fing und daraufhin die Suche von Fehlern mit der Suche von Käfern identifiziert wurde. 3

3 Bug findet sich mittlerweile auch im deutschen Sprachgebrauch, hat sich aber nur in der Umgangssprache durchsetzen können. In diesem Buch wird deshalb der Begriff Fehler verwendet. . In diesem Buch wird jedoch der Begriff Fehler als Synonym für Bug verwendet und darunter generell das Versagen des Systems verstanden, das durch eine Anwenderaktion, eine Interaktion mit der Systemumgebung oder einen Test herbeigeführt wurde.

4 Das zum Beispiel in [PKS02] verwendete „Testobjekt“ kann auch ein Teilsystem sein und aus mehreren Objekten bestehen. Es ist daher irreführend. In [Bin99] wird der Begriff „test point“ für einen Testdatensatz verwendet, der sehr schön die exemplarische, punktuelle Natur eines Tests herausstellt. Der TTCN-Standard [ISO92] unterscheidet weitere Testurteile. Zusätzlich zum Testerfolg („pass“) gibt es zwei Arten des Scheiterns („failure“, „error“) und die Alternativen „inconclusive“ und „none“, in denen das Testziel nicht geprüft werden konnte. Das Testurteil wird dort auch als „Verdikt“ bezeichnet. Das Testurteil „error“ kann in Java zum Beispiel als Terminierung des Testlings durch eine Exception interpretiert werden.

5 Der Begriff „Testmodell“ wurde bereits in Abbildung 4.1 eingeführt. Aufgrund des Generierungsaspekts aus UML-Modellen wird er dort etwas enger definiert, als zum Beispiel im Rational Unified Process [Kru03], in dem eine manuelle Umsetzung in Skripte und Testtreiber vorgeschlagen wird, die ebenfalls zum Testmodell gezählt werden. Werden die genannten Diagramme im Entwicklungsprozess zunächst nur zur Kommunikation der Entwickler untereinander oder zur abstrahierten Darstellung verwendet, so müssen diese normalerweise umgeformt und detailliert werden, um daraus Testmodelle zu erhalten, die zur Generierung von Tests geeignet sind. In den Kapiteln 4 und 5 wurde die Umsetzung einzelner Diagramme und OCL-Bedingungen in Code für einen Einsatz in Tests bereits ausführlich diskutiert. Dieses Kapitel wird daher den methodischen Einsatz durch Kombination dieser UML/P-Artefakte zu Testfällen für Konformitätstests besprechen.

6 Beispielsweise nutzt Ericsson Java zur Modellierung von Funktionstests im Mobilfunkbereich und TTCN [ISO92] nur für die Protokollvalidierung (Stand 2004).

7 Eine Abstraktion Ab definiert eine Äquivalenz durch x y Ab(x) = Ab(y).

8 JUnit verwendet den Begriff des „Failure“ für ein Scheitern des Tests und „Error“ für eine anormale Terminierung der Testdurchführung durch Exception. des Tests verwendet werden können. Diese Methoden werden aus der Klasse TestCase geerbt.


Bernhard Rumpe. Agile Modellierung mit UML. Springer 2012