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

Auf dieser Seite wird gezeigt, wie ein UiPath Test Manager- Testsatz über die CLI als Teil einer CI-Pipeline ausgeführt wird – und, was ebenfalls wichtig ist, wie das Ergebnis korrekt gelesen wird. Das uip tm -Tool teilt eine Testausführung aus einem bestimmten Grund in drei Verben auf; Wenn Sie nur eine von ihnen verwenden, kann dies zu einem erfolgreichen Build führen, auch wenn die Tests fehlgeschlagen sind.

Die Goldregel: Starten → Warten → Überprüfen

Kein einzelnes uip tm -Verb tritt ungleich Null aus , da Tests fehlgeschlagen sind. Damit eine Pipeline bei einer roten Testausführung fehlschlägt, sind drei Befehle erforderlich:

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. Abfragen, bis die Ausführung einen Endstatus erreicht (Passed, Failed, Cancelled). Beendet 0 wenn es einen Endstatus erreicht – da „abgeschlossen“ das Erfolgssignal für wait ist. Beendet 2 auf --timeout (eine domänenspezifische Wiederverwendung des Authentifizierungsfehler-Slots, sodass Skripte bei „zu lange gedauert“ verzweigen können, ohne Text zu parsen).
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.

Verknüpfungsmuster sind vorhanden (uip or jobs start --wait-for-completion wartet z. B. wartet auf einen einzelnen Auftrag), jedoch nicht für Testsätze. Schreiben Sie immer die drei Schritte auf.

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

--project-key ist für list obligatorisch; run leitet das Projekt vom Präfix des Testsatzschlüssels ab (DEMO:10 → Projekt 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

Überschreibungen werden mit den aktuellen Parameterdefinitionen des Testsatzes durch name (keine Beachtung von Groß-/Kleinschreibung) und, falls vorhanden, type abgeglichen. Wenn der Server keine Parameterdefinitionen meldet, werden die Eingaben unverändert gesendet.

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 "Data.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 testcaselogs 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 "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"

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.