openclaw-qa-testing

OpenClaw QA Testing

Verwende dieses Skill für qa-lab / qa-channel-Arbeiten. Nur Repository-lokale QA.

Zuerst lesen

• docs/concepts/qa-e2e-automation.md
• docs/help/testing.md
• docs/channels/qa-channel.md
• qa/README.md
• qa/scenarios/index.yaml
• extensions/qa-lab/src/suite.ts
• extensions/qa-lab/src/character-eval.ts

Modellrichtlinie

• Normale Live-Suite-Läufe basieren auf den QA-Lab-Quellen- und Auth-bewussten Standardwerten.
• Übergib --model, --alt-model oder --fast nicht standardmäßig. Ein weggelassenes --fast bedeutet nicht, dass fast deaktiviert ist; das Fast-Verhalten ist quellenabhängig.
• Bei szenariospezifischen Läufen ist die vollständige execution.summary maßgeblich und überschreibt die generischen Standardvorgaben, auch wenn sie andere Flags erfordert. Füge explizite Provider/Model-Pins nur hinzu, wenn execution.config.requiredProvider oder requiredModel diese erfordert.

Standard-Workflow

1. Lese das Szenario-Paket und die aktuelle Suite-Implementierung.
2. Entscheide die Lane:
   • mock/dev: mock-openai
   • echte Validierung: live-frontier
3. Für eine normale Live-Suite verwende:

pnpm openclaw qa suite \
  --provider-mode live-frontier \
  --output-dir .artifacts/qa-e2e/run-all-live-frontier-<tag>

4. Überwache die Ausgaben:
   • Zusammenfassung: .artifacts/qa-e2e/run-all-live-frontier-<tag>/qa-suite-summary.json
   • Bericht: .artifacts/qa-e2e/run-all-live-frontier-<tag>/qa-suite-report.md
5. Wenn der Benutzer die Live-UI sehen möchte, suche den aktuellen openclaw-qa-Listen-Port und melde http://127.0.0.1:<port>.
6. Wenn ein Szenario fehlschlägt, behebe die Grundursache im Produkt oder im Harness und führe die gesamte Lane erneut aus.

OTEL Smoke

Für die lokale QA-Lab-OpenTelemetry-Validierung verwende:

pnpm qa:otel:smoke

Dies startet einen lokalen OTLP/HTTP-Trace-Empfänger, führt das otel-trace-smoke-Szenario über qa-channel aus, dekodiert die emittierten Protobuf-Spans und überprüft die exportierten Trace-Namen und den Datenschutzvertrag. Es erfordert kein Opik, Langfuse oder externe Collector-Anmeldeinformationen.

QA-Anmeldeinformationen und 1Password

• Verwende op nur innerhalb von tmux für QA-Secret-Lookups in diesem Repository.
• Schnelle Auth-Prüfung innerhalb von tmux:

op account list

• Löse genehmigte 1Password-Element- und Feldreferenzen auf für:
  • OPENCLAW_QA_CONVEX_SITE_URL
  • OPENCLAW_QA_CONVEX_SECRET_MAINTAINER für die Maintainer-Rolle
  • OPENCLAW_QA_CONVEX_SECRET_CI für die CI-Rolle
• Wenn eine erforderliche Referenz fehlt oder veraltet ist, frage den Maintainer/Operator nach der aktuellen Element- und Feldreferenz. Frage nicht nach Secret-Werten im Chat und kopiere sie nicht in Logs oder Beweisartefakte.
• Die npm Telegram Docker Lane erfordert Convex-Credential-Leasing. Der Lease stellt den Test Server SUT Bot, die QA-Benutzerautorisierung und die Testgruppen-Metadaten bereit, die durch den Telegram E2E Userbot definiert sind. Direkte Telegram-Token-Variablen ersetzen nicht die erforderliche Convex-Konfiguration.
• Lade die genehmigte Site-URL und das rollenspezifische Secret über die genehmigte Secret-Quelle in die Umgebung des Befehls ein. Der Preflight erfordert die Site-URL und das passende Rollen-Secret vor dem Docker-Lauf.
• Mit geladener Maintainer-Konfiguration führe aus:

OPENCLAW_NPM_TELEGRAM_CREDENTIAL_SOURCE=convex \
OPENCLAW_NPM_TELEGRAM_CREDENTIAL_ROLE=maintainer \
OPENCLAW_NPM_TELEGRAM_PROVIDER_MODE=mock-openai \
OPENCLAW_NPM_TELEGRAM_PACKAGE_SPEC="openclaw@beta" \
pnpm test:docker:npm-telegram-live

• scripts/e2e/npm-telegram-live-runner.ts liest OPENCLAW_NPM_TELEGRAM_PROVIDER_MODE, nicht OPENCLAW_QA_PROVIDER_MODE.
• Für autorisierten gehosteten Proof verwende die vorhandene manuelle Lane, wenn deren qa-live-shared-Umgebung eine gültige Convex CI-Konfiguration hat. Ein Dispatch stellt keine Credentials bereit und umgeht keine Credential-Verweigerung.

ghx workflow run "NPM Telegram Beta E2E" --repo openclaw/openclaw --ref main \
  -f [email protected] \
  -f [email protected] \
  -f provider_mode=mock-openai

• Rufe die genaue Run-ID aus der Dispatch-URL ab. gh run view --json artifacts wird nicht unterstützt; liste Artefakte auf mit:

gh api repos/openclaw/openclaw/actions/runs/<run-id>/artifacts

WhatsApp Live Credentials

Verwende dies beim Einrichten oder Ersetzen von Convex kind=whatsapp-Credentials.

• Behandle WhatsApp-QA-Credentials als operator-eigene Live-Konten, nicht als generierte Fixtures.
• Verwende zwei dedizierte WhatsApp-fähige Testnummern: ein Fahrer-Konto und ein SUT-Konto. Verwende keine persönlichen Nummern oder persönlichen OpenClaw-WhatsApp-Konten aus dem gemeinsamen Pool.
• Registriere und verknüpfe jedes Konto manuell mit WhatsApp oder WhatsApp Business und speichere Web-Auth nur in isolierten lokalen Auth-Verzeichnissen außerhalb des Repositorys.
• Für Gruppenabdeckung erstelle eine dedizierte Testgruppe, die beide QA-Konten enthält, und speichere deren JID als groupJid; andernfalls sollte das Gruppen-Mentions-Gating-Szenario standardmäßig übersprungen werden und fehlschlagen, wenn es explizit angefordert wird.
• Verpacke die beiden Baileys-Auth-Verzeichnisse in Base64-.tgz-Payload-Felder und füge eine neue aktive Convex-Credential-Zeile hinzu. Bevorzuge das Hinzufügen einer neuen Zeile und das Deaktivieren veralteter/defekter Zeilen gegenüber dem Überschreiben von Credentials an Ort und Stelle.
• Erwartete Payload-Felder: driverPhoneE164, sutPhoneE164, driverAuthArchiveBase64, sutAuthArchiveBase64 und optional groupJid.
• Halte Credential-Material aus dem Repository, Logs, PRs und Screenshots fern. Redigiere Telefonnummern, es sei denn, der Operator fragt explizit nach lokalem Debugging.
• Validiere mit pnpm openclaw qa whatsapp --credential-source convex --credential-role maintainer --provider-mode mock-openai und bewahre Artefaktpfade sowie redigierte Bestehen/Fehlschlagen-Zusammenfassungen auf.
• Wenn WhatsApp eine verknüpfte Web-Sitzung ablaufen lässt oder ungültig macht, verknüpfe sie lokal neu, verpacke frische Auth-Archive, füge eine neue Convex-Zeile hinzu und deaktiviere dann die veraltete Zeile.

Character Evals

Verwende qa character-eval für Stil/Persona/Vibe-Prüfungen über mehrere Live-Modelle hinweg.

pnpm openclaw qa character-eval \
  --output-dir .artifacts/qa-e2e/character-eval-<tag>

• Führt lokale QA-Gateway-Unterprozesse aus, kein Docker.
• Das gepackte pnpm build lässt QA Lab + qa-channel absichtlich aus (nur Source-Checkout). Um openclaw qa/qa-channel aus einem gebauten Dist zu verwenden, baue mit OPENCLAW_BUILD_PRIVATE_QA=1 pnpm build (erzeugt dist/plugin-sdk/qa-lab.js, qa-runtime.js, dist/extensions/{qa-lab,qa-channel}) oder führe via pnpm dev aus.
• Ohne Modellflags verwendet Character Eval seine aktuellen quellendefinierten Standardwerte für Kandidat, Judge, Thinking und Fast.
• Wiederhole --model provider/model,thinking=<level>[,fast|,no-fast|,fast=<bool>] oder --judge-model ... nur, um das entsprechende Inventar explizit zu ersetzen.
• Füge keine neuen Beispiele mit separatem --model-thinking hinzu; behalte dieses Flag nur für Legacy-Kompatibilität.
• Der Bericht enthält Judge-Ranking, Laufstatistiken, Laufzeiten und vollständige Transkripte; füge keine rohen Judge-Antworten hinzu. Die Laufzeit ist Benchmark-Kontext, kein Bewertungssignal.
• Kandidaten- und Judge-Concurrency ist standardmäßig 16. Verwende --concurrency <n> und --judge-concurrency <n> zum Überschreiben, wenn lokale Gateways oder Provider-Limits eine sanftere Lane benötigen.
• Die Szenario-Quelle ist nur YAML unter qa/scenarios/: verwende index.yaml und szenariospezifische *.yaml-Dateien mit den Top-Level-Feldern title, scenario und optional flow. Füge niemals eingerahmte qa-scenario / qa-flow Markdown-Dateien hinzu.
• Für isolierte Character/Persona-Evals schreibe die Persona in SOUL.md und leere IDENTITY.md im Szenario-Flow. Verwende SOUL.md + IDENTITY.md nur, wenn du absichtlich testen möchtest, wie die normale OpenClaw-Identität mit dem Charakter kombiniert wird.
• Halte Prompts natürlich und aufgabenorientiert. Das Kandidaten-Modell soll Charakter-Setup über SOUL.md erhalten, dann normale Benutzer-Interaktionen wie Chat, Workspace-Hilfe und kleine Dateiaufgaben; frage nicht „wie würdest du reagieren?“ und sage dem Modell nicht, dass es in einem Eval ist.
• Bevorzuge mindestens eine echte Aufgabe, z.B. das Erstellen oder Bearbeiten eines kleinen Workspace-Artefakts, damit das Transkript den Charakter unter normaler Tool-Nutzung zeigt, statt reinem Rollenspiel.

Codex CLI Modell-Lane

Verwende Modell-Referenzen in der Form codex-cli/<codex-model>, wenn QA Codex als Modell-Backend testen soll.

Beispiele:

pnpm openclaw qa suite \
  --provider-mode live-frontier \
  --model codex-cli/<codex-model> \
  --alt-model codex-cli/<codex-model> \
  --scenario <scenario-id> \
  --output-dir .artifacts/qa-e2e/codex-<tag>

pnpm openclaw qa manual \
  --model codex-cli/<codex-model> \
  --message "Reply exactly: CODEX_OK"

• Behandle den konkreten Codex-Modellnamen als Benutzer-/Konfigurationseingabe; hardcore ihn nicht im Quellcode, in Dokumentationsbeispielen oder Szenarien.
• Live QA bewahrt CODEX_HOME, sodass Codex CLI Auth/Konfiguration funktioniert, während HOME und OPENCLAW_HOME in einer Sandbox bleiben.
• Mock QA sollte CODEX_HOME bereinigen.
• Wenn Codex bei jeder Runde Fallback/Auth-Text zurückgibt, überprüfe zuerst CODEX_HOME, relevante Secret-basierte Auth und Gateway-Kind-Logs, bevor du Szenario-Assertions änderst.
• Für Modellvergleiche füge codex-cli/<codex-model> als weiteren Kandidaten in qa character-eval hinzu; der Bericht sollte es als undurchsichtigen Modellnamen kennzeichnen.

Repository-Fakten

• Seed-Szenarien befinden sich in qa/scenarios/index.yaml und qa/scenarios/<theme>/*.yaml.
• Haupt-Live-Runner: extensions/qa-lab/src/suite.ts
• QA Lab Server: extensions/qa-lab/src/lab-server.ts
• Child-Gateway-Harness: extensions/qa-lab/src/gateway-child.ts
• Synthetischer Kanal: extensions/qa-channel/

Was „erledigt“ bedeutet

• Vollständige Suite grün für die angeforderte Lane.
• Benutzer erhält:
  • Watch-URL falls zutreffend
  • Bestehen/Fehlschlagen-Zählungen
  • Artefaktpfade
  • Kurze Notiz, was behoben wurde

Häufige Fehlermuster

• Live-Timeout zu kurz:
  • Erweitere Live-Wartezeiten in extensions/qa-lab/src/suite.ts
• Discovery kann keine Repository-Dateien finden:
  • Richte Prompts auf repo/... im angelegten Workspace aus
• Subagent-Proof zu spröde:
  • Bevorzuge stabile endgültige Antwortnachweise gegenüber temporären Child-Session-Listenings
• Harness-„Rebuild“-Verzögerung:
  • Ein dreckiger Tree kann einen Pre-Run-Build auslösen; erwarte dies, bevor Ports erscheinen

Beim Hinzufügen von Szenarien

• Füge Szenario-YAML unter qa/scenarios/ hinzu oder aktualisiere es; füge keine .md-Szenariodateien oder eingerahmte YAML-Blöcke hinzu.
• Halte die Kickoff-Erwartungen in qa/scenarios/index.yaml konsistent
• Füge ausführbare Abdeckung in extensions/qa-lab/src/suite.ts hinzu
• Bevorzuge End-to-End-Assertions gegenüber reinen Mock-Prüfungen
• Speichere Ausgaben unter .artifacts/qa-e2e/