OpenClaw QA E2E-Tests: Automatisierte Workflows

Wenn du dich schon einmal dabei ertappt hast, wie du stundenlang manuell durch Chat-Verläufe scrollst, um einen kleinen Bug in deinem Agenten zu finden, dann weißt du, wie frustrierend das sein kann. Automatisierte Tests sind der einzige Weg, um bei komplexen Interaktionen den Überblick zu behalten und sicherzustellen, dass dein System auch nach Änderungen stabil bleibt.

Mit OpenClaw QA-Automatisierung kannst du dein System in einer realistischen Umgebung testen, die weit über einfache Unit-Tests hinausgeht.

QA E2E Automatisierung

Der private QA-Stack ist dafür gedacht, OpenClaw in einer realistischen, kanalartigen Umgebung zu testen, die über einfache Unit-Tests hinausgeht.

Aktuelle Komponenten:

1. extensions/qa-channel: Ein synthetischer Nachrichtenkanal mit Unterstützung für DM, Channels, Threads, Reaktionen, Bearbeitungen und Löschungen.
2. extensions/qa-lab: Eine Debugger-UI und ein QA-Bus zur Beobachtung des Transkripts, zum Injizieren eingehender Nachrichten und zum Exportieren eines Markdown-Berichts.
3. qa/: Im Repository gespeicherte Seed-Assets für den Kickoff-Task und grundlegende QA-Szenarien.

Der aktuelle QA-Operator-Flow ist eine zweigeteilte QA-Seite:

1. Links: Gateway-Dashboard (Control UI) mit dem Agenten.
2. Rechts: QA Lab, das das Slack-ähnliche Transkript und den Szenarioplan anzeigt.

Starte es mit:

pnpm qa:lab:up

Dies baut die QA-Seite, startet den Docker-basierten Gateway-Lane und stellt die QA Lab-Seite bereit, auf der ein Operator oder eine Automatisierungsschleife dem Agenten eine QA-Mission geben, das reale Kanalverhalten beobachten und aufzeichnen kann, was funktioniert, fehlgeschlagen ist oder blockiert bleibt.

Für eine schnellere Iteration der QA Lab UI, ohne jedes Mal das Docker-Image neu zu bauen, starte den Stack mit einem bind-mounted QA Lab Bundle:

pnpm openclaw qa docker-build-image
pnpm qa:lab:build
pnpm qa:lab:up:fast
pnpm qa:lab:watch

qa:lab:up:fast behält die Docker-Services auf einem vorgefertigten Image und bind-mountet extensions/qa-lab/web/dist in den qa-lab Container. qa:lab:watch baut das Bundle bei Änderungen neu, und der Browser lädt automatisch neu, sobald sich der QA Lab Asset-Hash ändert.

Für einen transport-realen Matrix Smoke-Lane, führe aus:

pnpm openclaw qa matrix

Dieser Lane stellt einen temporären Tuwunel-Homeserver in Docker bereit, registriert temporäre Treiber-, SUT- und Beobachter-Benutzer, erstellt einen privaten Raum und führt dann das echte Matrix-Plugin innerhalb eines QA Gateway-Childs aus. Der Live-Transport-Lane hält die Child-Konfiguration auf den zu testenden Transport beschränkt, sodass Matrix ohne qa-channel in der Child-Konfiguration läuft. Er schreibt die strukturierten Berichts-Artefakte und ein kombiniertes stdout/stderr-Log in das ausgewählte Matrix QA-Ausgabeverzeichnis. Um auch die äußere scripts/run-node.mjs Build/Launcher-Ausgabe zu erfassen, setze OPENCLAW_RUN_NODE_OUTPUT_LOG=<path> auf eine repo-lokale Log-Datei.

Für einen transport-realen Telegram Smoke-Lane, führe aus:

pnpm openclaw qa telegram

Dieser Lane zielt auf eine echte private Telegram-Gruppe ab, anstatt einen temporären Server bereitzustellen. Er erfordert OPENCLAW_QA_TELEGRAM_GROUP_ID, OPENCLAW_QA_TELEGRAM_DRIVER_BOT_TOKEN und OPENCLAW_QA_TELEGRAM_SUT_BOT_TOKEN sowie zwei verschiedene Bots in derselben privaten Gruppe. Der SUT-Bot muss einen Telegram-Benutzernamen haben, und die Bot-zu-Bot-Beobachtung funktioniert am besten, wenn beide Bots den Bot-zu-Bot-Kommunikationsmodus in @BotFather aktiviert haben.

Live-Transport-Lanes teilen sich jetzt einen kleineren Vertrag, anstatt dass jeder seine eigene Szenario-Listenform erfindet:

qa-channel bleibt die breite synthetische Produktverhaltens-Suite und ist nicht Teil der Live-Transport-Abdeckungsmatrix.

Lane	Canary	Mention gating	Allowlist block	Top-level reply	Restart resume	Thread follow-up	Thread isolation	Reaction observation	Help command
Matrix	x	x	x	x	x	x	x	x
Telegram	x								x

Dies bewahrt qa-channel als breite Produktverhaltens-Suite, während Matrix, Telegram und zukünftige Live-Transporte sich eine explizite Transport-Vertrags-Checkliste teilen.

Für einen Linux-VM-Lane ohne Docker im QA-Pfad, führe aus:

pnpm openclaw qa suite --runner multipass --scenario channel-chat-baseline

Dies startet einen frischen Multipass-Gast, installiert Abhängigkeiten, baut OpenClaw innerhalb des Gastes, führt qa suite aus und kopiert dann den normalen QA-Bericht und die Zusammenfassung zurück in .artifacts/qa-e2e/... auf dem Host. Es verwendet dasselbe Szenario-Auswahlverhalten wie qa suite auf dem Host. Host- und Multipass-Suite-Läufe führen standardmäßig mehrere ausgewählte Szenarien parallel mit isolierten Gateway-Workern aus, bis zu 64 Worker oder die Anzahl der ausgewählten Szenarien. Verwende --concurrency <count>, um die Worker-Anzahl anzupassen, oder --concurrency 1 für die serielle Ausführung. Live-Läufe leiten die unterstützten QA-Auth-Eingaben weiter, die für den Gast praktisch sind: env-basierte Provider-Keys, den QA Live-Provider-Konfigurationspfad und CODEX_HOME, falls vorhanden. Halte --output-dir unter dem Repo-Root, damit der Gast durch den gemounteten Workspace zurückschreiben kann.

Repo-basierte Seeds

Seed-Assets befinden sich in qa/:

1. qa/scenarios/index.md
2. qa/scenarios/*.md

Diese befinden sich absichtlich in GitHub, damit der QA-Plan sowohl für Menschen als auch für den Agenten sichtbar ist.

qa-lab sollte ein generischer Markdown-Runner bleiben. Jede Szenario-Markdown-Datei ist die Quelle der Wahrheit für einen Testlauf und sollte definieren:

1. Szenario-Metadaten
2. Dokumentations- und Code-Referenzen
3. Optionale Plugin-Anforderungen
4. Optionalen Gateway-Konfigurations-Patch
5. Den ausführbaren qa-flow

Die wiederverwendbare Laufzeitumgebung, die qa-flow unterstützt, darf generisch und übergreifend bleiben. Zum Beispiel können Markdown-Szenarien transportseitige Helfer mit browserseitigen Helfern kombinieren, die die eingebettete Control UI über den Gateway browser.request Seam steuern, ohne einen speziellen Runner hinzuzufügen.

Die Baseline-Liste sollte breit genug bleiben, um Folgendes abzudecken:

1. DM- und Kanal-Chat
2. Thread-Verhalten
3. Nachrichten-Aktions-Lebenszyklus
4. Node.js Cron-Callbacks
5. Speicherabruf
6. Modellwechsel
7. Subagenten-Übergabe
8. Repo- und Dokumentations-Lesen
9. Eine kleine Build-Aufgabe wie Lobster Invaders

Transport-Adapter

qa-lab besitzt einen generischen Transport-Seam für Markdown-QA-Szenarien. qa-channel ist der erste Adapter an diesem Seam, aber das Designziel ist breiter: Zukünftige echte oder synthetische Kanäle sollten sich in denselben Suite-Runner einstecken, anstatt einen transport-spezifischen QA-Runner hinzuzufügen.

Auf Architekturebene ist die Aufteilung wie folgt:

1. qa-lab besitzt die generische Szenario-Ausführung, Worker-Parallelität, Artefakt-Schreiben und Reporting.
2. Der Transport-Adapter besitzt die Gateway-Konfiguration, Bereitschaft, eingehende und ausgehende Beobachtung, Transport-Aktionen und den normalisierten Transport-Status.
3. Markdown-Szenario-Dateien unter qa/scenarios/ definieren den Testlauf; qa-lab stellt die wiederverwendbare Laufzeitumgebung bereit, die sie ausführt.

Anleitungen für Maintainer zur Einführung neuer Kanal-Adapter findest du unter Testing.

Reporting

qa-lab exportiert einen Markdown-Protokollbericht aus der beobachteten Bus-Timeline. Der Bericht sollte beantworten:

1. Was hat funktioniert?
2. Was ist fehlgeschlagen?
3. Was blieb blockiert?
4. Welche Folge-Szenarien sind sinnvoll?

Für Charakter- und Stil-Prüfungen führe dasselbe Szenario über mehrere Live-Modell-Refs aus und schreibe einen bewerteten Markdown-Bericht:

pnpm openclaw qa character-eval \
  --model openai/gpt-5.4,thinking=xhigh \
  --model openai/gpt-5.2,thinking=xhigh \
  --model openai/gpt-5,thinking=xhigh \
  --model anthropic/claude-opus-4-6,thinking=high \
  --model anthropic/claude-sonnet-4-6,thinking=high \
  --model zai/glm-5.1,thinking=high \
  --model moonshot/kimi-k2.5,thinking=high \
  --model google/gemini-3.1-pro-preview,thinking=high \
  --judge-model openai/gpt-5.4,thinking=xhigh,fast \
  --judge-model anthropic/claude-opus-4-6,thinking=high \
  --blind-judge-models \
  --concurrency 16 \
  --judge-concurrency 16

Der Befehl führt lokale QA Gateway-Child-Prozesse aus, nicht Docker. Charakter-Eval-Szenarien sollten die Persona über SOUL.md festlegen und dann normale Benutzer-Turns wie Chat, Workspace-Hilfe und kleine Datei-Aufgaben ausführen. Dem Kandidaten-Modell sollte nicht gesagt werden, dass es bewertet wird. Der Befehl bewahrt jedes vollständige Transkript, zeichnet grundlegende Laufstatistiken auf und bittet dann die Judge-Modelle im Fast-Modus mit xhigh Reasoning, die Läufe nach Natürlichkeit, Vibe und Humor zu bewerten. Verwende --blind-judge-models beim Vergleich von Providern: Der Judge-Prompt erhält immer noch jedes Transkript und jeden Laufstatus, aber Kandidaten-Refs werden durch neutrale Labels wie candidate-01 ersetzt; der Bericht ordnet die Rankings nach dem Parsen wieder den echten Refs zu. Kandidaten-Läufe verwenden standardmäßig high Thinking, mit xhigh für OpenAI-Modelle, die dies unterstützen. Überschreibe einen spezifischen Kandidaten inline mit --model provider/model,thinking=<level>. --thinking <level> setzt immer noch einen globalen Fallback, und die ältere --model-thinking <provider/model=level> Form bleibt aus Kompatibilitätsgründen erhalten. OpenAI-Kandidaten-Refs verwenden standardmäßig den Fast-Modus, sodass die Prioritätsverarbeitung genutzt wird, wo der Provider dies unterstützt. Füge ,fast, ,no-fast oder ,fast=false inline hinzu, wenn ein einzelner Kandidat oder Judge eine Überschreibung benötigt. Übergebe --fast nur, wenn du den Fast-Modus für jedes Kandidaten-Modell erzwingen möchtest. Kandidaten- und Judge-Dauern werden im Bericht für Benchmark-Analysen aufgezeichnet, aber Judge-Prompts weisen explizit darauf hin, nicht nach Geschwindigkeit zu bewerten. Kandidaten- und Judge-Modell-Läufe verwenden standardmäßig eine Parallelität von 16. Verringere --concurrency oder --judge-concurrency, wenn Provider-Limits oder lokaler Gateway-Druck einen Lauf zu fehleranfällig machen. Wenn kein Kandidaten---model übergeben wird, verwendet das Character-Eval standardmäßig openai/gpt-5.4, openai/gpt-5.2, openai/gpt-5, anthropic/claude-opus-4-6, anthropic/claude-sonnet-4-6, zai/glm-5.1, moonshot/kimi-k2.5 und google/gemini-3.1-pro-preview. Wenn kein --judge-model übergeben wird, verwenden die Judges standardmäßig openai/gpt-5.4,thinking=xhigh,fast und anthropic/claude-opus-4-6,thinking=high.

Verwandte Dokumentation

1. Testing
2. QA Channel
3. Dashboard

Brauchst du weitere Hilfe bei der Einrichtung? Schau beim AI Setup Assistant vorbei.