Comment faire: exécuter des tests à partir de la CLI

Cette page montre comment exécuter un ensemble de test UiPath Test Manager à partir de la CLI dans le cadre d'un pipeline CI — et, tout aussi important, comment lire correctement le verbe. L’outil uip tm divise une exécution de test en trois verbes pour indiquer une raison; l'utilisation de l'un d'entre eux peut produire un build réussi même lorsque les tests ont échoué.

La règle d’or: lancer → attendre → vérifier.

Aucun verbe uip tm unique n’existe non nul, car les tests ont échoué. L'échec d'un pipeline lors d'une exécution de test rouge prend trois commandes:

1. Lancer — uip tm testsets run. Met l'exécution en file d'attente et quitte 0 dès qu'Orchestrator accepte la requête. Status: "Running" dans la réponse reflète l'état au lancement, et non le résultat final.
2. Bloc — uip tm wait. Interrogations jusqu'à ce que l'exécution atteigne un état terminal (Passed, Failed, Cancelled). Quitte 0 lorsqu'il atteint un état terminal, car « Terminé» est le signal de réussite de wait. Quitte 2 sur --timeout (une réutilisation spécifique au domaine de l'emplacement de l'erreur d'authentification, de sorte que les scripts peuvent se ramifier sur « pris trop de temps » sans analyser le texte).
3. Vérifier — uip tm report get. Lit Data.Failed (et Passed, Skipped, PassRate). Quitte 0 chaque fois qu'il récupère avec succès le résumé, indépendamment de la réussite/de l'échec — le script est chargé de transformer Data.Failed > 0 en une sortie non nulle.

Des modèles de raccourci existent (uip or jobs start --wait-for-completion, par exemple, attend+vérifieur sur une seule tâche), mais pas pour les ensembles de tests. Écrivez toujours les trois étapes.

Extrait viable minimum

#!/usr/bin/env bash
set -euo pipefail

# 1. Launch
EXECUTION_ID=$(uip tm testsets run \
  --test-set-key DEMO:10 \
  --output-filter "Data.ExecutionId" \
  --output plain)

# 2. Block (default timeout: 30 min; adjust with --timeout)
if ! uip tm wait \
  --execution-id "$EXECUTION_ID" \
  --project-key DEMO \
  --timeout 1800; then
  code=$?
  if [ "$code" -eq 2 ]; then
    echo "test run did not finish within 30 minutes" >&2
    exit 2
  fi
  echo "wait failed (exit $code)" >&2
  exit "$code"
fi

# 3. Verify
FAILED=$(uip tm report get \
  --execution-id "$EXECUTION_ID" \
  --project-key DEMO \
  --output-filter "Data.Failed" \
  --output plain)

if [ "$FAILED" -gt 0 ]; then
  echo "$FAILED test case(s) failed" >&2
  exit 1
fi

echo "all tests passed"

--output plain renvoie la valeur à barres d'un résultat de filtre scalaire; il s'agit du moyen le plus sûr de capturer un champ dans une variable Shell sans analyser JSON. Voir Modèles de script — lecture des valeurs hors de l'enveloppe.

Choix des entrées vers les commandes

uip tm testsets run a besoin de la clé de l'ensemble de tests, et non de son UUID. La clé a la forme <ProjectKey>:<Number> — par exemple DEMO:10 Deux façons de la trouver:

# From the Test Manager UI — it is the "Key" column in the test set list.

# Or from the CLI:
uip tm testsets list --project-key DEMO --filter smoke \
  --output-filter "Data[*].{key:TestSetKey, name:Name}"

--project-key est obligatoire sur list; run dérive le projet du préfixe de la clé d'ensemble de test (DEMO:10 → projet DEMO).

Si vous avez besoin de l'UUID numérique pour uip tm executions list --test-set-id, il s'agit du champ Id sur la même sortie de liste, et non le TestSetKey.

Choisir les cas exécutés

uip tm testsets run --execution-type contrôle les cas de test à l'intérieur de l'exécution de l'ensemble:

• automated (par défaut) — cas de test automatisés uniquement.
• manual — cas de test manuels uniquement.
• mixed — les deux.
• none — aucun filtre de type.

Pour CI, conservez la valeur par défaut (automated) — les cas manuels nécessitent un humain pour marquer la réussite/l'échec et se trouveront dans InProgress jusqu'à --timeout.

Remplacements de paramètres

Si l'ensemble de tests expose des paramètres (par exemple, une URL cible ou un ID de compte), remplacez-les au lancement par --input-path:

cat > ./params.json <<'EOF'
[
  {"name": "TargetUrl", "type": "String", "value": "https://staging.example.com"},
  {"name": "AccountId", "type": "String", "value": "acme-staging"}
]
EOF

uip tm testsets run --test-set-key DEMO:10 --input-path ./params.json

Les remplacements sont mis en correspondance par rapport aux définitions de paramètres actuelles de l'ensemble de tests par name (insensible à la casse) et, le cas échéant, type. Si le serveur ne rapporte aucune définition de paramètre, les entrées sont envoyées telles quelles.

Lire le verbe en détail

uip tm report get est le lecteur de résumé. La sortie par défaut vous donne la carte de score; passez --query (un filtre de style jq) pour extraire un sous-ensemble dans un appel:

# Pretty scorecard
uip tm report get --execution-id "$EXECUTION_ID" --project-key DEMO

# Script-friendly — JSON with just the counts
uip tm report get --execution-id "$EXECUTION_ID" --project-key DEMO \
  --query '{total: .TotalTests, passed: .Passed, failed: .Failed}'

L'enveloppe Data contient les champs suivants (schéma complet dans la référencereport get ):

• TotalTests, Passed, Failed, Skipped, PassRate ("80%"), Duration (HH:MM:SS).
• FailedTests — une entrée par cas de test ayant échoué, avec TestCaseName et une chaîne Error (soit le champ info du journal, soit une liste concaténée de messages d'assertion ayant échoué).

Lorsque vous avez besoin d'un fichier JUnit-XML que le tableau de bord de test de votre CI peut ingérer, utilisez uip tm result download au lieu de (ou avec) report get.

Présentation des cas ayant échoué dans les journaux CI

Transformez le tableau FailedTests en une ligne lisible par un humain par échec avant de quitter le pipeline:

if [ "$FAILED" -gt 0 ]; then
  uip tm report get \
    --execution-id "$EXECUTION_ID" \
    --project-key DEMO \
    --output-filter "Data.FailedTests[*].[TestCaseName, Error]" \
    --output plain >&2
  echo "$FAILED test case(s) failed" >&2
  exit 1
fi

Pour une analyse plus approfondie des échecs - détails assertion par assertion sur un seul cas échoué - utilisez uip tm testcaselogs list-assertions pour les ID de journal renvoyés par uip tm executions testcaselogs list --only-failed.

Réessayer des cas particuliers

Si une exécution comporte des échecs qui pourraient être malveillants (synchronisation, environnement), réessayez uniquement les cas ayant échoué :

uip tm executions retry \
  --execution-id "$EXECUTION_ID" \
  --project-key DEMO

uip tm executions retry réutilise le même ID d'exécution — aucun nouveau n'est créé. S’il n’y a pas d’échec de nouvelle tentative, il imprime un message d’information et quitte 0 (intentionnellement sans erreur).

Après retry, revenez en arrière dans wait + report get sur le même ID d'exécution.

Erreurs courantes

• Analyse de la sortie testsets run pour décider de la réussite/de l’échec. Le champ Status au moment du lancement est généralement Running — cela signifie que l'exécution a été mise en file d'attente, et non que tous les tests ont réussi. Appelez toujours wait puis report get.
• Obtention de l' --timeout sur wait. La valeur par défaut est de 1 800 secondes (30 minutes). Transmettez 0 pour attendre indéfiniment (rament ce que vous voulez dans CI); transmettre un plus grand nombre pour les suites longues.
• Traitement de la sortie 2 de wait comme un échec d'authentification. Sur wait spécifiquement, 2 signifie un délai d'attente, et non AuthenticationError — voir les codes de sortieuip tm wait .
• Utilisation de testsets verbes pour créer des tests. Les cas de test et leurs liens aux automatisations Orchestrator proviennent de uip tm testcases; testsets les regroupe uniquement.

Exemple entièrement compatible CI

Un extrait bash d'une étape de pipeline — échoue la version en cas d'échec, d'expiration ou d'erreurs de test:

#!/usr/bin/env bash
set -euo pipefail

TEST_SET_KEY="${TEST_SET_KEY:?TEST_SET_KEY is required}"
PROJECT_KEY="${PROJECT_KEY:?PROJECT_KEY is required}"
TIMEOUT="${TEST_TIMEOUT:-1800}"

EXECUTION_ID=$(uip tm testsets run \
  --test-set-key "$TEST_SET_KEY" \
  --output-filter "Data.ExecutionId" \
  --output plain)

echo "started execution $EXECUTION_ID" >&2

if ! uip tm wait \
  --execution-id "$EXECUTION_ID" \
  --project-key "$PROJECT_KEY" \
  --timeout "$TIMEOUT"; then
  code=$?
  case "$code" in
    2) echo "execution $EXECUTION_ID did not finish within ${TIMEOUT}s" >&2; exit 2 ;;
    *) echo "wait failed with exit $code" >&2; exit "$code" ;;
  esac
fi

# Get the scorecard and the names of any failed cases in one shot
uip tm report get \
  --execution-id "$EXECUTION_ID" \
  --project-key "$PROJECT_KEY"

FAILED=$(uip tm report get \
  --execution-id "$EXECUTION_ID" \
  --project-key "$PROJECT_KEY" \
  --output-filter "Data.Failed" \
  --output plain)

if [ "$FAILED" -gt 0 ]; then
  echo "$FAILED test case(s) failed" >&2
  exit 1
fi

echo "all tests passed"

Exécutez ce script après l'étape de déploiement de votre solution dans l'une des formules CI. La seule configuration spécifique à l'environnement est TEST_SET_KEY / PROJECT_KEY — définissez-les par environnement dans le pipeline, et le même script fait la promotion de manière propre à travers le développement/l'étape/la production.

Voir également

• Vue d’ensemble deuip tm — l’interface de commande complète.
• uip tm testsets run, uip tm wait, uip tm report get — les trois verbes utilisés ci-dessus.
• uip tm result download — Exportation XML JUnit pour les tableaux de bord CI.
• Modèles de script — interrogation, filtrage JSON, pipelines idempotents.
• Codes de sortie — le contrat partagé et le 2 spécifique au domaine de wait.