Testverfahren und -techniken
In dieser Lerneinheit tauchst du in die zentralen Teststrategien Black-Box- und White-Box-Testing ein und lernst deren charakteristische Merkmale und Einsatzgebiete kennen. Du verstehst die methodischen Unterschiede zwischen beiden Ansätzen und kannst einschätzen, welche Teststrategie sich für welchen Anwendungsfall am besten eignet. Diese Grundlagen ermöglichen dir, in der Praxis systematische Tests zu planen und durchzuführen, die optimal auf deine Testszenarien abgestimmt sind.
Einführung
Du sitzt im Code-Review und ein Kollege fragt: “Hast du die Grenzwerte getestet?” Du nickst – aber innerlich fragst du dich, ob deine drei Testfälle wirklich ausreichen. Oder ob du etwas Wichtiges übersehen hast.
In der Praxis scheitern viele Tests nicht an fehlendem Wissen, sondern an unsystematischer Anwendung. Wie weisst du, welche Werte du testen musst? Wie findest du die Stellen, an denen Software typischerweise versagt?
Genau hier helfen systematische Testverfahren. Sie geben dir Werkzeuge an die Hand, mit denen du gezielt und effizient testest – statt zu raten.
Lernziele
Nach dieser Lerneinheit kannst du:
- Black-Box- und White-Box-Testing unterscheiden und situationsgerecht die passende Strategie für dein Testszenario wählen.
- Grenzwertanalyse und Äquivalenzklassen anwenden, um mit wenigen Tests maximale Abdeckung zu erreichen.
- Zustandsbasierte Tests erstellen und Zustandsübergänge in Systemen systematisch prüfen.
- Entscheidungstabellen nutzen, um komplexe Geschäftslogik vollständig zu testen.
- Pairwise-Testing einsetzen, um Kombinationsexplosionen bei mehreren Parametern zu vermeiden.
Überleitung
Bevor wir in die einzelnen Techniken einsteigen, klären wir erst die Grundlage:
Was unterscheidet Black-Box- von White-Box-Testing?
Diese zwei Ansätze bilden das Fundament aller Testverfahren – und die Wahl zwischen ihnen bestimmt, welche Techniken du anwenden kannst.
Black-Box-Testing: Testen ohne Codekenntnis
Black-Box-Testing (auch funktionsbasiertes Testing) betrachtet Software als “schwarze Box”. Du testest ausschliesslich das beobachtbare Verhalten, ohne den Quellcode zu kennen.
Vorgehensweise:
- Testfälle basieren auf Spezifikationen und Anforderungen
- Eingaben werden gewählt, Ausgaben mit erwarteten Ergebnissen verglichen
- Der interne Code bleibt unsichtbar
Typische Black-Box-Techniken:
- Äquivalenzklassenbildung
- Grenzwertanalyse
- Entscheidungstabellen
- Zustandsbasiertes Testen
Beispiel: Eine Login-Funktion wird mit gültigen und ungültigen Anmeldedaten getestet, ohne den Authentifizierungscode zu kennen.
Black-Box-Beispiel: Login-Funktion testen
Szenario
Du testest die Login-Funktion einer Webanwendung. Du kennst die Anforderungen (Benutzername min. 3 Zeichen, Passwort min. 8 Zeichen), aber nicht den Quellcode.
Testfälle basierend auf Spezifikation
| Test | Benutzername | Passwort | Erwartung |
|---|---|---|---|
| 1 | ”max" | "geheim123” | Login erfolgreich |
| 2 | ”ab" | "geheim123” | Fehler: Benutzername zu kurz |
| 3 | ”max" | "kurz” | Fehler: Passwort zu kurz |
| 4 | "" | "" | Fehler: Felder leer |
| 5 | ”max" | "falsch123” | Fehler: Falsches Passwort |
Wichtig: Du testest das beobachtbare Verhalten – ohne zu wissen, wie die Validierung intern implementiert ist. Das ist der Kern von Black-Box-Testing.
White-Box-Testing: Testen mit Codekenntnis
White-Box-Testing (auch strukturbasiertes Testing) analysiert die interne Logik und Struktur der Software. Du kennst den Quellcode und erstellst Tests, die spezifische Codepfade durchlaufen.
Coverage-Metriken im White-Box-Testing:
| Metrik | Beschreibung | Ziel |
|---|---|---|
| Statement Coverage | Jede Codezeile mindestens einmal ausführen | 100% |
| Branch Coverage | Jede Verzweigung (if/else) beide Wege testen | 100% |
| Path Coverage | Alle möglichen Pfade durch den Code testen | Oft unrealistisch |
| Condition Coverage | Jede Teilbedingung einzeln prüfen | Bei komplexen Bedingungen |
In der Praxis ist Branch Coverage die wichtigste Metrik. Sie stellt sicher, dass jede Entscheidung im Code mindestens einmal mit true und einmal mit false durchlaufen wird.
White-Box-Beispiel: Branch Coverage erreichen
Szenario
Du entwickelst eine Rabattfunktion für einen Online-Shop. Die Funktion soll unterschiedliche Rabatte basierend auf Alter und Kundenstatus vergeben. Um sicherzustellen, dass alle Verzweigungen korrekt funktionieren, erstellst du Tests für 100% Branch Coverage.
def berechne_rabatt(alter, ist_stammkunde):
if alter < 18:
rabatt = 0.10 # Jugendrabatt
elif ist_stammkunde:
rabatt = 0.15 # Stammkundenrabatt
else:
rabatt = 0.05 # Standardrabatt
return rabattTestfälle für 100% Branch Coverage
| Test | Eingabe | Erwartung | Getesteter Branch |
|---|---|---|---|
| 1 | alter=16 | 0.10 | if alter < 18 |
| 2 | alter=30, ist_stammkunde=True | 0.15 | elif ist_stammkunde |
| 3 | alter=30, ist_stammkunde=False | 0.05 | else |
Mit diesen drei Tests wird jeder Branch mindestens einmal durchlaufen.
Wann welche Strategie?
Die Wahl zwischen Black-Box und White-Box hängt von mehreren Faktoren ab:
| Kriterium | Black-Box | White-Box |
|---|---|---|
| Codezugang | Nicht erforderlich | Erforderlich |
| Testperspektive | Nutzersicht | Entwicklersicht |
| Typische Phase | Systemtest, Abnahme | Unit-Test, Integration |
| Expertise | Fachlich | Technisch |
Praxisempfehlung: Kombiniere beide Ansätze. Unit-Tests (White-Box) für Codequalität, Systemtests (Black-Box) für Funktionalität aus Nutzersicht. So erreichst du maximale Testabdeckung mit unterschiedlichen Perspektiven.
Grenzwertanalyse: Fehler an den Rändern finden
Grenzwertanalyse testet systematisch an den Grenzen gültiger Eingabebereiche. Erfahrungsgemäss treten hier die meisten Fehler auf – Entwickler machen oft sogenannte “Off-by-One”-Fehler.
Beispiel: Funktion akzeptiert Werte von 1 bis 10
| Testfall | Wert | Erwartung |
|---|---|---|
| Untere Grenze -1 | 0 | Ungültig |
| Untere Grenze | 1 | Gültig |
| Obere Grenze | 10 | Gültig |
| Obere Grenze +1 | 11 | Ungültig |
Warum genau diese Werte? Du testest dort, wo der Code zwischen “gültig” und “ungültig” unterscheiden muss. Ein >= statt > oder <= statt < fällt mit diesen Tests sofort auf.
Äquivalenzklassenbildung: Weniger Tests, gleiche Abdeckung
Äquivalenzklassen gruppieren Eingabewerte, die vom System gleich behandelt werden. Ein Test pro Klasse reicht, um das Verhalten für alle Werte dieser Klasse zu prüfen.
Beispiel: Ein Eingabefeld akzeptiert Zahlen von 1 bis 100.
| Klasse | Wertebereich | Repräsentant | Erwartung |
|---|---|---|---|
| Ungültig (zu klein) | < 1 | -5 | Fehlermeldung |
| Gültig | 1-100 | 50 | Akzeptiert |
| Ungültig (zu gross) | > 100 | 150 | Fehlermeldung |
Kombination mit Grenzwertanalyse: Nutze Äquivalenzklassen zur Strukturierung und teste zusätzlich die Grenzen (0, 1, 100, 101). So erhältst du mit 7 Tests eine vollständige Abdeckung.
Zustandsbasiertes Testen: Übergänge prüfen
Zustandsbasiertes Testen prüft, wie ein System zwischen verschiedenen Zuständen wechselt. Ideal für Anwendungen mit definierten Modi oder Workflows.
Beispiel: Benutzerauthentifizierung
stateDiagram-v2 [*] --> Anmeldung Anmeldung --> Authentifiziert: Erfolg Anmeldung --> Anmeldung: Fehlgeschlagen Authentifiziert --> Abgemeldet: Logout Abgemeldet --> [*]
Testfälle aus dem Diagramm:
- Erfolgreiche Anmeldung → Zustand “Authentifiziert”
- Fehlgeschlagene Anmeldung → Bleibt in “Anmeldung”
- Logout aus “Authentifiziert” → Zustand “Abgemeldet”
Jeder Pfeil im Diagramm wird zu mindestens einem Testfall.
Entscheidungstabellen: Alle Kombinationen systematisch
Entscheidungstabellen dokumentieren systematisch alle Kombinationen von Bedingungen und deren Aktionen. So stellst du sicher, dass keine Kombination vergessen wird.
Beispiel: Premium-Zugang
| Regel | R1 | R2 | R3 | R4 |
|---|---|---|---|---|
| Angemeldet? | N | J | J | N |
| Kontostand > 100€? | - | N | J | J |
| Aktion | Login zeigen | Standard | Premium | Login zeigen |
Legende: J=Ja, N=Nein, -=irrelevant
Testfälle: Jede Spalte (R1-R4) wird zu einem Testfall. Bei 2 Bedingungen mit je 2 Werten entstehen maximal 4 Testfälle, die alle Situationen abdecken.
Pairwise-Testing: Kombinationsexplosion vermeiden
Pairwise-Testing reduziert Testfälle drastisch, indem es nur Paarkombinationen statt aller Kombinationen testet. Die meisten Fehler entstehen durch Wechselwirkungen zwischen zwei Parametern.
Beispiel: Browser (Chrome, Firefox) × OS (Win, Mac) × Netzwerk (WLAN, LAN)
Vollständig: 2×2×2 = 8 Tests | Pairwise: nur 4 Tests
| Test | Browser | OS | Netzwerk |
|---|---|---|---|
| 1 | Chrome | Win | WLAN |
| 2 | Chrome | Mac | LAN |
| 3 | Firefox | Win | LAN |
| 4 | Firefox | Mac | WLAN |
Warum reicht das? Jede Paarkombination kommt vor: Chrome+Win (T1), Chrome+Mac (T2), Firefox+WLAN (T4), Mac+LAN (T2) usw. Alle 12 möglichen Paare sind abgedeckt.
Explorative Tests: Strukturiert erkunden
Explorative Tests kombinieren Testdesign und -ausführung in Echtzeit. Tester nutzen ihre Erfahrung, um Schwachstellen zu finden, die strukturierte Tests übersehen.
Session-Based Test Management (SBTM): Strukturiert explorative Tests in dokumentierte Sessions:
| Element | Beschreibung |
|---|---|
| Charter | Klares Ziel der Session (z.B. “Prüfe Fehlerbehandlung bei Timeout”) |
| Timebox | Feste Dauer (typisch 60-90 Min.) |
| Notizen | Alle Beobachtungen während der Session |
| Defects | Gefundene Fehler |
| Issues | Fragen und Unklarheiten |
Erfahrungsbasierte Techniken:
- Error Guessing: Wo würde ein Entwickler typischerweise Fehler machen?
- Checklistenbasiert: Bekannte Problemstellen systematisch prüfen
Zusammenfassung und Ausblick
Zusammenfassung
Teststrategien: Black-Box vs. White-Box
In dieser Lerneinheit hast du die zwei grundlegenden Teststrategien kennengelernt:
- Black-Box-Testing testet das Verhalten von aussen – ohne Codekenntnis
- White-Box-Testing analysiert die interne Struktur – mit Coverage-Metriken wie Branch Coverage
Konkrete Testtechniken
Du hast gelernt, wie du mit systematischen Techniken effiziente Testfälle erstellst:
- Grenzwertanalyse findet Fehler an den Rändern von Wertebereichen
- Äquivalenzklassen reduzieren die Testanzahl durch Gruppierung
- Zustandsbasiertes Testen prüft Workflows und Zustandsübergänge
- Entscheidungstabellen decken alle Bedingungskombinationen ab
- Pairwise-Testing verhindert Kombinationsexplosionen
- Explorative Tests ergänzen strukturierte Methoden durch Erfahrung
Ausblick
In der nächsten Lerneinheit geht es um Testplanung und -management: Wie organisierst du deine Tests, priorisierst Testfälle nach Risiko und dokumentierst Testergebnisse systematisch?