Ein Negativtest in der Software prüft, wie ein System auf ungültige Eingaben, falsche Abläufe oder nicht vorgesehene Nutzung reagiert. Erwartet wird eine kontrollierte Ablehnung mit klarer Fehlermeldung und unverändertem Datenbestand. Mit dem juristischen „Negativattest“ hat der Begriff nichts zu tun. Fehlende Fehlerbehandlung ist teuer: In einer OSDI-Studie zu fünf verteilten Datensystemen gingen 92 % der katastrophalen Ausfälle darauf zurück. Die Beispiele unten stammen aus dem Schweizer Zahlungsverkehr: IBAN, QR-IBAN, Währung und Betrag.

Kurz gefasst: Ein Negativtest verwendet ein System auf nicht vorgesehene Weise und erwartet eine kontrollierte Ablehnung. Negative Testfälle leiten Sie aus ungültigen Äquivalenzklassen, Grenzwerten, fachlichen Regeln und intuitiver Testfallermittlung ab. Der deutsche ISTQB-Lehrplan 4.0.2 empfiehlt, pro Testfall nur eine ungültige Klasse zu testen. In einer OSDI-Studie gingen 92 % der katastrophalen Ausfälle in verteilten Datensystemen auf fehlerhafte Fehlerbehandlung zurück.

Abbildung 1: Positivtest und Negativtest im Vergleich

Was ist ein Negativtest nach ISTQB?

Ein Negativtest ist laut offiziellem ISTQB-Glossar „Eine Testart, bei der eine Komponente oder ein System auf eine Weise verwendet wird, die so nicht vorgesehen ist“ (ISTQB Glossar, 2026). Englische Synonyme sind invalid testing und dirty testing. Geprüft wird die Abwehr: Eingaben, Aktionen oder Zustände, die das System ablehnen oder ignorieren soll.

Viele Seiten zitieren noch eine ältere Formulierung aus einer inoffiziellen Kopie des Glossars. Maßgeblich ist das offizielle Glossar unter glossary.istqb.org, das die Definition oben in Deutsch und Englisch führt. Wer Testdokumentation für ein Audit schreibt, verweist am sichersten auf diese Quelle.

Für den Positivtest gibt es kein eigenes Stichwort im ISTQB-Glossar (Stand 27.09.2026). Der Begriff ist gängige Praxissprache: Ein Positivtest prüft mit gültigen Eingaben, ob das System den vorgesehenen Ablauf korrekt ausführt, oft „Happy Path“ genannt. Wie ein vollständiger Testfall mit Vorbedingungen und erwartetem Ergebnis aufgebaut ist, beschreibt unser Leitfaden zum Testfall.

Wie unterscheiden sich Positivtest und Negativtest?

Ein Positivtest bestätigt, dass gültige Eingaben zum erwarteten Ergebnis führen; ein Negativtest bestätigt, dass ungültige Eingaben kontrolliert abgewiesen werden. Der ISTQB-Lehrplan legt eine Reihenfolge fest: „Nachdem die positiven Testfälle abgeschlossen sind, sollte das Team Negativtests durchführen“ (ISTQB CTFL Lehrplan 4.0.2, 2025).

Negative Fälle gehören schon in die Anforderung. Laut Lehrplan 4.0.2 (§4.5.2) beschreiben Akzeptanzkriterien positive und negative Szenarien. Wie Sie das in einer User Story formulieren, zeigt der Artikel zu Akzeptanzkriterien mit positiven und negativen Fällen.

Warum lohnen sich Negativtests? Die Zahlen

Fehlerhafte Fehlerbehandlung verursachte in einer OSDI-Studie zu fünf verteilten Datensystemen 92 % der katastrophalen Ausfälle. Yuan et al. untersuchten 198 Ausfälle in Cassandra, HBase, HDFS, MapReduce und Redis und fanden: „almost all (92%) of the catastrophic system failures are the result of incorrect handling of non-fatal errors explicitly signaled in software“ (Yuan et al., OSDI, 2014).

Abbildung 2: Fehlerbehandlung als Ursache katastrophaler Ausfälle in fünf verteilten Datensystemen (Yuan et al., 2014)

Viele dieser Fehler wären billig zu finden gewesen. In 58 % der katastrophalen Ausfälle hätte ein einfacher Test des Fehlerbehandlungscodes den Fehler aufgedeckt. 35 % folgten drei trivialen Mustern (Stand 2014): leere oder nur loggende Handler, zu allgemein gefasste Abbrüche und Code mit TODO- oder FIXME-Vermerk. 77 % ließen sich mit einem Unit-Test reproduzieren. Die Studie betrifft verteilte Datensysteme, keine Banksoftware; die Prozentwerte gelten für diese Systeme.

Gezielte Tests für diesen Code sind selten. In einer Umfrage unter 154 Entwicklern gaben die Befragten an, dass in 70 % der Organisationen keine spezifischen Tests für Exception-Handling-Code existieren. Nur 27 % hatten Richtlinien zur Fehlerbehandlung (Ebert, Castor, Serebrenik, JSS, 2015). Die Zahl beruht auf Selbstauskunft der Befragten.

Ein Bankbeispiel: der fehlende Hard Block

Die britische Finanzaufsicht FCA büßte Citigroup Global Markets Limited 2024 mit £27.766.200. Ein Händler wollte einen Aktienkorb über US$58 Mio. verkaufen, machte einen Eingabefehler und erzeugte einen Korb über US$444 Mrd. Kontrollen blockierten US$255 Mrd., US$189 Mrd. gingen an einen Handelsalgorithmus. Verkauft wurden Aktien für US$1,4 Mrd. (FCA, 2024).

Laut FCA gab es „no hard block that would have rejected this large erroneous basket of equities in its entirety“. Der Fall ist ein Versagen der Handelskontrollen, kein einzelner fehlender Softwaretest. Er zeigt die Frage, die jeder Negativtest stellt: Was passiert mit einer formal möglichen, fachlich unplausiblen Eingabe? Eine harte Obergrenze ist eine ungültige Klasse, die Sie testen können.

Wie leiten Sie negative Testfälle Schritt für Schritt ab?

Negative Testfälle leiten Sie in fünf Schritten ab: ungültige Klassen und Grenzen bestimmen, fachliche Regeln prüfen, typische Fehler erraten, jede ungültige Klasse isolieren und das erwartete Ergebnis vorab festlegen. Für 100 % Äquivalenzklassen-Überdeckung zählt der CTFL-Lehrplan die ungültigen Klassen ausdrücklich mit (ISTQB CTFL Syllabus 4.0.1, 2024).

Abbildung 3: Negative Testfälle in fünf Schritten ableiten

1. Ungültige Äquivalenzklassen und Grenzen bestimmen. Eine ungültige Klasse enthält Werte, die das Testobjekt ablehnen oder ignorieren soll oder für die keine Verarbeitung definiert ist. Wählen Sie je Klasse einen Vertreter und prüfen Sie die Werte direkt jenseits jeder Grenze. Die Technik selbst erklärt der Artikel zu Äquivalenzklassen und Grenzwertanalyse.

2. Syntaktische und semantische Regeln trennen. Das OWASP-Cheat-Sheet zur Eingabeprüfung unterscheidet die korrekte Syntax strukturierter Felder (Datum, Währungssymbol) von der fachlichen Korrektheit der Werte (Startdatum vor Enddatum, Preis im erwarteten Bereich) (OWASP, laufend aktualisiert). Leiten Sie für jede Regel mindestens einen Verstoß ab.

3. Typische Fehler gezielt erraten. Die intuitive Testfallermittlung (error guessing) arbeitet mit bekannten Fehlerquellen. Der Lehrplan nennt bei Eingaben: korrekte Eingabe nicht akzeptiert, Parameter falsch oder fehlend. Fehlerangriffe (fault attacks) nach Whittaker provozieren Fehlerzustände: leeres Pflichtfeld, doppelte Übermittlung, abgelaufene Sitzung, Schritte in falscher Reihenfolge.

4. Pro Testfall genau eine ungültige Klasse testen. Der deutsche Lehrplan 4.0.2 hat 2025 ergänzt: „Ungültige Äquivalenzklassen sollten nicht gemeinsam in einem Testfall getestet werden, um Fehlermaskierung zu vermeiden“ (Lehrplan 4.0.2, 2025). Die englische Fassung 4.0.1 enthält diesen Satz nicht. Alle übrigen Felder bleiben gültig.

5. Das erwartete Ergebnis vorab festlegen. Notieren Sie Fehlercode, Meldungstext, markiertes Feld und den Datenzustand nach der Ablehnung. Ohne dieses Testorakel lautet das Ergebnis am Ende nur „das System hat irgendwie reagiert“.

Wie sieht Fehlermaskierung aus?

Ein Testfall sendet Betrag -50,00 und Währung USD. Das System lehnt die Währung ab und bricht die Prüfung ab. Die Betragsprüfung kommt nie zum Zug, ihr Zustand bleibt unbekannt. Zwei getrennte Testfälle beantworten beide Fragen.

Negative Pfade in längeren Abläufen, etwa ein Abbruch mitten in der Zahlungsfreigabe, gehören in ein eigenes Testszenario mit Ausnahmepfad. Der ISTQB-Lehrplan für Test Analysts nennt als Ausnahme-Szenario ausdrücklich „abnormal use or invalid input“ (ISTQB CTAL-TA 4.0, 2025).

Welche negativen Testfälle braucht eine Zahlungsmaske für QR-Rechnungen?

Eine Zahlungsmaske für Schweizer QR-Rechnungen braucht mindestens negative Testfälle für IBAN-Länge, IBAN-Prüfziffer, QR-Referenz, Währung und Betrag. Eine Schweizer IBAN hat 21 Zeichen, etwa CH93 0076 2011 6238 5295 7 (SIX IBAN, 2026). Jede Zeile der Tabelle enthält genau eine ungültige Klasse; alle anderen Felder sind gültig.

Abbildung 4: Checkliste für negative Testfälle einer Zahlungsmaske für QR-Rechnungen

Die Regeln stammen aus den SIX-FAQ zur QR-Rechnung: Wer eine QR-Referenz verwendet, muss eine QR-IBAN verwenden. Eine QR-IID liegt ausschließlich im Bereich 30000–31999, die QR-Referenz hat 26 Ziffern plus Prüfziffer, zulässig sind nur CHF und EUR (SIX QR-Rechnung FAQ, 2026).

Eine Formatprüfung beweist keine Kontoexistenz. Laut SIX bestätigt der IBAN-Check nur die formale Struktur, nicht die tatsächliche Gültigkeit. Testen Sie „formal korrekt, Konto existiert nicht“ dort, wo das Kernbankensystem antwortet, am einfachsten direkt über die Schnittstelle (siehe API-Testing). Echte Kunden-IBANs haben in Testdaten nichts verloren; wie Sie synthetische Werte erzeugen, steht im Beitrag zu DSGVO-konformen Testdaten.

Was ist das richtige erwartete Ergebnis eines Negativtests?

Das richtige erwartete Ergebnis ist eine kontrollierte Ablehnung: verständliche Meldung, keine Datenänderung, keine internen Details. NIST SP 800-53 Rev. 5 verlangt unter Control SI-11, dass Fehlermeldungen die nötige Information zur Korrektur liefern, ohne Informationen preiszugeben, die ein Angreifer ausnutzen könnte (NIST SP 800-53 Rev. 5, 2020).

Prüfen Sie bei jedem negativen Testfall diese Punkte:

• Die Meldung nennt Feld und Regel, etwa „Die IBAN muss 21 Zeichen haben“.

• Die Antwort enthält keinen Stacktrace, kein SQL-Fragment und keinen Servernamen.

• Es wurde keine Zahlung gespeichert und kein Saldo verändert.

• Der HTTP-Statuscode passt zur Ursache: 400 für eine fehlerhafte Anfrage, kein 500.

• Die Nutzerin kann korrigieren, ohne alle Felder neu einzugeben.

• Das Ereignis ist protokolliert, falls Ihre Anforderungen das verlangen.

Ein Absturz mit Fehlerseite ist ein Befund, selbst wenn die Zahlung nicht ausgeführt wurde. Der Test ist erst grün, wenn die Ablehnung genau so aussieht, wie Sie sie in Schritt 5 festgelegt haben.

Wo endet der Negativtest, und wo beginnt Security-Testing?

Ein funktionaler Negativtest prüft fachliche Regeln mit ausgewählten ungültigen Werten; Security-Testing und Fuzzing suchen mit Angriffsmustern oder großen Mengen generierter Eingaben nach ausnutzbaren Schwachstellen. Beide berühren die Eingabeprüfung. MITRE führt fehlerhafte Eingabeprüfung als CWE-20, in den CWE Top 25 von 2025 auf Platz 18 (MITRE CWE Top 25, 2025).

Was Autemos bei Negativtests übernimmt

Autemos automatisiert funktionale Negativtests aus Datensätzen. Sie legen die Fälle als Datensatz in CSV, XLSX oder JSON an: eine Zeile pro ungültiger Klasse, mit Spalten für Testwert und erwartete Meldung. Autemos lädt die Werte zur Laufzeit als typisierte Variablen. Einmal verwendbare Daten werden markiert, damit parallele Läufe sie nicht doppelt nutzen. Mehr dazu auf der Seite zum Testdaten-Handling in Autemos.

Autemos führt keine Penetrationstests und kein Fuzzing durch. Für SQL-Injection, Cross-Site-Scripting oder Protokoll-Fuzzing brauchen Sie ein Security-Werkzeug oder einen spezialisierten Dienstleister.

Häufig gestellte Fragen

Was ist der Unterschied zwischen Negativtest und Negativattest?

Ein Negativtest ist eine Testart in der Softwareentwicklung, ein Negativattest ist ein Begriff aus dem Recht. Die beiden teilen nur die Vorsilbe. Im Softwaretest gilt die ISTQB-Definition: Eine Komponente oder ein System wird auf eine Weise verwendet, die so nicht vorgesehen ist.

Gibt es eine ISTQB-Definition für den Positivtest?

Nein, das offizielle ISTQB-Glossar hat keinen Eintrag für positive testing (Stand 27.09.2026). Der Positivtest ist Praxissprache für Tests mit gültigen Eingaben entlang des vorgesehenen Ablaufs. Der Lehrplan verwendet den Begriff „positive Testfälle“ und ordnet sie vor den Negativtests ein.

Wie viele Negativtests braucht ein Eingabefeld?

Ein Eingabefeld braucht mindestens einen Negativtest pro ungültiger Äquivalenzklasse plus die Werte direkt jenseits jeder Grenze. Ein Betragsfeld mit Unter- und Obergrenze hat damit mindestens zwei ungültige Klassen. Für 100 % Äquivalenzklassen-Überdeckung verlangt der CTFL-Lehrplan, dass die ungültigen Klassen mitgetestet sind.

Lassen sich Negativtests automatisieren?

Ja, Negativtests eignen sich gut für die Automatisierung aus Datensätzen: ein Testablauf, viele Datenzeilen. Jede Zeile enthält eine ungültige Klasse und die erwartete Meldung. Autemos liest solche Datensätze aus CSV, XLSX oder JSON und führt sie über Web, Mobile, API und Desktop aus.

Ist ein Negativtest dasselbe wie ein Security-Test?

Nein, ein Negativtest prüft fachliche Eingaberegeln mit ausgewählten ungültigen Werten, ein Security-Test sucht nach ausnutzbaren Schwachstellen. Die Bereiche überschneiden sich bei der Eingabeprüfung (CWE-20). Penetrationstests und Fuzzing verlangen eigene Werkzeuge und Fachwissen.

Fazit

Ein Negativtest prüft, ob ein System ungültige Eingaben kontrolliert ablehnt. Das ISTQB-Glossar definiert ihn als Nutzung auf nicht vorgesehene Weise; für den Positivtest gibt es keinen Glossareintrag. Die Zahlen sprechen für den Aufwand: 92 % der von Yuan et al. untersuchten katastrophalen Ausfälle gingen auf Fehlerbehandlung zurück, und im FCA-Fall bei Citigroup führte eine fehlende harte Obergrenze dazu, dass Aktien im Wert von US$1,4 Mrd. ungewollt verkauft wurden.

Leiten Sie negative Testfälle aus ungültigen Klassen, Grenzen, fachlichen Regeln und typischen Fehlern ab. Testen Sie pro Fall genau eine ungültige Klasse und legen Sie die erwartete Meldung vorher fest. Für Schweizer Zahlungen heißt das: IBAN-Länge, Prüfziffer, QR-IBAN, CHF oder EUR und Betragsgrenzen einzeln abdecken. Wenn Sie solche Datensätze in Autemos automatisieren möchten, sprechen Sie mit unserem Team.