Automatiza QA con OpenClaw: Guía de E2E Testing

pnpm openclaw qa matrix

pnpm openclaw qa telegram

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

A veces, probar agentes complejos se siente como intentar atrapar humo con las manos: los tests unitarios simplemente no capturan la realidad de una conversación fluida o los comportamientos erráticos de una red. Si alguna vez te has frustrado porque tu código funciona en local pero falla al interactuar con canales reales, sabes exactamente a qué me refiero.

Aquí es donde entra OpenClaw para automatizar tus pruebas de QA de extremo a extremo, permitiéndote validar el comportamiento real de tus agentes en entornos controlados.

Automatización QA E2E

El stack de QA privado está diseñado para poner a prueba OpenClaw de una manera mucho más realista y similar a un canal real de lo que podría hacer un simple test unitario.

Las piezas actuales son:

• extensions/qa-channel: un canal de mensajes sintético con superficies para DM, canales, hilos, reacciones, ediciones y eliminaciones.
• extensions/qa-lab: una interfaz de depuración y un bus de QA para observar la transcripción, inyectar mensajes entrantes y exportar un informe en JSON o Markdown.
• qa/: activos semilla respaldados por el repositorio para la tarea de inicio y escenarios de QA de referencia.

El flujo actual del operador de QA es un sitio de QA de dos paneles:

• Izquierda: Panel de control del Gateway con el agente.
• Derecha: QA Lab, que muestra la transcripción al estilo Slack y el plan de escenarios.

Ejecútalo con:

pnpm qa:lab:up

Esto construye el sitio de QA, inicia el carril del Gateway respaldado por Docker y expone la página de QA Lab, donde un operador o un bucle de automatización puede asignar una misión de QA al agente, observar el comportamiento real del canal y registrar qué funcionó, qué falló o qué quedó bloqueado.

Para una iteración más rápida de la interfaz de QA Lab sin reconstruir la imagen de Docker cada vez, inicia el stack con un bundle de QA Lab montado:

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

qa:lab:up:fast mantiene los servicios de Docker en una imagen preconstruida y monta extensions/qa-lab/web/dist en el contenedor qa-lab. qa:lab:watch reconstruye ese bundle ante cambios, y el navegador se recarga automáticamente cuando cambia el hash del activo de QA Lab.

Para un carril de prueba de humo de Matrix con transporte real, ejecuta:

1. pnpm openclaw qa matrix

Este carril aprovisiona un servidor doméstico Tuwunel desechable en Docker, registra usuarios temporales de driver, SUT y observador, crea una sala privada y luego ejecuta el plugin real de Matrix dentro de un hijo del Gateway de OpenClaw. El carril de transporte en vivo mantiene la configuración del hijo limitada al transporte bajo prueba, por lo que Matrix se ejecuta sin qa-channel en la configuración del hijo. Escribe los artefactos del informe estructurado y un registro combinado de stdout/stderr en el directorio de salida de QA de Matrix seleccionado. Para capturar también la salida del constructor/lanzador scripts/run-node.mjs externo, establece OPENCLAW_RUN_NODE_OUTPUT_LOG=<path> en un archivo de registro local del repositorio.

Para un carril de prueba de humo de Telegram con transporte real, ejecuta:

1. pnpm openclaw qa telegram

Ese carril apunta a un grupo privado real de Telegram en lugar de aprovisionar un servidor desechable. Requiere OPENCLAW_QA_TELEGRAM_GROUP_ID, OPENCLAW_QA_TELEGRAM_DRIVER_BOT_TOKEN y OPENCLAW_QA_TELEGRAM_SUT_BOT_TOKEN, además de dos bots distintos en el mismo grupo privado. El bot SUT debe tener un nombre de usuario de Telegram, y la observación bot-a-bot funciona mejor cuando ambos bots tienen habilitado el modo de comunicación Bot-to-Bot en @BotFather.

Los carriles de transporte en vivo ahora comparten un contrato más pequeño en lugar de que cada uno invente su propia forma de lista de escenarios:

qa-channel sigue siendo la suite amplia de comportamiento de producto sintético y no es parte de la matriz de cobertura de transporte en vivo.

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

Esto mantiene a qa-channel como la suite amplia de comportamiento del producto, mientras que Matrix, Telegram y futuros transportes en vivo comparten una lista de verificación de contrato de transporte explícita.

Para un carril de máquina virtual Linux desechable sin llevar Docker a la ruta de QA, ejecuta:

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

Esto inicia un invitado Multipass nuevo, instala dependencias, construye OpenClaw dentro del invitado, ejecuta qa suite, y luego copia el informe de QA normal y el resumen de vuelta a .artifacts/qa-e2e/... en el host. Reutiliza el mismo comportamiento de selección de escenarios que qa suite en el host. Las ejecuciones de suite en el host y en Multipass ejecutan múltiples escenarios seleccionados en paralelo con trabajadores del Gateway aislados de forma predeterminada, hasta 64 trabajadores o el conteo de escenarios seleccionados. Usa --concurrency <count> para ajustar el conteo de trabajadores, o --concurrency 1 para ejecución serial. Las ejecuciones en vivo reenvían las entradas de autenticación de QA admitidas que son prácticas para el invitado: claves de proveedor basadas en entorno, la ruta de configuración del proveedor en vivo de QA y CODEX_HOME cuando esté presente. Mantén --output-dir bajo la raíz del repositorio para que el invitado pueda escribir de vuelta a través del espacio de trabajo montado.

Semillas respaldadas por el repositorio

Los activos semilla residen en qa/:

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

Estos están intencionalmente en GitHub para que el plan de QA sea visible tanto para humanos como para el agente.

qa-lab debe seguir siendo un ejecutor de markdown genérico. Cada archivo markdown de escenario es la fuente de verdad para una ejecución de prueba y debe definir:

1. Metadatos del escenario
2. Referencias a documentos y código
3. Requisitos opcionales de plugins
4. Parche de configuración opcional del Gateway
5. El qa-flow ejecutable

La superficie de ejecución reutilizable que respalda qa-flow puede permanecer genérica y transversal. Por ejemplo, los escenarios en markdown pueden combinar ayudantes del lado del transporte con ayudantes del lado del navegador que controlan la interfaz de usuario de control integrada a través de la costura browser.request del Gateway sin añadir un ejecutor de casos especiales.

La lista de referencia debe ser lo suficientemente amplia para cubrir:

1. Chat de DM y canales
2. Comportamiento de hilos
3. Ciclo de vida de acciones de mensajes
4. Devoluciones de llamada cron
5. Recuperación de memoria
6. Cambio de modelo
7. Transferencia de subagentes
8. Lectura de repositorios y documentos
9. Una pequeña tarea de construcción como Lobster Invaders

Adaptadores de transporte

qa-lab posee una costura de transporte genérica para escenarios de QA en markdown. qa-channel es el primer adaptador en esa costura, pero el objetivo de diseño es más amplio: los futuros canales reales o sintéticos deberían conectarse a la misma suite de ejecución en lugar de añadir un ejecutor de QA específico para cada transporte.

A nivel de arquitectura, la división es:

1. qa-lab posee la ejecución genérica de escenarios, concurrencia de trabajadores, escritura de artefactos e informes.
2. El adaptador de transporte posee la configuración del Gateway, preparación, observación de entrada y salida, acciones de transporte y estado de transporte normalizado.
3. Los archivos de escenario markdown bajo qa/scenarios/ definen la ejecución de la prueba; qa-lab proporciona la superficie de ejecución reutilizable que los ejecuta.

La guía de adopción para mantenedores sobre nuevos adaptadores de canal se encuentra en Testing.

Informes

qa-lab exporta un informe de protocolo en Markdown desde la línea de tiempo del bus observado. El informe debe responder:

1. Qué funcionó
2. Qué falló
3. Qué quedó bloqueado
4. Qué escenarios de seguimiento vale la pena añadir

Para comprobaciones de carácter y estilo, ejecuta el mismo escenario a través de múltiples referencias de modelos en vivo y escribe un informe en Markdown:

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

El comando ejecuta procesos hijos del Gateway de QA locales, no Docker. Los escenarios de evaluación de personajes deben establecer la personalidad a través de SOUL.md, y luego ejecutar turnos de usuario ordinarios como chat, ayuda en el espacio de trabajo y tareas pequeñas de archivos. No se debe decir al modelo candidato que está siendo evaluado. El comando preserva cada transcripción completa, registra estadísticas básicas de ejecución y luego pide a los modelos jueces en modo rápido con razonamiento xhigh que clasifiquen las ejecuciones por naturalidad, vibra y humor. Usa --blind-judge-models al comparar proveedores: el prompt del juez aún recibe cada transcripción y estado de ejecución, pero las referencias de los candidatos se reemplazan con etiquetas neutrales como candidate-01; el informe mapea las clasificaciones de vuelta a las referencias reales después del análisis. Las ejecuciones de candidatos usan high thinking por defecto, con xhigh para modelos de OpenAI que lo admiten. Sobrescribe un candidato específico en línea con --model provider/model,thinking=<level> (angle brackets shown literally). --thinking <level> aún establece una alternativa global, y la forma anterior --model-thinking <provider/model=level> (angle brackets shown literally) se mantiene por compatibilidad. Las referencias de candidatos de OpenAI usan el modo rápido por defecto para que se utilice el procesamiento prioritario donde el proveedor lo admita. Añade ,fast, ,no-fast o ,fast=false en línea cuando un solo candidato o juez necesite una anulación. Pasa --fast solo cuando quieras forzar el modo rápido para cada modelo candidato. Las duraciones de los candidatos y jueces se registran en el informe para el análisis de benchmarks, pero los prompts de los jueces dicen explícitamente que no clasifiquen por velocidad. Las ejecuciones de modelos candidatos y jueces usan concurrencia 16 por defecto. Reduce --concurrency o --judge-concurrency cuando los límites del proveedor o la presión del Gateway local hagan que una ejecución sea demasiado ruidosa. Cuando no se pasa ningún --model candidato, la evaluación de personajes usa por defecto 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 y google/gemini-3.1-pro-preview. Cuando no se pasa ningún --judge-model, los jueces usan por defecto openai/gpt-5.4,thinking=xhigh,fast y anthropic/claude-opus-4-6,thinking=high.

Documentación relacionada

• Testing
• QA Channel
• Dashboard

Si necesitas ayuda adicional con la configuración de tus pruebas, consulta nuestro AI Setup Assistant.