Testpfad

Van Wikipedia, de gratis encyclopedie

Als Testpfad bezeichnet man in der Softwareentwicklung ein Codeausführungszenario, von dem ein bestimmtes Verhalten erwartet und geprüft wird.

Happy Path[Bearbeiten | Quelltext bearbeiten]

Ein Happy Path[1], Happy Day Scenario oder Golden Path (sinngemäß: glücklicher Pfad) ist das einfachste Szenario, in welchem ein Codeabschnitt funktionieren soll, ohne dass Ausnahmen oder Fehlerzustände eintreten. Da dies die Basisfunktionalität des Codeabschnitts darstellt, ist der Happy Path das Mindeste das getestet werden sollte.

Der Happy Path alleine reicht allerdings nicht aus um die Funktionalität in Code mit Verzweigung zu testen. Will man beispielsweise eine Funktion zur Prüfung von Kreditkartennummern testen, so reicht es nicht mittels des Happy Path zu testen, ob gültige Kreditkartennummern zu einem positiven Ergebnis führen, sondern es muss zudem durch weitere Tests getestet werden, ob ungültige Nummern zu einem negativen Ergebnis führen.

Scary Path[Bearbeiten | Quelltext bearbeiten]

Ein Scary Path[1] (sinngemäß: furchteinflößender Pfad) ist ein Szenario, welches den Code zu einem Fehlverhalten oder in einen Fehlzustand bringt. Insbesondere solche, die andere Teile des Programms oder auch andere Programme ebenfalls zu einem Fehlverhalten oder in einen Fehlzustand bringt.

Der Scary Path ist vor allem dann zu testen, wenn durch das Fehlverhalten bzw. den Fehlerzustand ein hohes Risiko für die Stakeholder besteht.

Angry Path[Bearbeiten | Quelltext bearbeiten]

Ein Angry Path[1] (sinngemäß: verärgerter Pfad) ist ein Szenario, in welchem der getestete Code zu einem Ausnahmeverhalten führt, jedoch in einem gültigen und funktionierenden Zustand verbleibt. Dies betrifft insbesondere Ausnahmeverhalten durch die Eingabevalidierung.

Delinquent Path[Bearbeiten | Quelltext bearbeiten]

Ein Delinquent Path[1] (sinngemäß: krimineller Pfad) testet ob Authentifizierung, Autorisierung, Berechtigung, digitale Signierung, Verschlüsselung oder andere Sicherheitsmaßnahmen eingehalten werden.

Embarrassing Path[Bearbeiten | Quelltext bearbeiten]

Ein Embarrassing Path[1] (sinngemäß: peinlicher Pfad) ist ein Verhalten welches, wenn es nicht eingehalten wird, zu einer Rufschädigung des Entwicklers oder Unternehmens führen würde. Etwa wenn dem Nutzer eine falsche oder unpässliche Meldung angezeigt wird.

Desolate Path[Bearbeiten | Quelltext bearbeiten]

Ein Desolate Path[1] (sinngemäß: einsamer Pfad) ist ein Szenario, in dem die Funktion nicht mit ausreichenden Daten versorgt wird. Beispielsweise wenn mindestens einer der übergebenen Werte oder Abhängigkeiten auf null, 0, 1, -1, NaN, einen Standardwert oder ähnliches gesetzt wird.

Forgetful Path[Bearbeiten | Quelltext bearbeiten]

Ein Forgetful Path[1] (sinngemäß: vergesslicher Pfad) ist ein Testszenario, in dem dem Code zur Ausführung ungenügend Ressourcen bereitstehen und ein Datenverlust möglich ist. Etwa begrenzter Speicher, ein begrenzter Threadpool, eine Datei oder Datenbank in die geschrieben werden soll aber nicht vorhanden ist etc.

Indecisive Path[Bearbeiten | Quelltext bearbeiten]

Der Indecisive Path[1] (sinngemäß: unentschlossener Pfad) simuliert einen Benutzer, welcher eine Reihe von Aktionen setzt und diese wieder rückgängig machen will. Insbesondere ausgewählte Menüpunkte wieder abwählen, einen Zurück- oder Rückgängig-Button betätigen, sowie bereits gespeicherte Daten oder Änderungen wieder löschen.

Greedy Path[Bearbeiten | Quelltext bearbeiten]

Im Greedy Path[1] (sinngemäß: gieriger Pfad) wird eine möglichst große Anzahl von Optionen ausgewählt oder eine Vielzahl von Aktionen innerhalb kürzester Zeit ausgeführt.

Stressful Path[Bearbeiten | Quelltext bearbeiten]

Im Stressful Path[1] (sinngemäß: stressiger Pfad) wird ein Ausführungspfad solange belastet, bis die korrekte Funktion nicht mehr gewährleistet werden kann.

Beispielsweise sei eine Webanwendung, bei der die Anzahl von HTTP-Requests immer weiter erhöht wird, bis die Webanwendung, etwa aufgrund eines aufgebrauchten Verbindungs-Pools, nicht mehr reagiert. Dies erlaubt es Prognosen darüber anzustellen, ab welchem Volumen die Anwendung ausfallen wird.

Quellenangaben[Bearbeiten | Quelltext bearbeiten]

  1. a b c d e f g h i j Gojko Adzic, David Evans, Tom Roden: Fifty Quick Ideas To Improve Your Tests. Hrsg.: Neuri Consulting. 2015, ISBN 978-0-9930881-1-7, Tap into your emotions (englisch, 124 S.).