Softwaretests mit KI – von Unit-Tests bis zu Evaluierungen

Softwaretests mit KI bedeuten, Sprachmodelle und Agenten zum Schreiben, Ausführen und Analysieren von Tests einzusetzen – von Unit-Tests über E2E-Szenarien in Playwright bis zum automatischen Code-Review – sowie die KI-Funktionen der Anwendung selbst mithilfe von Evaluierungen und Sicherheitstests zu prüfen. KI beschleunigt die Testautomatisierung deutlich, nimmt dem Team aber nicht die Entscheidung ab, was und warum getestet wird. Falsch eingesetzt, produziert sie Hunderte Tests, die bestehen, aber nichts Wesentliches prüfen.

In diesem Artikel zeigen wir, wie KI bei den einzelnen Testarten hilft, wie man Anwendungen testet, die selbst Sprachmodelle nutzen, und welche Teile des Testprozesses man besser nicht der Maschine überlässt.

Softwaretests und KI – zwei verschiedene Themen

Hinter dem Schlagwort „Testen mit KI“ verbergen sich zwei Dinge, die man auseinanderhalten sollte:

• KI als Werkzeug für Tester und Entwickler – Generieren von Unit- und E2E-Tests, Fehleranalyse, Code-Review, Erstellen von Testdaten. Das betrifft jede Anwendung, auch eine ganz ohne KI-Funktionen.
• Testen von KI-Funktionen in der Anwendung – Prüfen, ob Chatbot, Assistent oder Agent korrekt antwortet, nichts erfindet, keine Daten preisgibt und sich nicht manipulieren lässt. Dafür braucht es andere Methoden als klassische Tests, denn die Ausgabe eines Modells ist nicht vollständig deterministisch.

Zunächst widmen wir uns dem ersten Bereich, danach dem zweiten.

KI-generierte Unit-Tests

Unit-Tests sind der Bereich, in dem KI am schnellsten Wirkung zeigt. Ein Agent wie Claude Code kann eine Funktion oder Klasse lesen, ihre Funktionsweise verstehen, eine Reihe von Tests generieren, sie ausführen und diejenigen korrigieren, die aus technischen Gründen fehlschlagen. Besonders nützlich ist das bei älterem Code ohne Tests, der geändert werden muss.

Worauf Sie achten sollten

• Tests, die Fehler festschreiben. KI schreibt Tests auf Basis dessen, wie der Code funktioniert – nicht, wie er funktionieren sollte. Berechnet eine Funktion den Rabatt falsch, „bestätigt“ der Test oft das falsche Ergebnis. Deshalb sollten Sie dem Agenten Anforderungen oder Beispiele erwarteter Ergebnisse mitgeben, nicht nur den Code.
• Tautologische Tests. Ein Test, der prüft, ob eine gemockte Funktion zurückgibt, was der Mock zurückgibt, erhöht die Codeabdeckung, aber nicht die Sicherheit.
• Zu viele Mocks. Werden alle Abhängigkeiten durch Attrappen ersetzt, prüft der Test kein reales Verhalten mehr.
• Abdeckung als Ziel. Eine hohe, von KI erzeugte Abdeckungsquote ist leicht zu erreichen und leicht zu überschätzen. Ein besserer Maßstab ist, ob die Tests absichtlich eingebaute Fehler erkennen – diese Technik nennt man Mutationstests.

Bewährte Praxis: Zuerst beschreibt ein Mensch die zu prüfenden Fälle (einschließlich Grenzfällen und fehlerhafter Daten), dann schreibt die KI die Tests, und zum Schluss prüft ein Entwickler sie genauso sorgfältig wie Produktivcode.

E2E-Tests in Playwright mit KI-Unterstützung

Playwright ist ein Open-Source-Framework zur Automatisierung von End-to-End-Tests für Webanwendungen, entwickelt von Microsoft. Es steuert Browser auf Basis der Engines Chromium, Firefox und WebKit, führt Tests parallel und in der CI aus und ermöglicht bei Fehlern die Analyse des Testablaufs im Trace Viewer (Screenshots, Netzwerkanfragen, einzelne Schritte). Integriert sind ein automatisches Warten auf Elemente, das das Problem instabiler Tests reduziert, sowie ein Testgenerator, der Nutzeraktionen aufzeichnet.

Wie KI bei Playwright hilft

1. Szenarien aus einer Beschreibung. Sie beschreiben den Weg des Nutzers („Konto registrieren, E-Mail bestätigen, Produkt in den Warenkorb legen, mit Testkarte bezahlen“), und der Agent schreibt den Test in Playwright, führt ihn aus und korrigiert ihn.
2. Agent im echten Browser. Dank des Playwright-MCP-Servers kann ein KI-Agent die Anwendung selbst öffnen, klicken, Formulare ausfüllen und das Ergebnis prüfen – und den Ablauf anschließend als festen Test speichern. Über das Protokoll schreiben wir im Artikel MCP – Model Context Protocol.
3. Fehleranalyse. Der Agent liest Bericht und Trace des Tests, ermittelt, ob der Test oder die Anwendung versagt hat, und schlägt eine Korrektur vor.
4. Pflege der Tests. Nach einer Änderung der Oberfläche aktualisiert die KI Selektoren und Schritte in vielen Tests gleichzeitig.
5. Bessere Locators. Der Agent kann fragile CSS-Selektoren in Locators auf Basis von Rollen und Labels umschreiben (z. B. eine Schaltfläche mit einem bestimmten Namen), die robuster gegenüber Designänderungen sind und nebenbei die Barrierefreiheit fördern.

Fallstricke KI-geschriebener E2E-Tests

Ein Agent, der „den Test zum Bestehen bringen“ soll, kann eine Assertion abschwächen, eine feste Wartezeit einfügen oder einen fehlschlagenden Schritt überspringen. Jede Änderung an Tests sollte daher ein Review mit der Frage durchlaufen: Prüft der Test noch, was er prüfen sollte? E2E-Tests sind zudem teurer in der Pflege als Unit-Tests – beschränken Sie sie auf die zentralen Geschäftsabläufe und decken Sie den Rest mit Tests niedrigerer Ebenen ab.

KI-Code-Review – automatische Codeprüfung

Tools für KI-Code-Review analysieren die Änderungen in einem Pull Request und hinterlassen Kommentare: potenzielle Fehler, fehlende Ausnahmebehandlung, Inkonsistenzen, Probleme mit der Lesbarkeit und mitunter Sicherheitslücken. Diese Funktion bietet u. a. GitHub Copilot, und Agenten wie Claude Code oder Codex lassen sich in der CI-Pipeline ausführen, um Änderungen nach festgelegten Regeln zu prüfen.

Wo KI-Code-Review gut funktioniert:

• schnelle erste Feedbackrunde, bevor die Änderung bei einem Menschen landet,
• Aufspüren typischer Fehler und Versäumnisse (null, fehlende Validierung, Tippfehler in Namen),
• Einhaltung der in den Anweisungen beschriebenen Team-Konventionen,
• Zusammenfassung eines großen Pull Requests für den Reviewer.

Wo es versagt:

• Beurteilung, ob die Änderung den geschäftlichen Anforderungen entspricht,
• Architekturentscheidungen und ihre langfristigen Folgen,
• Fehler, die aus Kontext außerhalb der geänderten Dateien entstehen,
• zu viele Kommentare – eine Flut kleiner Anmerkungen schläfert die Aufmerksamkeit der Reviewer ein.

KI-Code-Review ist eine Ergänzung, kein Ersatz. Bei 4B Systems prüft ein Entwickler jede Änderung – auch die, die ein KI-Agent vorbereitet hat.

Testautomatisierung mit KI – wo sie außerdem hilft

Testen von Anwendungen mit KI-Funktionen

Wenn die Anwendung selbst ein Sprachmodell nutzt – als Chatbot, Assistent, Wissenssuche oder Agent –, reichen klassische Tests nicht aus. Derselbe Prompt kann unterschiedliche Antworten liefern, und eine „richtige“ Antwort ist oft nicht ein bestimmter Text. Nötig sind drei zusätzliche Testarten.

Evaluierungen (Evals)

Eine Evaluierung ist ein Satz von Testfällen – Fragen, Dokumente, Aufgaben – samt Kriterien zur Bewertung der Antworten. Die Kriterien können einfach sein (enthält die Antwort den richtigen Betrag, hat sie das geforderte JSON-Format) oder beschreibend (entspricht die Antwort den Rückgaberichtlinien, ist der Ton angemessen). Ein Teil der Bewertungen erfolgt per Code, ein Teil durch ein anderes Modell, das nach festgelegten Regeln bewertet (sog. LLM-as-a-judge), und ein Teil – stichprobenartig – durch einen Menschen. Evaluierungen laufen bei jeder Änderung von Prompt, Modell, Daten oder RAG-Konfiguration, um Qualitätsrückschritte zu erkennen. Den Satz sollten Sie laufend um Fälle ergänzen, in denen die Anwendung bei echten Nutzern versagt hat.

Halluzinationen

Eine Halluzination ist eine Antwort, die glaubwürdig klingt, aber falsch ist oder sich nicht aus den Quellen ergibt. In RAG-Anwendungen testet man u. a.:

• ob die Antwort ausschließlich auf den bereitgestellten Dokumenten beruht,
• ob die angegebenen Quellen die genannte Information tatsächlich enthalten,
• ob das Modell zugibt, etwas nicht zu wissen, wenn die Dokumente keine Antwort enthalten,
• wie es sich bei Fangfragen und Fragen außerhalb des Themenbereichs verhält.

Prompt Injection und Sicherheit

Prompt Injection ist der Versuch, das Modell dazu zu bringen, seine Anweisungen zu ignorieren – direkt („Vergiss die vorherigen Anweisungen und …“) oder indirekt über Inhalte, die das Modell liest: ein Dokument, eine E-Mail, eine Webseite mit versteckten Anweisungen. Es ist eine der Hauptbedrohungen in der Liste OWASP Top 10 für LLM-Anwendungen. Tests sollten u. a. prüfen, ob die Anwendung:

• weder Systemanweisungen noch Daten anderer Nutzer preisgibt,
• die Berechtigungen des Nutzers auch dann respektiert, wenn das Modell manipuliert wurde,
• keine Aktionen (z. B. E-Mail-Versand, Datenänderung) ohne Bestätigung ausführt, wenn der Prozess dies erfordert,
• vom Modell generierte Inhalte sicher verarbeitet, sie z. B. nicht ohne Escaping in die Seite einfügt.

Die wichtigste Regel: Sicherungen dürfen sich nicht allein auf Anweisungen an das Modell stützen. Berechtigungen, Validierung und Bestätigungen müssen im Anwendungscode greifen. Mehr zur Gestaltung solcher Anwendungen lesen Sie im Artikel KI-Anwendung entwickeln.

Was man beim Testen nicht der KI überlassen sollte

KI kann einen großen Teil der Arbeit bei der Testautomatisierung übernehmen, doch einige Elemente sollten beim Menschen bleiben:

1. Die Entscheidung, was getestet wird. Die Auswahl kritischer Pfade, geschäftlicher Risiken und Prioritäten erfordert Kenntnis von Produkt und Kunden.
2. Akzeptanzkriterien. Der Mensch legt fest, wie sich das System verhalten soll. KI kann helfen, sie aufzuschreiben, sollte sie aber nicht erfinden.
3. Review der Tests. Von KI geschriebene Tests liest man genauso sorgfältig wie Produktivcode – besonders Änderungen, die einen fehlschlagenden Test „reparieren“.
4. Sicherheitstests. KI unterstützt die Suche nach Schwachstellen, doch die abschließende Bewertung und Penetrationstests erfordern Spezialisten.
5. Explorative Tests und UX. Das Gespür dafür, dass etwas für Nutzer verwirrend oder ärgerlich ist, bleibt eine Domäne des Menschen.
6. Produktivdaten. Der Agent sollte keinen Zugriff auf die Produktion oder echte personenbezogene Daten haben – Tests laufen in Testumgebungen mit synthetischen Daten.
7. Die Release-Entscheidung. Eine grüne Pipeline ist eine notwendige Bedingung, doch über das Deployment entscheidet das Team.

Wie wir bei 4B Systems Anwendungen testen

In Projekten für Web- und Mobile-Anwendungen verbinden wir klassische Praktiken mit KI-Tools: Agenten helfen beim Schreiben von Unit-Tests und E2E-Szenarien in Playwright, analysieren Fehler und liefern die erste Feedbackrunde im Code-Review, während Entwickler über den Testumfang entscheiden und jede Änderung prüfen. In Anwendungen mit KI-Funktionen bauen wir Evaluierungssätze und Tests zur Widerstandsfähigkeit gegen Prompt Injection noch vor dem Go-live. Mehr über unseren Ansatz lesen Sie auf der Seite KI-Anwendungen und KI-gestützte Entwicklung.

Fazit

KI beschleunigt Softwaretests spürbar: Sie generiert Unit-Tests, schreibt und pflegt E2E-Szenarien in Playwright, analysiert Fehler und unterstützt das Code-Review. Sie braucht jedoch Kontrolle – von KI geschriebene Tests können Fehler zementieren oder gar nichts prüfen. Anwendungen mit KI-Funktionen müssen zusätzlich mit Evaluierungen auf Halluzinationen und Prompt Injection getestet werden. Die Entscheidung, was getestet wird, Abnahmekriterien, Sicherheit und Releases bleiben in menschlicher Hand.

Sie brauchen eine Anwendung, die nicht nur schnell gebaut, sondern auch gründlich getestet ist? 4B Systems entwickelt Anwendungen mit KI-Unterstützung – mit automatisierten Tests in Playwright, Evaluierungen der KI-Funktionen und einem Review jeder Änderung durch einen Entwickler. Sehen Sie sich unser Angebot für KI-gestützte Entwicklung und automatisierte Tests an und beschreiben Sie Ihr Projekt – ein Angebot erhalten Sie innerhalb von 48 Stunden.

Häufig gestellte Fragen

Kann KI automatisierte Tests anstelle eines Entwicklers schreiben?

KI kann einen großen Teil der Tests schreiben, insbesondere Unit-Tests und E2E-Szenarien, und sie auch ausführen und korrigieren. Der Entwickler sollte jedoch festlegen, was getestet wird, und die generierten Tests prüfen, denn KI kann fehlerhaftes Verhalten des Codes festschreiben oder Tests schreiben, die nichts Wesentliches prüfen.

Was ist Playwright?

Playwright ist ein Open-Source-Framework für End-to-End-Tests von Webanwendungen, entwickelt von Microsoft. Es steuert Browser auf Basis von Chromium, Firefox und WebKit, wartet automatisch auf Seitenelemente und ermöglicht die Analyse des Testablaufs im Trace Viewer.

Ersetzt KI-Code-Review die Codeprüfung durch einen Menschen?

Nein. KI eignet sich gut als erste Feedbackrunde und zum Aufspüren typischer Fehler, beurteilt aber weder die Übereinstimmung mit den geschäftlichen Anforderungen noch Architekturentscheidungen. Die Änderung sollte ein Entwickler freigeben.

Wie testet man einen Chatbot oder KI-Assistenten?

Neben klassischen Tests braucht es Evaluierungen – also einen Satz von Fragen mit Kriterien zur Bewertung der Antworten, der bei jeder Änderung von Prompt, Modell oder Daten ausgeführt wird. Hinzu kommen Tests auf Halluzinationen, auf das Verhalten bei Fragen außerhalb des Themenbereichs und auf die Widerstandsfähigkeit gegen Prompt Injection.

Was ist Prompt Injection?

Der Versuch, das Modell dazu zu bringen, seine Anweisungen zu ignorieren – direkt in der Nachricht des Nutzers oder indirekt über den Inhalt eines Dokuments, einer E-Mail oder einer Webseite, die das Modell liest. Der Schutz erfordert Sicherungen im Anwendungscode – Berechtigungen, Validierung und Bestätigungen – und nicht nur Anweisungen an das Modell.

Darf man bei Tests mit KI Produktivdaten verwenden?

Das sollte man nicht. Tests sollten in Testumgebungen mit synthetischen Daten laufen, und KI-Agenten sollten keinen Zugriff auf die Produktion oder echte personenbezogene Daten haben – auch mit Blick auf die DSGVO.