Migrar
mabl
Convierte las pruebas, los flujos reutilizables y los planes de mabl en casos de prueba y planes de pruebas de Autonomy, sin modelos de elementos ni auto-heal.
Las pruebas de mabl viven en la nube de mabl. Primero expórtalas, por ejemplo como código de Playwright o como JSON, a una carpeta que tu agente de programación pueda leer. Después migra la exportación: cada prueba de mabl se convierte en un caso de prueba de Autonomy, y cada plan de mabl puede convertirse en un plan de pruebas.
Prompt
Pega esto en un agente de programación conectado al servidor MCP de Autonomy, desde dentro de la carpeta que contiene la exportación:
Migra las pruebas de mabl exportadas en esta carpeta a Autonomy con las herramientas MCP de Autonomy.
Preparación
1. Llama a autonomy_project_list y pregúntame qué proyecto usar. Llama a autonomy_environment_list con su projectId y pregúntame en qué entorno ejecutar. Los entornos y las aplicaciones de mabl corresponden a entornos de Autonomy; avísame si falta alguno.
2. Llama a autonomy_test_case_list con el projectId. Omite las pruebas que ya cubra un caso de prueba existente.
Para cada prueba
3. Crea UN caso de prueba con autonomy_test_case_create: projectId, name = el nombre de la prueba en mabl, platforms = ["web"] para las pruebas de navegador, ["api"] para las pruebas de API, ["android"] para las pruebas de Android. Las pruebas en iOS todavía no están disponibles: omite las pruebas de iOS y enuméramelas.
4. Escribe cada paso como un resultado esperado: lo que es cierto cuando el paso termina, en palabras sencillas ("Existe una cuenta nueva para un correo nuevo"). Di lo que demuestra la prueba, no cómo: sin clics, búsquedas de elementos, esperas ni pasos de aserción. Un paso puede abarcar varias acciones grabadas que sirven a un mismo resultado esperado. Usa 12 pasos o menos; divide una prueba más larga en varios casos de prueba.
5. Cada paso es {id, text, attachments[]}. Cada adjunto tiene id, kind y exact. Tipos: account {role}, inbox (sin dirección = una bandeja de entrada nueva por ejecución), phone, file, screenshot, data {label, value} o {label, intent} para datos generados.
6. Nunca escribas una contraseña, un token o una clave en un paso. Por cada cuenta con la que las pruebas inician sesión (credenciales de mabl, flujos de login), pídeme que la guarde en el panel (Sign-ins del proyecto, New sign-in) y que te diga su nombre de cuenta; después empieza la prueba con un paso como "El propietario de la tienda ha iniciado sesión" con esa cuenta adjunta. Para otras variables secretas, propón nombres y referéncialas como {{env.NAME}}; añádelas como valores secretos con autonomy_environment_upsert solo después de que yo esté de acuerdo.
7. Los valores sobre los que trata la prueba (el texto que comprueba una aserción, un cupón que debe aplicarse, una entrada que debe rechazarse): un adjunto data con exact: true. Las demás variables: {{env.NAME}}.
8. Datos de registro (correos de los buzones de mabl, nombres generados, contraseñas): una bandeja de entrada nueva y datos generados, nunca un valor fijo.
9. Integra los flujos reutilizables en los resultados esperados de las pruebas que los usan. En las pruebas dirigidas por datos, crea un caso de prueba por fila de la tabla de datos solo cuando las filas esperan resultados distintos; si no, usa datos de prueba. Si la exportación es código de Playwright, aplícale las mismas reglas.
Al terminar
10. Ofréceme crear un plan de pruebas por cada plan de mabl con autonomy_test_plan_create, con los casos de prueba migrados como testCaseIds.
11. Ejecuta un caso de prueba migrado con autonomy_run_trigger en el entorno que elegí. Síguelo con autonomy_run_get (pasa el último cursor y waitMs) hasta que termine. Para cada paso que no se haya superado, lee autonomy_run_step_actions y cuéntame qué pasó.
12. Termina con una tabla: prueba de origen, ID del caso de prueba, número de pasos y todo lo que no hayas podido trasladar.Equivalencias
| mabl | Autonomy |
|---|---|
| Una prueba | Un caso de prueba, en la misma plataforma. |
| Plan | Un plan de pruebas. Configura su programación en el panel. |
| Flujos reutilizables | Integrados en los resultados esperados de las pruebas que los usan. Un flujo de login se convierte en un paso con la sesión iniciada y un inicio de sesión guardado. |
| Clics grabados, modelos de elementos, auto-heal | No hacen falta. El agente encuentra los controles en el producto real en cada ejecución. |
| Aserciones | El resultado esperado, con el valor comprobado como adjunto data marcado como Exact. |
| Esperas | Se descartan. |
| Entornos y aplicaciones | Entornos con un objetivo por plataforma. |
| Variables | {{env.NAME}}, marcado como secreto cuando es una credencial. |
| Credenciales | Inicios de sesión guardados. |
| Tablas de datos | Un caso de prueba por fila solo cuando las filas esperan resultados distintos. Si no, datos de prueba. |
| Buzones de mabl | Un Fresh inbox per run. Consulta Bandejas de entrada y teléfonos. |
| Detección de cambios visuales | Un resultado esperado sobre el aspecto, con un adjunto screenshot. Consulta Comprobaciones visuales. |
| Disparadores de planes en despliegues y pull requests | Un plan de pruebas que se ejecuta en las pull requests. |
Consulta el resumen de la migración para ver un ejemplo completo.
¿No lo encontraste?