·
8 min
Systemtest: Was er prüft und wie er sich von anderen Teststufen abgrenzt
Roman Kirchmeier - Autemos
Ein Systemtest (system testing) prüft das komplette System gegen seine Anforderungsspezifikation, funktional wie nicht-funktional. Der deutschsprachige ISTQB-Lehrplan 4.0.2 führt ihn als eine von fünf Teststufen, zwischen Komponentenintegrationstest und Systemintegrationstest (ISTQB-Lehrplan CTFL 4.0.2, 2025). Viele deutsche Seiten zeigen noch vier Stufen, den Stand vor Version 4.0.
Innerhalb des funktionalen Testens ist das die Stufe, auf der fachliche Abläufe am fertigen Produkt laufen. Banken und Versicherungen beschäftigen dabei zwei praktische Fragen. Welche Testdaten dürfen in der Testumgebung liegen? Und was lässt sich automatisieren? Für die Daten gelten die Delegierte Verordnung (EU) 2024/1774 unter DORA und, für Schweizer Banken, das FINMA-Rundschreiben 2023/1.
Kurz gefasst: Der Systemtest ist laut ISTQB-Lehrplan 4.0.2 eine von fünf Teststufen. Er prüft das Gesamtverhalten eines kompletten Systems gegen die Systemspezifikation, funktional und nicht-funktional. Banken trennen die Testumgebung von der Produktion, und unter DORA liegen dort nur anonymisierte, pseudonymisierte oder randomisierte Produktionsdaten. Funktionale Abläufe und Regressionstests lassen sich gut automatisieren, Last- und Sicherheitstests brauchen eigene Werkzeuge.
Abbildung 1: Die fünf Teststufen nach ISTQB-Lehrplan 4.0.2
Was ist ein Systemtest?
Ein Systemtest ist eine Teststufe, die das Gesamtverhalten eines kompletten Systems oder Produkts gegen seine Anforderungsspezifikation prüft. Laut Lehrplan konzentriert er sich „auf das Gesamtverhalten und die Leistungsfähigkeiten eines gesamten Systems oder Produkts“ (ISTQB-Lehrplan CTFL 4.0.2, 2025).
Er umfasst häufig „funktionale Tests von End-to-End-Aufgaben und nicht-funktionale Tests von Qualitätsmerkmalen“. Ein Beispiel aus dem Onlinebanking: Eine Kundin eröffnet im Browser ein Konto, schließt die Identifikation ab und sieht das Konto danach in der Mobile-App. Geprüft wird dieser Ablauf am kompletten System, mit Oberfläche, Backend und Datenbank.
Die Testbasis sind die Anforderungsspezifikationen für das System. Im V-Modell steht diese Teststufe der Systemspezifikation gegenüber.
Welche fünf Teststufen beschreibt der ISTQB-Lehrplan?
Der ISTQB-Lehrplan 4.0.2 beschreibt fünf Teststufen, jede mit eigenem Testobjekt und Prüfziel:
Komponententest (auch Unittest): testet isolierte Komponenten.
Komponentenintegrationstest: testet Schnittstellen und Interaktionen zwischen Komponenten.
Systemtest: testet das Gesamtverhalten des kompletten Systems.
Systemintegrationstest: testet die Schnittstellen zu anderen Systemen und externen Diensten.
Abnahmetest: liefert den „Nachweis der Einsatzfähigkeit“ gegenüber den Geschäftsanforderungen.
Der Systemintegrationstest ist seit CTFL 4.0 eine eigene Stufe. Wer mit vier Stufen arbeitet, fasst unter dem Wort Integrationstest zwei verschiedene Prüfziele zusammen.
Wie unterscheidet sich der Systemtest von Integrationstest und E2E-Test?
Der Systemtest prüft das komplette System gegen seine Spezifikation, der Komponentenintegrationstest das Zusammenspiel von Komponenten und der Systemintegrationstest die Schnittstellen zu anderen Systemen. Ein E2E-Test beschreibt den Umfang eines Szenarios und ist keine eigene Teststufe.
Abbildung 2: Systemtest, Komponenten-Integrationstest und E2E-Szenario im Vergleich
Begriff | Was geprüft wird (nach ISTQB) | Beispiel Kontoeröffnung |
|---|---|---|
Komponentenintegrationstest | Schnittstellen und Interaktionen zwischen Komponenten | Der Kontoservice ruft die Adressprüfung mit den richtigen Parametern auf |
Systemtest | Gesamtverhalten des kompletten Systems gegen die Systemspezifikation | Kontoeröffnung im Browser bis zur Anzeige in der App |
Systemintegrationstest | Schnittstellen zu anderen Systemen und externen Diensten | Datenaustausch mit dem Identifikationsdienst und dem Kernbankensystem |
E2E-Szenario | Keine Teststufe: ein kompletter fachlicher Ablauf, der auf mehreren Stufen laufen kann | Registrierung bis zur ersten Überweisung in einem Durchgang |
Abnahmetest | Nachweis der Einsatzfähigkeit, idealerweise durch die vorgesehenen Benutzer | Der Fachbereich prüft die Kontoeröffnung gegen seine Geschäftsanforderungen |
IBM Think nennt diese Teststufe „performance-based, end-to-end software testing“ und ordnet sie dem Black-Box-Test zu (IBM Think, abgerufen 2026). Die englische Wikipedia setzt sie mit E2E-Tests gleich (Wikipedia, abgerufen 2026). Nach ISTQB gehören funktionale und nicht-funktionale Tests dazu, und Performanz ist eines von acht Qualitätsmerkmalen.
DORA führt „end-to-end testing“ in Art. 25 Abs. 1 der englischen Fassung als eigenen Testtyp neben „performance testing“ (Verordnung (EU) 2022/2554, 2022). Mehr zu den Nachbarthemen: der Integrationstest mit seinen Varianten, E2E-Tests über komplette Geschäftsprozesse und die Formen des Abnahmetests.
Was prüft ein Systemtest?
Ein Systemtest prüft, was das System tun soll (funktionaler Test), und wie gut es sich dabei verhält (nicht-funktionaler Test). Das Hauptziel funktionaler Tests ist laut Lehrplan „die Überprüfung der funktionalen Vollständigkeit, der funktionalen Korrektheit und der funktionalen Angemessenheit“ (ISTQB-Lehrplan CTFL 4.0.2, 2025).
Für die nicht-funktionale Seite nennt der Lehrplan acht Merkmale nach ISO/IEC 25010: Performanz, Kompatibilität, Gebrauchstauglichkeit (Interaktionsfähigkeit), Zuverlässigkeit, Security, Wartbarkeit, Übertragbarkeit (Flexibilität) und Safety. Safety ist neu in der Liste. Gebrauchstauglichkeit testet man laut ISTQB am besten am kompletten System in einer repräsentativen Testumgebung (ISTQB CTFL v4.0.1, 2024).
Black-Box-Testverfahren liegen nahe, weil die Testbasis eine Spezifikation ist. Laut CTFL lassen sich alle vier Testarten (funktional, nicht-funktional, Black-Box, White-Box) auf allen Teststufen anwenden. Die Verfahren im Detail zeigt der Beitrag zum Black-Box-Test mit Äquivalenzklassen und Grenzwerten.
Welche Testumgebung und welche Testdaten braucht ein Systemtest?
Ein Systemtest braucht eine von der Produktion getrennte, repräsentative Testumgebung und Testdaten ohne ungeschützte Produktionsdaten. Für Schweizer Banken schreibt das FINMA-Rundschreiben 2023/1 vor: „Es ist eine Trennung zwischen den Umgebungen für die Entwicklung oder das Testen und der Umgebung für die IKT-Produktion sicherzustellen.“ (FINMA-RS 2023/1, 2022)
Das Rundschreiben gilt seit dem 1. Januar 2024. Kritische Daten sind vor dem Zugriff Unberechtigter zu schützen, mit dem Zusatz: „Dies gilt auch für kritische Daten in Testumgebungen.“ Für Teilsysteme lässt der ISTQB-Lehrplan Simulationen zu.
Für Finanzunternehmen in der EU gilt DORA seit dem 17. Januar 2025. Die Delegierte Verordnung (EU) 2024/1774 legt in Art. 16 Abs. 5 lit. a fest, dass Nicht-Produktionsumgebungen nur anonymisierte, pseudonymisierte oder randomisierte Produktionsdaten speichern (Delegierte Verordnung (EU) 2024/1774, 2024). Ausnahmen nach Abs. 6 gelten nur für bestimmte Testanlässe, befristet, nach Genehmigung und mit Meldung an die IKT-Risikomanagementfunktion.
Schweizer Banken erreicht DORA nur über EU-Tochtergesellschaften oder EU-Geschäft. Autemos trennt die Testdaten-Konfiguration pro Umgebung, anonymisiert die Daten aber nicht selbst. Das muss vorher geschehen.
Wer führt den Systemtest durch?
Der Systemtest „kann von einem unabhängigen Testteam durchgeführt werden“, so der ISTQB-Lehrplan 4.0.2; eine Pflicht formuliert er nicht. Der CTFL-Lehrplan kennt mehrere Grade der Unabhängigkeit (ISTQB CTFL v4.0.1, 2024):
Die Autorin oder der Autor testet selbst.
Kolleginnen und Kollegen aus demselben Team testen.
Testende außerhalb des Teams testen.
Testende außerhalb der Organisation testen.
Unabhängige Testende erkennen laut Lehrplan andere Arten von Fehlerwirkungen. Als Nachteile nennt er die Isolation vom Entwicklungsteam und die Gefahr, als Engpass zu gelten.
DORA Art. 24 Abs. 4 verlangt, dass Tests im Programm für digitale operationale Resilienz von unabhängigen Parteien durchgeführt werden, intern oder extern. Die Delegierte Verordnung 2024/1774 fordert in Art. 17 Abs. 1 lit. b, dass genehmigende Funktionen unabhängig von denen sind, die Änderungen beantragen und umsetzen. Beide Stellen nennen diese Teststufe nicht beim Namen. Wer die Ergebnisse als Nachweis nutzt, sollte festhalten, wer getestet und wer freigegeben hat.
Welche Eingangs- und Endekriterien gelten?
Eingangskriterien legen fest, wann eine Teststufe beginnen darf, und Endekriterien, wann sie abgeschlossen ist. Der Lehrplan schreibt: „Eingangskriterien und Endekriterien sollten für jede Teststufe definiert werden und unterscheiden sich je nach den Testzielen.“ (ISTQB-Lehrplan CTFL 4.0.2, 2025)
Abbildung 3: Typische Eingangs- und Endekriterien nach ISTQB, Abschnitt 5.1.3
Typische Eingangskriterien nach Abschnitt 5.1.3:
Ressourcen sind verfügbar: Menschen, Werkzeuge, Umgebungen, Testdaten, Budget und Zeit.
Testmittel sind verfügbar: Testbasis, testbare Anforderungen, User-Storys und Testfälle.
Die anfängliche Qualität stimmt, zum Beispiel: „alle Smoke-Tests wurden bestanden“.
Typische Endekriterien:
Messungen der Gründlichkeit: Überdeckungsgrad, ungelöste Fehlerzustände, Fehlerdichte, fehlgeschlagene Testfälle.
Binäre Ja/Nein-Kriterien, zum Beispiel „alle Regressionstests sind automatisiert“.
Aufgebrauchte Zeit oder ausgeschöpftes Budget, sofern die Stakeholder das Restrisiko akzeptieren.
Für eine Bank heißt das: Umgebung getrennt, Testdaten freigegeben, Smoke-Tests auf dem neuen Build bestanden. Halten Sie diese Kriterien im Testplan für das Release fest, damit Entwicklung, Test und Fachbereich dieselben Bedingungen prüfen.
Wie lassen sich Systemtests automatisieren?
Funktionale Tests mit wiederholbaren Abläufen und klar erwarteten Ergebnissen lassen sich gut automatisieren; Gebrauchstauglichkeit und explorative Tests bleiben überwiegend manuell. Der CTFL-Lehrplan nennt als Nutzen weniger repetitive Arbeit, Konsistenz und schnellere Rückmeldung, als Risiken unrealistische Erwartungen und unterschätzten Wartungsaufwand (ISTQB CTFL v4.0.1, 2024).
Abbildung 4: Was sich im Systemtest automatisieren lässt und was nicht
Autemos, die KI-gestützte Testautomatisierung der selementrix GmbH aus Baar, automatisiert funktionale Tests über Web, Mobile, API und Desktop.
Prüfgegenstand | Umsetzung | Hinweis |
|---|---|---|
Fachliche Abläufe über Web, Mobile, API und Desktop | Automatisieren, etwa mit Autemos | Ein Test kann mehrere Browser, Geräte, API-Aufrufe und Benutzersitzungen umfassen |
Regressionstests | Automatisieren | ISTQB nennt sie einen starken Kandidaten für Automatisierung |
Datenvarianten (Beträge, Kundentypen, Limits) | Automatisieren, datengetrieben | Einmal verwendbare Daten werden markiert, damit parallele Läufe sie nicht doppelt nutzen |
Gebrauchstauglichkeit | Überwiegend manuell | IBM beschreibt Usability-Tests als weitgehend manuellen Prozess |
Explorative Tests | Manuell | Hängt am Urteil der Testenden |
Last- und Performanztests | Andere Werkzeuge | Autemos hat keine Last- oder Performanztests |
Security- und Penetrationstests | Andere Werkzeuge | Autemos führt keine Sicherheitstests durch |
Codeüberdeckung (White-Box) | Andere Werkzeuge | Autemos misst keine Codeüberdeckung |
Wie fangen Sie mit der Automatisierung an?
Wählen Sie die Abläufe aus der Systemspezifikation, die bei jedem Release bestehen müssen.
Klären Sie die Testdaten und die Konfiguration pro Umgebung.
Bauen Sie jeden Test als Workflow: Fachanwender per Drag and Drop, Engineers mit Code-Blöcken oder eingebundenen Playwright-Tests.
Lassen Sie bei Bedarf den AI Recorder einen Entwurf aus einem Jira-Ticket erstellen. Jeden KI-generierten Schritt gibt Ihr Team frei, bevor er läuft.
Starten Sie die Tests aus GitLab, GitHub Actions oder Jenkins und prüfen Sie die Endekriterien anhand der Ergebnisse in Jira/Xray und Allure.
Autemos exportiert Webtests als Playwright-Code (Java oder TypeScript) und Mobile-Tests als Appium-Code (Java), der Code läuft auch ohne Autemos. Wie ein Test entsteht, zeigen die visuellen Test-Workflows von Autemos.
Häufig gestellte Fragen
Was ist ein Systemtest laut ISTQB?
Laut ISTQB-Lehrplan 4.0.2 ist der Systemtest eine von fünf Teststufen und konzentriert sich auf das Gesamtverhalten eines kompletten Systems oder Produkts. Er umfasst häufig funktionale Tests kompletter Aufgaben und nicht-funktionale Tests von Qualitätsmerkmalen. Testbasis sind die Anforderungsspezifikationen für das System.
Was ist der Unterschied zwischen Integrationstest und Systemtest?
Der Komponentenintegrationstest prüft Schnittstellen und Interaktionen zwischen Komponenten, der Systemtest das komplette System gegen seine Spezifikation. Schnittstellen zu anderen Systemen und externen Diensten prüft seit CTFL 4.0 der Systemintegrationstest als eigene Stufe.
Ist ein Systemtest dasselbe wie ein E2E-Test?
Nein, E2E beschreibt den Umfang eines Szenarios, d. h. einen kompletten fachlichen Ablauf, und keine ISTQB-Teststufe. Solche Abläufe können auf der System-, Systemintegrations- oder Abnahmestufe laufen. Auf Systemebene kommen nicht-funktionale Tests von Qualitätsmerkmalen dazu.
Dürfen Produktionsdaten im Test verwendet werden?
Unter DORA dürfen Nicht-Produktionsumgebungen nur anonymisierte, pseudonymisierte oder randomisierte Produktionsdaten speichern (Art. 16 Abs. 5 lit. a, Delegierte Verordnung (EU) 2024/1774). Echte Produktionsdaten sind nur befristet, für bestimmte Testanlässe und nach Genehmigung erlaubt. FINMA-RS 2023/1 verlangt den Schutz kritischer Daten ausdrücklich auch in Testumgebungen.
Kann man Systemtests automatisieren?
Ja, funktionale Tests mit wiederholbaren Abläufen lassen sich gut automatisieren, allen voran Regressionstests. Gebrauchstauglichkeit und explorative Tests bleiben überwiegend manuell. Last-, Performanz- und Sicherheitstests brauchen spezialisierte Werkzeuge; Autemos deckt sie nicht ab und automatisiert ausschließlich funktionale Tests.
Fazit
Der Systemtest prüft das komplette System gegen seine Spezifikation und ist eine von fünf Teststufen im ISTQB-Lehrplan 4.0.2. Der Systemintegrationstest ist eine eigene Stufe, E2E beschreibt den Umfang eines Szenarios. Planen Sie funktionale und nicht-funktionale Anteile getrennt, denn Last-, Performanz- und Sicherheitstests brauchen eigene Werkzeuge.
In Banken und Versicherungen kommen Umgebung und Daten dazu: Schweizer Banken trennen Test und Produktion nach FINMA-RS 2023/1, EU-Finanzunternehmen speichern in Testumgebungen nach der Delegierten Verordnung (EU) 2024/1774 nur anonymisierte, pseudonymisierte oder randomisierte Produktionsdaten. Legen Sie Eingangs- und Endekriterien im Testplan fest und dokumentieren Sie, wer testet und wer freigibt.
Wiederholbare Abläufe und Regressionstests gehören in die Automatisierung. Wenn Sie klären möchten, welche Ihrer Systemtests sich mit Autemos automatisieren lassen, sprechen Sie mit unserem Team.
