Teststufen: Unit, Integration, System, Abnahme

In L1 hast du das V-Modell kennengelernt – die Idee, dass jeder Entwicklungsphase eine Test-Phase entspricht. In dieser Lektion vertiefen wir die rechte Seite des V: die vier Teststufen, ihre Reihenfolge, ihre Zuständigkeiten und die Frage, wer wann was testet.

Die vier klassischen Stufen: Unit-Test (einzelne Bausteine), Integrationstest (Zusammenspiel der Bausteine), Systemtest (das ganze System), Abnahmetest (durch den Kunden). Jede Stufe hat eigene Ziele, eigene Akteure und eigene Werkzeuge – wer die Unterscheidung sicher hat, kann jede IHK-Frage zum Thema beantworten.

1) Die Test-Pyramide – warum nicht jeder Test gleich viel kostet

Bevor wir auf die einzelnen Stufen schauen: ein zentrales Bild der modernen Test-Welt ist die Test-Pyramide. Sie ordnet die Stufen nach Anzahl und Kosten. Unten viele billige Tests, oben wenige teure:

Die Test-Pyramide

Die Pyramide ist nicht zufällig so: Unit-Tests laufen in Millisekunden und können tausendfach automatisiert sein. Ein E2E-Test (End-to-End, klickt durch echte UI) dauert Sekunden bis Minuten und ist anfällig für Flakiness. Die Faustregel: für jede UI-Schicht-Test gehören mindestens 10× so viele Unit-Tests darunter. Wer eine umgekehrte Pyramide hat (viele E2E, wenig Unit), nennt das „Ice-Cream-Cone" – ein bekanntes Anti-Pattern.

2) Die vier Stufen im Detail

Klick durch die Stufen und sieh, was jede ausmacht. Achte besonders auf Wer testet, Was wird geprüft, Welche Tools:

Die vier Teststufen

Unit-Test (Komponententest)

Wer: Entwickler

Was: einzelne Methode / Klasse

Tools: JUnit, pytest, Jest

Stil: White-Box

Die kleinste Testeinheit. Geprüft wird eine Methode oder Klasse isoliert, ohne Datenbank, ohne Netzwerk. Externe Abhängigkeiten werden durch Mocks ersetzt. Schnell (Millisekunden), trivial automatisierbar. Genau das Werkzeug für TDD. Vertieft in L6.

Beachte: die Stufen bauen aufeinander auf. Bevor du integrierst, müssen die Einzelteile sicher sein. Bevor du das System testest, muss die Integration funktionieren. Wenn du auf Systemtest-Ebene einen Bug findest, der eigentlich ein Unit-Bug ist, hat dein Unit-Test-Setup eine Lücke – das Problem hätte 10× billiger gefunden werden müssen.

3) Integration-Test – die Strategien

Beim Integrationstest geht es um das Zusammenspiel mehrerer Komponenten. Aber in welcher Reihenfolge soll man integrieren? Es gibt klassische Strategien, die in IHK-Klausuren auftauchen:

Integration-Strategien

Big-Bang

Alle Komponenten gleichzeitig zusammenbauen und testen. Schnell aufgesetzt, aber bei Fehlern schwer zu lokalisieren. Heute selten empfohlen.

Top-Down

Von der obersten Schicht (UI) abwärts integrieren. Untere Komponenten werden durch Stubs ersetzt, bis sie fertig sind. Vorteil: System-Logik früh testbar.

Bottom-Up

Von der untersten Schicht (DB-Layer) aufwärts. Obere Komponenten durch Treiber ersetzt. Vorteil: Basis-Module gründlich geprüft.

Sandwich / Hybrid

Kombination: Top-Down + Bottom-Up gleichzeitig, treffen sich in der Mitte. Häufigste Praxis-Strategie.

Die Begriffe Stub und Treiber (Driver) kommen in Klausuren gerne dran. Stub: Platzhalter für eine noch nicht fertige Komponente unter der zu testenden (gibt einfache Standard-Antworten zurück). Treiber: simuliert die Komponente über der zu testenden (ruft sie auf). Beide sind Test-Doubles – das Thema von L7.

4) System-Test vs. Abnahme-Test – die feine Linie

Beide testen das komplette System. Der Unterschied liegt im Fokus und in der Perspektive:

Systemtest: intern, von Test-Engineers. Geprüft wird gegen die Spezifikation – tut das System, was das Pflichtenheft sagt? Auch nicht-funktionale Anforderungen wie Performance, Sicherheit, Last. Verifikation.
Abnahmetest: durch den Kunden / Auftraggeber. Geprüft wird gegen die Erwartungen – tut das System, was wir wirklich brauchen? Auch wenn die Spezifikation lückenhaft war. Validierung.

Eselsbrücke: Systemtest = baut das System richtig. Abnahmetest = baut das richtige System. In agilen Teams verschmelzen die beiden manchmal, weil der Product Owner direkt während des Sprints abnimmt. Im V-Modell sind sie klar getrennt.

5) Spezial-Test-Arten

Innerhalb der Stufen (vor allem auf Systemebene) gibt es viele spezialisierte Test-Arten. Sie zielen auf nicht-funktionale Eigenschaften (vgl. K50 L1 FURPS+):

Spezial-Tests auf Systemebene

Lasttest

Wie verhält sich das System bei typischer Last? Tools: JMeter, k6.

Stresstest

Was passiert bei übermäßiger Last? Wo bricht es? Bricht es kontrolliert?

Performance-Test

Antwortzeit, Durchsatz – passt zu den SLAs? Vgl. K51 L8.

Security-Test

SQL-Injection, XSS, Auth-Lücken. Penetrationstests. Vgl. K11.

Usability-Test

Echte Nutzer beobachten – wo verlieren sie sich, was finden sie nicht?

Regression-Test

Funktionieren alte Features nach Änderung noch? Voll automatisiert in CI/CD.

Smoke-Test

Schnelltest „läuft das System überhaupt?". Vor jedem Release-Kandidat.

Rauchtest / Sanity

Quick-Check nach einem Bugfix: noch alles plausibel?

Der wichtigste in der Praxis: Regression-Test. Bei jeder Codeänderung wird sichergestellt, dass nichts kaputt geht, was vorher funktionierte. Genau das ist der Sinn einer großen automatisierten Test-Suite – sie ist das Sicherheitsnetz für die nächste Änderung.

6) Alpha- und Beta-Tests – die User-Tests

Eine Spezialform des Abnahmetests, die in IHK-Aufgaben gelegentlich auftaucht:

Alpha-Test: findet beim Hersteller statt, mit ausgewählten Endnutzern unter kontrollierten Bedingungen. „Wir laden 10 Power-User in unser Büro ein, sie probieren die neue Version aus."
Beta-Test: findet beim Kunden statt, in dessen echter Umgebung. Bekannt aus der Spiele-Welt: „Beta-Version öffentlich verfügbar, gebt Feedback". Größerer Nutzerkreis, weniger Kontrolle, dafür realistisches Feedback.

Reihenfolge: Alpha vor Beta. Alpha findet die offensichtlichen Probleme, Beta die feineren in echten Szenarien.

7) Wer testet wann?

Eine Übersicht für die Klausur – wer ist auf welcher Stufe aktiv:

Unit-Test: Entwickler*innen selbst, parallel zum Code-Schreiben.
Integrationstest: Entwickler*innen oder Test-Engineers, oft im CI-System automatisiert.
Systemtest: dedizierte Test-Engineers / QA-Abteilung, getrennt vom Entwicklungsteam.
Abnahmetest: Auftraggeber / Product Owner / Fachabteilung. Niemals von den Entwicklern selbst.

Das letzte Prinzip ist wichtig: man testet nicht den eigenen Code als Abnahme. Wer Code geschrieben hat, sieht ihn durch dieselbe Brille wie beim Schreiben – Lücken werden übersehen. Externe Sicht ist Pflicht.

8) Praxis-Beispiel: Online-Shop

Eine kurze Anwendung der Stufen auf einen Online-Shop:

Unit-Test: Methode calculateDiscount(price, code) liefert für 100 € und Code „SOMMER10" das Ergebnis 90 €.
Integrationstest: Bestell-Service ruft Discount-Service korrekt auf, Antwort kommt zurück, Bestellung wird mit Rabatt gespeichert.
Systemtest: kompletter Bestellvorgang inkl. Frontend → Backend → DB. Klick durch echte UI. Inklusive Performance-Tests (100 Bestellungen/Min).
Abnahmetest: Geschäftsführer probiert die neue Rabatt-Funktion, prüft ob sie wirklich seinen Wünschen entspricht. Gibt grünes Licht für Release.

9) Klausur-Highlights

Vier Stufen: Unit, Integration, System, Abnahme – in dieser Reihenfolge.
Integration-Strategien: Top-Down (mit Stubs), Bottom-Up (mit Treibern), Big-Bang, Sandwich.
Stub vs. Treiber: Stub ersetzt aufgerufene Komponente, Treiber die aufrufende.
System- vs. Abnahmetest: Verifikation vs. Validierung. Intern vs. Kunde.
Alpha vs. Beta: beim Hersteller vs. beim Kunden.
Test-Pyramide: viele Unit-Tests, wenige E2E-Tests. Umgekehrt = Anti-Pattern.

Zusammenfassung

Vier Teststufen: Unit (einzelne Methode, durch Entwickler), Integration (Zusammenspiel), System (komplettes System, Verifikation gegen Spec), Abnahme (durch Kunde, Validierung). Test-Pyramide: viele Unit-Tests unten, wenige E2E oben – umgekehrt ist Anti-Pattern. Integration-Strategien: Top-Down (mit Stubs), Bottom-Up (mit Treibern), Big-Bang, Sandwich. Spezial-Tests: Last, Stress, Security, Regression, Smoke. Alpha beim Hersteller, Beta beim Kunden. Nächste: Black-Box-Test.