uip tm executions

uip tm executions inspecciona y manipula las ejecuciones de prueba: los objetos producidos por uip tm testsets run. Utiliza estos verbos para enumerar las ejecuciones de un conjunto de pruebas, enumerar los registros de casos de prueba de una ejecución finalizada y reintentar solo los casos fallidos en su lugar.

El comando que inicia una ejecución es uip tm testsets run, que devuelve un ExecutionId. Cada verbo de esta página toma ese ID (o lo deriva del contexto).

Sinopsis

uip tm executions list --project-key <key> --test-set-id <uuid> [filters…]
uip tm executions testcaselogs list --execution-id <uuid> --project-key <key> [filters…]
uip tm executions retry --execution-id <uuid> (--project-key <key> | --test-set-key <key>) [--execution-type <type>]

Todos los verbos respetan las opciones globales y los códigos de salida estándar. Cada verbo acepta -t, --tenant <name> y --log-level <level> (predeterminado Information).

uip tm executions list

Enumera las ejecuciones asociadas a un conjunto de pruebas. Los filtros se aplican en el servidor; la CLI devuelve una página por llamada, con un tamaño de --top / --skip.

Argumentos: ninguno.

Opciones:

• --project-key <key> (obligatorio) : proyecto propietario.
• --test-set-id <uuid> (obligatorio) : UUID del conjunto de pruebas (el campo Id de testsets list, no TestSetKey).
• --filter <text> : busca ejecuciones por nombre.
• --status <status> : filtrar por estado de ejecución. Los valores aceptados provienen del enum SDK TestExecutionStatus .
• --execution-type <type> : filtrar por tipo de ejecución. Los valores aceptados provienen del SDK ExecutionType enum (automated, manual, mixed, none).
• --execution-finished-interval <interval> : filtrar por qué tan recientemente finalizó la ejecución. Los valores aceptados provienen del enum SDK TestExecutionFinishedInterval .
• --top <number> — tamaño de la página. El valor predeterminado es 50.
• --skip <number> : resultados a omitir. El valor predeterminado es 0.

Nota:

Los valores de enumeración exactos aceptados por --status, --execution-type y --execution-finished-interval se generan a partir del SDK de Test Manager en runtime. Ejecuta uip tm executions list --help para ver el conjunto actual de tu versión de herramienta instalada.

Ejemplo:

uip tm executions list \
  --project-key DEMO \
  --test-set-id a1b2c3d4-0000-0000-0000-000000000001 \
  --top 2

Forma de datos:

{
  "Code": "ExecutionsList",
  "Data": [
    {
      "Id": "b2c3d4e5-0000-0000-0000-000000000001",
      "Name": "Nightly Run 2025-04-15",
      "Status": "Passed"
    },
    {
      "Id": "b2c3d4e5-0000-0000-0000-000000000002",
      "Name": "Nightly Run 2025-04-14",
      "Status": "Failed"
    }
  ]
}

uip tm executions testcaselogs list

Enumera los registros de casos de prueba producidos por una sola ejecución. Cada registro es una ejecución de un caso de prueba, con resultado, estado y tiempo.

Argumentos: ninguno.

Opciones:

• --execution-id <uuid> (obligatorio) : ejecución para inspeccionar.
• --project-key <key> (obligatorio) : proyecto propietario.
• --only-failed — atajo para "mostrar solo los registros fallidos".
• --filter <text> : buscar registros por nombre.
• --results <results...> — resultados separados por espacios a incluir. Los valores aceptados provienen del enum SDK Result .
• --statuses <statuses...> : estados de ejecución separados por espacios. Los valores aceptados provienen del enum SDK TestCaseLogExecutionStatus .
• --duration-period <period> : filtrar por depósito de duración. Los valores aceptados provienen del enum SDK DurationPeriod .
• --top <number> — tamaño de la página. El valor predeterminado es 50.
• --skip <number> : resultados a omitir. El valor predeterminado es 0.

Ejemplo:

uip tm executions testcaselogs list \
  --execution-id a1b2c3d4-0000-0000-0000-000000000001 \
  --project-key DEMO \
  --only-failed

Forma de datos:

{
  "Code": "ExecutionTestCaseLogs",
  "Data": [
    {
      "Id": "c3d4e5f6-0000-0000-0000-000000000001",
      "TestCaseName": "Login flow",
      "Status": "Finished",
      "Result": "Failed"
    }
  ]
}

Cada Id en la salida es un UUID de registro de caso de prueba. Envíalo a uip tm testcaselogs list-assertions para ver por qué un registro de caso de prueba se marcó como Failed.

uip tm executions retry

Reintentar solo los casos de prueba fallidos de una ejecución completada, en su lugar. El comando:

1. Obtiene las estadísticas de la ejecución y se niega a continuar a menos que la ejecución esté en un estado terminal (de lo contrario, sale 1 con un mensaje de orientación).
2. Si no hay casos fallidos, imprime un sobre Message y sale de 0 : esto no es un error intencionadamente.
3. De lo contrario, recopila cada ID de registro de caso de prueba fallido (paginado) e inicia un reintento que se dirige solo a esos registros.

El reintento reutiliza el mismo ID de ejecución; no crea uno nuevo.

Argumentos: ninguno.

Opciones:

• --execution-id <uuid> (obligatorio) : ejecución para reintentar.
• --project-key <key> — proyecto propietario. Se requiere esto o --test-set-key .
• --test-set-key <key> : clave del conjunto de pruebas (p. ej. DEMO:42); la clave del proyecto se deriva del prefijo.
• --execution-type <type> — tipo de ejecución para el reintento: automated (predeterminado), manual, mixed o none.

Ejemplo:

uip tm executions retry \
  --execution-id a1b2c3d4-0000-0000-0000-000000000001 \
  --project-key DEMO

Forma de datos : cuando hay fallos al reintentar:

{
  "Code": "ExecutionRetry",
  "Data": {
    "ExecutionId": "a1b2c3d4-0000-0000-0000-000000000001",
    "Status": "Running",
    "StartTime": "2025-04-15T10:30:00Z",
    "RetriedCount": 3
  }
}

Cuando no hay fallos para reintentar:

{
  "Code": "ExecutionRetry",
  "Data": {
    "Message": "Execution 'a1b2c3d4-0000-0000-0000-000000000001' has no failed test cases to retry."
  }
}

Códigos de salida

Todos los verbos uip tm executions … siguen los códigos de salida estándar: 0 en caso de éxito (incluso cuando retry no encuentra nada que reintentar), 1 en fallo genérico, 2 en fallo de autenticación, 3 en error de validación.

El ciclo de vida de ejecución de Test Manager añade un comportamiento que vale la pena llamar explícitamente, y vive en wait, no en los verbos de ejecución en sí:

Distinguir "tiempo de espera agotado" de "finalizado con fallos"

No hay un solo verbo tm que salga distinto de cero porque las pruebas fallaron. El patrón de CI estándar es un proceso de tres pasos:

1. Lanzar : uip tm testsets run devuelve un ExecutionId y sale de 0 tan pronto como la ejecución se pone en cola.
2. Bloquear : uip tm wait --execution-id <id> --timeout <seconds> sondea hasta que la ejecución alcanza un estado terminal.
   • Sale de 0 cuando finaliza la ejecución (independientemente de si se aprobó/falló; "terminado" es la señal de éxito aquí).
   • Sale de 2 el --timeout de vencimiento. Esto es específico del dominio: el contrato compartido reserva 2 para AuthenticationError, pero wait lo reutiliza para TimeoutError , por lo que los scripts pueden ramificarse en "tardó demasiado" sin analizar el texto. Consulta la nota sobre esto en uip tm wait códigos de salida.
   • Sale de 1 en caso de fallo, interrupción o cancelación de la API.
3. Veredicto : uip tm report get --execution-id <id> se lee Passed / Failed / Skipped / PassRate. Tu script decide cómo se ve un pase y falla la compilación explícitamente (por ejemplo exit 1 cuando Failed > 0). report get en sí mismo sale 0 siempre que produce con éxito el resumen, independientemente del resultado de la ejecución que está resumiendo.

# Start the run
id=$(uip tm testsets run --test-set-key DEMO:10 --output-filter .Data.ExecutionId)

# Block with a timeout; branch on the outcome
if ! uip tm wait --execution-id "$id" --timeout 1800; then
  code=$?
  if [ "$code" -eq 2 ]; then
    echo "timed out" >&2
    exit 2
  fi
  echo "wait failed ($code)" >&2
  exit "$code"
fi

# Decide pass/fail from the summary
failed=$(uip tm report get --execution-id "$id" --project-key DEMO --output-filter .Data.Failed)
if [ "$failed" -gt 0 ]; then
  echo "$failed test case(s) failed" >&2
  exit 1
fi
echo "all passed"

Relacionado

• testsets run — start an execution.
• esperar : bloquea hasta que una ejecución alcanza un estado terminal.
• informe, resultado, archivo adjunto : artefactos posteriores a la ejecución.
• testcases — testcaselogs list-assertions turns a failed log into per-assertion detail.

Ver también

• Descripción general de Test Manager
• Códigos de salida : contrato compartido.
• Patrones de scripting : el proceso de tres pasos iniciar-esperar-verificar en detalle.