Richtlinie: Testfall
Diese Richtlinie erläutert das Festlegen und Entwerfen von Testsoftware.
Beziehungen
Hauptbeschreibung

Erläuterung

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 aus Anwendungsfällen ableiten

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).

Im Titel genannte Abbildung

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:

Im Titel genannte Abbildung

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.
  1. Abhebung einleiten - Der Kunde führt seine Bankkarte in den Kartenleser des Bankautomaten ein.
  2. Bankkarte überprüfen - Der Geldautomat liest den Kontocode vom Magnetstreifen der Bankkarte und überprüft, ob die Bankkarte akzeptiert werden kann.
  3. PIN eingeben - Der Geldautomat fordert die (vierstellige) PIN des Kunden an.
  4. 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.
  5. Optionen des Geldautomaten - Der Geldautomat zeigt die verfügbaren Alternativen an. In diesem Ablauf wählt der Kunde immer "Barabhebung" aus.
  6. 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).
  7. 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.
  8. Ausgabe - Das Geld wird ausgegeben.
  9. Kartenrückgabe - Die Bankkarte wird ausgeworfen.
  10. 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.

Testfälle aus ergänzenden Spezifikationen ableiten

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.

Testfälle für Leistungstests ableiten

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.

Testfälle für Sicherheits-/Zugriffstests ableiten

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

Testfälle für Konfigurationstests ableiten

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.)

Testfälle für Installationstests ableiten

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).

Testfälle für weitere nicht funktionale Tests ableiten

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.

Testfälle für Produktabnahmetests ableiten

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.

Testfälle zur Build-Verifikation für Regressionstests

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.

Testdaten für Testfälle definieren

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.