uip tm executions

uip tm executions inspecte et manipule les exécutions de test — les objets produits par uip tm testsets run. Utilisez ces verbes pour répertorier les exécutions d'un ensemble de tests, énumérer les journaux de cas de test d'une exécution terminée et réessayer uniquement les cas ayant échoué en place.

La commande qui permet de lancer une exécution est uip tm testsets run, qui renvoie une ExecutionId. Chaque verbe de cette page prend cet ID (ou le dérive du contexte).

Synthèse

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>]

Tous les verbes respectent les options globales et les codes de sortie standard. Chaque verbe accepte -t, --tenant <name> et --log-level <level> (par défaut Information).

uip tm executions list

Répertoriez les exécutions associées à un ensemble de tests. Les filtres sont appliqués côté serveur; la CLI renvoie une page par appel, dimensionnée par --top / --skip.

Arguments: aucun.

Options:

• --project-key <key> (obligatoire) : propriétaire du projet.
• --test-set-id <uuid> (obligatoire) : UUID de l'ensemble de tests (le champ Id de testsets list, non TestSetKey).
• --filter <text> — recherchez des exécutions par nom.
• --status <status> — filtrer par statut d'exécution. Les valeurs acceptées proviennent de l’enum du SDK TestExecutionStatus .
• --execution-type <type> — filtrer par type d'exécution. Les valeurs acceptées proviennent de l’enum ExecutionType du SDK (automated, manual, mixed, none).
• --execution-finished-interval <interval> — filtrer par date de fin d'exécution récente. Les valeurs acceptées proviennent de l’enum du SDK TestExecutionFinishedInterval .
• --top <number> — taille de la page. La valeur par défaut est 50.
• --skip <number> — résultats à ignorer. La valeur par défaut est 0.

Remarque :

Les valeurs enum exactes acceptées par --status, --execution-type et --execution-finished-interval sont générées à partir du SDK de Test Manager au moment du runtime. Exécutez uip tm executions list --help pour voir l'ensemble actuel de votre version d'outil installée.

Exemple :

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

Format des données:

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

Répertorie les journaux de cas de test produits par une seule exécution. Chaque journal est l'exécution d'un cas de test, qui porte le résultat, le statut et la synchronisation.

Arguments: aucun.

Options:

• --execution-id <uuid> (requis) : exécution à inspecter.
• --project-key <key> (obligatoire) : propriétaire du projet.
• --only-failed — raccourci pour « afficher uniquement les journaux ayant échoué».
• --filter <text> — recherchez les journaux par nom.
• --results <results...> — résultats séparés par des espaces à inclure. Les valeurs acceptées proviennent de l’enum du SDK Result .
• --statuses <statuses...> — statuts d'exécution séparés par des espaces. Les valeurs acceptées proviennent de l’enum du SDK TestCaseLogExecutionStatus .
• --duration-period <period> — filtrer par compartiment de durée. Les valeurs acceptées proviennent de l’enum du SDK DurationPeriod .
• --top <number> — taille de la page. La valeur par défaut est 50.
• --skip <number> — résultats à ignorer. La valeur par défaut est 0.

Exemple :

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

Format des données:

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

Chaque Id de la sortie est un UUID du journal de cas de test. Transmettez-le à uip tm testcaselogs list-assertions pour voir pourquoi un journal de cas de test a été marqué Failed.

uip tm executions retry

Réessayer uniquement les cas de test ayant échoué d’une exécution terminée, en place. La commande:

1. Récupère les statistiques d’exécution et refuse de continuer à moins que l’exécution ne soit dans un état terminal (sans quoi elle se termine 1 avec un message d’instruction).
2. S'il n'y a aucun cas ayant échoué, imprime une enveloppe Message et quitte 0 — il s'agit intentionnellement d'une erreur.
3. Sinon, collecte chaque ID de journal de cas de test ayant échoué (paginé) et lance une nouvelle tentative qui cible uniquement ces journaux.

La nouvelle tentative utilise le même ID d’exécution; il n'en crée pas de nouveau.

Arguments: aucun.

Options:

• --execution-id <uuid> (requis) : l'exécution à réessayer.
• --project-key <key> — propriétaire du projet. Il est obligatoire de spécifier soit ceci, soit --test-set-key .
• --test-set-key <key> — clé de l'ensemble de tests (par ex. DEMO:42); la clé du projet est dérivée du préfixe.
• --execution-type <type> — type d'exécution pour la nouvelle tentative: automated (par défaut), manual, mixed, ou none

Exemple :

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

Format des données — lorsqu'il y a des échecs de réessai:

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

Lorsqu’il n’y a pas d’échec de nouvelle tentative:

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

Codes de sortie

Tous les verbes uip tm executions … suivent les codes de sortie standard – 0 en cas de réussite (même lorsque retry ne trouve rien à réessayer), 1 en cas d'échec générique, 2 en cas d'échec d'authentification, 3 en cas d'erreur de validation.

Le cycle de vie d'exécution de Test Manager ajoute un comportement qui méritent d'être signalés explicitement, et il repose sur wait, et non sur les verbes d'exécution eux-mêmes:

Distinction « expiré» de « terminé avec des échecs»

Il n'y a pas de verbe tm unique qui se termine par non-zéro, car les tests ont échoué. Le modèle CI standard est un pipeline en trois étapes:

1. Lancer — uip tm testsets run renvoie un ExecutionId et quitte 0 dès que l'exécution est mise en file d'attente.
2. Bloquer — uip tm wait --execution-id <id> --timeout <seconds> interrogations jusqu'à ce que l'exécution atteigne un état terminal.
   • Quitte 0 lorsque l'exécution se termine (indépendamment de la réussite/de l'échec — « terminée» est le signal de réussite ici).
   • Quitte 2 au moment de l’expiration --timeout . Ceci est spécifique au domaine: le contrat partagé réserve 2 pour AuthenticationError, mais wait le réutilise pour TimeoutError afin que les scripts puissent se ramifier sur « pris trop de temps » sans analyser le texte. Consultez la note à ce sujet sous uip tm wait codes de sortie.
   • Quitte 1 en cas d'échec, d'interruption ou d'abandon de l'API.
3. Verdict — uip tm report get --execution-id <id> lit Passed / Failed / Skipped / PassRate. Votre script décide de l'apparence d'une réussite et échoue explicitement la construction (par ex. exit 1 sur Failed > 0). report get se quitte 0 chaque fois qu'il produit avec succès le résumé, quel que soit le résultat de l'exécution qu'il résume.

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

Associé

• testsets run — start an execution.
• attendre — bloquer jusqu'à ce qu'une exécution atteigne un état terminal.
• rapport, résultat, pièce jointe — artefacts post-exécution.
• testcases — testcaselogs list-assertions turns a failed log into per-assertion detail.

Voir également

• Vue d’ensemble de Test Manager
• Codes de sortie — contrat partagé.
• Modèles de script - le pipeline de vérification-attente-attente en trois étapes en détail.