uip tm executions

uip tm executions inspeciona e manipula execuções de teste — os objetos produzidos por uip tm testsets run. Use esses verbos para listar execuções para um conjunto de testes, enumerar os logs de casos de teste de uma execução concluída e tentar novamente apenas os casos com falha no local.

O comando que inicia uma execução é uip tm testsets run, que retorna um ExecutionId. Cada verbo nessa página leva esse ID (ou o deriva do contexto).

Resumo

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 os verbos honram as opções globais e os códigos de saída padrão. Cada verbo aceita -t, --tenant <name> e --log-level <level> (padrão Information).

uip tm executions list

Liste as execuções associadas a um conjunto de testes. Os filtros são aplicados no lado do servidor; a CLI retorna uma página por chamada, dimensionada por --top / --skip.

Argumentos: nenhum.

Opções:

• --project-key <key> (necessário) — possuindo projeto.
• --test-set-id <uuid> (necessário) — UUID do conjunto de testes (o campo Id de testsets list, não de TestSetKey).
• --filter <text> pesquisar execuções por nome.
• --status <status> filtre por status de execução. Os valores aceitos vêm do enum TestExecutionStatus do SDK.
• --execution-type <type> filtrar por tipo de execução. Os valores aceitos vêm do enum do SDK ExecutionType (automated, manual, mixed, none).
• --execution-finished-interval <interval> — filtre por quão recentemente a execução foi finalizada. Os valores aceitos vêm do enum TestExecutionFinishedInterval do SDK.
• --top <number> — tamanho da página. O padrão é 50.
• --skip <number> — resultados a ignorar. O padrão é 0.

Observação:

Os valores enum exatos aceitos por --status, --execution-type e --execution-finished-interval são gerados a partir do SDK do Test Manager no runtime. Execute uip tm executions list --help para ver o conjunto atual para sua versão da ferramenta instalada.

Exemplo:

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

Formato dos dados:

{
  "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

Lista os logs de casos de teste produzidos por uma única execução. Cada log é uma execução de um caso de teste, carregando resultado, status e tempo.

Argumentos: nenhum.

Opções:

• --execution-id <uuid> necessário) — execução para inspecionar.
• --project-key <key> (necessário) — possuindo projeto.
• --only-failed atalho para "mostrar apenas logs com falha".
• --filter <text> pesquisar logs por nome.
• --results <results...> resultados separados por espaço a serem incluídos. Os valores aceitos vêm do enum Result do SDK.
• --statuses <statuses...> — status de execução separados por espaço. Os valores aceitos vêm do enum TestCaseLogExecutionStatus do SDK.
• --duration-period <period> — filtrar por bucket de duração. Os valores aceitos vêm do enum DurationPeriod do SDK.
• --top <number> — tamanho da página. O padrão é 50.
• --skip <number> — resultados a ignorar. O padrão é 0.

Exemplo:

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

Formato dos dados:

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

Cada Id na saída é um UUID de log de caso de teste. Feed-o para uip tm testcaselogs list-assertions para ver por que um log de caso de teste foi marcado Failed.

uip tm executions retry

Tente novamente apenas os casos de teste com falha de uma execução concluída, no local. O comando:

1. Busca as estatísticas da execução e se recusa a prosseguir, a menos que a execução esteja em um estado terminal (caso contrário, ela sai 1 com uma mensagem de orientação).
2. Se houver zero casos com falha, imprime um envelope Message e sai 0 — isso não é intencionalmente um erro.
3. Caso contrário, coleta todos os IDs de log de casos de teste com falha (paginados) e inicia uma nova tentativa que tem como alvo apenas esses logs.

A nova tentativa reutiliza o mesmo ID de execução; ele não cria um novo.

Argumentos: nenhum.

Opções:

• --execution-id <uuid> necessário) — execução para tentar novamente.
• --project-key <key> — proprietário do projeto. Ou isso ou --test-set-key é necessário.
• --test-set-key <key> chave do conjunto de testes (por exemplo DEMO:42); a chave do projeto é derivada do prefixo.
• --execution-type <type> — tipo de execução para a nova tentativa: automated (padrão), manual, mixed ou none.

Exemplo:

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

Formato dos dados — quando há falhas para tentar novamente:

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

Quando não houver falhas para tentar novamente:

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

Códigos de saída

Todos os verbos uip tm executions … seguem os códigos de saída padrão — 0 no sucesso (mesmo quando retry não encontra nada para tentar novamente), 1 na falha genérica, 2 na falha de autenticação, 3 no erro de validação.

O ciclo de vida de execução do Test Manager adiciona um comportamento que vale a pena chamar explicitamente e ele reside em wait, não nos próprios verbos de execução:

Diferenciação de "tempo esgotado" de "concluído com falhas"

Não há um único verbo tm que saia diferente de zero porque os testes falharam. O padrão de CI padrão é um pipeline de três etapas:

1. Iniciar — uip tm testsets run retorna um ExecutionId e sai 0 assim que a execução é colocada na fila.
2. Bloquear — uip tm wait --execution-id <id> --timeout <seconds> faz pesquisas até que a execução atinja um estado terminal.
   • Sai de 0 quando a execução foi concluída (independentemente de aprovação/falha — "Finalizado" é o sinal de sucesso aqui).
   • Sai 2 na expiração --timeout . Isso é específico do domínio: o contrato compartilhado reserva 2 para AuthenticationError, mas wait o reutiliza para TimeoutError para que os scripts possam ramificar em " demorou muito" sem analisar o texto. Consulte a observação sobre isso em uip tm wait códigos de saída.
   • Sai 1 por falha de API, interrupção ou anulação.
3. Veredicto — uip tm report get --execution-id <id> lê Passed / Failed / Skipped / PassRate. Seu script decide como é uma aprovação e falha na compilação explicitamente (por exemplo exit 1 quando Failed > 0). O próprio report get sai de 0 sempre que produz com sucesso o resumo, independentemente do resultado da execução que está resumindo.

# 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.
• Wait — bloqueie até que uma execução atinja um estado terminal.
• relatório, resultado, anexo — artefatos pós-execução.
• testcases — testcaselogs list-assertions turns a failed log into per-assertion detail.

Veja também

• Visão geral do Test Manager
• Códigos de saída — contrato compartilhado.
• Padrões de script — o pipeline de três etapas iniciar-aguardar-verificar em detalhes.