110 5 Wirksame Testfälle entwickeln *

Transkript

1 110 5 Wirksame Testfälle entwickeln * Zur Ableitung der Testfälle verwenden Tester bei den spezifikationsorientierten Verfahren die erstellten Entwicklungsmodelle. Da die Spezifikationen als Dokumentation des Produktentwurfs einen wichtigen Bestandteil des Entwicklungsmodells darstellen, werden Black-Box-Tests auch als spezifikationsorientierte Testtechniken bezeichnet. Synonym verwendet wird auch die Bezeichnung funktionsorientierte Testtechnik, die stärker auch den in einer Spezifikation beschriebenen fachlichen oder technischen Funktionsumfang namentlich berücksichtigt:»spezifikationsorientierte Testtechniken«, S. 110 Die Struktur der Software, also der entwickelte Quellcode, unterstützt den Tester bei der Entwicklung geeigneter Testfälle. Diese Testtechniken werden aus diesem Grund auch als strukturorientierte Testtechnik oder als White-Box- Tests bezeichnet:»strukturorientierte Testtechniken«, S. 149 Beim freien Testen wird dem Tester größtmögliche Autonomie eingeräumt. Die Methoden stellen somit die Kompetenz der Mitarbeiter in den Vordergrund. Formale Aspekte wie Planbarkeit, Fortschritts- und Vollständigkeitskontrolle sind bei diesen Verfahren weniger wichtig, führen aber in der Praxis vielfach zu Problemen:»Freies Testen«, S. 169 Spezifikationsorientierte Verfahren Strukturorientierte Verfahren Freies Testen Designfehler 5.1 Spezifikationsorientierte Testtechniken * Bei den spezifikationsorientierten Testtechniken werden die Testfälle aus dem Entwicklungsmodell abgeleitet. Das Entwicklungsmodell beschreibt als Testbasis den Sollzustand und dient der Verifizierung des IST-Zustandes, der am Testobjekt durch den Testfall ermittelt wird. Die Vollständigkeit des Tests kann durch die relative Anzahl der überprüften Testbedingungen dargestellt werden, die in diesem Buch auch als funktionale Überdeckung bezeichnet wird. Hierbei lassen sich vielfach auch Fehler in den Entwicklungsmodellen selbst ermitteln, was jedoch nicht das primäre Ziel ist. Die vorgelagerte Qualitätssicherung der Dokumente er-

2 5.1 Spezifikationsorientierte Testtechniken * 111 senbildung werden mögliche Eingangs- und Ausgangswerte klassifiziert. Es wird auf diese Weise möglich, nur mit sinnvollen Repräsentanten dieser Klassen zu testen. Hierdurch wird die Anzahl der Testfälle auf Tests mit wenigen Repräsentanten begrenzt:»funktionale Äquivalenzklassenbildung«, S. 112 Auch die Grenzwertanalyse konzentriert sich auf die Definition von Eingangs- und Ausgangswerten. Sie fordert durch ihre Ableitungsregeln mit den Grenzwerten der Klassen zu testen. Die Grenzwertanalyse ist daher eine sinnvolle Ergänzung der funktionalen Äquivalenzklassenbildung, kann aber auch eigenständig verwendet werden:»grenzwertanalyse«, S. 119 Durch Entscheidungstabellen werden die Kombinationen möglicher Eingangs- und Ausgangsbedingungen in den Vordergrund gestellt. Neben den Werten selbst ist auch die Abhängigkeit einzelner Bedingungen untereinander für den Test wichtig bei der Ableitung wirksamer Testfälle: folgt mittels Prüfungen, so dass für den Testfallentwurf zunächst mangelfreie Konzepte unterstellt werden. Dies ist selbstverständlich praktisch selten der Fall, was eine Begründung dafür ist, dass auch während des Testens neue Anforderungen umzusetzen sind. Die spezifikationsorientierten Testtechniken nutzen als Modellbasiertes Testbasis die Entwicklungsmodelle und auch die Metamodelle, die zur Software-Entwicklung erstellt wurden. Die Ent- Testen wicklungsdokumente sind deshalb für die Entwicklungsaufgabe optimiert, eignen sich umgekehrt aber als Testbasis oft nur mit Einschränkungen. Beim sogenannten modellbasierten Testen umfassen die Entwicklungsmodelle die Bedürfnisse der Tester. Teilweise werden sogar bestehende Modellierungssprachen durch spezielle Notationen erweitert. Zielsetzung ist in diesen Fällen der automatische Entwurf von Testfällen aus dem Modell. Die unterschiedlichen spezifikationsorientierten Testtechniken konzentrieren sich auf verschiedene Aspekte beim Testfallentwurf. Ziel aller Techniken ist die Reduktion der möglichen Testfälle auf ein vernünftiges Minimum. Durch die Anwendung der funktionalen Äquivalenzklas- Eingangsbedingungen klassifizieren Repräsentanten auswählen Abhängigkeiten beachten

3 112 5 Wirksame Testfälle entwickeln * Notationen verwenden Historien hinzuziehen Anwendersicht berücksichtigen»entscheidungstabellentest«, S. 123 Die Herleitung von Entscheidungstabellen sollte nach festen Regeln erfolgen. Die Ursachen-Wirkungsanalyse bietet derartige Regeln und verfügt zudem über eine eigene Notation, die zur grafischen Darstellung von Entscheidungstabellen verwendet werden kann:»ursachen-wirkungsanalysen«, S. 125 Zustandsbezogene Tests gehen auf die Historie des Testobjektes ein. Neben den Werten der Bedingungen oder der funktionalen Abhängigkeit von Bedingungen bezieht diese Methode auch die möglichen Zustände des Testobjektes in den Test mit ein:»zustandsbezogener Test«, S. 134 Insbesondere zur Produktvalidierung ist es notwendig, die Testfälle aus Sicht des Anwenders zu formulieren. Wurden bei der Produktspezifikation Anwendungsfalldiagramme verwendet, kann aus den Dokumenten die Ableitung vorgenommen werden:»anwendungsfallbasierter Test«, S Funktionale Äquivalenzklassenbildung ** Methodisch ist die funktionale Äquivalenzklassenbildung den funktionsorientierten Testtechniken zuzuordnen. Die interne Programmstruktur des Testobjektes ist dem Tester daher unbekannt. Seine Testfälle beziehen sich auf die in der Spezifikation beschriebenen Funktionen. Um den Testaufwand zu minimieren, werden gleichwertige Eingangsbedingungen zu funktionalen Äquivalenzklassen gruppiert. Bei der dann folgenden Testfallplanung werden nur ausgewählte Repräsentanten der funktionalen Äquivalenzklassen als Eingangsbedingung des Testfalls berücksichtigt. Hintergrund Die funktionale Äquivalenzklassenbildung ist eine grundlegende Methode, um identifizierte Testbedingungen mit einer geringen Anzahl wirksamer Testfälle zu testen. Ausgangspunkt der Analyse ist eine einfache funktionale Betrachtung des Testobjektes, bei der Bedingungen bzw. Eingangsbedingungen, die Verarbeitung im Sinne des fachli-

4 5.1 Spezifikationsorientierte Testtechniken * 113 chen bzw. technischen Funktionsumfangs und die Ausgabe als Aktion unterschieden werden. Da es sich um eine spezifikationsorientierte Testtechnik handelt, wird die strukturelle Umsetzung des Funktionsumfangs nicht näher betrachtet. Die Beschreibung des Funktionsumfangs wird zur Ableitung der Testbedingungen verwendet. Hierbei bleiben bei der Äquivalenzklassenbildung die funktionalen Abhängigkeiten der Eingangsbedingungen, Grenzwerte und Vorbedingungen weitgehend unberücksichtigt. Diese Nachteile lassen sich durch andere Testtechniken kompensieren, die im Falle höherer Qualitätsanforderungen anzuwenden sind. Für jede Testbedingung werden die Wertebereiche der Eingangsbedingungen und auch der möglichen Transformationsergebnisse bestimmt und als Äquivalenzklasse bezeichnet. Der Wertebereich ergibt sich immer aus den Werten, die sich dem gleichen funktionalen Verhalten zuordnen lassen. Eine Webanwendung zur Verwaltung von Kundeninformationen ist in der Lage bis zu Kunden zu verwalten. Eine bestimmte Funktion erfordert als Eingangsbedingung die Kundennummer. Eine sinnvolle Äquivalenzklasse wären Kundennummer von eins bis Da die jeweiligen Nummern immer zum gleichen funktionalen Verhalten führen sollten. Wie wäre es aber mit ? Wie das Beispiel 1a zeigt, kann es pro Eingangsbedingung verschiedene Äquivalenzklassen geben. Mindestens eine gültige und darüber hinaus eine oder auch mehrere ungültige Klassen. Vorbereitung Beispiel 1a Anzahl Äquivalenzklassen Die Werte werden einer ungültigen Beispiel 1b Äquivalenzklasse zugeordnet. Zur Bildung der Testfälle wird lediglich ein einzelner, beliebiger Wert als Repräsentant der gesamten Äquivalenzklasse einbezogen. Die Anzahl der Testfälle wird deshalb begrenzt, da nur mit einem einzigen Wert eines Wertebereichs getestet werden muss. Als Maß der Testvollständigkeit gilt die funktionale Überdeckung. Es ergibt sich bei der Äquivalenzklassenanalyse aus der relativen Anzahl der in Repräsentant

5 114 5 Wirksame Testfälle entwickeln * den Test einbezogenen Äquivalenzklassen. Zu berücksichtigen sind sowohl Äquivalenzklassen der Eingangsbedingungen aber auch der möglichen Aktionen. Werden mehrere Eingangsbedingungen für einen einzelnen Testfall benötigt, können auch mehrere Äquivalenzklassen abgedeckt werden. In [MBT+04, S. 55] wird jedoch empfohlen, pro Testfall maximal eine ungültige Äquivalenzklasse einzubeziehen, denn die Überlagerung von ungültigen Klassen kann zur Fehlermaskierung führen. Beispiel 1c Das Programm»Kundenwert«soll nach Eingabe eines monatlichen Umsatzes den Kunden einer Kategorie zuordnen. Hierbei gilt, dass umsatzstarke Kunden der Kategorie»A«zugeordnet werden, wenn sie monatlich mehr als 1000 umsetzen. Die Kategorie»B«wird verwendet, wennderumsatzgrößer500 aber maximal 1000 beträgt. Wer einen niedrigeren Umsatz als 500 hat, wird als»c«kunde klassifiziert. Die möglichen Äquivalenzklassen und benötigten Testfälle werden in Tab dargestellt. Die Bezeichnung gäq wird für eine gültige Äquivalenzklasse verwendet und uäq für eine ungültige Äquivalenzklasse. Da es mehrere gültige und auch ungültige Klassen gibt, werden sie nummeriert. Testfall Typ fkt. Äquivalenzklasse Wertebereich Repräsentant T 1 gäq1 Eingangsbedingung > T 2 gäq2 Eingangsbedingung >500 und T 3 gäq3 Eingangsbedingung T 4 uäq1 Eingangsbedingung <0-350 T 1 gäq4 Transformationsergebnis T 2 gäq5 Transformationsergebnis T 3 gäq6 Transformationsergebnis A B C A B C Tab : Äquivalenzklassen.

6 5.1 Spezifikationsorientierte Testtechniken * 115 Die Bestimmung»aller«Äquivalenzklassen ist vielfach nicht möglich, da zur vollständigen Absicherung der Quellcode als Testbasis dienen müsste. Da aber die Entwicklungsmodelle die Testbasis bilden, besteht in aller Regel diese Option gar nicht. Vielfach werden deshalb zunächst initiale Äquivalenzklassen erstellt und ggf. in weitere Teilmengen (neue Äquivalenzklassen) zerlegt. Es sind dann weitere Testfälle mit den neuen Repräsentanten erforderlich. In [MBT+04, S. 55] werden einige Regeln vorgeschlagen, mit denen sich Äquivalenzklassen bilden lassen: Betrachtung von Wertebereichen: Basieren die Eingabeparameter auf einem Wertebereich, so sollten Sie neben einer gültigen, ebenso zwei ungültige funktionale Äquivalenzklassen bilden. Eingangsbedingung: Minuten pro Stunden: {1..60} gäq1 = {1..60} uäq1 = {62} und uäq2 = {0} Betrachtung einer beliebigen Wertmenge: Basiert die Eingangsbedingung auf eine Anzahl verschiedener Werte, so sollten Sie eine gültige funktionale Äquivalenzklasse und zwei ungültige Äquivalenzklassen bilden. Eingangsbedingung: Anzahl der Tage eines Monats (ohne Schaltjahre): {28,30,31} gäq1 = {28,30,31} uäq1 = {29} und uäq2 = {32} Sonstige Mengen: Basieren die Eingangsparameter auf Werten, wie zum Beispiel Mengen, die unterschiedlich behandelt werden, erstellen Sie pro Wert eine gültige funktionale Äquivalenzklasse und zusätzlich eine weitere ungültige funktionale Äquivalenzklasse. Alle Äquivalenzklassen Regeln 1. Regel Beispiel 2. Regel Beispiel 3. Regel Eingangsbedingung: ein paar Tiere: {Hund, Katze, Beispiel Maus} gäq1={hund}, gäq2={katze} und gäq3={maus} uäq1={löwe}

7 116 5 Wirksame Testfälle entwickeln * 4. Regel Beispiel 5. Regel Beispiel Reduktion der Testfälle Beispiel 1d Umgang mit Vorgaben: Falls eine Eingabebedingung einer bestimmten Vorgabe unterliegt, sollten Sie pro Regel/Aspekt neben einer gültigen auch eine ungültige Äquivalenzklasse bilden. Eingangsbedingung: Legen Sie ein Passwort fest, das mindestens 6 Zeichen lang ist und ein Sonderzeichen beinhaltet. gäq1={»passwörter die mehr als 6 Zeichen haben«} uäq1={»passwörter die weniger als 6 Zeichen aufweisen«} gäq2={»passwörter mit Sonderzeichen«} uäq2={»passwörter ohne Sonderzeichen«} Die Möglichkeit einer weiteren Zerlegung: Wenn Sie feststellen, dass einzelne Elemente der jeweiligen funktionalen Äquivalenzklasse durch das Programm nicht gleichwertig behandelt werden, sollten Sie unbedingt die betroffene funktionale Äquivalenzklasse weiter unterteilen. gäq1={»passwörter die mehr als 6 Zeichen haben«} gäq1={»klarameier«..»klarameier%«} Da»KlaraMeier%«ebenso ein Sonderzeichen beinhaltet, wird das Passwort möglicherweise funktional anders behandelt als»klarameier«zerlegung: gäq1={»klarameier«} gäq2={»klarameier%«} In einem Testfall können mehrere Repräsentanten verschiedener Äquivalenzklassen enthalten sein, um die Anzahl der benötigten Testfälle gering zu halten. Hierbei ist Folgendes zu beachten: In einem Testfall können mehrere Repräsentanten gültiger Äquivalenzklassen enthalten sein. Pro Testfall darf jedoch maximal ein Repräsentant einer ungültigen Äquivalenzklasse verwendet werden. Sämtliche Repräsentanten werden durch Testfälle berücksichtigt. Ein Programm zur Bearbeitung von Kundenreklamationen bietet Ihnen die Möglichkeit Kundennummer, Kundenklasse, Produkttyp und den eigentlichen Reklamati-

8 5.1 Spezifikationsorientierte Testtechniken * 117 Eingabe gültige funktionale Äquivalenzklasse (gäq) ungültige funktionale Äquivalenzklasse (uäq) Kundenklasse A DbisZ B C onsgrund zu erfassen. Es wurde spezifiziert, dass die Erfassung nur für sogenannte Vertragskunden möglich ist. Eine entsprechende Unterscheidung erfolgt über die erste Stelle der Kundennummer, die durch ein»v«gekennzeichnet sein muss. Zu den gültigen Kundenklassen zählen A-, B- oder C-Kunden. Derzeit vermarktet die Firma ausschließlich die Produkttypen»234«,»240«,»251«. Als Reklamationsgrund müssen Eintragungen vorgenommen werden, die jedoch weniger als 256 Zeichen betragen. Aus der Spezifikation werden die gültigen und ungültigen Äquivalenzklassen entnommen und in Tab dargestellt. Reklamationsgrund Kundennummer»Text ZeichenNummern mit V beginnendtext mit mehr als 255 Zeichenkein Textandere«Produkttypen 234 alle anderen Tab : Beispiel Äquivalenzklassen. Für die gebildeten Äquivalenzklassen werden in Beispiel 1e Tab Repräsentanten festgelegt. Da die Äquivalenzklassen der Kundenklasse und der Produkttypen nur aus einem Element bestehen, entspricht in diesen Fällen der Repräsentant auch seiner Äquivalenzklasse. In der Tab werden die Repräsentanten den Testfällen zugeordnet. Sämtliche Repräsentanten werden durch Beispiel 1f

9 118 5 Wirksame Testfälle entwickeln * Eingabe gültige Repräsentanten ungültige Repräsentanten Kundenklasse R 1 ={A} R 10 ={Z} Kundenklasse Kundenklasse Reklamationsgrund R 2 ={B} R 3 ={C} R 5 ={Schlechte Kommunikation} R 11 ={} Kundennummer R 6 ={v4711} R 12 ={x4711} Produkttypen R 7 ={234} R 13 ={999} Produkttypen R 8 ={240} Produkttypen R 9 ={251} Tab : Repräsentanten. Testfälle berücksichtigt. Es ist darüber hinaus sichergestellt, dass maximal ein Repräsentant einer ungültigen Äquivalenzklasse pro Testfall verwendet wird. Testfall Kundenklasse Reklamationsgrund Kundennummer Produkttypen T 1 R 10 R 5 R 6 R 7 T 2 R 1 R 11 R 6 R 8 T 3 R 2 R 5 R 12 R 9 T 4 R 3 R 5 R 6 R 13 Tab : Testfälle mit Äquivalenzklassen. Durch Äquivalenzklassen werden die funktionalen Abhängigkeiten der verschiedenen Repräsentanten untereinander nicht berücksichtigt. Eine Verbesserung lässt sich mit folgenden Maßnahmen erreichen: Anwendung der»ursachen-wirkungsanalyse«, S Alternativ durch Testfälle sämtliche Kombinationen aller Repräsentanten überprüfen. Alternativ partielle Kombinationen, z. B. Repräsentantenpaare, vollständig kombinieren.

10 5.1 Spezifikationsorientierte Testtechniken * 119 Alternativ typische»anwendungsfälle«, S. 141, bei der Auswahl der Repräsentanten berücksichtigen. Durch die Bildung der funktionalen Äquivalenzklassen lassen sich Testfälle nach einem einfachen Verfahren erstellen, das für sämtliche Teststufen geeignet ist. Der Testfortschritt und die Vollständigkeit können einfach ermittelt werden. Die Qualität des Tests hängt, wie bei allen spezifikationsorientierten Verfahren, von der Qualität der Testbasis ab. Werden Äquivalenzklassen nicht richtig erkannt, können mögliche Fehler nicht entdeckt werden. Durch die formale Testfallerstellung besteht die Möglichkeit die Testfälle wiederzuverwenden und auch bei einer Änderung der Testbasis anzupassen. So kann auch in späteren Phasen das Äquivalenzklassenschema geändert werden, um neue funktionale Anforderungen zu integrieren. Durch die Verpflichtung zur Erstellung ungültiger Äquivalenzklassen, wird der Gedanke des destruktiven Testens (Negativtest) gefördert. Fazit Grenzwertanalyse ** Fehlerwirkungen von Software-Produkten zeigen sich sehr oft an Intervallgrenzen. Durch eine Grenzwertanalyse wird die Testbasis gezielt nach Grenzwerten untersucht und durch Testfälle überprüft. Die Testfälle sollen sowohl die Bedingungen innerhalb eines Intervalls aber auch außerhalb (in Nähe der Intervallgrenze) kontrollieren. Zusammenhängende Teilmengen werden mathematisch als Intervall bezeichnet. Sie sind»geschlossen«, wenn die Endpunkte im Intervall enthalten sind. Umgekehrt werden sie»offen«genannt, wenn sich die Grenzwerte nicht mehr im Intervall befinden. Denkbar sind auch Kombinationen. Ein geschlossenes Intervall für eine Teilmenge der natürlichen Zahlen kann in folgender Weise mathematisch beschrieben werden: [m,n] = {x N m x n}. Ähnlich wird das offene Intervall ausgedrückt: (m,n) = {x N m<x<n}. Das Intervall (1,6) = {x N 1<x<6} ist offen und enthält die Elemente {2,3,4,5}. Darüber hinaus enthält das geschlossene Intervall [1,6] = {x N 1 x 6} ebenso das erste und das letzte Element also insgesamt die Menge {1,2,3,4,5,6}. Intervalle Beispiel

11 120 5 Wirksame Testfälle entwickeln * Frage Antwort Grenzwertanalyse Die beiden Intervallformen finden in der Softwaretechnik breite Anwendung, beispielsweise bei der Verwendung von Vergleichsoperatoren oder dem Wertebereich bestimmter funktionaler Ergebnisse. Sie sind daher bereits in der Spezifikation zu unterscheiden. Natürlichsprachliche Spezifikationen verwenden jedoch die beschriebene mathematische Notation zur Unterscheidung nicht. Vielmehr muss der Sachverhalt widerspruchsfrei ausformuliert werden. Die Spezifikation des Eingabefensters eines Urlaubsplaners enthält folgenden Hinweis: Das Fenster soll die Eingabe des Urlaubszeitraums durch zwei Eingabefelder ermöglichen. Sie werden kennzeichnet mit»von«und»bis«. Im Test fällt später auf, dass die Berechnung der eingetragenen Urlaubstage immer um genau einen Tag abweicht. Warum? Durch die Verwendung des Wortes»bis«ist nicht widerspruchsfrei ausgedrückt, ob der letzte Urlaubstag im Intervall der Urlaubstage enthalten ist. Hierdurch entsteht ein Fehlerpotenzial. Genau dieses Fehlerpotenzial soll durch die Grenzwertanalyse reduziert werden, in dem Eingaben von Testfällen Grenzwerte sind [MBT+04, S. 59]. Zur weiteren Verifizierung sind auch Eingaben direkt außerhalb und ebenso innerhalb der Grenze jedoch in der unmittelbaren Nähe zum Grenzwert zu berücksichtigen. Neben Eingaben können auch Transformationsergebnisse in die Grenzwertanalyse einbezogen werden. Die Grenzwertanalyse lässt sich auch mit der Äquivalenzklassenbildung kombinieren und unterstützt bei der Auswahl geeigneter Repräsentanten und der Bildung von weiteren gültigen und ungültigen Aquivalenzklassen. Der Grenzwert und auch der weitere Wert innerhalb des Intervalls entsprechen dann Repräsentanten zweier gültiger Äquivalenzklassen. Der Wert außerhalb der Intervallgrenzen repräsentiert eine ungültige Äquivalenzklasse. Die Grenzwertanalyse kann nicht nur bei numerischen Wertebereichen, sondern auch bei Listen, Mengen oder beispielsweise Zeichenketten angewendet werden. Es sollte deshalb sehr genau analysiert werden, ob und welche Grenzen ein bestimmter Parameter haben könnte.

12 5.1 Spezifikationsorientierte Testtechniken * 121 Die Spezifikation einer Software enthält die Information, Beispiel 1 dass die Benutzerkennungen durch eine maximale Länge von 8 Zeichen begrenzt sind. Die Zeichenanzahl von 8 stellt somit eine Grenze dar. Als Repräsentant einer gültigen Äquivalenzklasse (Grenzwert) könnte zum Beispiel die Benutzerkennung»Knötters«verwendet werden. Eine weitere Äquivalenzklasse wird aus Benutzerkennungen mit 7 Zeichen gebildet werden. Ein Repräsentant wäre beispielsweise»schmidt«. Der Repräsentant einer ungültigen Äquivalenzklasse wäre eine beliebige neunstellige Kennung, zum Beispiel»Donnsbach«. In Abb werden die drei Repräsentanten dargestellt Repräsentant innerhalb des Wertebereichs Grenzwert des Wertebereiches Repräsentant außerhalb des Wertebereichs Abb : Intervall mit Grenzwert und zwei weiteren Repräsentanten für die Grenzwertanalyse. Da es sich bei typischen Eingangsbedingungen um Intervalle handelt, sollten immer beide Intervallgrenzen überprüft werden. Diese wurde im Beispiel 1 noch nicht berücksichtigt. Die korrekte Bildung möglicher Äquivalenzklassen durch die Grenzwertanalyse hängt stark von der Qualität der Testbasis ab. Vielfach werden Definitionen unvollständig oder gar nicht spezifiziert. Eine Möglichkeit in diesen Fällen geeignete Grenzwerte zu bestimmen, ist die Überarbeitung der Spezifikation durch die Entwickler oder die Festlegung sinnvoller Grenzen durch die Testverantwortlichen. Zweiteres empfiehlt sich primär bei implizit bekannten Attributen wie etwa die Größe von Rufnummern, Kundennummern, Bankleitzahlen und Kontonummern. Lassen sich weder durch Überarbeitung noch durch eigene Festlegungen sinnvolle Intervallgrenzen bestimmen, sollte mindestens mit den Wertgrenzen der Datentypen getestet werden (Tab ).

13 122 5 Wirksame Testfälle entwickeln * Datentypen in Java Speicherbedarf untere Intervallgrenze obere Intervallgrenze boolean 1Byte false true char 2Byte byte 1Byte short 2Byte int 4Byte long 8Byte float 4Byte -3, , Tab : Intervallgrenzen von Java-Datentypen. Testfälle 1. Regel Um die Anzahl nötiger Testfälle zu begrenzen, werden in [MBT+04, S. 59 f.] einige Vereinfachungsregeln vorgeschlagen: Eingangsbedingung, Intervall aus Dezimalzahlen Handelt es sich bei den Eingangsbedingungen um ein Intervall aus Dezimalzahlen, so sollte mit den beiden Intervallgrenzen und zwei naheliegenden Werten außerhalb der jeweiligen Intervallgrenze getestet werden. A={x R 1.00 x 1.00} Beispiel Repräsentanten wären beispielsweise: R={ 1.001, 1.00, 1.00, 1.001} Äquivalenzklassen wären: gäq1 ={ 1.00}, gäq 2 ={1.00}, uäq 1 ={x R x>1.00}, uäq 2 ={x R x< 1.00} 2. Regel Eingangsbedingung, Intervall natürlicher Zahlen Handelt es sich bei den Eingangsbedingungen um ein Intervall natürlicher Zahlen, so sollte mit den beiden Intervallgrenzen und zwei nächsten Werten außerhalb der jeweiligen Intervallgrenze getestet werden. A={x N 1 x 1} Beispiel Repräsentanten wären beispielsweise: R={ 1, 1, 2, 2} Äquivalenzklassen wären: gäq1 ={ 1}, gäq 2 ={1}, uäq 1 ={ 2}, uäq 2 ={2}

14 5.1 Spezifikationsorientierte Testtechniken * 123 Eingangsbedingung, Intervall aus sonstigen Elementen wie Listen Handelt es sich bei den Eingangsbedingungen um ein Intervall mit sonstigen Elementen, so sollte mit dem ersten und dem letzten Element getestet werden. Transformationsergebnisse Können bei den möglichen Transformationsergebnissen Intervalle ermittelt werden, sollten die Regeln 1 3 auf sie angewendet werden. Einfallsreichtum, Scharfsinn Sind Grenzen nicht unmittelbar zu erkennen, sollten sie durch entsprechenden»einfallsreichtum«gebildet werden. 3. Regel 4. Regel 5. Regel Entscheidungstabellentest ** Der Entscheidungstabellentest wird bei einer natürlichsprachlichen Testbasis angewendet. Er bietet eine Möglichkeit, einzelne Testbedingungen in Form von Aktionen und Eingangsbedingungen aus den Dokumenten zu extrahieren und tabellarisch aufzubereiten. Wurden alle Eingangsbedingungen einer Aktion aufgeführt, können alle notwendigen Testfälle unmittelbar abgeleitet werden. Der Entscheidungstabellentest ist ein funktionsorientiertes Testverfahren. In einer Entscheidungstabelle werden die Eingangsbedingungen und Aktionen des Testobjektes logisch dargestellt und Testfällen zugeordnet. Die Aktionen und Bedingungen werden aus der Spezifikation entnommen. Das Verfahren findet sehr oft Anwendung, wenn die Spezifikation in einer formalen und natürlichsprachlichen Form vorliegt. Die Entscheidungstabelle dient dann zur Strukturierung und Vorbereitung des Tests. Den Mitarbeitern einer Firma werden Prämien ausbezahlt, wenn sie länger als ein Jahr im Unternehmen beschäftigt sind und individuell vereinbarte Ziele erreichen. Dieser Sachverhalt lässt sich in einer Entscheidungstabelle darstellen. Es ergeben sich dann durch die möglichen Kombinationen der drei Eingangsbedingungen (2 3 ) acht Testfälle (Tab ). Funktionsorientiert Beispiel 1a

15 124 5 Wirksame Testfälle entwickeln * T1 T2 T3 T4 T5 T6 T7 T8 Bedingung 1 Beschäftigung länger als 1 Jahr? ja nein ja nein ja nein ja nein Bedingung 2 Ziel abgestimmt? Bedingung 3 Aktion nein nein ja ja nein nein ja ja Ziel erreicht? nein nein nein nein ja ja ja ja Auszahlung der Prämie Jahr nein nein nein nein nein nein ja nein Tab : Beispiel für eine Entscheidungstabelle. Entscheidungstabellen werden sehr schnell unübersichtlich, denn jede neue Bedingung wirkt sich exponentiell auf die Anzahl nötiger Testfälle aus. Um sie trotzdem einsetzen zu können, wird die Anzahl der nötigen Testfälle begrenzt, indem zum Beispiel funktional abhängige Bedingungen, die in der Praxis nicht entstehen können, unbeachtet bleiben. Beispiel 1b In den Testfällen T5 und T6 schließen sich Bedingungen aus. In den Testfällen wird eine Situation beschrieben, in der ein Ziel erreicht, jedoch nicht abgestimmt war. Da diese Situation nicht eintreten kann, wird daher auch auf die entsprechenden Testfälle verzichtet (Tab ). Bedingung 1 Beschäftigung länger als 1 Jahr? T1 T2 T3 T4 T7 T8 ja nein ja nein ja nein Bedingung 2 Ziel abgestimmt? nein nein ja ja ja ja Bedingung 3 Ziel erreicht? nein nein nein nein ja ja Aktion Auszahlung der Prämie Jahr nein nein nein nein ja nein Tab : Beispiel zur Vereinfachung einer Entscheidungstabelle. Weitere Vereinfachungsregeln werden im Kapitel Ursachen-Wirkungsanalyse (siehe»ursachen-wirkungsanalysen«, S. 125) vorgestellt. Die Ergebnisse dieser Methode ergeben eine weitgehend vereinfachte Entscheidungstabelle.

16 5.1 Spezifikationsorientierte Testtechniken * Ursachen-Wirkungsanalysen ** Bei der Ursachen-Wirkungsanalyse werden aus der Spezifikation die funktionalen Beschreibungen nach Ursache und Wirkung getrennt aufgenommen und als Graph dargestellt. Sowohl Ursachen und auch Wirkungen werden in eine binäre Form überführt. Primäres Ziel beim Testfallentwurf der Ursachen-Wirkungsanalyse ist die Beachtung der funktionalen Abhängigkeiten der Ursachen. Durch Vereinfachungen der»und«- und»oder«-bedingungen lässt sich die Anzahl notwendiger Testfälle reduzieren. Die Ursachen-Wirkungsanalyse ist ein funktionsorientiertes Testverfahren. Die Testfälle werden wie bei der funktionalen Äquivalenzklassenbildung oder der Grenzwertanalyse anhand der Spezifikation entworfen, jedoch schließt sie eine ganz wesentliche Lücke beim Testfallentwurf: Berücksichtigung von funktionalen Abhängigkeiten zwischen den Eingangsbedingungen. Wechselwirkungen zwischen den Eingangsbedingungen. Im Unterschied zu anderen funktionsorientierten Testverfahren stellt diese Methode die Kombinationen möglicher Eingangsbedingungen in den Vordergrund des Testens und weniger die Bestimmung geeigneter Testdaten. Durch die Anwendung der Ursachen-Wirkungsanalyse soll eine systematische Auseinandersetzung mit einer Spezifikation erreicht werden, um Widersprüche innerhalb des Dokumentes zu entdecken und die Anzahl der notwendigen Testfälle einer Testsuite zu minimieren. Die Ursachen-Wirkungsanalyse wird durch einen Ursachen- Wirkungsgraphen möglich, in dem logische Beziehungen zwischen Ursachen und Wirkungen grafisch beschrieben sind. Ursachen sind die Eingangsbedingungen einer Funktion, während die Wirkungen das Ergebnis der Transformation sind. Der Ursachen-Wirkungsgraph entspricht einer definierten Notation, durch die sich natürlichsprachliche Spezifikationen darstellen lassen. Zunächst wird eine Ursachen-Wirkungsanalyse auf Basis der Spezifikation durchgeführt. Vorstellbar wäre es ebenso, dass z. B. durch eine Entscheidungstabelle die benötigten Zusammenhänge bereits als Teil des Entwicklungsmodells be- Unterschied Aufbau Erste Schritte

17 126 5 Wirksame Testfälle entwickeln * schrieben werden. Ausgehend von der natürlichsprachlichen Spezifikation empfiehlt Glenford J. Myers in [MBT+04, S. 66] nach folgenden Regeln vorzugehen, die anhand eines Beispiels erklärt werden: Beispiel 1a 1. Regel 2. Regel Beispiel 1b Eine Auktionsplattform kennzeichnet Kunden mit einem bestehenden Vertrag als profiseller, wenn sie als Privatpersonen ein monatliches Handelsvolumen von mehr als 250 erreichen oder sich direkt als gewerblicher Kunde ausgewiesen haben. Grundsätzlich können nur Kunden den profiseller-status erreichen, wenn sie weniger als 3-mal negativ bewertet wurden. Unterteilung der Spezifikation: Die Spezifikation sollte in geeignete Teilbereiche gegliedert werden, mit denen dann jeweils eine Analyse durchgeführt wird. Hierdurch werden die Kombinationsmöglichkeiten reduziert. Ursachen und Wirkungszusammenhänge erkennen: Aus der Spezifikation werden Ursachen und Wirkungen entnommen. Eine Ursache kann zum Beispiel eine Eingangsbedingung oder auch eine Äquivalenzklasse sein. Die Wirkung entspricht immer der Aktion des Testobjektes. Folgende Äquivalenzklassen können aus dem Beispiel 1a abgleitet werden: gäqkunde 1 ={privat}, gäq Kunde 2 ={gewerblich} gäqbewertungstyp 1 ={x N x<3}, gäq Bewertungstyp 2 ={x N x 3} gäqumsatztyp 1 ={x N x>250}, gäq Umsatztyp 2 ={x N x 250} gäqvertragspartner ={ja}, gäq Interessent ={ja} gäqseller 1 ={profiseller}, gäq Seller 2 ={kein profi} Hieraus ergeben sich folgende Repräsentanten: RKunde 1 =R K1 ={privat}, R Kunde 2 =R K2 ={gewerblich} RBewertungstyp 1 =R B1 ={2}, R Bewertungstyp 2 =R B2 ={12} RUmsatztyp 1 =R U1 ={500}, R Umsatztyp 2 =R U2 ={100} RVertragspartner 1 =R V ={ja} R Vertragspartner 2 =R I ={nein} RSeller 1 =R S1 ={profiseller}, R Seller 2 =R S2 ={kein profi}

18 5.1 Spezifikationsorientierte Testtechniken * 127 Grafische Darstellung: 3. Regel Die Teilbereiche werden analysiert und als Ursache-Wirkungsgraphen dargestellt. Die entsprechenden Repräsentanten bzw. die Eingangsbedingungen werden binär dargestellt und mit Bezug zur möglichen Wirkung verknüpft. Die Darstellung der Zustände orientiert sich an bekannten booleschen Verknüpfungsmöglichkeiten: Bei der Identität entspricht der boolesche Zustand der Ein- Identität gangsbedingung dem Ausgangszustand. Die Ursache hat somit einen direkten Einfluss auf die Wirkung. Der komplementäre Ausdruck der Identität ist die Negation Negation. Der boolsche Ausgangszustand entspricht in diesem Fall dem invertierten Eingangszustand. Eine beliebige Ursache der betrachteten Funktion führt zur ODER erwarteten Wirkung. Erst wenn sämtliche Ursachen eintreten, stellt sich die er- UND wartete Wirkung ein. Die logischen Beziehungen der Ursachen und Wirkungen werden in Form eines Ursachen- Wirkungsgraphen dargestellt. Die vorhandenen logischen Beziehungen werden ähnlich einer Schaltfunktion in den Graphen eingetragen. Die möglichen Notationen sind in Abb als Übersicht dargestellt. Identität Negation a b a b ODER UND a a v c v c b b Abb : Logische Beziehungen zwischen Ursachen. Die verschiedenen boolschen Eingangsbedingungen a bis h werden durch die Repräsentanten der gültigen Äquivalenzklassen beschrieben: Beispiel 1c

19 128 5 Wirksame Testfälle entwickeln * a={wahr} wenn a=rk1, b={wahr} wenn b=r K2 a={falsch} wenn a=rk2, b={falsch} wenn b=r K1 c={wahr} wenn c=rb1, d={wahr} wenn d=r B2 c={fasch} wenn c=rb2, d={falsch} wenn d=r B1 e={wahr} wenn e=ru1, f={wahr} wenn f=r U2 e={falsch} wenn e=ru2, f={falsch} wenn f=r U1 g={wahr} wenn g=rv, h={wahr} wenn h=r I g={falsch} wenn g=ri, h={falsch} wenn h=r V z={wahr} wenn z=rs1, z={falsch} wenn z=r S2 Die entsprechenden Eingangsbedingungen werden in einen Ursache-Wirkungsgraphen überführt. Die vorhandenen logischen Beziehungen werden im Graphen gekennzeichnet (Abb ). a b c d e v x v y v z f g h Legende: a-h Ursachen z Wirkung x,y Verknüpfungen Abb : Ursachen-Wirkungsgraph. 4. Regel Kommentierung: Im Ursachen-Wirkungsgraph werden alle funktionalen Abhängigkeiten kommentiert. Es sind nicht immer alle Ursachenkombinationen möglich, da die Ursachen vielfach untereinander in Abhängigkeit stehen. Dies ist zum Beispiel der Fall, wenn sich eine Ursache aus mehreren Äquivalenz-

20 5.1 Spezifikationsorientierte Testtechniken * 129 klassen ergibt. Zur Kommentierung empfehlen [MBT+04, S. 64] verschiedene Abhängigkeitstypen: Exclusive bedeutet, dass bei mehreren Wirkungen maximal eine wirksam sein kann (Tab ). Exclusive Eingang (a) Eingang (b) mögliche Kombination Aktion (c) 1 1 nein x 0 1 ja ja ja 0 Tab : Wertetabelle der Exclusive-Einschränkung. Eingang (a) Eingang (b) mögliche Kombination Aktion (c) 1 1 ja ja ja nein x Tab : Wertetabelle der Inclusive-Einschränkung. Sind die Eingangsbedingungen durch die Inclusive-Form eingeschränkt, dann besteht von mehreren Wirkungen immer mindestens eine (Tab ). Wird hingegen immer nur exakt eine Bedingung erfüllt, so lässt sich die Only-one-Kennzeichnung verwenden (Tab ). Die Requires-Einschränkung besagt, dass eine Ursache eine andere erfordert. In der Abb kann die Ursache c nur den Zustand»wahr«annehmen, wenn b zuvor ebenso»wahr«angenommen hat. Die»Maskierung«unterdrückt eine Aktion durch eine andere. Nimmt in Abb c den Zustand»wahr«an, erhält b den Zustand»falsch«. Only-one Requires Mask

21 130 5 Wirksame Testfälle entwickeln * Eingang (a) Eingang (b) mögliche Kombination Aktion (c) 1 1 nein x 0 1 ja ja nein x Tab : Wertetabelle der Only-one-Einschränkung. Exclusive Only-one c c E O b b Inclusive R equires M asks c c c I R M b b b Abb : Einschränkungen als Grundform der Kommentierung. Beispiel 1d 5. Regel Der Ursachen-Wirkungsgraph des Beispiels 1c wird entsprechend der 4. Regel kommentiert (Abb ). Überführung: Der Ursache-Wirkungsgraph wird in eine Entscheidungstabelle überführt. In [MBT+04, S. 79] wird hierzu eine Herangehensweise vorgeschlagen, an der sich dieses Buch orientiert: Auswahl einer Wirkung. Rückverfolgung durch den Graph.

22 5.1 Spezifikationsorientierte Testtechniken * 131 a O b c R O O O d e f g h v x v y v Legende: a-h Ursachen z Wirkung x,y Verknüpfungen z Abb : Kommentierungen im Ursachen-Wirkungsgraph. Anlegen einer Spalte für jede Ursache bzw. Ursachenkombination. Aufnahme aller Möglichkeiten, durch die die ausgewählte Wirkung»wahr«wird. Bei der Aufnahme sind die Einschränkungen zu beachten. Für jede Ursache- und Ursachenkombination werden auch alle anderen Wirkungen beschrieben. Trotz der Berücksichtigung der im Ursachen-Wirkungsgraphen enthaltenen Einschränkungen, verhält sich die Anzahl der möglichen Testfälle nahezu exponentiell zu den Ursachen. Dies liegt daran, dass bei einer»oder«-kombination eine Wirkung durch eine Vielzahl von Kombinationen vorhandener Ursachen möglich ist. Umgekehrt ist bei einer»und«- Kombination keine Wirkung durch eine Vielzahl von Kombinationen ohne Ursachen möglich. In [MBT+04, S. 79] werden daher weitere Möglichkeiten zur Einschränkung vorgeschlagen, die in den wesentlichen Aspekten wiedergegeben werden:

23 132 5 Wirksame Testfälle entwickeln * ODER Das Ergebnis von»1«einer»oder«-verknüpfung wird überprüft, indem alle Fälle aufgenommen werden, bei denen nur eine Eingabe gesetzt (=1) ist. Kann diese Eingabe aufgrund der untergeordneten Knoten durch unterschiedliche Situationen entstehen, müssen diese zusätzlichen Kombinationen einbezogen werden. Die Regeln gelten dann für die Unterknoten entsprechend. Hinweis UND Beispiel 1e Pfadsensitivierung Es wird immer nur eine Eingabe der jeweiligen»oder«- Verknüpfung betrachtet, um Fehler nicht zu maskieren. Dies wird auch als Pfadsensitivierung bezeichnet. Das Ergebnis von»0«einer»oder«-verknüpfung wird überprüft, indem alle Möglichkeiten geprüft werden, die zu dem Zustand geführt haben. Auch in diesem Fall sind für die verschiedenen Situationen der Unterknoten entsprechende Einträge vorzusehen. Das Ergebnis von»1«einer»und«-kombination wird überprüft, indem alle verschiedenen Situationen einbezogen werden, die zur Wirkung geführt haben. Dies schließt die unterschiedlichen Kombinationen der Unterknoten mit ein. Das Ergebnis von 0 einer»und«-verknüpfung wird überprüft, indem jede mögliche Kombination gebildet wird. Es müssen jedoch nicht alle Unterknoten miteinbezogen werden, sondern pro Verknüpfung nur ein repräsentatives Szenario der Unterknoten. In [Ligg02, S. 65] empfiehlt der Autor für»und«-verknüpfungen mit dem Ergebnis 0 nur solche Eingabekombinationen zu bilden, bei denen eine Eingabe den Wert 0 und alle anderen den Wert 1 besitzen. Diese sinnvolle Regel lässt sich aufgrund möglicher Einschränkungen leider nicht immer anwenden. Es wird daher an dieser Stelle gefordert, die Anzahl der gleichzeitig vorhandenen Ursachen lediglich auf ein Minimum zu begrenzen. Im Idealfall auf maximal eine. Der im Beispiel 1d erweiterte Ursachen-Wirkungsgraph wird nun in eine Entscheidungstabelle überführt (Tab ).

24 5.1 Spezifikationsorientierte Testtechniken * 133 a b c d e f g h x y z Tab : Entscheidungstabelle. Testfälle Aus den Zeilen der Entscheidungstabellen lassen sich die Testfälle entnehmen. In der Tab werden die Testfälle und die Repräsentanten den Ursachen zugeordnet. Es lassen sich sieben Testfälle mit folgender Ausprägung ableiten. T1 ={privater Kunde, 2x negativ bewertet, 500 Umsatz, Vertragspartner} T2 ={gewerblicher Kunde, 2x negativ bewertet, 100 Umsatz, Vertragspartner} T3 ={gewerblicher Kunde, 2x negativ bewertet, 500 Umsatz, Vertragspartner} T4 ={privater Kunde, 12x negativ bewertet, 500 Umsatz, Vertragspartner} T5 ={privater Kunde, 2x negativ bewertet, 100 Umsatz, Vertragspartner} T6 ={gewerblicher Kunde, 12x negativ bewertet, 100 Umsatz, Vertragspartner} T6 ={gewerblicher Kunde, 2x negativ bewertet, 100 Umsatz, kein Vertragspartner} 6. Regel Beispiel 1f

25 134 5 Wirksame Testfälle entwickeln * Testfall a b c d e f g h z T 1 R K1 R K1 R B1 R B1 R U1 R U1 R V R V R S1 T 2 R K2 R K2 R B1 R B1 R U2 R U2 R V R V R S1 T 3 R K2 R K2 R B1 R B1 R U1 R U1 R V R V R S1 T 4 R K1 R K1 R B2 R B2 R U2 R U2 R V R V R S2 T 5 R K1 R K1 R B1 R B1 R U2 R U2 R V R V R S2 T 6 R K2 R K2 R B2 R B2 R U2 R U2 R V R V R S2 T 7 R K2 R K2 R B1 R B1 R U2 R U2 R I R I R S2 Tab : Testfälle. Automaten Zustandsbezogener Test ** Durch einen zustandsbezogenen Test wird die Historie eines Systems in den Test miteinbezogen. Um die unterschiedlichen Zustände überprüfen zu können, werden sie aus der Spezifikation abgeleitet. Bereits beim Softwareentwurf sollte das Software-Produkt durch ein entsprechendes zustandsbezogenes Modell spezifiziert werden. Aus diesem lassen sich dann als Testbedingungen für die Testfälle alle Zustände und auch Zustandsübergänge extrahieren und testen. Bei vielen Systemen hängt das Ergebnis oder die Ausgabe nicht nur von einer Eingabe oder einem Ereignis ab, sondern von der Historie, die das System bis dahin durchlaufen hat. Vielfach bewirken gleiche Ereignisse (Ursachen) unterschiedliche Aktionen, wenn aufgrund seiner Historie ein System diese Ereignisse unterschiedlich bewertet. Zum Beschreiben solcher Zusammenhänge eignen sich Zustandsautomaten, auch endliche Automaten genannt. Testen lassen sie sich durch den zustandsbezogenen Test. Unter einem Automaten versteht man im Allgemeinen ein technisches Gerät, das zu einer Eingabe ein bestimmtes Ergebnis ausgibt. Beispiele dafür sind Geldautomaten, Fahrkartenautomaten und Warenautomaten. In der Informatik steht der Automatenbegriff vorwiegend für ein mathematisches Modell von Geräten oder Systemen.

26 5.1 Spezifikationsorientierte Testtechniken * 135 Ein endlicher Automat oder Zustandsautomat (finite automaton, finite state machine, sequential machine) besteht aus einer endlichen Anzahl von internen Konfigurationen Zustände genannt. Der Zustand eines Systems beinhaltet implizit die Informationen, die sich aus den bisherigen Eingaben ergeben haben und die benötigt werden, um die Reaktion des Systems auf noch folgende Eingaben zu bestimmen. Gegenüber einem allgemeinen Automaten besitzen endliche Automaten nur eine endliche Zahl von Zuständen. Bei deterministischen endlichen Automaten gibt es zu einem Ereignis eines Zustandes maximal einen Übergang in einen anderen Zustand. Der nichtdeterministische endliche Automat bietet hingegen mehrere Zustandsübergänge. Deterministische endliche Automaten können mit und ohne Aktionen modelliert werden. Aktionen sind die eigentlichen Aktivitäten, Berechnungen oder Ausgaben. Beim sogenannten Mealy-Automaten ist die Aktion an die Transition (Zustandsübergang) gebunden. Der Moore-Automat koppelt hingegen seine Aktionen an den Zustand selbst. Eine Kombination beider Techniken bietet der Harel-Automat ( statechart). Weiterhin lassen sich mit dem Harel-Automaten auch Nebenläufigkeit und hierarchische Zustandsautomaten beschreiben. Ein Zustandsautomat kann als Zustandsdiagramm, Zustandstabelle oder Zustandsmatrix dargestellt werden. Für Zustandsdiagramme gibt es verschiedene grafische Notationen, von denen sich insbesondere die UML-Notation ( Unified Modeling Language) durchgesetzt hat. Der zustandsbezogene Test wird anhand einer Steuerung eines flexiblen Fertigungssystems erklärt. Das Fertigungssystem ist in der Lage metallische Werkstücke zu bohren. Grundsätzlich werden die Bohrungen entgratet und ebenso überprüft. Die Beschickung erfolgt automatisch, ebenso die Entnahme. Die Steuerung wird in Abb durch ein Zustandsdiagramm spezifiziert. Dieses dient ebenso als Testbasis. Die Steuerung zeichnet sich durch sechs Arbeitszustände aus. Im Zustand»Initialisiert«befindet sich der Automat, wenn die Steuerung eingeschaltet ist, das Werkstück geladen wurde aber zur Bearbeitung noch nicht fixiert ist. Nach der Fixierung nimmt die Steue- Endlicher Automat Mealy, Moore und Harel Beispiel 1a

27 136 5 Wirksame Testfälle entwickeln * rung den Zustand»Bereit«an. Das Werkstück kann, nachdem der Startknopf gedrückt wurde, gebohrt, entgratet und geprüft werden. Jeder Arbeitsschritt ist aus Sicht der Steuerung ein Betriebszustand. Nach jedem Arbeitsschritt muss das Überwachungspersonal den nächsten Arbeitsschritt freigeben. Steuerung anschalten Positioniert Bearbeitungsende beenden / pneumatische Entnahme Freigabe Refpunkt anfordern/ Motor positioniert Fixierung Freigabe / bohren Initialisiert Bereit Gebohrt weitere Bearbeitung / Arbeitsposition anfahren Freigabe / entgraten Geprüft Freigabe / messen Entgratet Entnahme / pneumatische Entnahme Ereignis / Aktion Zustand Abb : Zustandsdiagramm. Zustände testen Beispiel 1b In einer Zustandstabelle lassen sich Zustände, Ereignisse, Aktionen und auch Folgezustände darstellen. Als erstes Testziel gilt beim zustandsbezogenen Test die Überprüfung jedes Zustandes durch einen Testfall. Die Testabdeckung kann dann aus dem Verhältnis»getestete Zustände«zur»Gesamtanzahl aller Zustände«bestimmt werden (Tab ). Die aus dem Beispiel 1a identifizierten Zustände werden in Tab in eine Zustandstabelle überführt. Für jeden Zustand sollte mindestens ein Testfall entworfen wer-

28 5.1 Spezifikationsorientierte Testtechniken * 137 den. Die Steuerung nimmt insgesamt sechs Zustände ein, so dass ebenso viel Testfälle entstehen. Testfall Zustand Ereignis Aktion Folgezustand T 1 Initialisiert Fixierung Bereit T 2 Bereit Refpunkt anfordern Motor positionieren Positioniert Bereit Freigabe bohren Gebohrt T 3 Gebohrt Freigabe entgraten Entgratet T 4 Positioniert Freigabe Bereit Positioniert Beenden pneumatische Entnahme Bearbeitungsende T 5 Entgratet Freigabe messen Geprüft T 6 Geprüft Entnahme pneumatische Entnahme Bearbeitungsende Geprüft weitere Bearbeitung Arbeitsposition anfahren Bereit Tab : Zustandstabelle. Durch die Überprüfung aller Zustände ist nicht zwangsläufig sichergestellt, dass alle Zustandsübergänge überprüft wurden. Es ist möglich, dass ein Zustand durch verschiedene Ereignisse erreicht werden kann. Ein weiteres Testziel ist daher die Überprüfung sämtlicher spezifizierter Zustandsübergänge. Die Überprüfung sämtlicher Zustandsübergänge beinhaltet immer den Test sämtlicher Zustände. Je nach Modellierung wird die Aktion dem Zustandsübergang oder dem Zustand zugeordnet, die ebenso durch die Testfälle getestet werden müssen. Die Ereignisse und die verschiedenen Zustände des Beispiels 1a werden in einer Zustandsmatrix (Tab ) dargestellt. Es lassen sich auf diese Weise sämtliche Zustandsübergänge darstellen und Testfälle zuordnen. Die Felder der Matrix entsprechen den Folgezuständen. Die aktuellen Zustände stehen in der Überschriftenzeile. Es werden insgesamt neun Testfälle benötigt, um die Zustandsübergänge zu testen. Zustandsübergänge testen Beispiel 1c

29 138 5 Wirksame Testfälle entwickeln * Testfall Ereignis\ Zustand Initialisiert Bereit Gebohrt Positioniert Entgratet Geprüft T 1 Fixierung Bereit T 2 Refpunkt anfordern Positioniert T 3 Freigabe Gebohrt T 4 Freigabe Entgratet T 5 Freigabe Bereit T 6 Beenden Bearbeitungsende T 7 Freigabe Geprüft T 8 Entnahme Bearbeitungsende T 9 weitere Bearbeitung Bereit Tab : Zustandsmatrix. Ist die Fehlerbehandlung im Zustandsdiagramm nicht spezifiziert, sollte für jeden Zustandswechsel auch ein Testfall entworfen werden, der einen Übergang in einen Fehlerzustand bewirkt und die Reaktion überprüft. Da die Zustandsspezifikation die Auslöseereignisse nicht enthält, müssen im Testfall die Ereignisse definiert werden. In gleicher Weise ist mit dem Fehlerzustand umzugehen. Hier sollte immer ein Testorakel befragt werden, wie der jeweilige Fehlerzustand (z. B. einfache Rückmeldung eines Fehlercodes, Fehleraktion oder besondere, sprechende Anwenderhinweise) auszusehen hat. Im Zustandsdiagramm sollten neben den Arbeitszuständen die für die Verwendung des Automaten typisch sind immer auch Fehlerzustände oder Fehlerereignisse spezifiziert werden. Diese enthalten dann die Bezeichnung wie Fehler, Störung oder Ausfall. Da das Zustandsdiagramm Fehlerbehandlungen testen

30 5.1 Spezifikationsorientierte Testtechniken * 139 die Testbasis darstellt, sollte im Rahmen einer Prüfung auf fehlende Fehlerzustände bzw. Fehlerereignisse geachtet werden. In Abb wurde eine potenzielle Fehlersituation Beispiel 1d durch den neuen Zustand Störung dargestellt. Der Test wird aus diesem Grund, um die Testfälle T 10 und T 11 erweitert, die die beiden neuen Zustandsübergänge von»gebohrt«nach»störung«und von»entgratet«nach»störung«überprüfen. Steuerung anschalten Positioniert Bearbeitungsende beenden / pneumatische Entnahme Freigabe Störung Refpunkt Refpunkt anfahren/ anfordern/ Motor Motor positionieren positioniertstörung /Anlagenstopp Fixierung Freigabe / bohren Initialisiert Bereit Gebohrt Störung /Analgenstopp Anlagenstopp weitere Bearbeitung /Arbeitsposition anfahren Freigabe / entgraten Geprüft Freigabe / messen Entgratet Entnahme / pneumatische Entnahme Ereignis /Aktion Zustand Abb : Modellierung von Fehlerzuständen im Zustandsdiagramm. In Tab werden Fehlerzustände vorgesehen, die von jedem Arbeitszustand eingenommen werden können. Es ergeben sich weitere 9 Testfälle (T 10 -T 18 ). Beispiel 1e Vielfach ist es sinnvoller auf Basis des Zustandsdiagramms oder auch der Zustandstabelle zu entscheiden, ob und welche Zustandsübergänge zu Fehlerzuständen führen. Als Indikator können hierzu beispielsweise die Aktionen des Au-

31 140 5 Wirksame Testfälle entwickeln * Testfall Ereignis\ Zustand Bereit Initialisiert Gebohrt Positioniert Entgratet Geprüft T 10 Fixierung Fehler T 11 Refpunkt anfordern Fehler T 12 Freigabe Fehler T 13 Freigabe Fehler T 14 Freigabe Fehler T 15 Beenden Fehler T 16 Freigabe Fehler T 17 Entnahme Fehler T 18 weitere Bearbeitung: Fehler Tab : Fehlerzustände in der Zustandsmatrix. tomaten inhaltlich bewertet werden. Umfangreichere oder komplexere Aktionen entsprechen einem höheren Fehlerpotenzial und sollten daher genauer betrachtet werden. Ebenso ist es möglich, dass Fehlerereignisse einen Zustandswechsel in einen falschen Arbeitszustand bewirken. Die Zustandstabelle ermöglicht es, auch für derartige Situationen mögliche Zustandsübergänge festzulegen, die dann durch Testfälle zu überprüfen sind. Beispiel 1f Bewertung In Tab werden die möglichen Fehlerzustände und somit die Testfälle reduziert. Der Testmanager sieht mögliche Fehlerzustände insbesondere bei den Hauptbearbeitungsschritten der Anlage. Dies ist die Durchführung der Bohrung und die anschließende Entgratung. Der zustandsbezogene Test findet in der Automatisierungstechnik breite Anwendung, kann aber prinzipiell bei jeder historienverarbeitenden Software angewendet werden. Er setzt voraus, dass bereits in einer adäquaten Weise die Spezifikation erstellt wurde. So eignen sich natürlichsprachliche Spezifikationen nicht, um aus ihnen entsprechende

32 5.1 Spezifikationsorientierte Testtechniken * 141 Testfall Ereignis\ Zustand Bereit Initialisiert Gebohrt Positioniert Entgratet Geprüft Fixierung Bereit Refpunkt anfordern Positioniert T 10 Freigabe Fehler T 11 Freigabe Fehler Freigabe Bereit Beenden Bearbeitungsende Freigabe Geprüft Entnahme Bearbeitungsende weitere Bearbeitung Bereit Tab : Auswahl möglicher Fehlerzustände. Testfälle abzuleiten. Liegt die Spezifikation bereits als Zustandsdiagramm, -tabelle oder -matrix vor, können schnell konkrete Testfälle abgeleitet werden Anwendungsfallbasierter Test ** Testfälle beim anwendungsfallbasierten Test ergeben sich aus der Beschreibung der fachlichen Logik. Die Testbedingungen werden entweder aus der Spezifikation extrahiert oder liegen bereits in Anwendungsfallbeschreibungen vor. Der anwendungsfallbasierte Test findet Anwendung in den höheren Teststufen.