Teststufen & Testarten

Framework: 5 Attribute je Teststufe (CTFL Kap. 2.2.1) — Der Lehrplan unterscheidet Teststufen anhand von genau fünf Attributen, um Überschneidungen zu vermeiden: ① Testobjekt · ② Testziele · ③ Testbasis · ④ Fehlerzustände & Fehlerwirkungen · ⑤ Vorgehensweise & Verantwortlichkeiten. Diese fünf Attribute strukturieren auch die Karten unten — und sind prüfungsrelevant.

Stufenübergang: In sequenziellen SDLC-Modellen (z.B. V-Modell) sind die Endekriterien einer Teststufe typischerweise Teil der Eingangskriterien der nächsten Stufe — Teststufen sind also nicht unabhängig, sondern verkettet.

Stufe 1 · CT Komponententest Component / Unit Testing

Testobjekte

Komponenten Module Klassen DB-Module

Testbasis

Detaildesign Code Datenmodell Komponentenspez.

Typische Fehlerzustände

Falsche Logik Datenflussfehler Falsche Berechnung Fehlende Abzweigung

Verantwortlich

Entwickler

Besonderheiten

Isolation (Stubs/Treiber) TDD möglich Hohe Automatisierung

Stufe 2 · CIT Komponentenintegrationstest Component Integration Testing

Testobjekte

Schnittstellen APIs Datenbank-APIs Subsysteme

Testbasis

Use Cases Softwaredesign Schnittstellenspez. Workflows

Typische Fehlerzustände

Schnittstellenfehler Falsche Datenübergabe Falsche Sequenz Unbehandelte Fehler

Verantwortlich

Entwickler Tester

Integrationsstrategien

Bottom-up Top-down Big Bang

Stufe 3 · ST Systemtest System Testing

Testobjekte

Gesamtsystem End-to-End-Aufgaben System-Konfiguration

Testbasis

Systemanforderungen Use Cases Sequenzdiagramme Risikoanalyse

Typische Fehlerzustände

Falsche End-to-End-Abläufe Performanzprobleme Sicherheitslücken Falsche Systemkonfig.

Verantwortlich

Unabh. Tester Testteam

Besonderheiten

Produktionsähnl. Umgebung Funktional + nicht-funk.

Stufe 4 · SIT Systemintegrationstest System Integration Testing

Testobjekte

Externe Systeme Microservices APIs (extern) Drittanbieter

Testbasis

Systemdesign Systemarchitektur Kommunikationsprotokolle

Typische Fehlerzustände

Inkonsistente Nachrichten Kommunikationsfehler Falsche Datenannahmen Sicherheitsprobleme

Verantwortlich

Tester Systemarchitekten

Besonderheiten

Nach Systemtest Vor Abnahmetest

Stufe 5 · UAT Abnahmetest Acceptance Testing

Testobjekte

Gesamtsystem Geschäftsprozesse Betriebsbereitschaft

Testbasis

Geschäftsanforderungen Akzeptanzkriterien Regulatorische Anforderungen Verträge / SLAs

Typische Fehlerzustände

Anforderungen nicht erfüllt Geschäftsprozess fehlerhaft Usability-Probleme

Verantwortlich

Auftraggeber Endnutzer Product Owner

Entscheidung

Go / No-Go Deployment-Freigabe

⚡ Zusammenhang: Reihenfolge CIT ↔ SIT — Der Systemintegrationstest (Stufe 4) findet nach dem Systemtest (Stufe 3) statt, nicht davor. Die logische Reihenfolge ist: CT → CIT → ST → SIT → Abnahmetest. Viele verwechseln das, weil beide „Integrationstests" heißen — aber CIT testet Schnittstellen zwischen Komponenten, SIT testet Schnittstellen zwischen Systemen.

Bottom-up

Integration beginnt bei den untersten Komponenten (Blätter im Baum) und arbeitet sich nach oben. Treiber simulieren übergeordnete Komponenten.

Echte Komponenten werden früh getestet

Kein Stubs für untergeordnete Komponenten

Gesamtsystem erst spät sichtbar

Top-down

Integration beginnt bei der obersten Komponente und arbeitet sich nach unten. Stubs ersetzen noch nicht verfügbare untergeordnete Komponenten.

Gesamtarchitektur früh validierbar

Frühe Demo möglich

Viele Stubs nötig — Aufwand

Big Bang

Alle Komponenten werden gleichzeitig integriert und das Gesamtsystem auf einmal getestet. Kein schrittweises Vorgehen.

Einfach zu planen

Fehlerlokalisierung sehr schwierig

Risiko: Viele Fehler auf einmal

UAT — User Acceptance Testing

Endnutzer prüfen ob das System ihre tägliche Arbeit unterstützt. Fokus: Geschäftsprozesse, Bedienbarkeit.

OAT — Operational Acceptance Testing

IT-Betrieb prüft Betriebsbereitschaft: Backup, Recovery, Wartung, Sicherheitspatches, Performanz unter Last.

Vertraglicher Abnahmetest

Prüfung gegen vertraglich vereinbarte Akzeptanzkriterien — z.B. Lieferantenvertrag, SLA.

Regulatorischer Abnahmetest

Prüfung gegen gesetzliche Anforderungen, Normen, Compliance. Z.B. DSGVO, Medizinprodukte-Richtlinie.

Alpha-Test

Im Unternehmen, durch ausgewählte (interne) Nutzer oder Kunden — kontrollierte Umgebung des Herstellers.

Beta-Test

Beim Kunden, in seiner eigenen Umgebung — unkontrolliert, echte Nutzungsbedingungen. Folgt typischerweise dem Alpha-Test.

Matrix: Alle Testarten sind auf jeder Teststufe anwendbar

Teststufe ↓ / Testart →	Funktionaler Test	Nicht-funk. Test	Black-Box-Test	White-Box-Test
● Komponententest	✓Logik, Berechnung	◑Performance (Shift-Left)	◑API-Spezifikation	✓Code-Überdeckung
● Komp.-Integrationstest	✓Schnittstellenfunktion	◑Zuverlässigkeit	✓Schnittstellenspez.	◑Integrationsstruktur
● Systemtest	✓End-to-End-Szenarien	✓Last, Sicherheit, Usability	✓Anforderungsbasiert	◑Selten auf Systemebene
● Syst.-Integrationstest	✓Kommunikation, Protokolle	✓Sicherheit, Datenschutz	✓Schnittstellenverhalten	◑Systemarchitektur
● Abnahmetest	✓Geschäftsprozesse	✓Usability, Compliance	✓Nutzeranforderungen	◑Sehr selten

⚠ Häufige Prüfungsfalle: Teststufe ≠ Testart — sie sind orthogonale Konzepte. Teststufe = wo im SDLC getestet wird. Testart = was getestet wird. Ein funktionaler Test (Testart) kann auf jeder Teststufe durchgeführt werden. ✓ = Schwerpunkt auf dieser Stufe · ◑ = möglich, aber seltener

Testart 1 · Funktional Funktionaler Test Functional Testing

Bewertet Funktionen — das „Was tut es?". Prüft ob Anforderungen und Use Cases korrekt umgesetzt sind.

Testbasis: Anforderungen, funktionale Spezifikationen, Use Cases. Kann auf allen Teststufen angewandt werden.

Testart 2 · Nicht-funktional Nicht-funktionaler Test Non-Functional Testing

Bewertet Qualitätsmerkmale — das „Wie gut tut es es?". ISO/IEC 25010 definiert: Performanz · Kompatibilität · Gebrauchstauglichkeit · Zuverlässigkeit · Sicherheit · Wartbarkeit · Übertragbarkeit · Safety.

Zusammenhang: Viele nicht-funktionale Tests leiten sich direkt von funktionalen Tests ab — da für nfunk. Tests dieselben funktionalen Testfälle verwendet werden können, ergänzt um nfunk. Messgrößen (z.B. Antwortzeit, Fehlerrate). Shift-Left: Nicht-funktionale Tests sollten so früh wie möglich beginnen — auch auf Komponentenebene.

Testart 3 · Strukturbasiert White-Box-Test White-Box Testing

Leitet Tests aus der internen Struktur ab — Code, Architektur, Ablaufpläne. Typisch: Anweisungsüberdeckung (SC), Zweigüberdeckung (BC).

Schwerpunkt: Komponenten- und Integrationsstufe. Nicht zu verwechseln mit: White-Box-Testverfahren (Kap. 4.3).

Testart 4 · Spezifikationsbasiert Black-Box-Test Black-Box Testing

Leitet Tests aus der Spezifikation ab — ohne Kenntnis der internen Struktur. Typisch: EP, BVA, Entscheidungstabellen.

Schwerpunkt: System- und Abnahmestufe. Gilt für funktionale UND nicht-funktionale Tests.

CT · Confirmation Testing

Fehlernachtest

Confirmation Testing (Re-Test)

Frage Ist der behobene Fehlerzustand wirklich weg?

Auslöser Ein spezifischer Fehlerzustand wurde gemeldet und behoben.

Umfang Gezielt — nur die Testfälle die vorher fehlschlugen, plus ggf. neue Tests für die Änderung.

Je nach Risiko Vollständige Wiederholung aller fehlgeschlagenen Tests oder — bei Zeit-/Geldmangel — nur die Testschritte, die die konkrete Fehlerwirkung reproduziert haben.

Automatisierung Selektiv — oft manuell oder kleiner automatisierter Subset.

RT · Regression Testing

Regressionstest

Regression Testing

Frage Hat die Änderung etwas anderes (vorher Funktionierendes) kaputt gemacht?

Auslöser Jede Änderung am System — Fehlerbehebung, neues Feature, Refactoring.

Umfang Breit — Regressionstestsuiten wachsen mit jeder Iteration. Entscheidung: vollständig vs. risikobasiert ausgewählt.

Automatisierung Sehr gut geeignet — da Suiten viele Male wiederholt werden. Empfehlung: CI/CD-Pipeline.

⚠ Häufige Verwechslung: Fehlernachtest = „Ist der Bug weg?" · Regressionstest = „Hat die Fehlerbehebung einen anderen Bug erzeugt?" — Beide können und sollen auf allen Teststufen angewendet werden, wann immer Fehlerzustände behoben oder Änderungen vorgenommen wurden.

Was ist Wartungstest?

Wartungstest wird durchgeführt, wenn ein bestehendes System geändert, migriert oder außer Betrieb genommen wird — also nach der initialen Auslieferung, im laufenden Betrieb.

Der Umfang hängt ab von:

Grad des Risikos der Änderung
Größe des bestehenden Systems
Umfang der Änderung selbst

Wichtig: Wartungstest ≠ eigene Teststufe. Er kann auf jeder Teststufe stattfinden und umfasst typischerweise sowohl Fehlernachtests als auch ausgedehnte Regressionstests — da Änderungen am bestehenden System unbeabsichtigte Seiteneffekte auslösen können.

Auslöser für Wartungstest (CTFL Kap. 2.3)

① Änderungen

Geplante Erweiterungen (releasebasiert) Korrigierende Änderungen Hotfixes

② Umgebungsmigration

Plattformwechsel (OS, DB, Infrastruktur) Datenkonvertierung / -migration Tests der neuen Umgebung

③ Außerbetriebnahme

End-of-Life einer Anwendung Tests der Datenarchivierung Langfristige Aufbewahrungspflichten

⚠ Prüfungsrelevanz FL-2.3.1 (K2): Der Lernziel-Level ist K2 (verstehen/erklären) — du sollst Wartungstest und seine Auslöser zusammenfassen können. Die drei Auslöserkategorien (Änderungen · Umgebungsmigration · Außerbetriebnahme) sind prüfungsrelevant. Der Zusammenhang mit Regressionstest ist zentral: jede Wartungsänderung erfordert typischerweise einen Regressionstest des betroffenen Systems.

V-Modell — Teststufen & Entwicklungsphasen

Testpyramide — Testvolumen & Automatisierungsgrad

⚡ Zusammenhang: Testpyramide & Shift-Left: Die Pyramide zeigt: Je früher (weiter unten) ein Fehler gefunden wird, desto günstiger ist die Behebung. Shift-Left bedeutet, möglichst viele Tests auf die niedrigste sinnvolle Teststufe zu verschieben. Ein Bug der im Komponententest gefunden wird kostet typischerweise 10–100× weniger als derselbe Bug im Abnahmetest.

① Fünf Teststufen — CTFL Kap. 2.2.1

② Integrationsstrategien · CTFL Kap. 2.2.1 (Komponentenintegrationstest)

③ Abnahmetest — Unterarten · CTFL Kap. 2.2.1

④ Teststufe ≠ Testart — orthogonale Konzepte · CTFL Kap. 2.2.2

⑤ Vier Testarten im Detail · CTFL Kap. 2.2.2

⑥ Fehlernachtest vs. Regressionstest · CTFL Kap. 2.2.3

⑦ Wartungstest · CTFL Kap. 2.3 · FL-2.3.1 (K2)

⑧ Visuelle Zusammenhänge — V-Modell & Testpyramide