So: Führen Sie Tests über die CLI aus

Führen Sie einen Test Manager-Testsatz über die UiPath CLI als Teil einer CI-Pipeline aus und interpretieren Sie das Ausführungswort korrekt.

This page shows how to run a UiPath Test Manager test set from the CLI as part of a CI pipeline — and, just as importantly, how to read the verdict correctly. The uip tm tool splits a test set run into three verbs for a reason; using only one of them can produce a passing build even when tests have failed.

Die Goldregel: Starten → Warten → Überprüfen

For a test set run, no single uip tm verb exits non-zero because tests failed. Getting a pipeline to fail on a red test set run takes three commands (a package run takes one, see Run every test in an uploaded package):

1. Starten – uip tm testsets run. Stellt die Ausführung in eine Warteschlange ein und beendet 0 , sobald der Orchestrator die Anforderung akzeptiert. Status: "Running" in der Antwort spiegelt den Status beim Start wider, nicht das Endergebnis.
2. Block — uip tm wait. Polls until the execution reaches a terminal state (Finished or Cancelled). Exits 0 when it reaches any terminal state — because "finished" is the success signal for wait. Exits 2 on --timeout (a domain-specific reuse of the authentication-error slot, so scripts can branch on "took too long" without parsing text).
3. Überprüfen – uip tm report get. Liest Data.Failed (und Passed, Skipped, PassRate). Beendet 0 immer dann, wenn die Zusammenfassung erfolgreich abgerufen wird, unabhängig davon, ob sie bestanden/fehlgeschlagen sind – das Skript ist dafür verantwortlich, Data.Failed > 0 in einen Exit ungleich Null umzuwandeln.

A launch+wait shortcut does exist for test sets — uip tm testsets run --wait launches and blocks in one call (--timeout/--poll-interval tune the poll) — but it still isn't launch+wait+verify: a Finished run exits 0 even when tests inside it failed (only a Cancelled run exits 1). You still need the separate verify step to catch a red run. Always write the three steps (or the two-step run --wait plus the same report get verify at the end).

Run every test in an uploaded package

When the tests ship in a package already uploaded to Orchestrator, uip tm run --type package launches, waits, and verifies in one call. It runs every test case in the package, with no test set to author, writes a JUnit or UiPath report to --result-path, and exits 1 when a test fails or reports no result, no test runs, or the run is cancelled, so the pipeline fails on a red run without a separate verify step.

uip tm run --type package \
  --project-key DEMO \
  --package-name MyTests \
  --package-version 1.0 \
  --folder-path Shared \
  --result-path ./results/junit.xml

Code beenden	Bedeutung
0	Every test passed.
1	A test failed or reported no result, the run was cancelled, no test ran, or a service call failed. A missing login or no access to the project also exits 1, before the run starts.
2	Login or permission problem after the run starts.
3	Bad option or input.
4	The run exceeded --timeout.

Minimales funktionierendes Snippet

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

# 1. Launch
EXECUTION_ID=$(uip tm testsets run \
  --test-set-key DEMO:10 \
  --output-filter "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 "Failed" \
  --output plain)

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

echo "all tests passed"

--output plain gibt den einfachen Wert für ein skalares Filterergebnis zurück; Dies ist die sicherste Methode, um ein Feld in einer Shell-Variablen zu erfassen, ohne JSON zu parsen. Siehe Skriptmuster – Lesen von Werten aus dem Umschlag.

Auswahl von Eingaben für die Befehle

uip tm testsets run benötigt den Testsatzschlüssel, nicht seine UUID. Der Schlüssel hat das Format <ProjectKey>:<Number> – z. B. DEMO:10. Zwei Möglichkeiten, sie zu finden:

# 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 "[*].{key:TestSetKey, name:Name}"

list takes the project as --project-key or --project-id. run derives the project from the test set key's prefix (DEMO:10 → project DEMO).

Wenn Sie die numerische UUID für uip tm executions list --test-set-id benötigen, ist dies das Id -Feld in derselben Listenausgabe – nicht TestSetKey.

Auswählen, welche Fälle ausgeführt werden

uip tm testsets run --execution-type steuert, welche Testfälle innerhalb des Satzes ausgeführt werden:

• automated (Standard) – nur automatisierte Testfälle.
• manual – nur manuelle Testfälle.
• mixed – beides.
• none – Kein Typfilter.

Behalten Sie für CI den Standardwert (automated) bei – manuelle Fälle erfordern einen Menschen, um „bestanden“/fehlgeschlagen zu markieren, und bleiben InProgress bis --timeout.

Parameterüberschreibungen werden übergeben

Wenn der Testsatz Parameter verfügbar macht (z. B. eine Ziel-URL oder eine Konto-ID), überschreiben Sie sie beim Start mit --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

Overrides are matched against the test set's current parameter definitions by name (case-insensitive) and, when present, type. If the server reports no parameter definitions, the inputs are sent as-is. The overrides are saved on the test set, so later runs without --input-path reuse them.

Lesen des Urteils im Detail

uip tm report get ist der Leser der Zusammenfassung. Die Standardausgabe gibt Ihnen die Bewertungskarte; Übergeben Sie --query (einen Filter im JQ-Stil), um eine Teilmenge in einem Aufruf zu extrahieren:

# 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}'

Der Umschlag Data hat die folgenden Felder (vollständiges Schema in der report get -Referenz):

• TotalTests, Passed, Failed, Skipped, PassRate ("80%"), Duration (HH:MM:SS).
• FailedTests – Ein Eintrag pro fehlgeschlagenem Testfall mit TestCaseName und einer Error -Zeichenfolge (entweder das info -Feld des Protokolls oder eine verkettete Liste fehlgeschlagener Assertionsnachrichten).

Wenn Sie eine JUnit-XML-Datei benötigen, die das Test-Dashboard Ihrer CI erfassen kann, verwenden Sie uip tm result download anstelle (oder neben) report get.

Fehlgeschlagene Fälle in CI-Protokollen anzeigen

Verwandeln Sie das FailedTests -Array pro Fehler in eine visuell lesbare Zeile, bevor Sie die Pipeline beenden:

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

Für eine tiefere Fehleranalyse – Assertion-für-Assertion-Details zu einem einzelnen fehlgeschlagenen Fall – verwenden Sie uip tm testcaselog list-assertions für die Protokoll-IDs, die von uip tm executions testcaselogs list --only-failed zurückgegeben werden.

Fehlerhafte Fälle werden wiederholt

Wenn eine Ausführung Fehler aufweist, die fehlerhaft sein könnten (Zeitpunkt, Umgebung), wiederholen Sie nur die fehlgeschlagenen Fälle :

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

uip tm executions retry verwendet dieselbe Ausführungs-ID wieder – es wird keine neue erstellt. Wenn es keine Fehler beim Wiederholen gibt, wird eine Informationsmeldung ausgegeben und 0 wird beendet (absichtlich kein Fehler).

Führen Sie nach retry eine Schleife zurück durch wait + report get auf derselben Ausführungs-ID.

Häufige Fallstricke

• Analysieren der testsets run -Ausgabe, um zu entscheiden, ob sie bestanden/fehlgeschlagen sind. Das Status -Feld beim Start ist in der Regel Running – es bedeutet, dass die Ausführung in der Warteschlange stand und nicht, dass jeder Test bestanden hat. Rufen Sie immer wait und dann report get auf.
• --timeout auf wait wird vergessen. Der Standardwert ist 1800 Sekunden (30 Minuten). Übergeben Sie 0 um unbegrenzt zu warten (selten, was Sie bei CI möchten); übergeben Sie eine größere Zahl für lange Suiten.
• Beenden von 2 aus wait wird als Authentifizierungsfehler behandelt. Insbesondere bei wait bedeutet 2 eine Zeitüberschreitung, nicht AuthenticationError – siehe uip tm wait Austrittscodes.
• Verwenden von testsets Verben zum Erstellen von Tests. Testfälle und deren Links zu Orchestrator-Automatisierungen stammen von uip tm testcases; testsets gruppiert sie nur.

Vollständiges CI-fähiges Beispiel

Ein Bash-Snippet für einen Pipelineschritt – der Build schlägt fehl, wenn ein Test fehlschlägt, eine Zeitüberschreitung oder Fehler auftritt:

#!/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 "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 "Failed" \
  --output plain)

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

echo "all tests passed"

Führen Sie dieses Skript nach Ihrem Schritt zur Lösungsbereitstellung in einem der CI-Rezepte aus. Die einzige env-spezifische Konfiguration ist TEST_SET_KEY / PROJECT_KEY – legen Sie sie pro Umgebung in der Pipeline fest, und mit demselben Skript wird sauber über dev/stage/prod hinweg heraufgestuft.

Siehe auch

• uip tm -Übersicht – die vollständige Befehlsoberfläche.
• uip tm testsets run, uip tm wait, uip tm report get – die drei oben verwendeten Verben.
• uip tm result download – JUnit-XML-Export für CI-Dashboard.
• Skriptingmuster – Abrufe, JSON-Filter, idempotente Pipelines.
• Austrittscodes – der gemeinsame Vertrag und der domänenspezifische wait 2.