Testmethoden und -arten

Dieser Beitrag ist eine Begriffserklärung zu Testmethoden und ihrer Klassifikation – inklusive Prüfungsfragen und Tags.

In a Nutshell

Wer testet? – Mensch (manuell) vs. Maschine (automatisch), Entwickler vs. Benutzer.
Was wird getestet? – Unit (Komponente), Integration, System (E2E).
Wie wird getestet? – Bottom‑Up/Top‑Down, statisch/dynamisch, Blackbox/Whitebox, explorativ.
Wann wird getestet? – Vorher/Nachher, Abnahme.
Warum wird getestet? – Regression, Last/Performance, Smoke.

Kompakte Fachbeschreibung

Wer testet?

• Entwickler: Unit, Integration, Contract, statische Analyse, TDD
• QS/Tester: Systemtests, E2E, explorative Tests, Abnahme
• Maschine: Automatisierte Regression, Lasttests, CI‑Pipelines

Was wird getestet?

• Unit‑Test: isolierte Klasse/Funktion
• Integrationstest: Zusammenarbeit von Komponenten (DB, Netzwerk)
• System/E2E‑Test: vollständiger Nutzerfluss über UI & Infrastruktur

Wie wird getestet?

• Bottom‑Up: zuerst kleine Einheiten, dann Integration
• Top‑Down: zuerst Stubs, dann reale Komponenten
• Statisch: Code‑Analyse ohne Ausführung (Lint, Security Scan)
• Dynamisch: Code wird ausgeführt (Unit, Integration, E2E)
• Blackbox: nur über Schnittstellen, keine Kenntnis des Innenlebens
• Whitebox: Kenntnis der internen Struktur, Zweig‑/Pfadabdeckung
• Explorativ: erfahrungsbasiertes, unskriptiertes Testen

Wann & Warum

• Vorher (Entwicklungsphase): TDD, Unit, statische Analyse
• Nachher: Systemtests, Abnahme, Regression
• Regression: Sicherstellen, dass Änderungen nichts kaputt machen
• Last/Belastung: Verhalten unter Spitzenlast prüfen
• Smoke: schnelle Prüfung, ob Kernfunktionen nach Deployment funktionieren

Prüfungsrelevante Stichpunkte

• Testklassifikation (Wer, Was, Wie, Wann, Warum) sicher unterscheiden
• Unit vs. Integration vs. E2E klar abgrenzen
• Blackbox vs. Whitebox anwenden (Beispiele)
• Testdoubles: Stubs vs. Mocks
• Eigenschaften guter Unit‑Tests (korrekt, isoliert, schnell, aussagekräftig, wartbar)
• Testfallermittlung: Äquivalenzklassen, Grenzwertanalyse, Zweig-/Pfadüberdeckung
• Testprozess: Auswahl, Kriterien, Daten, Protokoll, Auswertung
• TDD: Rot‑Grün‑Refactor‑Zyklus
• Regression, Last, Smoke als typische Testarten

Kernkomponenten

1. Testklassifikation (Wer, Was, Wie, Wann, Warum)
2. Testebenen (Unit, Integration, System)
3. Testansätze (Bottom‑Up, Top‑Down, Blackbox, Whitebox)
4. Testdoubles (Stub, Mock, Fake, Spy)
5. Testfallermittlung (Äquivalenzklassen, Grenzwerte, Überdeckung)
6. Testautomatisierung (Frameworks, CI, Reporting)
7. Testdatenmanagement (Fixtures, Factories, Seed)
8. Testprozess (Planung, Durchführung, Auswertung, Protokoll)
9. Qualitätssicherung (Reviews, Audits, Metriken)
10. Werkzeuge (Testframeworks, Mock‑Libraries, CI/CD)

Praxisbeispiel (Bestellabwicklung)

Unit (Whitebox):
- Klasse: RabattService
- Methode: berechneRabatt(kunde, artikel)
- Testfall: Neukunde, Standardartikel → erwartet 0 %
- Überdeckung: alle Zweige (Kundentyp, Artikeltyp)

Integration (Blackbox):
- Komponenten: Service → Repository → DB
- Test: Speichern/Lesen einer Bestellung mit echtem DB‑Container
- Kriterium: Persistierte Daten = erwartete Daten

E2E (Top‑Down):
- Flow: Browser → Portal → API → DB → Message Broker
- Szenario: Bestellung aufgeben, Zahlung simulieren
- Erwartung: Bestätigung sichtbar, DB‑Eintrag, Event

Regression (automatisiert):
- Vorher: Bestellung mit 5 Artikeln, 10 % Rabatt → 110 €
- Nachher: Gleiches Szenario → muss 110 € bleiben

Lasttest:
- Lastprofil: 500 Nutzer gleichzeitig, 10 s
- Kriterium: 95‑Perzentil Antwortzeit <300 ms, keine Fehler

Smoke:
- Nach Deployment: Login, Artikel suchen, in den Warenkorb legen
- Kriterium: Alle 3 Aktionen erfolgreich

Vorteile und Nachteile

Vorteile

• Systematische Abdeckung von Risiken
• Frühe Fehlererkennung (Unit/TDD)
• Nachvollziehbare Qualität (Regressionstests)
• Geringere Ausfallkosten (Lasttests)

Nachteile

• Aufwand für Testpflege
• Flaky Tests bei unklaren Abhängigkeiten
• Fokus auf „Zahlen“ statt Nutzen ohne klare Ziele

Typische Prüfungsfragen (mit Kurzantwort)

1. Blackbox vs. Whitebox? Blackbox: nur über Schnittstellen; Whitebox: Kenntnis der internen Struktur.
2. Unit vs. Integration? Unit: isoliert; Integration: reale Zusammenarbeit von Komponenten.
3. Was ist TDD? Test‑Driven Development: Rot (Test scheitert) → Grün (Test besteht) → Refactor.
4. Eigenschaften guter Unit‑Tests? Korrekt, isoliert, schnell, aussagekräftig, wartbar, einfach ausführbar.
5. Testfallermittlungsmethoden? Äquivalenzklassen, Grenzwertanalyse, Zweig-/Pfadüberdeckung.

Wichtigste Quellen

1. https://martinfowler.com/articles/practical-test-pyramid.html
2. https://testing.googleblog.com
3. https://www.istqb.org