KI-gestützte Testfall-Generierung: Warum „Erstell mir 10 Tests" nicht reicht

Der Ablauf ist vertraut: Funktionsblock kopieren, in ein LLM einfügen, „Erstell mir 10 Testfälle dafür” tippen, Ergebnis übernehmen. Syntaktisch sieht alles sauber aus, die Testsuite wächst, das Gefühl einer erledigten Aufgabe stellt sich ein. Und genau hier liegt das Problem.

Was dabei entsteht, sind meistens zehn Tests, die dieselbe Äquivalenzklasse abdecken — zehnmal der Happy Path, leicht variiert. Grenzwerte fehlen, Fehlerfälle fehlen, und die Assertions prüfen in vielen Fällen nicht das beabsichtigte Verhalten, sondern das tatsächlich implementierte. Das ist kein Zufall, sondern eine strukturelle Schwäche des naiven Ansatzes. LLMs sind Sprachmodelle: Sie generieren Tests, die plausibel klingen und syntaktisch korrekt sind. Ob sie fachlich richtig sind, ist eine andere Frage.

Dieser Artikel beschreibt, was gute Testfall-Prompts von schlechten unterscheidet, wie man die Qualität generierter Tests überprüft und wo LLMs bei der Testfall-Generierung grundsätzliche Grenzen haben.

Was gute Testfall-Prompts von schlechten unterscheidet

Der Kernunterschied ist einfach zu benennen: Ein guter Prompt überträgt die Testdesign-Methodik in die Anweisung. Ein schlechter Prompt übergibt dem Modell implizit die Aufgabe, diese Methodik selbst zu erfinden — was es regelmäßig nicht zuverlässig tut.

Eine groß angelegte Studie aus 2024, die 216.300 generierte Tests für 690 Java-Klassen auswertete, zeigte: Reasoning-basierte Prompting-Techniken wie Chain-of-Thought und Guided Tree-of-Thought verbessern Compilierbarkeit und Lesbarkeit der Tests messbar gegenüber einfacheren Prompts — Kompilierungsfehlerquoten von bis zu 86 % blieben aber auch bei Reasoning-Ansätzen bestehen. Halluzinationsbedingte Fehler blieben persistent, und Anti-Pattern wie „Magic Number Tests” und „Assertion Roulette” traten bei allen getesteten Modellen auf.¹

Daraus folgt: Das Modell braucht nicht nur Code als Input, sondern eine explizite Testdesign-Strategie. Die wichtigsten Muster:

Äquivalenzklassenbildung explizit anfordern

Statt: „Erstell Testfälle für diese Funktion.”

Besser:

Analysiere zunächst den Eingaberaum dieser Funktion.
Identifiziere alle Äquivalenzklassen – sowohl gültige als auch ungültige Partitionen.
Erstelle genau einen repräsentativen Testfall pro Klasse.
Dokumentiere die Klasse als Kommentar über jedem Test.

Das Modell wird gezwungen, den Suchraum zu strukturieren, bevor es Tests schreibt. Tests ohne benannte Klasse sind im Review sofort als Duplikat-Kandidaten erkennbar.

Grenzwertanalyse erzwingen (Boundary-Value Analysis)

Für jede numerische Eingabe und jeden String-Parameter:
– Identifiziere den minimalen gültigen Wert, den maximalen gültigen Wert,
  den Wert knapp unterhalb der unteren Grenze und knapp oberhalb der oberen Grenze.
– Erstelle je einen Testfall für diese vier Grenzpunkte.
– Begründe in einem Kommentar, warum dieser Wert ein Grenzwert ist.

Forschung zur LLM-basierten Grenzwertanalyse untersucht, wie explizite Prompts die Testqualität gegenüber unstrukturierten Ansätzen beeinflussen — die Ergebnisse sind von der Struktur des Eingaberaums abhängig und fallen unterschiedlich aus.² Was sich konsistent zeigt: Das Modell muss die Grenzwerte als Aufgabe gestellt bekommen, nicht als implizite Erwartung.

Risikobasiertes Testdesign

Kontext: Diese Funktion berechnet Rückerstattungsbeträge.
Fehler sind geschäftskritisch (finanzieller Schaden, Compliance-Relevanz).
Priorisiere Testfälle nach Fehlerrisiko:
1. Zuerst: negative Beträge, Nullwerte, Integer-Überläufe
2. Dann: Kombinationen mehrerer gleichzeitiger Rabattregeln
3. Zuletzt: Standardfälle

Erstelle 8 Testfälle in dieser Reihenfolge, jeweils mit Risikobegründung.

Ohne Risikokontext generiert das Modell keine risikoorientierte Verteilung. Mit expliziter Priorisierung entsteht eine Testsuite, die den wirtschaftlichen Wert der Tests maximiert — nicht nur die Anzahl.

Spezifikation als Orakel mitgeben

Ein fundamentales Problem bei der LLM-gestützten Testgenerierung: Wenn kein Soll-Verhalten explizit definiert ist, codiert das Modell das Ist-Verhalten als Soll. Konstantinou, Degiovanni und Papadakis zeigten 2024 empirisch, dass LLM-basierte Testgenerierung dieselbe Grundschwäche aufweist wie traditionelle Werkzeuge: generierte Oracles spiegeln das tatsächlich implementierte Verhalten wider, nicht das beabsichtigte.³

Gegenmittel: Spezifikation explizit übergeben.

Spezifikation: Rabatt darf 30 % des Nettobetrags nicht überschreiten.
Null-Beträge sind ungültig. Währungen werden auf zwei Dezimalstellen gerundet.

Generiere Testfälle, die ausschließlich gegen diese Spezifikation testen.
Jede Assertion muss direkt aus der Spezifikation ableitbar sein.

Auch natürlichsprachliche Anforderungen reichen — entscheidend ist, dass das Modell eine externe Referenz hat und nicht auf die Implementierung angewiesen ist.

State-Transition-Tests

Für Zustandsmaschinen und Workflows eignet sich ein expliziter Transition-Prompt:

Identifiziere alle Zustände dieser Komponente und alle erlaubten Übergänge.
Erstelle:
– einen Test pro erlaubtem Übergang
– einen Test pro unerlaubtem Übergang (erwartet Exception oder Fehlerstatus)
– einen Test für jeden Endzustand

Ohne strukturierte Anweisung zur Zustandsexploration orientiert sich das Modell typischerweise an den offensichtlichsten, häufigsten Zustandsübergängen — seltene oder implizite Transitionen werden übergangen. Der Prompt erzwingt eine explizite Aufzählung aller Zustände, bevor Tests generiert werden.

Wie man die Qualität KI-generierter Tests prüft

Syntaktische Korrektheit und Kompilierbarkeit sind notwendige, aber keine hinreichenden Qualitätskriterien. Eine 2024 veröffentlichte empirische Studie zu GitHub Copilot in Python zeigte: Selbst mit bestehendem Test-Context waren 54,72 % der generierten Tests fehlerhaft, gebrochen oder leer. Ohne bestehende Tests im selben Modul stieg dieser Anteil auf 92,45 %.⁴

Das Ergebnis deckt sich mit dem, was Teams in der Praxis berichten: Das Tool läuft, die Tests werden akzeptiert, aber eine Regression wird nicht aufgefangen. Woran liegt das — und wie erkennt man es?

Review-Checkliste

Bevor generierte Tests in eine Testsuite übernommen werden, sollte jeder Test fünf Fragen bestehen:

Äquivalenzklasse identifizierbar? Lässt sich ablesen, welche Eingabeklasse dieser Test repräsentiert? Tests ohne erkennbare Klasse sind Duplikat-Kandidaten.
Assertion gegen Spezifikation ableitbar? Kann der Erwartungswert aus einem Dokument oder einer Regel hergeleitet werden — oder ist er eine Vermutung des Modells?
Testisolation gewährleistet? Ist der Test unabhängig von Ausführungsreihenfolge, Datenbankzustand oder externen Diensten?
Fehlerfall unterscheidbar? Würde dieser Test auch fehlschlagen, wenn die Implementierung die falsche Fehlerklasse wirft oder einen falschen HTTP-Statuscode zurückgibt?
Grenzwert oder Mitte-der-Klasse? Wie viele der generierten Tests prüfen unauffällige Standardwerte statt Grenzen? Mehr als 60 % Standardwerte sind ein Warnsignal.

Mutation Score

Code-Coverage ist eine notwendige, aber leicht zu täuschende Metrik. Atlassian beschreibt das Problem präzise: Ein Test kann eine Zeile ausführen, ohne ihr Ergebnis zu prüfen — und trotzdem zur Coverage beitragen.⁵

Mutation Testing adressiert das. Werkzeuge wie PIT (Java) oder mutmut (Python) injizieren systematisch kleine Fehler in den Produktivcode — Operator-Tausch (> wird >=), Rückgabewert-Änderungen, Bedingungsnegation — und messen, wie viele dieser Mutanten die Testsuite erkennt.

In Atlassians Erfahrung mit KI-gestütztem Mutation Testing starteten fünf untersuchte Projekte mit Mutation-Coverage-Ausgangswerten zwischen 56 % und 84 % und erreichten nach Einsatz des KI-Assistenten Werte zwischen 80 % und 96 % — alle fünf Projekte erreichten damit das selbstgesteckte Ziel von 80 %.⁵ Meta setzte LLMs zur Generierung von Mutanten und zugehörigen Tests ein und erzielte in einem Praxisversuch von Oktober bis Dezember 2024 eine Test-Akzeptanzrate von 73 % durch Privacy-Engineers.⁶

Als Orientierung: Ein Mutation Score unter 60 % deutet darauf hin, dass die Testsuite große Klassen realer Bugs nicht aufdecken würde. Wang et al. zeigten 2024, dass LLM-generierte Mutanten traditionellen regelbasierten Mutanten in der Fehlererkennungsrate weit überlegen sein können — mit Werten von 87,98 % gegenüber 41,64 % bei regelbasierten Ansätzen.⁷

Äquivalenzklassen-Abdeckung

Auch ohne Mutation-Testing-Werkzeug lässt sich eine aussagekräftige Metrik erheben: Wie viele der vorher identifizierten Äquivalenzklassen sind durch mindestens einen Test abgedeckt? Diese manuelle oder halbautomatische Prüfung eignet sich als schnelles Qualitäts-Gate im Pull-Request-Review — insbesondere wenn der Prompt die Klassen bereits explizit benennt.

Praktische Grenzen: Was LLMs bei der Testfall-Generierung nicht leisten

Implizites Domänenwissen

LLMs kennen das, was in Trainings-Daten stand. Sie kennen nicht die spezifischen Regeln eines Versicherungsvertrages, einer Branchen-Compliance-Anforderung oder eines unternehmensinternen Workflows. Für solche Tests fehlt dem Modell die Grundlage, um korrekte Oracles zu generieren.

Chu et al. formulieren es 2025 direkt: Schwache Fehlererkennungsfähigkeit bleibt eine kritische Herausforderung, weil das semantische Verständnis für realistische Eingaben und korrekte Oracles ohne domänenspezifischen Kontext fehlt.⁸

Test-Oracle-Problem

Wenn das Modell keine Spezifikation als Referenz hat, greift es auf die Implementierung zurück. Das ist der einfachste Weg — und der gefährlichste: Tests, die das Ist-Verhalten einer fehlerhaften Implementierung kodieren, werden grün sein, solange der Bug existiert, und rot werden, wenn der Bug behoben wird.

Konstantinou, Degiovanni und Papadakis bestätigen das empirisch: LLM-basierte Testgenerierung produziert Oracles, die das tatsächliche Programmverhalten widerspiegeln — nicht das beabsichtigte. Trotzdem übertreffen LLM-generierte Oracles in der Fehlererkennungsrate traditionelle Werkzeuge wie EvoSuite.³

Flakiness und nicht-deterministisches Verhalten

LLMs generieren Tests für deterministisches Verhalten — und haben strukturell keinen Mechanismus, um Flakiness vorherzusagen. Parallel-Ausführung, Zeit-Abhängigkeiten, Race Conditions und externe Dienste bleiben blind spots. Ein generierter Test, der lokal grün ist, kann in CI-Umgebungen regelmäßig fehlschlagen — ohne dass das Modell darauf hinweist.

Komplexe Zustandsmaschinen und State-Explosion

Für Module mit tiefer Zustandsverschachtelung oder großen Zustandsräumen stoßen LLMs an Coverage-Grenzen. Chu et al. identifizieren 2025 schwache Fehlererkennungsfähigkeit als kritische Herausforderung für LLM-basierte Testgenerierung — insbesondere dort, wo das Modell ohne domänenspezifischen Kontext keine korrekten Oracles ableiten kann.⁸ In der Praxis zeigt sich das besonders bei Zustandsmaschinen: Das Modell generiert Tests für erreichbare, offensichtliche Zustände — seltene oder implizite Transitionen werden typischerweise übersehen.

Was das bedeutet

Atlassian beschreibt ihre Erfahrung direkt: In Projekten mit schlecht strukturiertem Code stagnierte die Mutation Coverage bei ca. 60 %, weil der KI-Assistent Testfälle für Strukturen generierte, die refaktoriert werden müssten, bevor sinnvolle Tests möglich sind. Das Modell zeigt, wo Designprobleme existieren — lösen kann es sie nicht.⁵

LLMs eignen sich gut für gut strukturierten, gut dokumentierten Code mit klaren Schnittstellen. Sie eignen sich schlecht für Legacy-Code mit impliziten Abhängigkeiten, undokumentierten Annahmen und komplexem Zustandsraum.

Fazit: Fünf Fragen vor dem nächsten Test-Prompt

KI-gestützte Testfall-Generierung ist ein nützliches Werkzeug — aber kein Autopilot. Das Modell braucht dieselben Informationen, die ein erfahrener Tester braucht: eine Partition des Eingaberaums, Grenzwertdefinitionen, eine Spezifikation als Orakel und einen Risikokontext. Wer diese Informationen in den Prompt überträgt, bekommt brauchbarere Ergebnisse. Wer hofft, dass das Modell sie selbst ermittelt, bekommt zehn syntaktisch korrekte, inhaltlich weitgehend redundante Tests.

Vor dem nächsten Test-Sprint lohnen fünf Fragen:

Welche Äquivalenzklassen hat dieser Eingaberaum? Und hat der Prompt das Modell explizit gebeten, sie zu benennen?
Welche Grenzwerte sind relevant? Wurden sie als explizite Aufgabe übergeben — nicht als implizite Erwartung?
Gibt es eine Spezifikation, die als Orakel dient? Auch ein Satz natürlichsprachlicher Anforderungen reicht.
Wie wird der Mutation Score nach der Generierung geprüft? Coverage allein ist kein hinreichender Qualitätsnachweis.
Wo endet der sinnvolle Einsatzbereich? Für Legacy-Code mit implizitem Domänenwissen und komplexem Zustandsraum gilt ein anderer Maßstab als für neue, gut dokumentierte Module.

Wendkûuni C. Ouédraogo, Kader Kaboré, Yinghua Li, Haoye Tian, Anil Koyuncu, Jacques Klein, David Lo und Tegawendé F. Bissyandé, „Large-scale, Independent and Comprehensive study of the power of LLMs for test case generation”, arXiv:2407.00225, eingereicht 2024-06-28, https://arxiv.org/abs/2407.00225, abgerufen am 2026-06-09. ↩
„Boundary Value Test Input Generation Using Prompt Engineering with LLMs: Fault Detection and Coverage Analysis”, arXiv:2501.14465, 2025, https://arxiv.org/abs/2501.14465, abgerufen am 2026-06-09. ↩
Michael Konstantinou, Renzo Degiovanni und Mike Papadakis, „Do LLMs generate test oracles that capture the actual or the expected program behaviour?”, arXiv:2410.21136, eingereicht 2024-10-28, https://arxiv.org/abs/2410.21136, abgerufen am 2026-06-09. ↩ ↩²
Khalid El Haji, Carolin Brandt und Andy Zaidman, „Using GitHub Copilot for Test Generation in Python: An Empirical Study”, in: Proceedings of the 5th ACM/IEEE International Conference on Automation of Software Test (AST 2024), Lissabon, 2024, https://dl.acm.org/doi/10.1145/3644032.3644443, abgerufen am 2026-06-09. ↩
Atlassian Engineering, „Automating Mutation Coverage with AI: Our Journey and Key Learnings”, Inside Atlassian Blog, 2025, https://www.atlassian.com/blog/development/automating-mutation-coverage-with-ai, abgerufen am 2026-06-09. ↩ ↩² ↩³
Engineering at Meta, „LLMs Are the Key to Mutation Testing and Better Compliance”, 2025-09-30, https://engineering.fb.com/2025/09/30/security/llms-are-the-key-to-mutation-testing-and-better-compliance/, abgerufen am 2026-06-09. ↩
Bo Wang, Mingda Chen, Ming Deng, Youfang Lin, Mark Harman, Mike Papadakis und Jie M. Zhang, „A Comprehensive Study on Large Language Models for Mutation Testing”, arXiv:2406.09843, 2024, https://arxiv.org/abs/2406.09843, abgerufen am 2026-06-09. ↩
Bei Chu, Yang Feng, Kui Liu, Zhaoqiang Guo, Yichi Zhang, Hange Shi, Zifan Nan und Baowen Xu, „Large Language Models for Unit Test Generation: Achievements, Challenges, and Opportunities”, arXiv:2511.21382, eingereicht 2025-11-26, https://arxiv.org/abs/2511.21382, abgerufen am 2026-06-09. ↩ ↩²

Transparenzhinweis: Dieser Beitrag wurde KI-gestützt erstellt und vor Veröffentlichung redaktionell geprüft.