Testautomatisierung mit KI On-Premise für Unit-, Integrations- und Playwright-Tests

Tests, geschrieben von einem Modell auf dem eigenen Server

Ein QA- oder Entwicklungsteam kann Unit-, Integrations- und End-to-End-Tests mit einem offenen Modell auf der eigenen GPU erzeugen; der Quellcode geht dabei nur an den eigenen Modellserver. Ein Coding-Agent schreibt einen Test, führt ihn aus, liest den Fehler und behebt ihn; die Test Agents von Playwright tun dasselbe für Browsertests, und ein Mutationstest prüft danach, ob die neuen Tests Fehler finden. Eine NVIDIA RTX PRO 6000 Blackwell Workstation Edition oder Max-Q mit 96 GB versorgt ein Team, ein Server mit RTX PRO 6000 Server Edition erledigt dieselben Aufträge für eine ganze Abteilung in der nächtlichen Pipeline.

Dieser Leitfaden richtet sich an QA-Leitungen, Testautomatisierer und Entwicklungsleitungen. Er fasst zusammen, was Studien gemessen haben, welches Werkzeug welche Art von Test schreibt, wie Sie das Ergebnis prüfen und welche Hardware passt. Wie die Agenten an ein lokales Modell angebunden werden, steht in unserem Leitfaden zu Claude Code mit lokalem Modell; Embedded C und MISRA haben einen eigenen Leitfaden, lokale KI für Unit-Tests in Embedded C, und Review-Bots für Merge Requests behandelt selbst gehostetes KI-Code-Review.

Was Studien zu KI-geschriebenen Tests gemessen haben

arXiv-Zusammen­fassungen von 2402.09171 (14. Februar 2024), 2501.12862 (22. Januar 2025), 2403.16218 (v4, 9. Mai 2025) und 2410.00752 (v2, 18. März 2025), gelesen am 30. Oktober 2026. Nur TestGenEval nennt in der Zusammenfassung ein Modell; keine der Studien berichtet Ergebnisse auf RTX PRO Hardware.

Metas Paper zu TestGen-LLM, „Automated Unit Test Improvement using Large Language Models at Meta“, beschreibt ein Werkzeug, das bestehende, von Menschen geschriebene Tests verbessert und jeden Kandidaten durch Filter prüft, bevor ein Mensch ihn sieht. In der Auswertung bei Instagram kompilierten 75 Prozent der erzeugten Testfälle, 57 Prozent bestanden zuverlässig und 25 Prozent erhöhten die Abdeckung. Nach diesen Zahlen brachten drei von vier erzeugten Tests keine zusätzliche Abdeckung, und die Filter entfernten sie vor dem Review.

Das Folgepaper „Mutation-Guided LLM-based Test Generation at Meta“ dreht die Reihenfolge um. Sein System ACH erzeugt zuerst wenige Mutanten, also simulierte Fehler zu einem bestimmten Anliegen wie dem Datenschutz, und lässt dann das Modell Tests schreiben, die sie entdecken. Über 10.795 Android-Kotlin-Klassen auf sieben Plattformen entstanden 9.095 Mutanten und 571 Tests zur Absicherung des Datenschutzes, und die Entwickler übernahmen in Test-a-thons bei Messenger und WhatsApp 73 Prozent davon.

Zwei akademische Benchmarks liefern sehr unterschiedliche Zahlen. CoverUp, eine Schleife mit Abdeckungsanalyse für Python, erreichte im Median pro Modul 80 Prozent Zeilen- und Zweigabdeckung gegenüber 47 Prozent für CodaMosa. TestGenEval ließ Modelle vollständige Testdateien für 1.210 Codedateien aus 11 Python-Repositories schreiben, und das beste Modell der Studie, GPT-4o, erreichte „an average coverage of only 35.2%“. Die beiden Studien nutzen andere Projekte, Modelle und Aufgaben; die Werte lassen sich also nicht direkt vergleichen. Die Autoren von CoverUp führen ihr Ergebnis sowohl auf das Modell zurück als auch darauf, wie Abdeckungsanalyse, Codekontext und Rückmeldung über mehrere Runden zusammenwirken, nach demselben Prinzip wie Metas Filter.

Werkzeuge für Unit-, Integrations- und End-to-End-Tests

Dokumentation und Release Notes von Playwright, das Repository von Qodo Cover und das Repository von Playwright, gelesen am 30. Oktober 2026; OpenCode und Claude Code wie in unserem Claude-Code-Leitfaden am 30. Oktober 2026 geprüft; die Gateway-Dokumentation von Anthropic am 30. Oktober 2026 erneut gelesen.

Coding-Agenten für Unit- und Integrationstests. OpenCode und Claude Code lesen das Repository, schreiben eine Testdatei, führen den Testbefehl im Terminal aus und reparieren, was fehlschlägt. OpenCode verbindet sich mit einem OpenAI-kompatiblen Endpunkt wie vLLM oder Ollama. Claude Code erreicht ein lokales Modell über den Endpunkt im Anthropic-Format, den beide bereitstellen; die Dokumentation von Anthropic stellt aber klar, dass Anthropic „doesn't support routing Claude Code to non-Claude models through any gateway“. Dieses Setup läuft also außerhalb des Supports. Geben Sie dem Agenten eine Projekt-Anweisungsdatei mit Testframework, Namensregeln, wiederzuverwendenden Fixtures und dem Befehl, der die Abdeckung misst.

Playwright Test Agents für End-to-End-Tests. Playwright 1.56 führte „three custom agent definitions designed to guide LLMs“ ein: Der Planner erkundet die Anwendung und schreibt einen Testplan in Markdown, der Generator macht daraus Playwright-Testdateien und prüft Selektoren und Assertions an der laufenden Anwendung, und der Healer führt die Suite aus und repariert fehlschlagende Tests. npx playwright init-agents schreibt die Definitionen ins Repository, laut Release Notes von 1.56 mit Schleifen für VS Code, Claude Code und OpenCode. Die Dokumentation sagt „use your AI tool of choice“ und verlangt, die Definitionen nach jedem Playwright-Update neu zu erzeugen. Pläne landen in specs/, Tests in tests/, ausgehend von einem Seed-Test, der einen einsatzbereiten Page-Kontext bereitstellt. Laut Dokumentation kann der Healer einen Test auch übersprungen lassen, wenn er die Funktion für defekt hält; jemand sieht sich also jeden übersprungenen Test an. Seit Version 1.62 bringt Playwright zudem den Playwright-MCP-Server mit.

Qodo Cover, früher ein beliebtes offenes Werkzeug für Unit-Tests zur Erhöhung der Abdeckung, schreibt seit dem 15. Juni 2025: „This repository is no longer maintained. Please fork it if you wish to continue development or use it in your own projects.“ Wir installieren es nicht.

Sie können die Workstation oder den Server allein bestellen, die Einrichtung von vLLM, einem Coding-Modell, OpenCode und den Playwright-Agenten allein oder beides zusammen: das System mit allem fertig installiert und eingerichtet; schreiben Sie uns, wir schlagen Ihnen die beste Lösung für Ihre Aufgaben und Ihr Budget vor.

Mutationstests als Qualitätsprüfung

Die Abdeckung zeigt, welche Zeilen ein Test ausführt. Ob der Test einen Fehler bemerken würde, ist eine eigene Frage: Ein erzeugter Test, der eine Funktion aufruft und nichts prüft, erhöht die Abdeckung und findet nichts. Der Mutationstest misst diese zweite Eigenschaft. In den Worten von PIT: „Faults (or mutations) are automatically seeded into your code, then your tests are run. If your tests fail then the mutation is killed, if your tests pass then the mutation lived.“ Ein überlebender Mutant zeigt auf eine Assertion, die den Tests fehlt.

pitest.org und die Repositories von PIT, Stryker und mutmut, gelesen am 30. Oktober 2026. PIT arbeitet mit Ant, Maven und Gradle; mutmut braucht ein System mit Fork-Unterstützung und läuft unter Windows daher nur in WSL.

Ein Quality Gate für erzeugte Tests folgt den Filtern von Meta, ergänzt um Mutanten:

1. Kompiliert. Der Test lässt sich bauen, seine Imports lösen sich auf.
2. Besteht wiederholt. Er besteht mehrere Läufe hintereinander; das sortiert instabile Tests aus, die von Zeit oder Reihenfolge abhängen.
3. Erhöht die Abdeckung. Die Abdeckung des geänderten Codes steigt gegenüber der bestehenden Suite.
4. Tötet Mutanten. Der Mutation Score des berührten Codes steigt, oder überlebende Mutanten gehen als nächste Aufgabe an den Agenten zurück, wie bei ACH.
5. Besteht das Review. Eine Entwicklerin liest die Assertions vor dem Merge. Ein Test, der einen heutigen Fehler als erwarteten Wert festschreibt, besteht jede automatische Prüfung.

Ein Mutationstest führt die Tests für jeden Mutanten erneut aus, auf den Prozessoren Ihrer Build-Rechner und nicht auf der GPU; beschränken Sie ihn deshalb im Merge Request auf die geänderten Dateien und lassen Sie die volle Analyse nachts laufen.

Welches Modell, wie viel Kontext

Ein Agent, der Tests schreibt, schickt bei jedem Schritt die Anweisungen, den zu testenden Code, vorhandene Tests und die Ausgabe jedes Testlaufs mit. Er braucht daher ein Modell mit verlässlichem Tool Calling und einen Kontext von mindestens 64.000 Token, das Minimum, das Ollama für Coding-Agenten verlangt. Wir rechnen mit 128K Token, wie in unserem Claude-Code-Leitfaden.

Die offenen Modelle, die auf eine oder zwei Workstation-Karten passen, sind Qwen3.6-35B-A3B (35B gesamt, 3B aktiv, SWE-bench Verified 73,4 laut Qwen), das dichte Qwen3.8-27B (SWE-bench Pro 61,7 im Claude-Code-Harness, laut Qwen) und Qwen3-Coder-Next (80B gesamt, 3B aktiv), alle unter Apache 2.0. Ihre Karten nennen Benchmarks für Repository-Reparatur und Terminalarbeit; weder die Karte von Qwen3.6-35B-A3B noch die von Qwen3.8-27B nennt einen Benchmark für Testgenerierung. Machen Sie deshalb einen Pilot mit Ihrem eigenen Code: Wählen Sie 20 Klassen ohne Tests, lassen Sie den Agenten arbeiten und zählen Sie die Tests, die das Quality Gate oben bestehen. Qwen3.6-35B-A3B rechnet je Token rund 3B seiner 35B Parameter und liest damit nur einen Bruchteil der Gewichte, die das dichte Qwen3.8-27B liest; nach unserer Rechnung antwortet es deshalb um ein Mehrfaches schneller, und das zählt, wenn ein Agent pro Datei Dutzende Runden dreht.

GPUs vom einzelnen Entwickler bis zur nächtlichen Pipeline

Interaktive Arbeit braucht schnelle Antworten für jede Entwicklerin, nächtliche Testerzeugung braucht Durchsatz. Unsere Nutzer-pro-Karte-Regel nimmt 90 Prozent des vom Treiber gemeldeten Speichers, abzüglich 3 GiB pro Karte und der Gewichte, wie in unserem Leitfaden erklärt, wie viele Nutzer eine RTX PRO 6000 bedient.

Sitzungen im Speicher nach unserer Nutzer-pro-Karte-Regel mit 16-Bit-Cache (FP8-Cache in Klammern), aus unserem Claude-Code-Leitfaden vom 30. Oktober 2026; für interaktive Arbeit plant dieser Leitfaden weniger Sitzungen bei 50 Token pro Sekunde, zum Beispiel 11 (23) auf einer RTX PRO 6000 Workstation Edition oder Max-Q, nach unserer Schätzung eine Obergrenze.

Einstieg. Eine RTX PRO 4500 Blackwell (32 GB) versorgt einen Entwickler, der mit einem Agenten Tests schreibt. Die RTX PRO 5000 Blackwell mit 72 GB versorgt ein kleines QA-Team.

Mitte. Eine RTX PRO 6000 Workstation Edition oder Max-Q (96 GB) hält 18 Sitzungen des 35B-A3B-Modells und reicht für ein Team von etwa zehn Personen; 11 davon laufen mit den geplanten 50 Token pro Sekunde, für dieses Mixture-of-Experts-Modell nach unserer Schätzung eine Obergrenze. Wer das dichte Modell bevorzugt, bekommt auf derselben Karte Qwen3.8-27B in FP8 mit 6 Sitzungen zu 128K im Speicher, 13 mit FP8-Cache, und nach unserer Schätzung höchstens etwa 63 Token pro Sekunde für eine einzelne Anfrage. Zwei Karten betreiben Qwen3-Coder-Next als Tensor-Parallel-Paar. Zwei Karten der Workstation Edition mit je 600 W sind für diese Edition das realistische Maximum; drei oder vier Max-Q gehören nur in ein Gehäuse, das dafür gebaut ist, mit starkem, gerichtetem Luftstrom.

Groß. Für die nächtliche Testerzeugung über viele Repositories übernimmt ein Rack-Server mit RTX PRO 6000 Server Edition. Der nächste veröffentlichte Durchsatzwert ist NVIDIAs TensorRT-LLM-Ergebnis für Qwen3-30B-A3B in FP4 auf einer RTX PRO 6000 Server Edition: 374 Ausgabe-Token pro Sekunde bei Prompts mit 32.768 Token und Antworten mit 1.024 Token bei maximalem Offline-Durchsatz. Nach unserer Rechnung sind das 374 × 60 ÷ 1.024, etwa 22 Aufrufe pro Minute. Braucht ein Agent 20 Aufrufe, um die Tests für ein Modul fertigzustellen, eine Annahme zur Veranschaulichung, schafft eine Karte höchstens etwa 66 Module pro Stunde, nach unserer Schätzung eine Obergrenze. Zählen Sie die Aufrufe pro Modul in Ihrem Pilot. Vier Karten mit je 600 W und zwei Prozessoren AMD EPYC 9355 ziehen nach unserer Schätzung etwa 3,4 kW. Unser Leitfaden zum Server für Coding-Agenten legt den gemeinsam genutzten Fall aus.

Senden Sie uns die Zahl der Entwickler, die Sprachen und Testframeworks und wie viele Repositories der nächtliche Lauf abdecken soll; wir legen Workstation oder Server und das Modell für diese Last aus.

Testgenerierung in der CI-Pipeline

Der GPU-Rechner stellt das Modell bereit; die Tests laufen dort, wo sie immer laufen. Ein CI-Job checkt den Branch aus, startet den Agenten mit der Anweisungsdatei des Projekts, lässt ihn im Container des Jobs Tests schreiben und ausführen, wendet das Quality Gate an und öffnet einen Merge Request mit den bestandenen Tests. Browsertests brauchen Browser und die zu testende Anwendung in diesem Container; das kostet Prozessorzeit und Arbeitsspeicher auf den Runnern, nicht auf dem GPU-Server. Unser Leitfaden zu GPU-Runnern für CI behandelt Runner, die selbst eine GPU brauchen.

Vier Einstellungen senken das Risiko. Lassen Sie den Agenten in einem Container ohne Produktionszugangsdaten laufen, denn er führt den Code aus, den er schreibt. Geben Sie jeder Pipeline einen eigenen Schlüssel auf einem LLM-Gateway mit Schlüsseln und Protokoll, denn vLLMs eigenes --api-key schützt nur einen Teil der Pfade und verwaltet keine Nutzer. Tragen Sie in der Konfiguration des Agenten den Kontext ein, mit dem der Server gestartet wurde, damit lange Testläufe komprimiert werden, bevor der Server eine Anfrage ablehnt. Und setzen Sie in der Konfiguration von OpenCode "share": "disabled", denn sein Befehl /share lädt das Gespräch, das Code enthalten kann, zu opencode.ai hoch.

FAQ