openclaw-qa-testing

Pruebas QA de OpenClaw

Usa esta habilidad para trabajar con qa-lab / qa-channel. Solo pruebas QA locales del repositorio.

Leer primero

• 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

Política de modelo

• Las ejecuciones normales de suites en vivo dependen de los valores predeterminados de QA Lab que reconocen la fuente y la autenticación.
• No pases --model, --alt-model o --fast por defecto. Omitir --fast no significa que fast esté deshabilitado; el comportamiento fast es propiedad de la fuente.
• Para ejecuciones específicas de escenarios, el execution.summary completo es autoritativo y anula la guía genérica predeterminada, incluso cuando requiere otras banderas. Añade pines explícitos de proveedor/modelo solo cuando execution.config.requiredProvider o requiredModel lo requieran.

Flujo de trabajo predeterminado

1. Lee el paquete de escenarios y la implementación actual de la suite.
2. Decide el carril:
   • mock/dev: mock-openai
   • validación real: live-frontier
3. Para una suite en vivo normal, usa:

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

4. Observa las salidas:
   • resumen: .artifacts/qa-e2e/run-all-live-frontier-<tag>/qa-suite-summary.json
   • informe: .artifacts/qa-e2e/run-all-live-frontier-<tag>/qa-suite-report.md
5. Si el usuario quiere observar la interfaz de usuario en vivo, encuentra el puerto de escucha actual de openclaw-qa e informa http://127.0.0.1:<puerto>.
6. Si un escenario falla, corrige la causa raíz del producto o del arnés, luego vuelve a ejecutar el carril completo.

Prueba de humo OTEL

Para la validación local de OpenTelemetry en QA-lab, usa:

pnpm qa:otel:smoke

Esto inicia un receptor local de trazas OTLP/HTTP, ejecuta el escenario otel-trace-smoke a través de qa-channel, decodifica los spans protobuf emitidos y verifica los nombres de traza exportados y el contrato de privacidad. No requiere Opik, Langfuse ni credenciales de colector externo.

Credenciales QA y 1Password

• Usa op solo dentro de tmux para la búsqueda de secretos QA en este repositorio.
• Verificación rápida de autenticación dentro de tmux:

op account list

• Los secretos de prueba en vivo directa de Telegram npm actualmente residen en el elemento de 1Password:
  • bóveda: OpenClaw
  • elemento: Telegram E2E
• Ese elemento es el primer lugar para buscar:
  • OPENCLAW_QA_TELEGRAM_DRIVER_BOT_TOKEN
  • OPENCLAW_QA_TELEGRAM_SUT_BOT_TOKEN
  • OPENCLAW_QA_PROVIDER_MODE
  • OPENCLAW_NPM_TELEGRAM_PACKAGE_SPEC
• Los secretos QA de Convex actualmente residen en elementos de 1Password:
  • bóveda: OpenClaw
  • elemento: OPENCLAW_QA_CONVEX_SITE_URL
  • elemento: OPENCLAW_QA_CONVEX_SECRET_MAINTAINER
  • elemento: OPENCLAW_QA_CONVEX_SECRET_CI
• Elementos adicionales de notas/inicio de sesión relacionados vistos durante el trabajo con credenciales QA:
  • bóveda: Private
  • elementos: OPENCLAW QA, Convex, Telegram
• Si falta un valor requerido de esas notas:
  • no adivines
  • pregunta al mantenedor/operador por el valor actual o el nombre del elemento actual de 1Password
  • para ejecuciones directas de Telegram, OPENCLAW_QA_TELEGRAM_GROUP_ID puede estar almacenado por separado de Telegram E2E
  • para ejecuciones de Convex, la credencial de Telegram arrendada debe proporcionar el id del grupo de Telegram y los tokens de bot juntos; no requieras un OPENCLAW_QA_TELEGRAM_GROUP_ID separado
  • para ejecuciones de Convex, prefiere OpenClaw/OPENCLAW_QA_CONVEX_SITE_URL; si está desactualizado o no está claro, pregunta por la URL del pool activo antes de ejecutar
• Prefiere las variables de entorno directas de Telegram para el carril Docker de npm Telegram cuando estén 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

• Prefiere el modo Convex cuando el objetivo sea una infraestructura QA compartida estable:
  • arrendamiento round-robin de credenciales
  • wrapper más ligero para la configuración específica del canal
  • flujos CLI/admin alrededor de las credenciales del pool
• Nota sobre el carril Docker de npm Telegram en vivo:
  • scripts/e2e/npm-telegram-live-runner.ts lee OPENCLAW_NPM_TELEGRAM_PROVIDER_MODE
  • no asumas que OPENCLAW_QA_PROVIDER_MODE es consumido por ese wrapper
  • si una nota de 1Password solo da OPENCLAW_QA_PROVIDER_MODE, asígnalo explícitamente a OPENCLAW_NPM_TELEGRAM_PROVIDER_MODE antes de ejecutar el carril Docker
• Forma viva verificada:
  • el modo Convex puede pasar el carril Docker real sin variables de entorno directas de Telegram
  • el payload de Telegram arrendado incluye el id del grupo acoplado a los tokens de driver/SUT
  • una ejecución real de pnpm test:docker:npm-telegram-live pasó con:
    • 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 falta la variable de entorno directa de Telegram localmente y op signin bloquea, prefiere enviar el carril manual de GitHub porque el entorno qa-live-shared ya tiene credenciales CI de Convex:

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

• Consulta el id de ejecución exacto desde la URL de envío. gh run view --json artifacts no es compatible; lista los artefactos con:

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

Credenciales en vivo de WhatsApp

Usa esto al configurar o reemplazar credenciales kind=whatsapp de Convex.

• Trata las credenciales QA de WhatsApp como cuentas en vivo propiedad del operador, no como fixtures generados.
• Usa dos números de prueba dedicados con capacidad de WhatsApp: una cuenta driver y una cuenta SUT. No uses números personales ni cuentas personales de OpenClaw WhatsApp en el pool compartido.
• Registra y vincula cada cuenta manualmente con WhatsApp o WhatsApp Business, almacenando la autenticación web solo en directorios de autenticación locales aislados fuera del repositorio.
• Para cobertura de grupo, crea un grupo de prueba dedicado que incluya ambas cuentas QA y almacena su JID como groupJid; de lo contrario, el escenario de control de menciones de grupo debe omitirse por defecto y fallar cuando se solicite explícitamente.
• Empaqueta los dos directorios de autenticación de Baileys en campos de payload .tgz en base64 y agrega una nueva fila de credenciales Convex activa. Prefiere agregar una fila nueva y deshabilitar filas obsoletas/rotas en lugar de sobrescribir las credenciales existentes.
• Campos de payload esperados: driverPhoneE164, sutPhoneE164, driverAuthArchiveBase64, sutAuthArchiveBase64 y groupJid opcional.
• Mantén el material de credenciales fuera del repositorio, registros, PRs y capturas de pantalla. Redacta los números de teléfono a menos que el operador solicite explícitamente depuración local.
• Valida con pnpm openclaw qa whatsapp --credential-source convex --credential-role maintainer --provider-mode mock-openai y conserva las rutas de artefactos más los resúmenes de éxito/fallo redactados.
• Si WhatsApp caduca o invalida una sesión web vinculada, vuelve a vincular localmente, empaqueta nuevos archivos de autenticación, agrega una nueva fila de Convex y luego deshabilita la fila obsoleta.

Evaluaciones de personajes

Usa qa character-eval para comprobaciones de estilo/persona/vibra a través de múltiples modelos en vivo.

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

• Ejecuta procesos hijo de la puerta de enlace QA local, no Docker.
• El pnpm build empaquetado omite QA Lab + qa-channel por diseño (solo checkout del código fuente). Para ejercitar openclaw qa/qa-channel desde un dist construido, compila con OPENCLAW_BUILD_PRIVATE_QA=1 pnpm build (emite dist/plugin-sdk/qa-lab.js, qa-runtime.js, dist/extensions/{qa-lab,qa-channel}) o ejecuta a través de pnpm dev.
• Sin banderas de modelo, character eval usa sus valores predeterminados actuales de candidato, juez, pensamiento y fast definidos por la fuente.
• Repite --model provider/model,thinking=<level>[,fast|,no-fast|,fast=<bool>] o --judge-model ... solo para reemplazar el inventario correspondiente explícitamente.
• No agregues nuevos ejemplos con --model-thinking separado; mantén esa bandera solo como compatibilidad heredada.
• El informe incluye la clasificación del juez, estadísticas de ejecución, duraciones y transcripciones completas; no incluyas respuestas sin procesar del juez. La duración es contexto de referencia, no una señal de calificación.
• La concurrencia de candidato y juez predeterminada es 16. Usa --concurrency <n> y --judge-concurrency <n> para anular cuando las puertas de enlace locales o los límites del proveedor necesiten un carril más suave.
• La fuente de escenarios es solo YAML bajo qa/scenarios/: usa index.yaml y archivos *.yaml por escenario con title, scenario y flow opcional de nivel superior. Nunca agregues archivos Markdown con bloques qa-scenario / qa-flow.
• Para evaluaciones aisladas de personaje/persona, escribe la persona en SOUL.md y deja IDENTITY.md en blanco en el flujo del escenario. Usa SOUL.md + IDENTITY.md solo cuando pruebes intencionalmente cómo la identidad normal de OpenClaw se combina con el personaje.
• Mantén los mensajes naturales y con forma de tarea. El modelo candidato debe recibir la configuración del personaje a través de SOUL.md, luego turnos de usuario normales como chat, ayuda del espacio de trabajo y tareas pequeñas de archivos; no preguntes "¿cómo reaccionarías?" ni le digas al modelo que está en una evaluación.
• Prefiere al menos una tarea real, como crear o editar un artefacto pequeño del espacio de trabajo, para que la transcripción capture al personaje bajo uso normal de herramientas en lugar de puro juego de roles.

Carril de modelo Codex CLI

Usa referencias de modelo con la forma codex-cli/<codex-model> siempre que QA deba ejercitar Codex como backend de modelo.

Ejemplos:

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"

• Trata el nombre concreto del modelo Codex como entrada de usuario/configuración; no lo hardcodees en el código fuente, ejemplos de documentación o escenarios.
• QA en vivo conserva CODEX_HOME para que la autenticación/configuración de Codex CLI funcione mientras mantiene HOME y OPENCLAW_HOME en un entorno aislado.
• QA mock debe limpiar CODEX_HOME.
• Si Codex devuelve texto de respaldo/autenticación en cada turno, primero verifica CODEX_HOME, la autenticación respaldada por secretos relevante y los registros del proceso hijo de la puerta de enlace antes de cambiar las aserciones del escenario.
• Para comparación de modelos, incluye codex-cli/<codex-model> como otro candidato en qa character-eval; el informe debe etiquetarlo como un nombre de modelo opaco.

Hechos del repositorio

• Los escenarios semilla viven en qa/scenarios/index.yaml y qa/scenarios/<theme>/*.yaml.
• Ejecutor principal en vivo: extensions/qa-lab/src/suite.ts
• Servidor de QA lab: extensions/qa-lab/src/lab-server.ts
• Arnés de puerta de enlace hijo: extensions/qa-lab/src/gateway-child.ts
• Canal sintético: extensions/qa-channel/

Cómo se ve "terminado"

• Suite completa en verde para el carril solicitado.
• El usuario obtiene:
  • URL de observación si aplica
  • conteos de éxito/fallo
  • rutas de artefactos
  • nota concisa sobre lo que se corrigió

Patrones comunes de fallo

• Tiempo de espera en vivo demasiado corto:
  • amplía las esperas en vivo en extensions/qa-lab/src/suite.ts
• El descubrimiento no encuentra archivos del repositorio:
  • apunta los prompts a repo/... dentro del espacio de trabajo sembrado
• Prueba de subagente demasiado frágil:
  • prefiere evidencia de respuesta final estable sobre listados de sesiones hijas transitorias
• Demora de "reconstrucción" del arnés:
  • un árbol sucio puede desencadenar una compilación previa a la ejecución; espera eso antes de que aparezcan los puertos

Al agregar escenarios

• Agrega o actualiza el YAML del escenario bajo qa/scenarios/; no agregues archivos de escenario .md ni bloques YAML encerrados.
• Mantén alineadas las expectativas de inicio en qa/scenarios/index.yaml.
• Agrega cobertura ejecutable en extensions/qa-lab/src/suite.ts.
• Prefiere aserciones de extremo a extremo sobre verificaciones solo mock.
• Guarda las salidas bajo .artifacts/qa-e2e/.