Wenn es darum geht, ob ein Projektteam in der Lage ist, einen Stakeholder mit der Software zufrieden zu stellen, ist
eine klare Bestimmung der Stakeholder-Erwartungen der alles entscheidende Faktor. Testfälle sind grundsätzlich
Artefakte, die die Erwartungen von Stakeholdern widerspiegeln und so zu ihrer Verifizierung und Auswertung beitragen
können, ganz gleich, ob die Anforderungen mehr oder weniger vollständig spezifiziert sind.
Wenn eine sinnvolle Liste mit Anforderungen verfügbar ist, muss das Testteam Tests planen, die diese Anforderungen in
angemessener Weise prüfen. Beachten Sie, dass die Validierung der Software anhand von Anforderungen je nach Art der
Anforderungen unterschiedlich ausfallen kann. Wenn beispielsweise die Anforderungen an die Funktionalität und Leistung
der Software geprüft werden sollen, kann ein Tester automatisierte Testverfahren einsetzen. Die Überprüfung einer
Konfigurationsanforderung, z. B. des Herunterfahren des Hostcomputers, kann dagegen manuelle Testverfahren erfordern.
Möglicherweise sind Sie nicht in der Lage, alle Anforderungen zu überprüfen, oder nicht für die Überprüfung aller
Anforderungen zuständig. In einer solchen Situation ist es entscheidend, dass Sie sich auf die wichtigsten und
geeignetsten Anforderungen des aktuellen Arbeitsbereichs konzentrieren. Bei dieser Auswahl gilt es Kosten, Risiken und
die Notwendigkeit für die Überprüfung bestimmter Anforderungen gegeneinander abzuwägen. Im Allgemeinen wird die Auswahl
der Anforderungen durch den Umfang der aktuellen Iteration begrenzt.
Anforderungen sind eine wichtige Quelle, aus der Tests abgeleitet werden können, jedoch nicht die einzige
Informationsquelle für Tests. Es ist sogar so, dass Anforderungen in vielen Fällen keine ausreichende Basis für die
Entwicklung von Tests sind. Es sollten auch Testfälle berücksichtigt werden, die auf vorhandenen Risiken,
Einschränkungen, Technologien, Änderungsanfragen (Mängeln), Fehlern usw. basieren.
Weitere Informationen zur Entwicklung von Testideen finden Sie im Abschnitt Konzept: Liste mit
Testideen.
Die Festlegung von Testfällen ist aus verschiedenen Gründen sinnvoll.
-
Testfälle können als Fundament für das Entwerfen und Implementieren der tatsächlichen Tests dienen. Wenn Sie sich
ausführlicher mit einem Testfall beschäftigen, verstehen Sie besser, welche Anforderungen dieser an Design und
Implementierung der Tests stellt. Die so investierte Zeit können Sie dann beim eigentlichen Entwerfen und
Implementieren einsparen.
-
Einige Tests sind besonders komplex oder detailliert. Insbesondere bei solchen Tests sind sorgfältige Überlegungen
vor Beginn der Testimplementierung von Vorteil. Testfälle und das Testdesign sind gut geeignete Artefakte für diese
Überlegungen.
-
Die Gründlichkeit, mit der getestet wird, gilt als direkt proportional zur Anzahl der Tests. Der Testprozess selbst
wird oft als zuverlässiger angesehen, wenn die Gründlichkeit durch die Anzahl der bezeichneten Testfälle belegt
werden kann.
-
Eine Möglichkeit, die Vollständigkeit von Tests zu überprüfen, ist die Überwachung der Abdeckung bestimmter
Motivationselemente. Für einen Abdeckungsbericht könnte beispielsweise die Anzahl der angegebenen Testfälle, die
Anzahl der für jeden Testfall implementierten oder ausgeführten Tests oder der für jeden Testfall erwartete Aufwand
ermittelt werden.
-
Bei wachsender Anzahl von Testfällen steigen bis zu einem gewissen Grad auch der Testaufwand und die Komplexität
der Tests. Wenn Sie Testfälle aufschlüsseln, kann der erforderliche Testaufwand gründlicher und detaillierter
durchdacht werden.
-
Welche Arten des Testdesigns und der Testentwicklung zum Einsatz kommen und welche Ressourcen benötigt werden, ist
teilweise von der Anzahl und Komplexität der Testfälle abhängig.
Im Hinblick auf Testfälle gibt es jedoch einige Problemstellungen, die beachtet werden sollten:
-
Nicht jeder Test ist so komplex, dass es lohnt, ein Testfallartefakt zu erstellen, das geprüft und verwaltet werden
muss. Bei einfachen Tests ist eine kurze Beschreibung der Anforderungen oft ausreichend. In diese Kategorie könnte
sogar die Mehrzahl der Testfälle eingeordnet werden. Die auf das Dokumentieren einer Vielzahl einfacher Testfälle
verwendete Zeit könnte am Ende für wichtigere Testaufgaben fehlen.
-
Einige der Testideen, die Sie zu Beginn haben, werden sich im Nachhinein als fehlerbehaftet erweisen. Konkret
bedeutet dies, dass Sie einige der Testfälle, die Sie ausgehend von jenen ersten Testideen entwickelt haben,
verwerfen werden. Dies hat zur Folge, dass jede detaillierte Dokumentation solcher Testfälle auch hinfällig wird.
In Abdeckungsberichten, die auf Testfällen basieren, müsste diese Situation ebenfalls berücksichtigt werden. Für
Abdeckungsberichte sollten Sie daher wichtigere Kriterien als Testfälle heranziehen. Testfälle sollten als interne
Artefakte des Testteams angesehen und nach Bedarf verwendet werden.
Testfälle werden häufig nach Testtypen oder zu testenden Anforderungen kategorisiert bzw. klassifiziert, so dass es ein
breites Spektrum von Testfällen gibt. Ein heuristisches Verfahren zur Bestimmung von Testfällen beginnt mit Folgendem:
-
Es ist zu demonstrieren, dass die Anforderung erfüllt wurde (positiver Testfall).
-
Es ist zu demonstrieren, dass die Anforderung nur unter den gewünschten Bedingungen erfüllt werden kann
(Negativtest). Dieser Testfall spiegelt nicht annehmbare, anormale oder unerwartete Bedingungen/Daten wieder, denen
die Software logisch betrachtet ausgesetzt werden könnte.
Testfälle für Funktionstests werden aus den Anwendungsfällen des Testobjekts abgeleitet (siehe Arbeitsergebnis: Anwendungsfall). Sie sollten Testfälle für jedes
Anwendungsfallszenario entwickeln. Die Anwendungsfallszenarien ergeben sich aus der Beschreibung der Pfade (Basisablauf
und alternative Abläufe) durch den Anwendungsfall (vom Beginn bis zum Abschluss des Anwendungsfalls).
Im folgenden Beispieldiagramm sind die verschiedenen Pfade durch einen Anwendungsfall (Basisablauf und alternative
Abläufe)durch Pfeile dargestellt. Der Basisablauf, dargestellt durch die gerade schwarze Linie, ist der einfachste Pfad
durch den Anwendungsfall. Jeder alternative Ablauf beginnt zunächst wie der Basisablauf und mündet dann abhängig von
einer bestimmten Bedingung in einem abweichenden Ablauf. Alternative Abläufe können wieder in den Basisablauf übergehen
(wie hier die alternativen Abläufe 1 und 3), aus einem anderen alternativen Ablauf hervorgehen (hier der alternative
Ablauf 2) oder den Anwendungsfall beenden, ohne zuvor in einen anderen Ablauf zu münden (hier die alternativen Abläufe
2 und 4).
Beispiele für den Ablauf von Ereignissen in einem Anwendungsfall
Wenn Sie jedem der möglichen Pfade durch den Anwendungsfall im obigen Diagramm folgen, können Sie die verschiedenen
Anwendungsfallszenarien bestimmen. Wenn wir mit dem Basisablauf beginnen und diesen dann mit alternativen Abläufen
kombinieren, ergeben sich die folgenden Anwendungsfallszenarien:
Szenario 1
|
Basisablauf
|
|
|
|
Szenario 2
|
Basisablauf
|
Alternativer Ablauf 1
|
|
|
Szenario 3
|
Basisablauf
|
Alternativer Ablauf 1
|
Alternativer Ablauf 2
|
|
Szenario 4
|
Basisablauf
|
Alternativer Ablauf 3
|
|
|
Szenario 5
|
Basisablauf
|
Alternativer Ablauf 3
|
Alternativer Ablauf 1
|
|
Szenario 6
|
Basisablauf
|
Alternativer Ablauf 3
|
Alternativer Ablauf 1
|
Alternativer Ablauf 2
|
Szenario 7
|
Basisablauf
|
Alternativer Ablauf 4
|
|
|
Szenario 8
|
Basisablauf
|
Alternativer Ablauf 3
|
Alternativer Ablauf 4
|
|
Anmerkung: Zur Vereinfachung ist in den Szenarien 5, 6 und 8 nur die einfache Ausführung der im alternativen
Ablauf 3 dargestellten Schleife vorgesehen.
Die Testfälle für die einzelnen Szenarien werden abgeleitet, indem die spezifischen Bedingungen ermittelt werden, die
zu einem bestimmten Szenario führen.
Nehmen wir beispielsweise an, der im obigen Diagramm dargestellte Anwendungsfall gibt für den alternativen Ablauf 3
Folgendes an:
"Zu diesem Ablauf der Ereignisse kommt es, wenn der in Schritt 2 ("Betrag eingeben") eingegebene Betrag größer als der
derzeit verfügbare Betrag ist. Das System zeigt eine Warnung an und kehrt zum Schritt 2 des Basisablaufs, "Betrag
eingeben", zurück, damit der Bankkunde einen neuen abzuhebenden Betrag eingeben kann."
Ausgehend von diesen Informationen können Sie die erforderlichen Testfälle für die Ausführung des alternativen Ablaufs
bestimmen:
Testfall-ID
|
Szenario
|
Bedingung
|
Erwartetes Ergebnis
|
TF x
|
Szenario 4
|
Schritt 2 - Abzuhebender Betrag > Kontostand
|
Rückkehr zu Schritt 2 des Basisablaufs
|
TF y
|
Szenario 4
|
Schritt 2 - Abzuhebender Betrag < Kontostand
|
Der alternative Ablauf 3 ist nicht erforderlich. Der Basisablauf wird fortgesetzt.
|
TF z
|
Szenario 4
|
Schritt 2 - Abzuhebender Betrag = Kontostand
|
Der alternative Ablauf 3 ist nicht erforderlich. Der Basisablauf wird fortgesetzt.
|
Anmerkung: Die oben genannten Testfälle sind starke Vereinfachungen, da keine weiteren Informationen einbezogen
wurden. Es gibt selten Testfälle, die tatsächlich so simpel sind.
Nachfolgend sehen Sie ein realistischeres Beispiel dafür, wie Testfälle aus Anwendungsfällen abgeleitet werden können:
Beispiel:
Akteure und Anwendungsfälle für einen Bankautomaten
In der folgenden Tabelle sind der Basisablauf und einige alternative Abläufe für den Anwendungsfall des obigen
Diagramms (Abhebung von Bargeld) angegeben:
Basisablauf
|
Zu Beginn dieses Anwendungsfalls befindet sich der Geldautomat in Bereitschaft.
-
Abhebung einleiten - Der Kunde führt seine Bankkarte in den Kartenleser des Bankautomaten
ein.
-
Bankkarte überprüfen - Der Geldautomat liest den Kontocode vom Magnetstreifen der Bankkarte und
überprüft, ob die Bankkarte akzeptiert werden kann.
-
PIN eingeben - Der Geldautomat fordert die (vierstellige) PIN des Kunden an.
-
Kontocode und PIN prüfen - Anhand der Codes wird festgestellt, ob das Konto gültig ist und ob
die eingegebene PIN für das Konto die richtige ist. In diesem Ablauf ist das Konto ein gültiges
Konto und die eingegebene PIN ist die dem Konto zugeordnete PIN.
-
Optionen des Geldautomaten - Der Geldautomat zeigt die verfügbaren Alternativen an. In diesem
Ablauf wählt der Kunde immer "Barabhebung" aus.
-
Betrag eingeben - Der Geldautomat fordert zur Eingabe des Abhebungsbetrags auf. In diesem
Ablauf wählt der Kunde einen der vorgegebenen Beträge aus (€ 10, € 20, € 50 oder € 100).
-
Genehmigung - Der Geldautomat leitet die Verifizierung beim Banksystem ein, indem er die
Karten-ID, die PIN, den Betrag und die Kontoinformationen als Transaktion sendet. In diesem
Ablauf ist das Banksystem online und antwortet mit der Genehmigung für die Barabhebung.
Anschließend aktualisiert es den Kontostand entsprechend.
-
Ausgabe - Das Geld wird ausgegeben.
-
Kartenrückgabe - Die Bankkarte wird ausgeworfen.
-
Beleg - Der Beleg wird gedruckt und ausgegeben. Der Geldautomat aktualisiert außerdem das
interne Protokoll entsprechend.
Zum Abschluss des Anwendungsfalls befindet sich der Geldautomat in Bereitschaft.
|
Alternativer Ablauf 1 - Ungültige Karte
|
Falls bei Schritt zwei des Basisablaufs (Bankkarte überprüfen) die Karte nicht gültig ist, wird sie mit
einer entsprechenden Nachricht ausgeworfen.
|
Alternativer Ablauf 2 - Kein Geld im Geldautomaten
|
Wenn der Geldautomat bei Schritt 5 des Basisablaufs (Optionen des Geldautomaten) kein Geld enthält,
wird die Option "Barabhebung" nicht angezeigt.
|
Alternativer Ablauf 3 - Nicht genug Geld im Geldautomaten
|
Wenn der Geldautomat bei Schritt 6 des Basisablaufs (Betrag eingeben) nicht genug Geld enthält, um den
angeforderten Betrag auszahlen zu können, wird eine entsprechende Nachricht angezeigt und der Ablauf
mit Schritt 6 des Basisablaufs (Betrag eingeben) fortgesetzt.
|
Alternativer Ablauf 4 - Falsche PIN
|
Bei Schritt 4 des Basisablaufs (Kontocode und PIN prüfen) hat der Kunde drei Versuche, die korrekte PIN
einzugeben.
Wird eine falsche PIN eingegeben, zeigt der Geldautomat die entsprechende Nachricht an. Solange der
Kunde noch Eingabeversuche frei hat, kehrt dieser Ablauf zum Schritt 3 des Basisablaufs (PIN eingeben)
zurück.
Falls auch beim letzten Versuch eine falsche PIN eingegeben, wird die Karte einbehalten. Der
Geldautomat kehrt in den Bereitschaftsstatus zurück, und dieser Anwendungsfall ist beendet.
|
Alternativer Ablauf 5 - Konto nicht vorhanden
|
Falls das Banksystem bei Schritt 4 des Basisablaufs (Kontocode und PIN prüfen) einen Code zurückgibt,
der angibt, dass das Konto nicht gefunden wurde oder kein Konto für Barabhebungen ist, zeigt der
Geldautomat die entsprechende Nachricht an und fährt mit Schritt 9 des Basisablaufs (Kartenrückgabe)
fort.
|
Alternativer Ablauf 6 - Nicht genug Geld auf dem Konto
|
Falls das Banksystem bei Schritt 7 des Basisablaufs (Genehmigung) einen Code zurückgibt, der angibt,
dass auf dem Konto weniger Geld verfügbar ist als in Schritt 6 des Basisablaufs (Betrag eingeben)
eingegeben wurde, zeigt der Geldautomat die entsprechende Nachricht an und fährt mit Schritt 6 des
Basisablaufs (Betrag eingeben) fort.
|
Alternativer Ablauf 4 - Tageshöchstsatz für Abhebungen erreicht
|
Falls das Banksystem bei Schritt 7 des Basisablaufs (Genehmigung) einen Code zurückgibt, der angibt,
dass der Kunde mit dieser Anforderung den Höchstbetrag überschreiten würde, der innerhalb von 24
Stunden abgehoben werden darf, zeigt der Geldautomat die entsprechende Nachricht an und fährt mit
Schritt 6 des Basisablaufs (Betrag eingeben) fort.
|
Alternativer Ablauf x - Protokollfehler
|
Falls das Protokoll bei Schritt 10 des Basisablaufs (Beleg) nicht aktualisiert werden kann, wird der
Geldautomat in den sicheren Modus, in dem alle Funktionen ausgesetzt werden. An das Banksystem wird ein
Alarm gesendet, der anzeigt, dass der Betrieb des Geldautomaten ausgesetzt wurde.
|
Alternativer Ablauf y - Abbruch
|
Der Kunde kann die Transaktion zu jedem Zeitpunkt beenden (abbrechen). Die Transaktion wird gestoppt
und die Karte ausgeworfen.
|
Alternativer Ablauf z - Störfall
|
Der Geldautomat ist mit Bewegungsdetektoren und zahlreichen Sensoren ausgestattet, die verschiedene
Funktionen (z. B. den Netzstrom, den Druck auf die verschiedenen Klappen und Schlitze) überwachen.
Sobald ein Sensor aktiviert wird, wird ein Alarmsignal an die Polizei gesendet. Der Geldautomat wird in
den sicheren Modus versetzt, in dem alle Funktionen ausgesetzt sind, bis die entsprechenden Neustart-
oder Reinitialisierungsmaßnahmen ergriffen werden.
|
Laut Iterationsplan müssen wir in der ersten Iteration überprüfen, ob der Anwendungsfall 'Barabhebung' korrekt
implementiert wurde. Der gesamte Anwendungsfall ist noch nicht implementiert. Bisher wurden nur die folgenden
Abläufe implementiert:
-
Basisablauf - Abhebung eines vorgegebenen Betrags (€ 10, € 20, € 50, € 100)
-
Alternativer Ablauf 2 - Kein Geld im Geldautomaten
-
Alternativer Ablauf 3 - Nicht genug Geld im Geldautomaten
-
Alternativer Ablauf 4 - Falsche PIN
-
Alternativer Ablauf 5 - Konto nicht vorhanden / Falsche Kontoart
-
Alternativer Ablauf 6 - Nicht genug Geld auf dem Konto
Aus diesem Anwendungsfall können die folgenden Szenarien abgeleitet werden:
Szenario 1 - Erfolgreiche Barabhebung
|
Basisablauf
|
|
Szenario 2 - Kein Geld im Geldautomaten
|
Basisablauf
|
Alternativer Ablauf 2
|
Szenario 3 - Nicht genug Geld im Geldautomaten
|
Basisablauf
|
Alternativer Ablauf 3
|
Szenario 4 - Falsche PIN (Eingabeversuche frei)
|
Basisablauf
|
Alternativer Ablauf 4
|
Szenario 5 - Falsche PIN (keine Eingabeversuche mehr)
|
Basisablauf
|
Alternativer Ablauf 4
|
Szenario 6 - Konto nicht vorhanden / Falsche Kontoart
|
Basisablauf
|
Alternativer Ablauf 5
|
Szenario 7 - Nicht genug Geld auf dem Konto
|
Basisablauf
|
Alternativer Ablauf 6
|
Anmerkung: Zur Vereinfachung wurden die Schleifen der alternativen Abläufe 3 und 6 (Szenarien 3 und 7) und
Kombinationen mehrerer Schleifen nicht in die obige Tabelle aufgenommen.
Für jedes dieser sieben Szenarien müssen Testfälle ermittelt werden. Für die Festlegung und Verwaltung von Testfällen
können Matrizes oder Entscheidungstabellen verwendet werden. Nachfolgend sehen Sie ein allgemeines Format, bei dem jede
Zeile einen Testfall repräsentiert und die Spalten die Informationen zum jeweiligen Testfall enthalten. In diesem
Beispiel sind zu jedem Testfall eine Testfall-ID, eine Bedingung (oder Beschreibung), alle im Testfall vorkommenden
Datenelemente (als Eingabe oder bereits in der Datenbank vorhanden) und das erwartete Ergebnis angegeben.
Beginnen Sie bei der Entwicklung der Matrix mit der Bestimmung der Datenelemente, die für die Ausführung der
Testfallszenarien erforderlich sind. Legen Sie dann für jedes Szenario mindestens einen Testfall fest, der die
Bedingung für die Ausführung des Szenariums enthält. In der folgenden Matrix wird beispielsweise mit G (gültig)
angegeben, dass diese Bedingung erfüllt (GÜLTIG) sein muss, damit der Basisablauf ausgeführt wird. Mit U (ungültig)
wird die Bedingung bezeichnet, die den gewünschten alternativen Ablauf auslöst. Mit n. z. wird in der folgenden Tabelle
angegeben, dass die jeweilige Bedingung für den Testfall nicht zutrifft.
TF-ID
|
Szenario / Bedingung
|
PIN
|
Kontonummer
|
Eingegebener Betrag
(ausgewählter Betrag)
|
Kontostand
|
Im Geldautomaten verfügbarer Betrag
|
Erwartetes Ergebnis
|
BA1
|
Szenario 1 - Erfolgreiche Barabhebung
|
G
|
G
|
G
|
G
|
G
|
Erfolgreiche Barabhebung
|
BA2
|
Szenario 2 - Kein Geld im Geldautomaten
|
G
|
G
|
G
|
G
|
U
|
Option für Barabhebung wird nicht angezeigt; Anwendungsfall endet
|
BA3
|
Szenario 3 - Nicht genug Geld im Geldautomaten
|
G
|
G
|
G
|
G
|
U
|
Warnung; Rückkehr zu Schritt 6 des Basisablaufs (Betrag eingeben)
|
BA4
|
Szenario 4 - Falsche PIN (> 1 Versuch frei)
|
U
|
G
|
n. z.
|
G
|
G
|
Warnung; Rückkehr zu Schritt 4 des Basisablaufs (PIN eingeben)
|
BA5
|
Szenario 4 - Falsche PIN (1 Versuch frei)
|
U
|
G
|
n. z.
|
G
|
G
|
Warnung; Rückkehr zu Schritt 4 des Basisablaufs (PIN eingeben)
|
BA6
|
Szenario 4 - Falsche PIN (0 Versuche frei)
|
U
|
G
|
n. z.
|
G
|
G
|
Warnung; Karte wird einbehalten; Anwendungsfall endet
|
Nach der obigen Matrix werden die vier Szenarien mit sechs Testfällen ausgeführt. Der Testfall BA1 für den Basisablauf
ist ein so genannter positiver Testfall. Der Pfad des Basisablaufs wird ohne Abweichungen bis zu Ende ausgeführt. Für
eine umfassende Überprüfung des Basisablaufs müssen negative Testfälle einbezogen werden, um sicherzustellen, dass der
Basisablauf nur unter den entsprechenden Bedingungen verwendet wird. Diese negativen Testfälle werden von den
Testfällen BA2 bis BA6 repräsentiert. (Das grau hinterlegte Feld gibt die Bedingung an, die die Ausführung der
alternativen Abläufe nach sich zieht.) BA2 bis BA6 sind für den Basisablauf negative Testfälle, für die alternativen
Abläufe 2 bis 4 jedoch positive Testfälle. Außerdem gibt es für jeden der alternativen Abläufe wenigstens einen
negativen Testfall (BA1 mit dem Basisablauf).
Szenario 4 ist ein Beispiel dafür, dass ein positiver und ein negativer Testfall pro Szenario nicht immer ausreichend
ist. Wenn Szenario 4 (falsche PIN) gründlich getestet werden soll, sind mindestens drei positive Testfälle erforderlich
(die Szenario 4 aufrufen):
-
Die falsche PIN wird eingegeben, und der Kunde hat drei weitere Eingabeversuche frei. Dieser alternative Ablauf
mündet in Schritt 3 des Basisablaufs (PIN eingeben).
-
Die falsche PIN wird eingegeben, und der Kunde hat keine Eingabeversuche mehr frei. Bei diesem alternativen Ablauf
wird die Karte einbehalten und der Testfall beendet.
-
Beim letzten Eingabeversuch wird die RICHTIGE PIN eingegeben. Dieser alternative Ablauf mündet in Schritt 5 des
Basisablaufs (Betrag eingeben).
In der obigen Matrix wurden keine tatsächlichen Werte für die Bedingungen (Daten) eingegeben. Eine solche Matrix hat
den Vorteil, dass sie einen guten Überblick über die zu testenden Bedingungen gibt. Anhand dieser Matrix lässt sich
auch leicht bestimmen, ob genug Testfälle definiert wurden, denn Sie müssen sich nur die Gs und Us ansehen (in unserem
Beispiel die grau hinterlegten Zellen). Sie werden in der obigen Tabelle einige Bedingungen finden, für die es keine
grau hinterlegten Zellen gibt. Es fehlen somit Testfälle, z. B. für Szenario 6 (Konto nicht vorhanden oder falsche
Kontoart) und Szenario 7 (nicht genug Geld auf dem Konto).
Sobald Sie genug Testfälle festgelegt haben, sollten Sie sie auswerten und auf ihre Genauigkeit und Angemessenheit
prüfen. Doppelt vorhandene, äquivalente oder anderweitig redundante Testfälle sollten gestrichen werden. Weitere
Details hierzu finden Sie im Abschnitt Konzept: Liste mit
Testideen. Zusätzliche Informationen enthält auch der Abschnitt Testdaten
für Testfälle definieren.
TF-ID
|
Szenario / Bedingung
|
PIN
|
Kontonummer
|
Eingegebener Betrag
(ausgewählter Betrag)
|
Kontostand
|
Im Geldautomaten verfügbarer Betrag
|
Erwartetes Ergebnis
|
BA1
|
Szenario 1 - Erfolgreiche Barabhebung
|
4987
|
809-498
|
50,00
|
500,00
|
2.000
|
Erfolgreiche Barabhebung; Kontostand aktualisiert (450,00)
|
BA2
|
Szenario 2 - Kein Geld im Geldautomaten
|
4987
|
809-498
|
100,00
|
500,00
|
0,00
|
Option für Barabhebung wird nicht angezeigt; Anwendungsfall endet
|
BA3
|
Szenario 3 - Nicht genug Geld im Geldautomaten
|
4987
|
809-498
|
100,00
|
500,00
|
70,00
|
Warnung; Rückkehr zu Schritt 6 des Basisablaufs (Betrag eingeben)
|
BA4
|
Szenario 4 - Falsche PIN (> 1 Versuch frei)
|
4978
|
809-498
|
n. z.
|
500,00
|
2.000
|
Warnung; Rückkehr zu Schritt 4 des Basisablaufs (PIN eingeben)
|
BA5
|
Szenario 4 - Falsche PIN (1 Versuch frei)
|
4978
|
809-498
|
n. z.
|
500,00
|
2.000
|
Warnung; Rückkehr zu Schritt 4 des Basisablaufs (PIN eingeben)
|
BA6
|
Szenario 4 - Falsche PIN (0 Versuche frei)
|
4978
|
809-498
|
n. z.
|
500,00
|
2.000
|
Warnung; Karte wird einbehalten; Anwendungsfall endet
|
Die obigen Testfälle sind nur ein kleiner Teil der Testfälle, die erforderlich sind um den Anwendungsfall der
Barabhebung für diese Iteration zu überprüfen. Weitere erforderliche Testfälle wären unter anderem:
-
Szenario 6 - Konto nicht vorhanden oder falsche Kontoart: Das Konto wurde nicht gefunden oder ist nicht verfügbar.
-
Szenario 6 - Konto nicht vorhanden oder falsche Kontoart: Von dem Konto sind keine Barabhebungen möglich.
-
Szenario 7 - Nicht genug Geld auf dem Konto: Der angeforderte Betrag liegt über dem Kontostand.
In späteren Iterationen, wenn andere Abläufe implementiert werden, sind Testfälle für folgende Szenarien erforderlich:
-
Ungültige Karte (Die Karte wurde als verloren oder gestohlen gemeldet, stammt nicht von einer anerkannten Bank, hat
einen beschädigten Magnetstreifen usw.)
-
Nicht lesbare Karte (Der Kartenleser ist blockiert, offline oder funktioniert nicht.)
-
Aufgelöstes, gesperrtes oder anderweitig nicht verfügbares Konto.
-
Der Geldautomat enthält nicht genug Geld oder kann den angeforderten Betrag mit den vorhandenen Banknoten nicht
auszahlen. (Dieser Fall unterscheidet sich von BA3 dadurch, dass hier nur eine bestimmte Stückelung möglich ist,
jedoch nicht alle Banknoten fehlen.)
-
Das Banksystem ist nicht erreichbar, so dass keine Genehmigung erteilt werden kann.
-
Mitten in einer Transaktion geht das Bankennetz offline oder fällt der Strom aus.
Beachten Sie beim Ermitteln von Testfällen für Funktionstests Folgendes:
-
Für jedes Anwendungsfallszenario müssen ausreichend positive und negative Testfälle bestimmt werden.
-
Die Testfälle berücksichtigen alle von den Anwendungsfällen implementierten Geschäftsregeln. Es muss sichergestellt
sein, dass es Testfälle innerhalb und außerhalb der Grenzbedingungen/-werte sowie mit den Grenzbedingungen/-werten
der Geschäftsregeln gibt.
-
Die Testfälle berücksichtigen die Abfolge von Ereignissen oder Aktivitäten (z. B. die in den Ablaufdiagrammen des
Designmodells angegebenen) oder Objektstatus bzw. -bedingungen der Benutzerschnittstelle.
-
Die Testfälle berücksichtigen alle für den Anwendungsfall definierten speziellen Anforderungen, z. B. die
minimale/maximale Leistung, die während der Ausführung der Anwendungsfälle manchmal mit der minimalen/maximalen
Auslastung oder dem minimalen/maximalen Datenvolumen kombiniert wird.
Der Abschnitt Testdaten für Testfälle definieren enthält weitere
Anleitungen.
Artefakte für funktionale Anforderungen, wie es Anwendungsfallspezifikationen sind, können nicht alle Anforderungen für
ein Testobjekt widerspiegeln. Nicht funktionale Anforderungen, z. B. an Leistung, Sicherheit und Zugriff, und
Konfigurationsanforderungen geben weitere Verhaltensmöglichkeiten oder Merkmale des Testobjekts an und werden oft
getrennt von den funktionalen Anforderungen dokumentiert. Diese ergänzende Spezifikation ist eine der Hauptquellen für
das Ableiten von Testfällen für solche zusätzlichen Anforderungen.
Nachfolgend sind Richtlinien für die Ableitung dieser zusätzlichen Testfälle beschrieben.
Die Primärvorgabe für Leistungstests sind die ergänzenden Spezifikationen, die nicht funktionale Anforderungen
enthalten (siehe Arbeitsergebnis: Ergänzende Spezifikationen). Gehen Sie beim Ableiten
von Testfällen für Leistungstests nach den folgenden Richtlinien vor:
-
Stellen Sie sicher, dass für jede Anweisung der ergänzenden Spezifikation, die ein Leistungskriterium angibt,
mindestens ein Testfall festgelegt ist. Leistungskriterien werden in der Regel als Zeit pro Transaktion, Anzahl der
Transaktionen pro Benutzer oder als Perzentile angegeben.
-
Stellen Sie sicher, dass für jeden kritischen Anwendungsfall mindestens ein Testfall festgelegt ist. Kritisch sind
jene Anwendungsfälle, die in den obigen Anweisungen angegeben sind und/oder im Dokument zur Auslastungsanalyse, das
durch Leistungsermittlungen ausgewertet werden muss (siehe Arbeitsergebnis: Dokument zur Auslastungsanalyse).
Wie bei den Funktionstests wird es auch hier in der Regel mehr als einen Testfall pro Anwendungsszenario oder
Anforderung geben. Es ist üblich, mehrere Testfälle zu definieren, z. B. einen unterhalb des Leistungsgrenzwerts
(durchschnittliche Transaktionsrate), einen weiteren mit dem Grenzwert (hohe Transaktionsrate) und einen dritten
Testfall oberhalb des Grenzwertes (Spitzentransaktionsrate).
Neben den obigen Leistungskriterien müssen Sie Bedingungen angeben, die sich auf die Antwortzeit auswirken. Dazu
gehören unter anderem:
-
Größe der Datenbank - Wie viele Datensätze gibt es?
-
Auslastung - Transaktionsmuster:
-
Art, Anzahl und Häufigkeit simultaner Benutzeraktionen
-
Art, Anzahl, Häufigkeit und Dauer simultan ausgeführter Transaktionen
-
Umgebungsmerkmale (Hardware-, Netware-, Softwarekonfiguration)
Es ist gängige Praxis, Testfälle für Leistungstest in tabellarischen Matrizes zu erfassen, ähnlich denen für
Funktionstests.
Im Abschnitt Testdaten für Testfälle definieren finden Sie weitere Details.
Nachfolgend sind einige Beispiele für die verschiedenen Arten von Leistungstests aufgeführt:
Belastungstests:
TF-ID
|
Auslastung
|
Bedingung
|
Erwartetes Ergebnis
|
PBA1
|
1
(ein GA)
|
Vollständige Abhebungstransaktion
|
Für die gesamte Transaktion werden < 20 Sekunden benötigt (nicht vom Akteur abhängige
Ablaufsteuerung).
|
PBA2
|
2
(1.000 simultane GA)
|
Vollständige Abhebungstransaktion
|
Für die gesamte Transaktion werden < 30 Sekunden benötigt (nicht vom Akteur abhängige
Ablaufsteuerung).
|
PBA3
|
3
(10.000 simultane GA)
|
Vollständige Abhebungstransaktion
|
Für die gesamte Transaktion werden < 50 Sekunden benötigt (nicht vom Akteur abhängige
Ablaufsteuerung).
|
Stresstests:
TF-ID
|
Auslastung
|
Bedingung
|
Erwartetes Ergebnis
|
SBA1
|
2
(1.000 simultane GA)
|
Datenbanksperre; 2 GA fragen dasselbe Konto ab
|
GA-Anforderungen werden in eine Warteschlange gestellt.
|
SBA2
|
2
(1.000 simultane GA)
|
Keine Kommunikation mit dem Banksystem möglich
|
Die Transaktion wird in die Warteschlange gestellt oder überschreitet das Zeitlimit.
|
SBA3
|
2
(1.000 simultane GA)
|
Die Kommunikation mit dem Banksystem wird während der Transaktion unterbrochen.
|
Es erscheint eine Warnung.
|
Akteure und Anwendungsfälle beschreiben die Interaktion zwischen externen Benutzern des Systems und den Aktionen des
Systems für die Ausgabe eines Betrages an einen bestimmten Akteur. Bei komplexen Systemen gibt es viele Akteure. Hier
ist es wichtig, dass Testfälle entwickelt werden, mit denen sichergestellt wird, dass nur die Anwendungsfälle nur von
den angegebenen Akteuren ausgeführt werden können. Dies gilt insbesondere, wenn der Ablauf der Ereignisse im
Anwendungsfall je nach Akteur ein anderer ist.
Bei den GA-Anwendungsfällen sind beispielsweise verschiedene Ereignisabläufe möglich, wenn der eine Akteur 'Bankkunde'
eine Karte der Bank benutzt, der der Geldautomat (GA) gehört, und ein anderer 'Bankkunde' eine Karte einer
Konkurrenzbank verwendet oder versucht, die Karte einer Bank einzusetzen, die nicht zum Cashpool gehört.
Beachten Sie dieselben Richtlinien wie oben für funktionale Testfälle.
Der Abschnitt Testdaten für Testfälle definieren enthält weitere
Anleitungen.
Beispieltestfälle für Sicherheit und Zugriff:
TF-ID
|
Bedingung
|
Karte
(G = gültige Karte)
|
Kartenleser
(G = gültiger Lesevorgang)
|
Bankennetz
|
Erwartetes Ergebnis
|
KBA1
|
Im Bankennetz
|
G
|
G
|
G
|
Alle Anwendungsfälle sind verfügbar.
|
KBA2
|
Außerhalb des Bankennetzes
|
G
|
G
|
U
|
Nur Anwendungsfall Barabhebung
|
KBA3
|
Karte nicht lesbar
|
U
|
G
|
G
|
Warnung; Karte wird ausgeworfen
|
KBA4
|
Karte als gestohlen gemeldet
|
U
|
G
|
G
|
Warnung; Karte wird einbehalten
|
KBA5
|
Karte abgelaufen
|
U
|
G
|
G
|
Warnung; Karte wird einbehalten
|
In typischen verteilten Systemen können viele zulässige Kombinationen aus Hardware und Software unterstützt werden. Mit
Tests sollte überprüft werden, ob die Leistung des Testobjekts in verschiedenen Konfigurationen, z. B. mit
verschiedenen Betriebssystemen, Browsern oder CPU-Geschwindigkeiten, akzeptabel ist. Die Tests müssen darüber hinaus
Kombinationen von Komponenten abdecken, um Mängel feststellen zu können, die durch Interaktionen verschiedener
Komponenten entstehen. Solche Tests könnten beispielsweise sicherstellen, dass die Version der von einer Anwendung
installierten DLLs nicht in Konflikt mit den Versionen derselben DLLs einer anderen Anwendung gerät.
Beachten Sie beim Ableiten von Testfällen für Konfigurationstests die folgenden Richtlinien:
-
Stellen Sie sicher, dass für jede kritische Konfiguration mindestens ein Testfall festgelegt ist. Ermitteln Sie
dazu die erforderlichen Hardware- und Softwarekonfigurationen für die Umgebung des Testobjekts und ordnen Sie
diesen Konfigurationen Prioritäten zu, damit die am häufigsten vorkommenden zuerst getestet werden. Zu diesen
Konfigurationen gehören unter anderem:
-
Druckerunterstützung
-
Netzverbindungen (LANs und WANs)
-
Serverkonfigurationen (Servertreiber, Serverhardware)
-
Weitere Software (auf dem Desktop und/oder auf Servern installiert)
-
Softwareversionen für die gesamte installierte Software
-
Stellen Sie sicher, dass für jede problemanfällige Konfiguration mindestens ein Testfall festgelegt ist. Dazu
könnten folgende Konfigurationen gehören:
-
Hardware mit dem niedrigsten Durchsatz
-
vorhandene Softwareprogramme mit einem Verlauf von Kompatibilitätsproblemen
-
Clientzugriff auf den Server über die langsamste LAN/WAN-Verbindung
-
Unzureichende Ressourcen (geringe CPU-Geschwindigkeit, Mindestspeicher oder -auflösung, minimaler
Plattenspeicherplatz usw.)
Mit Installationstests muss überprüft werden, ob das Testobjekt in allen möglichen Installationsszenarien installiert
werden kann. Bei diesen Szenarien kann es sich beispielsweise um eine Erstinstallation des Testobjekts handeln oder um
die Installation einer neueren Version oder eines neueren Builds (auf einer Maschine mit der älteren Version).
Installationstests sollen auch sicherstellen, dass sich das Testobjekt annehmbar verhält, wenn anormale Bedingungen
(wie unzureichender Plattenspeicherplatz) auftreten.
Die Testfälle sollten die Installationsszenarien für die Software abdecken. Dazu gehören unter anderem:
-
Installation von Verteilerdatenträgern (Disketten, CD-ROMs oder Dateiserver)
-
Neuinstallation
-
Vollständige Installation
-
Benutzerdefinierte Installationen
-
Upgradeinstallationen
Für die Installationsprogramme für Client-/Serversoftware gibt es eine spezielle Gruppe von Testfällen. Im Gegensatz zu
hostgestützten Systemen ist das Installationsprogramm hier in der Regel in ein Programm für den Server und eines für
den Client unterteilt. Daher ist es wichtig, dass bei Installationstests alle Komponenten des Testobjekts installiert
werden (einschließlich Clients, Mittelschichten und Server).
Im Idealfall werden Sie alle erforderlichen Angaben für das Ableiten von Testfällen im Anwendungsfallmodell, im
Designmodell und in der ergänzenden Spezifikation finden. Es ist jedoch nicht unüblich, dass Sie die darin enthaltenen
Angaben vervollständigen müssen.
Beispiele:
-
Testfälle für Betriebstests (um sicherzustellen, dass die installierte Software lange Zeit funktioniert, bis ein
Fehler auftritt)
-
Testfälle zur Untersuchung von Leistungsengpässen und der Systemkapazitäten oder zur Extrembelastung des
Testobjekts, um einen Fehler auszulösen
Diese Testfälle sind in den meisten Fällen Varianten oder Zusammenfassungen der Testfälle, die Sie aus den zuvor
definierten Testfällen abgeleitet haben.
Produktabnahmetests sind die letzten Tests und werden unmittelbar vor dem Deployment der Software ausgeführt. Mit
Abnahmetests wird geprüft, ob die Software bereit ist und von den Benutzern verwendet werden kann, um die Funktionen
und Aufgaben auszuführen, für die die Software entwickelt wurde. Neben der Ausführung der Software zur Überprüfung
ihrer Betriebsbereitschaft werden in den Produktabnahmetests alle an den Kunden gelieferten Arbeitsergebnisse
überprüft. Dazu gehören beispielsweise Schulungen, die Dokumentation und die Konfektionierung.
Die Testfälle für die Softwarearbeitsergebnisse werden wie in den obigen Abschnitten beschrieben abgeleitet. Je
nachdem, wie formal der Produktabnahmetest sein soll, werden die Testfälle dieselben wie die oben definierten oder
diesen sehr ähnlich sein (formaler Abnahmetest) oder nur eine Untergruppe der oben definierten Testfälle sein (nicht
formaler Abnahmetest). Vor der Implementierung und Ausführung von Produkttests muss unabhängig von der Tiefe der
Testfälle Einigkeit über die Testfälle und die Kriterien für die Produktabnahme erzielt werden.
Die Bewertung von Arbeitsergebnissen (bei denen es sich nicht um Software handelt) kann je nach Art des zu bewertenden
Arbeitsergebnisses ganz verschieden sein. Lesen Sie die Richtlinien und Prüflisten für jedes spezifische
Arbeitsergebnis, um festzustellen, was wie zu bewerten ist.
Bei Regressionstests werden zwei Builds oder Versionen desselben Testobjekts miteinander verglichen und Differenzen als
potenzielle Mängel ermittelt. Es wird somit davon ausgegangen, dass eine neue Version sich wie eine frühere Version
verhalten sollte. Auf diese Weise soll sichergestellt werden, dass sich mit den Änderungen der neuen Version keine
Mängel eingeschlichen haben.
Im Idealfall werden alle Testfälle einer Iteration auch in den folgenden Iterationen verwendet. Verwenden Sie beim
Ermitteln, Entwerfen und Implementieren von Testfällen, die folgenden Richtlinien, um bei minimalem Verwaltungsaufwand
maximal von den Regressionstests profitieren und eine maximale Wiederverwendungsquote erreichen zu können:
-
Stellen Sie sicher, dass der Testfall nur die kritischen Datenelemente benennt. (Das sind die Elemente, die zur
Erzeugung/Unterstützung der zu testenden Bedingung erforderlich sind.)
-
Stellen Sie sicher, dass jeder Testfall eindeutige Eingaben oder eine eindeutige Folge von Ereignissen beschreibt,
die zu einem eindeutigen Verhalten des Testobjekts führen.
-
Streichen Sie redundante oder äquivalente Testfälle.
-
Fassen Sie Testfälle mit identischem Anfangsstatus des Testobjekts und identischem Testdatenstatus zusammen.
Nachdem Sie die Testfälle diskutiert und ein allgemeines Einverständnis erzielt haben, können Sie die eigentlichen
Testwerte detaillierter definieren (z. B. in der Matrix für die Testfallimplementierung) und die Testdatenartefakte
erstellen.
Zusätzliche Informationen zum Definieren und Verwalten von Testdaten finden Sie im Abschnitt Richtlinie: Testdaten.
|