openclaw-qa-testing

Tests QA OpenClaw

Utilisez cette compétence pour le travail qa-lab / qa-channel. Tests QA locaux au dépôt uniquement.

À lire en premier

• 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

Politique de modèle

• Les exécutions normales de suite live reposent sur les paramètres par défaut de QA Lab, conscients de la source et de l'authentification.
• Ne passez pas --model, --alt-model ou --fast par défaut. L'omission de --fast ne signifie pas que fast est désactivé ; le comportement fast appartient à la source.
• Pour les exécutions spécifiques à un scénario, le execution.summary complet fait autorité et remplace les directives génériques par défaut, y compris lorsqu'il nécessite d'autres drapeaux. Ajoutez des indications explicites de fournisseur/modèle uniquement lorsque execution.config.requiredProvider ou requiredModel l'exige.

Workflow par défaut

1. Lisez le pack de scénarios et l'implémentation actuelle de la suite.
2. Décidez du pipeline :
   • mock/dev : mock-openai
   • validation réelle : live-frontier
3. Pour une suite live normale, utilisez :

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

4. Surveillez les sorties :
   • résumé : .artifacts/qa-e2e/run-all-live-frontier-<tag>/qa-suite-summary.json
   • rapport : .artifacts/qa-e2e/run-all-live-frontier-<tag>/qa-suite-report.md
5. Si l'utilisateur souhaite surveiller l'interface live, trouvez le port d'écoute actuel de openclaw-qa et signalez http://127.0.0.1:<port>.
6. Si un scénario échoue, corrigez la cause racine du produit ou du harnais, puis réexécutez le pipeline complet.

Test OTEL

Pour la validation OpenTelemetry locale de QA-lab, utilisez :

pnpm qa:otel:smoke

Cela démarre un récepteur de traces OTLP/HTTP local, exécute le scénario otel-trace-smoke via qa-channel, décode les spans protobuf émises et vérifie les noms de traces exportées et le contrat de confidentialité. Cela ne nécessite pas Opik, Langfuse, ni d'identifiants de collecteur externes.

Identifiants QA et 1Password

• Utilisez op uniquement dans tmux pour la recherche de secrets QA dans ce dépôt.
• Vérification rapide de l'authentification dans tmux :

op account list

• Les secrets live directs des tests Telegram npm se trouvent actuellement dans l'élément 1Password :
  • coffre : OpenClaw
  • élément : Telegram E2E
• Cet élément est le premier endroit à vérifier pour :
  • OPENCLAW_QA_TELEGRAM_DRIVER_BOT_TOKEN
  • OPENCLAW_QA_TELEGRAM_SUT_BOT_TOKEN
  • OPENCLAW_QA_PROVIDER_MODE
  • OPENCLAW_NPM_TELEGRAM_PACKAGE_SPEC
• Les secrets QA Convex se trouvent actuellement dans les éléments 1Password :
  • coffre : OpenClaw
  • élément : OPENCLAW_QA_CONVEX_SITE_URL
  • élément : OPENCLAW_QA_CONVEX_SECRET_MAINTAINER
  • élément : OPENCLAW_QA_CONVEX_SECRET_CI
• Éléments de notes/connexion supplémentaires consultés lors du travail sur les identifiants QA :
  • coffre : Private
  • éléments : OPENCLAW QA, Convex, Telegram
• Si une valeur requise est absente de ces notes :
  • ne devinez pas
  • demandez au mainteneur/opérateur la valeur actuelle ou le nom actuel de l'élément 1Password
  • pour les exécutions directes Telegram, OPENCLAW_QA_TELEGRAM_GROUP_ID peut être stocké séparément de Telegram E2E
  • pour les exécutions Convex, l'identifiant Telegram loué doit fournir l'ID de groupe Telegram et les tokens de bot ensemble ; n'exigez pas un OPENCLAW_QA_TELEGRAM_GROUP_ID séparé
  • pour les exécutions Convex, préférez OpenClaw/OPENCLAW_QA_CONVEX_SITE_URL ; si cela est obsolète ou peu clair, demandez l'URL du pool actif avant d'exécuter
• Préférez les variables d'environnement Telegram directes pour le pipeline Docker npm Telegram lorsqu'elles sont disponibles :

OPENCLAW_QA_TELEGRAM_GROUP_ID="..." \
OPENCLAW_QA_TELEGRAM_DRIVER_BOT_TOKEN="..." \
OPENCLAW_QA_TELEGRAM_SUT_BOT_TOKEN="..." \
OPENCLAW_QA_PROVIDER_MODE="mock-openai" \
OPENCLAW_NPM_TELEGRAM_PACKAGE_SPEC="openclaw@beta" \
pnpm test:docker:npm-telegram-live

• Préférez le mode Convex lorsque l'objectif est une infrastructure QA partagée stable :
  • location d'identifiants en round-robin
  • wrapper plus léger pour la configuration spécifique au canal
  • flux CLI/administration autour des identifiants mutualisés
• Note sur le pipeline Docker npm Telegram live :
  • scripts/e2e/npm-telegram-live-runner.ts lit OPENCLAW_NPM_TELEGRAM_PROVIDER_MODE
  • ne supposez pas que OPENCLAW_QA_PROVIDER_MODE est consommé par ce wrapper
  • si une note 1Password ne donne que OPENCLAW_QA_PROVIDER_MODE, mappez-le explicitement à OPENCLAW_NPM_TELEGRAM_PROVIDER_MODE avant d'exécuter le pipeline Docker
• Forme live vérifiée :
  • le mode Convex peut passer le pipeline Docker réel sans variables d'environnement Telegram directes
  • le payload Telegram loué inclut l'ID de groupe couplé aux tokens driver/SUT
  • une exécution réelle de pnpm test:docker:npm-telegram-live a réussi avec :
    • OPENCLAW_QA_CREDENTIAL_SOURCE=convex
    • OPENCLAW_QA_CREDENTIAL_ROLE=maintainer
    • OPENCLAW_QA_CONVEX_SITE_URL
    • OPENCLAW_QA_CONVEX_SECRET_MAINTAINER
    • OPENCLAW_NPM_TELEGRAM_PROVIDER_MODE=mock-openai
• Si la variable d'environnement Telegram directe est manquante localement et que op signin bloque, préférez déclencher le pipeline GitHub manuel car l'environnement qa-live-shared possède déjà les identifiants Convex CI :

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

• Interrogez l'ID d'exécution exact à partir de l'URL de déclenchement. gh run view --json artifacts n'est pas supporté ; listez les artefacts avec :

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

Identifiants WhatsApp live

Utilisez ceci lors de la configuration ou du remplacement d'identifiants Convex kind=whatsapp.

• Traitez les identifiants QA WhatsApp comme des comptes live appartenant à l'opérateur, et non comme des fixtures générées.
• Utilisez deux numéros de test dédiés compatibles WhatsApp : un compte driver et un compte SUT. N'utilisez pas de numéros personnels ni de comptes WhatsApp OpenClaw personnels dans le pool partagé.
• Enregistrez et liez chaque compte manuellement avec WhatsApp ou WhatsApp Business, en stockant l'authentification Web uniquement dans des répertoires d'authentification locaux isolés en dehors du dépôt.
• Pour la couverture de groupe, créez un groupe de test dédié qui inclut les deux comptes QA et stockez son JID comme groupJid ; sinon, le scénario de vérification de mention de groupe doit être ignoré par défaut et échouer lorsqu'il est explicitement demandé.
• Conditionnez les deux répertoires d'authentification Baileys dans des champs de payload .tgz encodés en base64 et ajoutez une nouvelle ligne d'identifiant Convex active. Préférez ajouter une nouvelle ligne et désactiver les lignes obsolètes/cassées plutôt que d'écraser les identifiants en place.
• Champs de payload attendus : driverPhoneE164, sutPhoneE164, driverAuthArchiveBase64, sutAuthArchiveBase64, et groupJid optionnel.
• Gardez le matériel d'identifiant en dehors du dépôt, des logs, des PR et des captures d'écran. Masquez les numéros de téléphone sauf si l'opérateur demande explicitement un débogage local.
• Validez avec pnpm openclaw qa whatsapp --credential-source convex --credential-role maintainer --provider-mode mock-openai et conservez les chemins d'artefacts ainsi que les résumés succès/échec masqués.
• Si WhatsApp expire ou invalide une session Web liée, reliez localement, conditionnez de nouvelles archives d'authentification, ajoutez une nouvelle ligne Convex, puis désactivez la ligne obsolète.

Évaluations de personnage

Utilisez qa character-eval pour les vérifications de style/persona/vibe sur plusieurs modèles live.

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

• Exécute des processus enfants de la passerelle QA locale, pas Docker.
• Le pnpm build packagé omet QA Lab + qa-channel par conception (uniquement avec checkout source). Pour utiliser openclaw qa/qa-channel à partir d'une distribution construite, construisez avec OPENCLAW_BUILD_PRIVATE_QA=1 pnpm build (émet dist/plugin-sdk/qa-lab.js, qa-runtime.js, dist/extensions/{qa-lab,qa-channel}) ou exécutez via pnpm dev.
• Sans drapeaux de modèle, l'évaluation de personnage utilise ses candidats, juge, pensée et valeurs rapides par défaut définis par la source.
• Répétez --model provider/model,thinking=<level>[,fast|,no-fast|,fast=<bool>] ou --judge-model ... uniquement pour remplacer l'inventaire correspondant explicitement.
• N'ajoutez pas de nouveaux exemples avec --model-thinking séparé ; conservez ce drapeau uniquement pour la compatibilité héritée.
• Le rapport inclut le classement du juge, les statistiques d'exécution, les durées et les transcriptions complètes ; n'incluez pas les réponses brutes du juge. La durée est un contexte de benchmark, pas un signal de notation.
• La concurrence par défaut des candidats et du juge est de 16. Utilisez --concurrency <n> et --judge-concurrency <n> pour la surcharger lorsque les passerelles locales ou les limites du fournisseur nécessitent un pipeline plus doux.
• La source du scénario est uniquement en YAML sous qa/scenarios/ : utilisez index.yaml et des fichiers *.yaml par scénario avec title, scenario, et flow optionnel au niveau supérieur. N'ajoutez jamais de fichiers Markdown délimités qa-scenario / qa-flow.
• Pour les évaluations de personnage/persona isolées, écrivez le persona dans SOUL.md et laissez IDENTITY.md vide dans le flux du scénario. Utilisez SOUL.md + IDENTITY.md uniquement lorsque vous testez intentionnellement comment l'identité normale d'OpenClaw se combine avec le personnage.
• Gardez les prompts naturels et orientés tâche. Le modèle candidat doit recevoir la configuration du personnage via SOUL.md, puis des tours utilisateur normaux comme le chat, l'aide à l'espace de travail et les petites tâches sur fichiers ; ne demandez pas « comment réagiriez-vous ? » et ne dites pas au modèle qu'il est dans une évaluation.
• Préférez au moins une tâche réelle, comme créer ou modifier un petit artefact d'espace de travail, afin que la transcription capture le personnage dans une utilisation normale des outils plutôt que du pur jeu de rôle.

Pipeline de modèle Codex CLI

Utilisez des références de modèle sous la forme codex-cli/<codex-model> lorsque la QA doit exercer Codex en tant que backend de modèle.

Exemples :

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"

• Traitez le nom concret du modèle Codex comme une entrée utilisateur/config ; ne le codez pas en dur dans la source, les exemples de documentation ou les scénarios.
• La QA live préserve CODEX_HOME afin que l'authentification/configuration de Codex CLI fonctionne tout en gardant HOME et OPENCLAW_HOME isolés dans des bacs à sable.
• La QA mock doit nettoyer CODEX_HOME.
• Si Codex renvoie un texte de repli/d'authentification à chaque tour, vérifiez d'abord CODEX_HOME, l'authentification pertinente basée sur les secrets, et les logs enfants de la passerelle avant de modifier les assertions du scénario.
• Pour la comparaison de modèles, incluez codex-cli/<codex-model> comme un autre candidat dans qa character-eval ; le rapport doit l'étiqueter comme un nom de modèle opaque.

Faits sur le dépôt

• Les scénarios de base se trouvent dans qa/scenarios/index.yaml et qa/scenarios/<theme>/*.yaml.
• Exécuteur live principal : extensions/qa-lab/src/suite.ts
• Serveur de laboratoire QA : extensions/qa-lab/src/lab-server.ts
• Harnais passerelle enfant : extensions/qa-lab/src/gateway-child.ts
• Canal synthétique : extensions/qa-channel/

À quoi ressemble « terminé »

• Suite complète verte pour le pipeline demandé.
• L'utilisateur obtient :
  • URL de surveillance si applicable
  • compteurs succès/échec
  • chemins d'artefacts
  • note concise sur ce qui a été corrigé

Schémas d'échec courants

• Délai d'attente live trop court :
  • élargissez les attentes live dans extensions/qa-lab/src/suite.ts
• La découverte ne trouve pas les fichiers du dépôt :
  • pointez les prompts vers repo/... dans l'espace de travail initialisé
• Preuve de sous-agent trop fragile :
  • préférez les preuves stables de la réponse finale au listage transitoire des sessions enfants
• Délai de « reconstruction » du harnais :
  • un arbre sale peut déclencher une construction pré-exécution ; attendez-vous à cela avant que les ports n'apparaissent

Lors de l'ajout de scénarios

• Ajoutez ou mettez à jour le YAML du scénario sous qa/scenarios/ ; n'ajoutez pas de fichiers .md de scénario ni de blocs YAML délimités.
• Maintenez les attentes de lancement alignées dans qa/scenarios/index.yaml
• Ajoutez une couverture exécutable dans extensions/qa-lab/src/suite.ts
• Préférez les assertions de bout en bout aux vérifications uniquement mock
• Sauvegardez les sorties sous .artifacts/qa-e2e/