Docs de Autonomy
Migrar

Resumen

Pasa una suite de Playwright, Cypress, Puppeteer, Selenium, Appium, Maestro o mabl a Autonomy con un solo prompt para tu agente de programación.

Tus pruebas actuales ya dicen qué recorridos importan. Los selectores, las esperas, los objetos de página y los fixtures que los rodean son la parte que se rompe. Una migración conserva lo primero y descarta lo segundo: cada prueba se convierte en un caso de prueba de Autonomy, escrito como unos pocos pasos con resultados esperados, y el agente averigua los clics en el producto real durante la ejecución.

Cómo funciona

  1. Conecta tu agente de programación a Autonomy por MCP. Consulta Conectar un cliente. Cuando pida acceso, permite Create and edit test cases, Create and edit test plans y Start runs. Añade Create and edit environments si quieres que añada valores del entorno por ti.
  2. Abre el repositorio que contiene la suite y pega el prompt de la página de tu framework.
  3. El agente empieza con autonomy_project_list y autonomy_environment_list, te pregunta qué proyecto y qué entorno usar, y consulta autonomy_test_case_list para no duplicar la cobertura.
  4. Crea un caso de prueba por cada prueba con autonomy_test_case_create, opcionalmente los agrupa con autonomy_test_plan_create, ejecuta uno y lee el resultado con autonomy_run_get y autonomy_run_step_actions.

Para unas pocas pruebas, también puedes usar Describe what to test en el panel: describe el recorrido o adjunta un archivo .feature, y Autonomy redacta los pasos. Consulta Creación.

En qué se convierte una prueba

En tu suiteEn Autonomy
Una prueba, spec o flujoUn caso de prueba, en la misma plataforma: web, Android o API. Las pruebas en iOS llegarán pronto.
Lo que demuestra la pruebaLos pasos. Cada paso es un resultado esperado en palabras sencillas, como "El pedido aparece como pagado".
Clics, escritura, selectores, objetos de páginaNada. El agente los averigua en el producto real.
Esperas, sleeps, reintentosNada. El agente espera lo que necesita el resultado esperado.
AsercionesEl texto del resultado esperado. Un valor sobre el que trata la aserción se convierte en un adjunto data marcado como Exact.
Helper de inicio de sesión, estado de autenticación guardadoUn paso como "El propietario de la tienda ha iniciado sesión", con un inicio de sesión guardado adjunto como account.
Contraseñas, tokens y clavesUn inicio de sesión guardado, o un valor del entorno secreto usado como {{env.NAME}}. Nunca un valor literal en un paso.
URL base, builds de la app, configuraciónEl entorno: sus objetivos de plataforma y sus valores.
Correos, nombres y contraseñas aleatoriosUn Fresh inbox per run (inbox) y datos generados (data con una intención).
Fixtures de subidaUn adjunto file de los Files del proyecto.
Llamadas a capturas de pantallaUn adjunto screenshot. Para comparaciones con el diseño, consulta Comprobaciones visuales.
Comprobaciones de redUn resultado esperado sobre lo que ve el usuario o la API. La ejecución conserva todas las peticiones en su pestaña Network. Consulta API y red.
Suites, bloques describe, etiquetasOpcionalmente, un plan de pruebas.

Un caso de prueba tiene hasta 12 pasos en el panel y hasta 50 a través de la API. Mantén los casos de prueba migrados en 12 pasos o menos para que las personas puedan seguir editándolos; divide una prueba más larga en varios casos de prueba.

Ejemplo

Una prueba de Playwright:

test("sign up and apply a coupon", async ({ page }) => {
  await page.goto("/signup");
  await page.fill("#email", `qa+${Date.now()}@example.com`);
  await page.fill("#password", "Hunter2!Hunter2!");
  await page.click("button[type=submit]");
  await page.goto(await verificationLink());
  await expect(page.getByText("Email verified")).toBeVisible();
  await page.goto("/plans");
  await page.fill("[name=coupon]", "SPRING25");
  await expect(page.locator(".total")).toHaveText("$37.50");
});

se convierte en tres pasos con resultados esperados. El correo aleatorio pasa a ser una bandeja de entrada nueva, la contraseña pasa a ser un dato generado, y el cupón y el total son Exact porque la prueba trata sobre ellos:

{
  "projectId": "<project id>",
  "name": "Sign up and apply a coupon",
  "platforms": ["web"],
  "steps": [
    {
      "id": "s1",
      "text": "A new account exists for a fresh email.",
      "attachments": [
        { "id": "a1", "kind": "inbox", "exact": false },
        { "id": "a2", "kind": "data", "label": "Password", "intent": "a strong password", "exact": false }
      ]
    },
    {
      "id": "s2",
      "text": "The verification email arrives and its link verifies the account.",
      "attachments": []
    },
    {
      "id": "s3",
      "text": "On the Plans page, the coupon applies and the total shows $37.50.",
      "attachments": [
        { "id": "a3", "kind": "data", "label": "Coupon", "value": "SPRING25", "exact": true },
        { "id": "a4", "kind": "data", "label": "Total", "value": "$37.50", "exact": true }
      ]
    }
  ]
}

Un adjunto de cuenta nombra un inicio de sesión guardado por su nombre de cuenta: { "id": "a5", "kind": "account", "role": "store-owner", "exact": false }. Los inicios de sesión se guardan en el panel, en Sign-ins del proyecto, así que el prompt te pide sus nombres en lugar de crearlos.

Reglas para una migración fiel

  • Resultados esperados, no instrucciones. #btn-submit-2 y waitForSelector no dicen nada del producto. "El pedido aparece como pagado" sí.
  • Una prueba, un caso de prueba. No combines pruebas ni añadas pasos que la prueba no comprobaba.
  • Exact solo para lo que trata la prueba. Un precio comprobado, un cupón que debe aplicarse o un número de teléfono que debe rechazarse son Exact. Todo lo demás son datos de prueba: si el producto dice que un valor ya está en uso, el agente usa uno nuevo.
  • Nada de secretos en los pasos. Las credenciales se convierten en inicios de sesión guardados o en valores secretos del entorno. Los secretos se rellenan por referencia y el agente nunca los ve.

Guías por framework

¿No lo encontraste?

On this page