uip tm

uip tm is the Test Manager tool: it manages test projects, test cases, test sets, executions, results, reports, and attachments on a UiPath Test Manager tenant. Install it with uip tools install tm, or invoke uip tm … and let auto-install run. See Tools (plugins) for the install model and uip tools for the command that manages tool installation.

tm is the command prefix — never uip test-manager. Use the commandPrefix column from uip tools list to confirm.

资源

Each resource has its own reference page. The verb set on each page matches the commands registered by uip tm — run uip tm --help to confirm the full surface on your installation.

资源	用途
project	Create, list, update, delete Test Manager projects; set or clear the default Orchestrator folder.
testcase	Create, list, update, delete test cases; link or unlink Orchestrator automations; list result history; list test sets that contain a test case.
testset	Create, list, update, delete test sets; add or remove test cases; list contained test cases; execute a test set and return an execution ID.
execution	List executions for a test set; list test case logs for an execution; retry the failed test cases of a finished execution.
结果	Download the results of a test execution as a JUnit XML report.
report	Get a summary report (counts, pass rate, duration, failed cases) for a completed execution.
attachment	Download attachments (screenshots, logs, files) captured by test case logs in an execution.
wait	Poll a test execution until it reaches a terminal state; returns a non-zero exit code on timeout.

tm testcaselog list-assertions lives on the test case page — see testcase. It is registered as a separate testcaselog subcommand at runtime, but documented with test cases because it reads the assertion artifacts attached to a test case log.

Synopsis

uip tm <resource> <verb> [options]

Default output is --output json. All uip tm verbs honor the four global options (--output, --output-filter, --log-level, --log-file).

Typical flow

Test Manager resources form a chain. A full CI run normally walks it end to end:

1. project — one-time setup. Create the project (or reuse an existing one), and optionally pin a default Orchestrator folder so later commands can omit --folder-key.
2. testcase — author test cases and link each one to an Orchestrator package entry point with testcase link-automation. This is the step that makes them runnable.
3. testset — group test cases into an executable suite with testset create followed by testset add-testcases.
4. testset execute — start a run. Returns an ExecutionId that every downstream command takes as input.
5. wait — block the script until the execution reaches a terminal state (Passed, Failed, Cancelled). Use --timeout to cap the wait.
6. report / result / attachment — after the run: a structured summary (report get), a JUnit XML file for CI test dashboards (result download), and any captured artifacts (attachment download).
7. execution retry — optional: if the run had failures that may be flaky, re-run only the failed test case logs in place.

The same flow works ad-hoc at a terminal: each verb prints a self-contained JSON envelope with the IDs the next step needs.

Authentication and scope

Every uip tm verb resolves tenant and project context through the active session. See Authentication for sign-in; the --tenant / -t flag on every verb overrides the session default for that one call. Project scope is resolved from --project-key (or derived from --test-set-key on execution-level verbs that accept either).

退出代码

Standard CLI exit codes apply to every verb. One verb adds domain-specific behavior:

• uip tm testset execute followed by uip tm wait — see Exit codes on execution. wait exits 2 on timeout, so a script can branch on timeout vs. finish-with-failures vs. clean pass without parsing JSON. Test-failure detection itself happens via report get or result download, not via the execute command's exit code.

另请参阅

• Concepts: how UiPath CLI is organized
• Sessions — how tenant and project context are resolved.
• Scripting patterns — exit-code branching and JSON filtering for CI.
• Output formats — JSON envelope and --output-filter.