Cada pantalla del Studio, y lo que hace.

Cómo se ven los archivos

Cada prueba que el Studio escribe o importa es código de un framework que tu equipo ya conoce. El motor añade evidencia, telemetría, veredictos y self-healing a su alrededor; no lo reemplaza.

• Playwright, JavaScript y TypeScript: un archivo de Playwright Test. El import del fixture al inicio es el del Studio; el cuerpo es page, locators y expect.
• Playwright, Python: pytest-playwright a secas, una función test_ que recibe page. Corre solo con pytest.
• Selenium, Python: pytest con un fixture driver. El conftest.py del workspace recurre a un WebDriver simple cuando el motor no es quien lo ejecuta.
• Selenium, JavaScript: código de selenium-webdriver dentro de run({ driver, By, until }). El runner del Studio crea y cierra el driver.
• Las pruebas de API usan el formato JavaScript propio del Studio.

Cómo salir

Tus pruebas, tu evidencia y tu historial son archivos en tu workspace. Para ejecutar la suite sin Nexus: las pruebas de Python corren tal cual, los imports de Playwright en JavaScript vuelven a apuntar a @playwright/test (un checkpoint visual, si añadiste alguno, hay que reemplazarlo), y las funciones run() de Selenium en JavaScript necesitan unas líneas que inicien un driver. Las pruebas de API habría que reescribirlas para otro runner.

Patrol

Donde se escriben, ejecutan y programan las pruebas. El árbol muestra cada prueba con un logo por navegador, coloreado según su estado, y la franja de ejecución sobre el editor dice con palabras qué está haciendo cada navegador.

• Cinco pestañas: Test cases, Run patrol, Nexus Recorder, AI writer y Test Adapter.
• Objetivos: Desktop matrix (Chromium, Firefox y WebKit), Mobile emulated, Real device (un teléfono Android real), o Desktop + real device para la PC y un teléfono Android a la vez, con la evidencia archivada por identidad.
• Un navegador tras otro por defecto, o hasta tres a la vez y varias pruebas a la vez cuando lo configuras. Selenium corre en Chromium y Firefox.
• Las pruebas nuevas ensayan en el sandbox, que no escribe historial, antes de que sus ejecuciones empiecen a contar.
• Feature flags: cada flag corre activado, desactivado o ambos, enviado por cookie, encabezado, almacenamiento local o query string, y la tarjeta nombra la combinación con la que falla una prueba.

Nexus Recorder

Registra lo que haces en el navegador como código de prueba. No hay IA de por medio: lo que haces clic es lo que se escribe.

• Graba para Desktop, Mobile emulated o un Real device: un teléfono Android por USB, manejando el Chrome del propio teléfono.
• Escribe Playwright en JavaScript, TypeScript o Python, o Selenium en JavaScript o Python.
• O registra las llamadas de API que hace la página como pruebas REST o GraphQL, sin encabezados de autenticación ni de cookies, y con los campos que parecen secretos convertidos en variables de entorno.
• Los Selector Maps escanean una página sin IA, califican cada selector HIGH, MEDIUM o LOW, y guardan el mapa en tu disco.

Test Adapter

Trae al Studio las pruebas que tu equipo ya tiene, sin reescribirlas a mano.

• Pega una prueba, suelta un archivo o apunta a una carpeta: Playwright o Selenium en JavaScript, TypeScript o Python, bajo Playwright Test, mocha, jest, pytest o unittest.
• Reescribe por reglas, no con IA: el lanzamiento del navegador y la configuración pasan al fixture del Studio, mientras las aserciones, condiciones, bucles y esperas quedan como estaban.
• Muestra el diff lado a lado y el conteo de aserciones antes y después. Una aserción perdida bloquea la importación a menos que la aceptes, línea por línea.
• Una IA opcional atiende solo lo que ninguna regla cubre, y su código enfrenta al Vet estricto. Las pruebas conservadas ensayan en el sandbox hasta tres ejecuciones limpias.
• Cypress, WebdriverIO, Robot Framework, Java y C# no están soportados.

Repair line y self-healing

Lo que pasa cuando se rompe un locator. Nada se repara a tus espaldas.

• Self-healing, en Suggest por defecto: tras una falla, un navegador en segundo plano repite la prueba hasta la línea fallida y lee la página, así que los candidatos quedan listos. Sin IA, y la prueba sigue en rojo.
• Repair line, desde el margen de esa línea: vuelve a grabar solo ese paso, o cambia el selector, el más fuerte primero y XPath al final. El cambio llega al editor sin guardar, y guardarlo es tu aprobación.
• Ask my AI which one puede reordenar los candidatos, nunca añadir uno. La versión anterior del archivo se queda en su línea de tiempo.
• Locator health lista los locators débiles de la prueba abierta y los repara de la misma manera.

Devices & Mobile

Teléfonos Android reales, conectados por USB a la máquina que corre el motor. Sin granja de dispositivos, sin minutos que comprar.

• Varios teléfonos a la vez, por adb y el Chrome DevTools Protocol, con una guía para conectar el primero.
• Watch screen refleja un teléfono en tu PC: se controla desde esta pantalla, y es solo de visualización cuando se abre desde Patrol.
• Emulación móvil, a partir de los perfiles de dispositivo de Playwright: Chrome en Android, Safari en un iPhone emulado mediante WebKit, y un perfil de gama baja. Los dispositivos reales son solo teléfonos Android; un iPhone siempre es emulado.
• Las pruebas en un teléfono corren de una en una, y una ejecución en teléfono siempre se queda en la máquina a la que está conectado el teléfono.

Watch

En Patrol, bajo Run patrol: vuelve a ejecutar una selección con un temporizador, sin supervisión.

• Repeat cada 5 minutos a 24 horas, u Once, on a date. Termina cuando lo detienes, tras un número de ejecuciones, o en una fecha.
• Corre como su propio proceso, así que cerrar el Studio no lo detiene. Necesita esa máquina encendida: mientras duerme, las ejecuciones programadas esperan o se omiten.
• Avisa por Telegram o Slack solo cuando cambia un estado, como ALERT o RECOVERED.

Docker y SSH

El Studio es una app de escritorio para Windows 11, en tu PC o, opcionalmente, en una mini PC con Windows 11. Desde ahí, el motor ejecuta las suites de un espacio de trabajo en esta máquina, en Docker sobre ella, o por SSH en otra máquina. El Studio en sí nunca corre en Docker ni por SSH.

• En Docker, la suite corre en el contenedor runner sobre el mismo disco, así que la evidencia llega a tu workspace como siempre.
• Por SSH, en un VPS con Ubuntu 24.04 LTS, Docker Engine y Compose v2, al que se llega con acceso por clave: el motor ejecuta ahí la suite en la misma imagen de contenedor que Docker aquí, y la evidencia se queda ahí hasta que la descargues.
• Los teléfonos Android reales, las suites de Selenium y Python, el caos de infraestructura y la importación de resultados siempre corren en la máquina del propio Studio.
• La barra superior muestra dónde corre el workspace y su RAM y CPU. El ritmo adaptativo, cuando lo activas, ajusta los navegadores simultáneos a la RAM libre.

Pruebas de API

Pruebas REST y GraphQL con siete veredictos propios. Se ejecutan desde Patrol como cualquier prueba, y cada endpoint archiva su propia carpeta en la sección API testing del Evidence Locker.

• API_SECURE: todas las aserciones se cumplieron y la forma de la respuesta coincide con la última registrada. API_FLAKY: pasó en un reintento. API_DRIFTED: pasó, pero la forma cambió, y el diff nombra cada campo añadido, quitado o con el tipo cambiado. Una deriva cuenta como aprobada hasta que la hagas estricta.
• API_BREACHED: falló una aserción. API_DEGRADED: más lento que el presupuesto de latencia, 2000 ms por defecto, y solo es un veredicto cuando el rendimiento es estricto. API_VULNERABLE: una solicitud sin credenciales recibió respuesta donde se esperaba un 401 o un 403; un encabezado de seguridad ausente, por sí solo, nunca produce este veredicto. API_BLOCKED: un 429, o un 403 con firma de Cloudflare o Akamai, de modo que la solicitud nunca llegó a tu producto.
• En pantalla: tarjetas de endpoints, passing, runs over the budget, shape changed, vulnerable ever y slowest observed; los filtros all, failed, drifted y vulnerable; y una tabla con endpoint, verdict, min, median, p95, max, n y pass rate. Un endpoint con menos de 20 observaciones muestra un guion, no un percentil.
• Haz clic en una ejecución para abrirla en seis pestañas: Report, Request, Response, Performance, Schema y AI Analysis, la última completada con tu IA conectada. Un paso fallido de un flujo ofrece Re-run from step N y Re-run failed step.
• Se archiva por ejecución en api-evidence: request.json, response.json, performance.json, schema.json, report.md y metadata.json, con los secretos enmascarados en encabezados y cuerpo. report.md termina con un comando curl que repite la llamada. Las ejecuciones que pasan conservan las 20 más recientes por prueba; las fallas se conservan siempre.
• API Flow Recorder: en el Nexus Recorder, graba las llamadas que hace la página y luego Review the recording before the suite is written. Calls lista cada una con su método, ruta, estado, categoría y el motivo. Solo las llamadas de API de negocio, de autenticación, de lectura y las que cambian el estado entran de inicio en la suite; los beacons de telemetría, los hosts de terceros, los recursos estáticos y los preflights quedan fuera, y puedes marcarlos para incluirlos. Flows encadenan un valor de una respuesta a una solicitud posterior, como un token de inicio de sesión, y Redactions lista los campos con aspecto de secreto marcados como nunca escritos.
• Desde la revisión: Generate test escribe la suite, Generate OpenAPI escribe un borrador 3.1 con tipos y códigos de estado y sin valores grabados, y Load test abre las llamadas como un plan de Load.

History

Cada prueba en cada identidad, ejecución tras ejecución.

• Pestañas para el resumen, la fiabilidad, el rendimiento, la API, las fallas, la cobertura, la calidad y los resultados de pruebas unitarias y de integración.
• Tendencias por sesión, día o semana: Regressed, Recovered, Still broken, Slower. La matriz de identidades enfrenta cada prueba con cada navegador y dispositivo.
• Unitarias e integración: importa XML JUnit de Jest, Vitest, pytest, Maven o gotestsum, separado de los números de extremo a extremo.
• Riesgo, en el Evidence Locker y en Patrol: un ranking por qué tan seguido una prueba cambia de estado, se rompe o cuesta tiempo, donde nada se llama flaky por debajo de cinco ejecuciones, y un riesgo predicho con una regresión logística sobre tu historial, con un respaldo EWMA cuando hay pocos datos.

Lo que contiene una fila de History →

Visual Regression

Comparación de píxeles contra las imágenes que aprobaste. La primera ejecución con --visual establece la línea base y cada ejecución posterior se compara con ella. La pantalla se abre en lo que necesita una decisión: Pixels moved.

• Cada regresión es una tarjeta: la prueba, el checkpoint, la proporción de píxeles que cambiaron frente a su tolerancia, "N of M px", las dimensiones, cuántas áreas cambiaron y una nota cuando la captura nunca se estabilizó. Los píxeles de borde remezclados por el anti-aliasing no se cuentan.
• Vistas Side by side, Swipe, Diff y Blink, y las earlier runs del mismo checkpoint: una regresión es un hecho, cuatro seguidas cada una un poco peor son una interfaz que se va desviando, y cuatro idénticas son una prueba grabada contra algo inestable.
• Las líneas base se guardan por navegador y plataforma. Approve this change reemplaza solo la imagen de ese checkpoint; Approve all es para un cambio que afecta a muchos, como un encabezado global.
• Ajustes en la misma pantalla, con sus valores por defecto: Compare pixels on every run desactivado, Full-page tolerance 1.0%, Element checkpoint tolerance 0.1%, A regression fails the test desactivado (la regresión se registra y la prueba sigue en SECURE; activado, da BREACHED), y Masked on every photo (CSS selectors) para un reloj o un anuncio.
• Se archiva por regresión en visual-regression: baseline.png, current.png, diff.png (rojo lo que cambió, ámbar el anti-aliasing ignorado, gris lo que no cambió), visual-report.md y result.json, los 10 más recientes por prueba y checkpoint, a unos 1 MB por juego.

Executive Report

La calidad de un release en un solo PDF, para quien lo firma.

• Elige un periodo: todo el tiempo, los últimos 7, 30 o 90 días, o un rango personalizado.
• Una decisión de release de go, caution o no-go, con confianza, cobertura y tasa de aprobación.
• Fallas con su causa raíz e impacto en el negocio, estabilidad por prueba, hallazgos de seguridad, pruebas de API y la pirámide de calidad de resultados de extremo a extremo, integración y unitarios.
• Las recomendaciones salen de reglas, no de una IA.

Chaos Lab

Pruebas de resiliencia, del navegador al contenedor.

• Fallas del navegador: latencia de Network (≈3G), un Offline blackout en plena prueba, un CPU throttle 4x en Chromium, o todo a la vez, con pérdida de paquetes y presión de memoria encima.
• Infraestructura: registra un contenedor Docker, o la app bajo prueba, y luego páusalo, deténlo, termínalo o reinícialo, con o sin una prueba corriendo contra él.
• La recuperación se mide con una sonda de salud cada 500 ms: tiempo de detección, tiempo de recuperación, disponibilidad. El resultado dice RESILIENT, DEGRADED, NOT_RECOVERED o NOT_INJECTED.
• Solo objetivos registrados, nunca los contenedores del propio Studio. La falla se anota antes de dispararse y siempre se restaura, y un aprobado en el que no se disparó ninguna falla nunca se llama resiliente.

Load

Concurrencia, percentiles y un veredicto, del propio motor.

• Worker threads en el motor, sin herramienta de carga externa, y un reporte con el esquema statistics.json de Apache JMeter.
• Solicitudes por segundo, p50, p90, p95 y p99, tasa de errores y APDEX. El veredicto es PASS, OVER_BUDGET o UNMEASURED.
• Measure Web Vitals under load: una página real de Chromium muestreada antes, cada 15 segundos durante y después de la carga, para LCP, CLS, FCP, TTFB y TBT.
• Solo se arma después de que escribes AUTHORIZED, y un objetivo que no es esta máquina vuelve a preguntar.

Security

Ejecuta las verificaciones de seguridad que configuras y registra lo que encontró, con la evidencia. Smart Monkey, el escáner DAST, está en la pantalla Security, en Run a scan.

• Smart Monkey escanea un objetivo que tienes autorización para probar: XSS, inyección SQL, control de acceso roto, IDOR, SSRF, inyección de comandos, path traversal, inyección de plantillas, XXE, redirecciones abiertas, CORS, encabezados de seguridad, flags de cookies y secretos JWT débiles, entre otros.
• Elige una phase o ejecútalas todas: pre-auth, auth-transit, post-auth, http-probes (cookies, CORS, encabezados, JWT, redirecciones, archivos), ssrf, cmdi, xss-oob, sqli (ciega, booleana y basada en tiempo), idor, o agent (descubrimiento orquestado y con presupuesto). Una línea en lenguaje sencillo explica la que elegiste.
• La confirmación fuera de banda usa un listener HTTP en tu propia máquina: cada payload lleva un token aleatorio de 32 caracteres, y SSRF, inyección de comandos y XSS ciego cuentan solo cuando el objetivo hace el callback con ese token. No hay callback por DNS ni un servicio público como Interactsh o Burp Collaborator, así que nada sobre tu objetivo va a un tercero.
• Authorization to test: un host sin un fundamento registrado se rechaza antes de enviar un solo paquete, y las direcciones privadas y locales pasan sin él. Cada escaneo registra su autorización, operador, objetivo, operación y una ventana de 60 minutos, sellados localmente y nunca enviados a ningún lado.
• Cada sesión archiva una carpeta por hallazgo con audit_report.json, screenshot.png, replay.webm cuando la grabación sobrevivió, y un replay.mjs ejecutable que nexus replay corre contra la carpeta del hallazgo. La raíz de la sesión añade session_summary.json y results.sarif. Se conservan las 10 sesiones más recientes.
• SARIF 2.1.0, un resultado por hallazgo: la regla es el CWE del hallazgo, CRITICAL y HIGH se leen como error, MEDIUM como warning, el resto como note, y la ubicación es la URL sondeada. GitHub code scanning y GitLab lo ingieren directamente, y nexus monkey lo escribe en un runner de CI sin el Studio.

Verificaciones de calidad dentro de una ejecución

Se activan por ejecución en Run patrol o en Settings. Cada una es solo informativa hasta que la haces estricta, y entonces se vuelve un veredicto.

• Accesibilidad con axe-core contra WCAG 2.1 AA, más el tamaño de los objetivos táctiles en teléfonos.
• Web Vitals contra presupuestos (LCP 2.5 s, CLS 0.1, INP 200 ms, TTFB 800 ms), y una auditoría de lazy loading que califica de A a F cómo carga la página sus imágenes.
• Detección de bloqueos: un 403, un 429 o una página de desafío se lee como BLOCKED. Las señales de automatización se ocultan del sitio por defecto, y un interruptor lo desactiva.
• El modo estricto convierte una falla en A11Y_VIOLATION, PERFORMANCE_DEGRADED o SECURITY_VIOLATION.

Timeouts

Cuánto puede esperar un paso de Playwright antes de que la ejecución diga TIMEOUT. Cuatro diales en Settings, en Execution & Timeouts. Los valores de abajo son los predeterminados.

AI Providers

La IA detrás del análisis forense de las fallas y del triage de los hallazgos de Smart Monkey.

• Local only es el valor por defecto: un modelo en esta máquina mediante Ollama, sin respaldo en la nube.
• Auto, Anthropic u OpenAI cuando lo eliges, y la pantalla dice claramente cuándo los prompts salen de tu red. Las claves son de solo escritura.

Settings

Los interruptores detrás de las demás pantallas, en un solo lugar.

• Integraciones: Telegram, Jira y Slack. Apagadas hasta que las activas; entonces Jira archiva una falla (BREACHED, BREACHED_FLAKY o CHAOS_BREACHED) o un TIMEOUT, nunca un bloqueo, un crash, un sitio inalcanzable ni un error de configuración.
• Evidencia y retención: cuántos reportes de bugs, capturas de pruebas aprobadas y sesiones de escaneo conserva cada prueba.
• Selectores y self-healing, ritmo adaptativo según la presión de RAM, y las señales de automatización que muestra el navegador.