uipath-test

UiPath Test Assistant

UiPath Test Manager のプロジェクト、要件（AI によるテストケース生成、要件の評価、古くなったテストケースの検索を含む）、テストケース、テストセット、実行、ログ、欠陥、添付ファイル、結果、カスタムフィールド、ラベル、ペルソナに合わせて共有可能なテストレポートを管理します。

使用場面

Test Manager の CRUD、アップロードしたパッケージ内のすべてのテストの CI 実行、実行分析、カバレッジ、回帰傾向、失敗率、Go／No-Go サマリー、失敗した実行のトリアージ、不安定なテストと回帰の分析、失敗のエビデンス、QA エンジニア、開発者、リリースマネージャー向けの共有可能なレポート。

概念と CLI

要件ではテスト対象を定義し、テストケースではシナリオを定義します。テストケースにはテストステップを含められます。テストセットではテストケースをグループ化し、テストセットまたはテストケースを実行すると実行が作成されます。テストケースログには実行内のテストケースが記録され、ナビゲーションに使用されます。テストステップログにはステップが記録され、テストケースログのアサーションはアサーションステップです。Test Manager のAIは、要件の説明と添付ファイルをもとに動作します。テストケースの提案、要件の改善案の提示、またはリンクされたテストケースのうち古くなっているように見えるものの指摘を行います。それぞれバックグラウンドジョブとして実行され、アクティビティ ID が付与されます。欠陥とは、1 つのテストケースログから起票され、プロジェクトの欠陥トラッカー（Jira、Azure DevOps、…）に同期されるバグです。

外部 Playwright パッケージは、Orchestrator にパッケージ化してアップロードするスイートです。取り込み時に、リンク手順なしで Playwright のテストごとに 1 つのテストケースが自動作成され、それぞれに PW_Tag_*、PW_Project_*、PW_Suite_*、PW_File_* のラベルが付与されます。これらはサーバーレスのクラウドランタイムで実行されます。references/playwright-first-mile-guide.md を参照してください。

uip tm を使用します。構文を確認するには、uip tm --help および uip tm <command> <subcommand> --help を実行してください。すべての uip コマンドには必ず --output json を指定してください。以下のすべてのコマンドで必要です。

コマンド

プロジェクト、フォルダー、要件

• プロジェクト：uip tm project list --filter <NAME_OR_KEY> で名前またはキーを検索します。project create --name <PROJECT_NAME> --project-key <PROJECT_KEY> で作成します。project update --project-key <PROJECT_KEY> --name <PROJECT_NAME> で名前／説明を更新します。project delete --project-key <PROJECT_KEY> で削除します。project set-default-folder --project-key <PROJECT_KEY> --folder-key <FOLDER_KEY> で既定の Orchestrator フォルダーを設定します。project clear-default-folder --project-key <PROJECT_KEY> で解除します。project owners list --project-key <PROJECT_KEY> [<PROJECT_KEY> ...] で所有者を一覧表示します。
• 権限：uip tm project-permissions get は Data.Permissions（呼び出し元がそのプロジェクトで持つ権限名）と Data.Count を返します。Project.Read が必要なため、get が成功した場合は必ず Project.Read が含まれます（Count >= 1）。読み取りアクセス権がない場合は 403（または表示できないプロジェクトの場合は 404）となり、空の配列を含む Success が返されることはありません。公開されているのは get のみです。
• プロジェクト設定：uip tm project settings get --project-key <PROJECT_KEY> でタイムゾーン、実行名の形式、ステップ上限、既定のフォルダー、ガバナンスを読み取ります。project settings update --project-key <PROJECT_KEY> [--time-zone <IANA_NAME>] [--execution-name-format <TEMPLATE>] で、最初の2項目のみを書き込みます。IANA 名、プレースホルダー、読み取り専用フィールド、一部だけ適用される更新については、references/project-settings-guide.md を参照してください。
• uip or folders list -n <name> --all --output json でフォルダーキーを取得できます。現在のユーザーに表示されるすべてのフォルダーが返されます。
• uip tm requirements を先頭に付けます：list --project-key <PROJECT_KEY>；list-by-test-execution --project-key <PROJECT_KEY> --execution-id <uuid>；get --project-key <PROJECT_KEY> (--requirement-id <uuid> | --requirement-key <key>)（UUID とキーは相互排他的です）；create --project-key <PROJECT_KEY> --name <name>；update --project-key <PROJECT_KEY> --requirement-id <uuid>（名前／説明を更新し、--name または --description の少なくとも一方が必要です）；delete --project-key <PROJECT_KEY> --requirement-ids <uuid...>（複数の ID を指定）；export --project-key <PROJECT_KEY> --output-file <path>（.xlsx をエクスポート）；list-testcase-ids --project-key <PROJECT_KEY> --requirement-id <uuid>；testcases --project-key <PROJECT_KEY> --requirement-id <uuid> (--add-testcase-ids <uuid...> | --remove-testcase-ids <uuid...>)（追加／削除の指定は相互排他的です）。
• プロジェクト全体を移動またはバックアップするには、uip tm project export → uip tm project import（.tmh パッケージ）を使用します：references/project-migration-guide.md。ジョブは uip tm migration get|list|download で読み取ります。パッケージスキーマは uip tm migration schemas list|download で確認できます。
  • どちらも数分かかるジョブです。--wait を渡してください（エクスポートでは --output-file も指定します）。指定しない場合は、migration get で確認するジョブ ID が返されます。進行状況を確認するために、エクスポートまたはインポートをもう一度開始しないでください。
  • 自動化はデフォルトで含まれます（--exclude automation で除外）。ガバナンス、プロジェクト設定（Test Cloud のみ。それ以外では 403）、プロンプトを含めるには --include を指定します。
  • テストセットの移行形式は .tmh のみです。テストケースと要件は Excel にもエクスポートできます（testcases export、requirements export）。形式や目的を指定せずに「エクスポートして」と依頼された場合は、どれを使うか確認してください。
  • インポートの前に、既存のプロジェクトに取り込むか、新しいプロジェクトにするか（--create-project）を確認してください。キーが使用済みの場合は、--new-project-key を指定するか確認してください。

要件に関する AI

uip tm requirements generate-testcases、uip tm requirements evaluate、uip tm requirements find-obsolete-testcases は、それぞれバックグラウンドの AI ジョブを実行して ActivityId を返します。開始するたびに AI ユニットを消費します。1 回だけ開始し、その後は --activity-id <ACTIVITY_ID> を再利用して待機、表示、作成、リンク解除、削除を行ってください。再試行のために再度開始しないでください。 待機時間の上限には --timeout 540 を指定し、シェルの制限時間は 600 秒にしてください。シナリオ、フィールドの意味（Score、ConfidenceLevel）、結果のルールについては、references/requirement-ai-guide.md を参照してください。

テストケース

• uip tm testcases create --project-key <PROJECT_KEY> --name <TEST_CASE_NAME>で作成します。list --project-key <PROJECT_KEY>は一覧表示します。任意の--filter <text>は名前／キーをPREFIXで照合し、部分文字列では照合しません。update --project-key <PROJECT_KEY> --test-case-key <TEST_CASE_KEY> --name <TEST_CASE_NAME>は名前、説明、事前条件、または事後条件を更新します。少なくとも1つのフィールドが必要です。delete --project-key <PROJECT_KEY> --test-case-key <TEST_CASE_KEY>はキーを指定して削除します。
• link-automation --project-key <PROJECT_KEY> --test-case-key <TEST_CASE_KEY> --folder-key <FOLDER_KEY> --package-name <PACKAGE_NAME> --test-name <TEST_NAME>はOrchestratorパッケージのオートメーションをリンクします。任意の--entry-point-id <PACKAGE_ENTRY_POINT_ID>（list-automationsから取得）を指定すると、IDで紐付け、--test-nameより優先されます。unlink-automation --project-key <PROJECT_KEY> --test-case-key <TEST_CASE_KEY>はリンクを解除します。list-automations --project-key <PROJECT_KEY> --folder-key <FOLDER_KEY>はフォルダーのテストエントリポイントを一覧表示します。任意で--package-name <PACKAGE_NAME>を指定できます。各行にはPackageEntryPointIdが含まれます。list-testsets --project-key <PROJECT_KEY> --test-case-key <TEST_CASE_KEY>は、そのテストケースを含むセットを一覧表示します。
• uip tm testcases（フラグは--helpで確認）を使用して、テストケースを検索、棚卸し、コピー、一括作成します。
  • 「Xのラベルが付いたケースを含むセットはどれですか」という質問には、ケースごとにループせず、list-testsets --labels Xを1回実行します。明示的に割り当てられたセットのみが表示され、動的ラベルによってケースを取り込むセットは表示されないことを伝えてください。
  • cloneはキーを返さずにAcceptedを返し、バックグラウンドでコピーします。手順は最後にコピーされます。Instructionsのlist --filterを使ってコピーを探してください。確認や再試行のために再度クローンしないでください。5xxエラーの後は、コピーが存在する可能性があるため、まず一覧表示してください。ラベル、ドキュメント、要件、パラメーターは、--includeを指定した場合にのみコピーされます。
  • bulk-create --fileは、{"name", "labels": [...], "steps": [{"description", "expectedResult"}]}のJSON配列を受け取ります。名前は一意ではないため、再実行すると重複が作成されます。既存の名前が含まれている可能性がある場合は、--skip-existingを指定してください。ファイルエラー（終了コード3）の場合、何も作成されません。後続のバッチが失敗しても、先行するバッチは残ります。内容を報告し、再実行する前に確認してください。KeysResolved: falseでも作成済みです。
  • list --automatedでは、Playwrightにリンクされたケースは除外されます。group-byで403が発生した場合（ライセンスまたは機能が無効）、処理を中止してユーザーに伝えてください。
• 手順：uip tm testcases steps list --project-key <PROJECT_KEY> --test-case-id <TEST_CASE_ID>は、--test-case-keyではなく--test-case-id <UUID>を指定して手動手順を一覧表示します。steps get --project-key <PROJECT_KEY> --step-id <UUID>は取得します。steps add --project-key <PROJECT_KEY> --test-case-id <UUID> --description <text>はフラグ形式の手順を追加します（--descriptionは必須です）。または、steps add --project-key <PROJECT_KEY> --test-case-id <UUID> --step '<json>' [--step '<json>' ...]でJSON形式の手順を複数追加できます（フラグ形式とは同時に使用できず、アトミックではありません。後続の追加に失敗しても、それ以前の手順は残ります）。steps update --project-key <PROJECT_KEY> --step-id <UUID>は、渡されたフィールドのみを更新します。steps move --project-key <PROJECT_KEY> --step-id <UUID> --target-position <n>は、0から始まる位置に移動します。steps delete --project-key <PROJECT_KEY> --step-id <UUID> --yesは削除します。
• list-result-history --project-key <PROJECT_KEY> --test-case-id <TEST_CASE_ID>は履歴を一覧表示します。任意で--only-failed、--filter、--limit、--offsetを指定できます。run --project-key <PROJECT_KEY> --test-case-id <TEST_CASE_ID> --name <EXECUTION_NAME> --execution-type <manual|automated|none|mixed>は、スペース区切りで指定した1つ以上のテストケースUUIDに対する実行を開始します。任意で--async、--folder-key、--robot-user-key、--machine-keyを指定できます。
• uip tm testcases add --test-set-key <TEST_SET_KEY> (--test-case-keys <KEY1> <KEY2> … | --labels <Label1> <Label2> …)は、明示的なキー、または少なくとも1つのラベルが付いたすべてのテストケースを追加します。セレクターは同時に使用できず、複数の値をスペース区切りで指定します。キーはカンマ区切り形式（DEMO:1,DEMO:2）も受け付けますが、ラベルは受け付けません（--labels A,Bは1つのラベルです）。ラベルの照合はOR条件で、完全一致かつ大文字小文字を区別しません。スペースを含むラベルは引用符で囲んでください。--dynamicを指定しない場合、--labelsは現在一致するケースを一度だけセットにコピーします。後からラベルが付いたテストケースは追加されません。uip tm testcases remove --test-set-key <TEST_SET_KEY> --test-case-keys <KEY1,KEY2,...>は、カンマ区切りで指定した静的なリンクを削除します。動的ラベルのみによって含まれているテストケースに対しては、コマンドは成功しますが何も行いません。その場合は、テストケースのラベルまたはセットの動的ラベルを変更してください。
• テストケースを動的に割り当てます（メンバーシップはラベルに従います）：uip tm testcases add --test-set-key <TEST_SET_KEY> --labels <Label1> <Label2> … --dynamicは、ラベルをテストセットに保存します。指定したラベルの少なくとも1つが付いたすべてのテストケース（OR条件、完全一致、大文字小文字を区別しない）がセットの一部となり、後からラベルが付いたテストケースも含め、毎回の実行に含まれます。既存のラベルと統合され（最大30個）、静的なリンクは維持されます。DynamicLabelsとMatchedTestCasesを返します。--dynamicと--limitおよび--test-case-keysは併用できません。uip tm testcases remove --test-set-key <TEST_SET_KEY> --dynamic [--labels <Label1> …] --yesは指定したラベルを削除します。--labelsを省略するとすべて削除されます（ResultはRemoved、Cleared、またはNotSet）。外部ソースにリンクされたテストセットでは使用できません。ラベルを追跡する必要があるスイート（CIで「smokeのラベルが付いたすべて」など）には--dynamicを選択し、固定スナップショットには指定しないでください。uip tm testcases add --helpに--dynamicが表示されない場合、CLIのバージョンが古いため、--dynamicを付けずに--labelsを使用し、ラベルが変更されたら再実行してください。
• パラメーター（uip tm testcases parameters、テストケースのみ）：値を指定するフラグは--valueではなく--default-valueです。
  • 名前はテストケースごとに一意で、大文字小文字を無視して完全一致で照合されます。曖昧検索は行われません（User name ≠ Username）。list --searchで存在を確認し、Nameが完全一致するか確認してください。結果が空の場合は存在しないことを意味し、Rule 4/10による中止の対象ではありません。近似する名前がある場合は、最も近い名前でよいかユーザーに確認してください。
  • 既存のパラメーターは、「add」のリクエストで値が異なっていても、決して変更しないでください。そのパラメーターに対してupdateを実行しないでください。単一追加の場合は、すでに存在することを伝え、別の名前を確認してください。複数のテストケースへの追加では、そのパラメーターをスキップして値を変更せず、スキップしたものとして列挙してください。存在しない名前の変更を求められた場合は、作成する前に確認してください。使用中の名前への変更は拒否されます。その旨を報告してください。削除は確認してください（Rule 5）。
  • deleteは何も削除されなかった場合でもSuccessを返します。Data.Passed／Data.Failedを報告してください。複数のテストケースへの追加では、各ケースに対してlistを実行し、不足している名前のみaddで追加してから、テストケースごとに追加分とスキップ分を要約してください。
• run、steps list、steps add、list-result-history、testcaselog start／finishでは、--test-case-id <UUID>を使用します。IDはuip tm testcases list --output json（Id）から取得するか、開いたばかりの実行に結果を記録する場合は、その実行独自のログから取得します。ログからは1回の呼び出しですべてのIDを取得できます（「実行のライフサイクル」を参照）。update、delete、link-automation、unlink-automation、list-testsetsでは、単数形の--test-case-key <PROJECT_KEY:NUMBER>を使用します。テストセットの一括メンバーシップには、カンマ区切りの--test-case-keys <KEY1,KEY2,...>を使用します。steps listとaddを除くすべてのstepsコマンドでは、--step-id <UUID>を使用します。IDはsteps list（Id）から取得してください。

テストセットと実行

• uip tm testsets create --project-key <PROJECT_KEY> --name <TEST_SET_NAME>。必要に応じて --dynamic-labels <Label1> … を指定すると、これらのラベルに基づいてテストケースが動的に割り当てられたセットを作成します（DynamicLabels、MatchedTestCases を返します）。list --project-key <PROJECT_KEY> では、必要に応じて --filter <text>、--folder-key、--include-last-execution を指定できます。update --test-set-key <TEST_SET_KEY> --name <TEST_SET_NAME> は名前と説明を更新します。delete --test-set-key <TEST_SET_KEY>。list-testcases --project-key <PROJECT_KEY> --test-set-key <TEST_SET_KEY> は、実行時に実行されるケース（静的リンクと動的ラベルの一致分）を AssignmentType の Static、Dynamic、Both とともに一覧表示します。get-dynamic-assignment --project-key <PROJECT_KEY> --test-set-key <TEST_SET_KEY> は、DynamicLabels（該当なしの場合は []）と MatchedTestCases を返します。
• uip tm testsets run --test-set-key <TEST_SET_KEY> は実行し、実行 ID を返します。必要に応じて --execution-type <automated|manual|mixed|none>（既定値は automated）、--input-path <FILE>、Playwright の場合は --playwright-project <name> を指定できます。uip tm testsets playwright-context --test-set-key <TEST_SET_KEY> はステータスを確認し、IsPlaywright、利用可能なプロジェクト、選択済みプロジェクトを返します。
• キーの形式は PROJECT_KEY:NUMBER です。メンバーシップの追加・削除（静的または --dynamic）には、testsets の動詞ではなく uip tm testcases add／uip tm testcases remove を使用します。Playwright セットでは、--playwright-project <name> に大文字と小文字を区別する playwright.config の名前を 1 つ指定します（実行ごとに指定できるプロジェクトは最大 1 つ）。選択内容は保持されます。すべてのテストケースは、同じ Playwright パッケージに属している必要があります。名前が不明な場合は、有効な名前を一覧表示してすぐにエラーになります。まず playwright-context で確認し、IsPlaywright に応じて処理を分岐してください。どちらの機能も、Test Manager の Playwright サポートと、外部パッケージコマンドを含む CLI が必要です。利用可否の確認と、サポートがない場合の対応から始まる references/playwright-first-mile-guide.md を参照してください。
• uip tm testsets（get、clone、set-execution-order、settings get、settings set、assign-user、set-folder、set-robot、set-execution-target、autoselect-packages、group-by、list --labels）でセットを設定します。
  • clone は完了を待機して、コピーの TestSetKey を返します。--no-wait を指定すると、キーなしで Accepted を返します。タイムアウトは失敗を意味します。処理を中止し、決して再度クローンしないでください。名前は重複可能なため、ほかのどのセットとも重複しない名前をコピーに付けてください。フォルダー、ロボット、パッケージ、強制フラグ、実行順序はコピーされません。
  • set-execution-order では、割り当てられたすべてのケースを列挙する必要があります（先に list-testcases を実行してください。実行順序は表示されません）。実行がこの順序に従うのは、settings set --enforce-execution-order を設定した後だけです。
  • settings で書き込み可能なのは強制フラグのみです。失敗時停止、カバレッジ、動画、リモート制御、Autopilot は読み取り専用であることを伝えてください。
  • 名前を指定するオプション（--folder-path、--robot-name、--assignee-email）は Orchestrator で解決されます。そこで、または set-execution-target／group-by（ライセンスまたは機能が無効）の実行時に 403 が発生した場合は、処理を中止してユーザーに伝えてください。autoselect-packages は何も保存しません。
• uip tm executions list --project-key <PROJECT_KEY> は上位 n 件を一覧表示します。必要に応じて --test-set-id <UUID>、--filter <text>、--status、--execution-type、--execution-finished-interval、--limit、--offset を指定できます。一般的な単一テストセットまたは単一プロジェクトのクエリには、このコマンドを使用してください。list-filtered --project-key <PROJECT_KEY> は --test-set-id、--status、--execution-type、--execution-finished-interval、--limit、--offset に加えて、--updated-by、--labels、--test-execution-ids、--sort-by を受け取ります。--filter はありません。ここでの名前検索には --search を使用します。ラベルによるフィルタリング、複数の実行 ID、カスタム順序、または --updated-by を使う場合に使用してください。どちらも同じ列挙値を受け付けます。値は小文字で、それ以外は拒否されます。--status <pending|running|cancelling|finished|cancelled>、--execution-type <manual|automated|none|mixed|autonomous>、--execution-finished-interval <lastHour|lastDay|lastWeek|last15Days|last30Days>。応答では Status が大文字で表示されます（Running、Finished）。応答の値をフィルターとして再入力しないでください。
• get-stats --execution-id <EXECUTION_ID> --project-key <PROJECT_KEY> は、実行の合格／不合格／未設定の合計を集計します（report get も完了した実行を要約します。executions list／list-filtered の各行には、実行ごとの集計は含まれません）。run --execution-id <EXECUTION_ID> --execution-type <TYPE> は再実行します。必要に応じて --test-case-log-ids <UUID...>（スペース区切り）と --async を指定できます。retry --execution-id <EXECUTION_ID> は失敗したケースのみを再試行します。必要に応じて --project-key、--test-set-key、--execution-type を指定できます。testcaselogs list --execution-id <EXECUTION_ID> --project-key <PROJECT_KEY> はケースログを一覧表示します（--only-failed、--filter、--limit、--offset）。これはネストされたコマンドであり、トップレベルの executions の動詞ではありません。テストケース UUID には uip tm testcases run、テストセットキーには uip tm testsets run、実行の再実行には uip tm executions run を使用してください。

実行ライフサイクル

uip tm testsets run --test-set-key <KEY> --execution-type manual で手動実行を開始します（ID は Data.ExecutionId です。executions create 動詞はありません）。各 --test-case-id は、実行独自のログから uip tm executions testcaselogs list --execution-id <ID> で取得し、testcaselog start／finish で各ケースを記録します。最後のログが完了すると、手動実行は自動的に終了します。executions finish は、ログを開いたまま残した実行を強制終了するためのものであり、通常の最終ステップではありません。set-reporting-date には、すでに終了済みの実行（Status ではなく ExecutionFinished）が必要です。手動実行と自動実行の違い、フィルター付き読み取り、cancel／delete／finish／export／set-reporting-date に関するすべての注意事項、および終了コードの仕様については、references/executions-guide.md を参照してください。フラグと列挙値は -h で確認できます。

テストセットのスケジュール

• 動詞（フラグは --help で確認）：uip tm schedules create|update|list|next-runs|enable|disable|delete。読み取り操作は list のみで、ID による取得はありません。そのため、update の前に list で値を確認してください。update は定義全体を置き換えるため、維持したいフラグはすべて指定してください。また、有効状態は変更できないため、enable／disable を使用してください。delete と --all には --yes が必要です。
• --cron は秒から始まる6 フィールドまたは 7 フィールドの式で、Unix cron 形式ではありません（毎日 02:00 の場合は 0 0 2 1/1 * ? * です。CLI は 5 フィールドの式をクライアント側で拒否します）。--cron-details は繰り返し設定の JSON で、すべての繰り返しタイプで必須です。--start-time／--disable-time は、--timezone で解釈される壁時計時刻 YYYY-MM-DDTHH:mm です。秒や Z を付けると拒否されます。next-runs には list が出力する ID を渡してください。内部のエンドポイントは別の GUID をキーとしており、不正な ID には 200 と空のリストを返します。cron／繰り返し設定のルールと注意点については、references/schedules-guide.md を参照してください。

アップロード済みパッケージを実行する（CI）

uip tm run --type package --package-name <PACKAGE_NAME> --package-version <VERSION> --folder-path <FOLDER_PATH> --project-key <PROJECT_KEY> --output json は、Orchestrator にすでにアップロードされているパッケージ内のすべてのテストを実行し、--max-retries <N> で失敗したテストを再実行して、レポートを書き出します。まず uip rpa pack ／ uip or packages upload でパッケージを作成してアップロードしてください。

• <VERSION> は uip or packages versions <PACKAGE_NAME> --folder-path <FOLDER_PATH> --output json で取得してください。アプリのバージョン（1.0）を指定すると、最新の 1.0.x パッチが実行されます。特定のバージョンを指定する場合は最新のパッチである必要があり、古いバージョンを指定すると、何も作成されずに終了コード 3 で終了します。
• CI ステップの制限時間より短い値を --timeout <SECONDS> に指定してください（デフォルトは 7200 です）。先にステップが強制終了されると、レポートは作成されません。
• RunPackageTestsFailed または RunPackageCancelled を伴う終了コード 1 はテスト結果です。結果を報告し、ルール 10(d) を参照してください。終了コード 4 はタイムアウトです。実行はまだ続いている可能性があり、Data.OutputPath には未完了のテストをスキップとして示した途中までのレポートが格納されます。タイムアウトを報告してください。スキップされたテストを合格として数えてはいけません。それ以外のすべての非ゼロ終了コードでは停止してください（ルール 10）。
• どのテストでも宣言されていない --input-path の名前は Data.IgnoredInputs に列挙されます。ユーザーに伝えてください（通常は入力ミスです）。

ログ、レポート、添付ファイル、結果

• uip tm testcaselog start --project-key <PROJECT_KEY> --execution-id <EXECUTION_ID> --test-case-id <TEST_CASE_ID> で開始します。任意で --run-id <NUMBER> を指定できます。finish --project-key <PROJECT_KEY> --execution-id <EXECUTION_ID> --test-case-id <TEST_CASE_ID> --result <None|Passed|Failed|Restricted> --has-error <true|false> --executed-by <EMAIL> で終了し、結果を記録します（--result、--has-error、--executed-by の3つはすべて必須です）。これにより、手動実行のテストケースが Failed として記録されます。--executed-by にはメールアドレスを指定しますが、空でないことが検証された後に破棄されます。保存される ExecutedBy は認証済みの呼び出し元です。そのため、指定した人物に結果が帰属したとユーザーに伝えてはいけません。任意で --detail-link <URL>、--run-id、--is-post-condition-met、--step-logs <json> または --step-logs-file <path> を指定できます。start には既存の実行が必要です。executions create はありません。uip tm testcases run … --execution-type manual または testsets run … --execution-type manual で実行を開始してください。
• ログを読み取るには、testcaselog list（--results／--statuses／--labels／--search／--assignees で絞り込みます。日付や実行での絞り込みには対応していません。実行を絞り込むには executions testcaselogs list を使用します）、get --test-case-log-id <ID>（--include-assertions）、latest --test-case-ids <ID...>（各ケースの最新ログ）を使用します。**結果が上書きされるのは、Result と OriginalResult の両方に値が設定されていて、かつ異なる場合のみです。OriginalResult が空なら、上書きされていません。**確定した結果を修正するには、override create|update|delete|get を使用します（create には --result と --reason が必要です）。失敗を割り当てるには、assign --assignee-email <EMAIL>（CLI が解決します）または --assignee-id <IDP_UUID>（UUID）を使用します。全コマンドと注意点については、references/testcaselog-guide.md を参照してください。
• uip tm testcaselog list-assertions --project-key <PROJECT_KEY> --test-case-log-id <TEST_CASE_LOG_ID> でアサーションを一覧表示します。render-assertions はアサーションを Markdown として返します。get-robot-logs は有効期限付きリンクを返します（または --output-file でダウンロードします）。uip tm teststeplog list --project-key <PROJECT_KEY> --test-case-log-id <TEST_CASE_LOG_ID> でステップログを一覧表示します。
• uip tm report get --execution-id <EXECUTION_ID> (--project-key <KEY> | --test-set-key <KEY>) で完了した実行の概要を取得します。プロジェクトを特定するオプションは、ちょうど1つ指定する必要があります。--execution-id のみを渡すと、Provide --project-key or --test-set-key で終了します。
• uip tm attachment download --execution-id <EXECUTION_ID> でテストケースの添付ファイルをダウンロードします。attachment upload --object-id <UUID> --object-type <type> --file <path> で、--object-type testCaseLog などの Test Manager オブジェクトにアップロードします。uip tm result download --execution-id <EXECUTION_ID> で JUnit XML をダウンロードします。必要に応じて --project-key、--test-set-key、--result-path <DIR> を指定できます。
• 単一ファイル（uip tm attachment、upload は AttachmentId を返します）：まずオブジェクトを検索し（list --test-case-keys／--requirement-keys）、FileName でファイルを選んでから、その AttachmentId を使用します。一致するものがない場合や同名ファイルが複数ある場合は、確認してください。
  • list は、--source を渡さない限り userBased ファイルのみを表示します（ロボットまたは Studio のエビデンス：orchestrator、studio、taskCapture）。解決できないキーは、ほかの結果と並んで Unresolved に表示されます。これらを明示してください。不明な --object-ids の ID も AttachmentCount: 0 と表示されます。
  • --object-type は親オブジェクトの種類であり、ファイルの種類ではありません。誤った値でも処理が成功する場合があります。
  • download --attachment-id は、--result-path／--output-file を指定しない場合、サーバー上の名前で現在のフォルダーに書き込みます。既存のファイルを置き換えることはありません。already exists の場合は処理を停止して確認してください。--overwrite を渡すのは、ユーザーから指示があった場合のみです。
  • update で変更できるのは名前のみです（--file-name）。--all は呼び出しごとに1ページ分です。Pagination に従ってください。削除する前に確認してください（Rule 5）。
• ファイルの出力：uip tm testcases export（テストケースを .xlsx に出力します。--test-case-ids を指定しない場合はプロジェクト全体が対象です）および uip tm report export（実行のレポートは --execution-id --format excel|pdf|junit、選択した結果を PDF にする場合は --test-case-log-ids を指定します。2件以上の場合は1つの .zip になります）：
  • ユーザーがファイルを求めている場合は、--wait --output-file <path> を渡してください。--wait を指定しない場合はジョブの開始のみとなります。Initiated／InProgress の間は uip tm export-jobs get --job-id を使ってポーリングし、Failed／Cancelled で停止してください。その後、Instructions に表示されるとおりに attachment download --attachment-id <AttachmentId> を実行します。状況を確認するために同じエクスポートを二度開始してはいけません。
  • 既存の --output-file は処理の開始前に拒否されます。確認し、指示された場合のみ --overwrite を渡してください。
  • export-jobs get には、ジョブを開始したプロジェクトが必要です（それ以外のプロジェクトでは 404 が返されます）。テナントで JUnit が無効になっている場合（feature is not enabled）や、結果の PDF で 403（ライセンス）が返される場合は、その旨を報告し、再試行しないでください。

Playwright パック

uip tm pack --project-path <dir> --type playwright --project-key <PROJECT_KEY> --name <PackageName> --package-version <ver> -o <out-dir> は Playwright スイートを .nupkg にパックします。ロックファイルと @playwright/test が必要です。--package-version は NuGet/SemVer 形式で、3 個または 4 個の数値パートと、任意のプレリリース／ビルドサフィックスを指定します（1.0.0、1.0.0.0、1.0.1-beta.1）。1.0 と数値以外の値は拒否されます。--project-key はテストケースを自動取り込みする Test Manager プロジェクトを指定します。--no-create-test-cases を指定すると自動取り込みをスキップし、--dry-run でプレビューできます。uip or packages upload <nupkg> でアップロードします。パッキングはオフラインで実行され、認証は不要です。アップロード → 取り込み → ラベル入力 → 実行のパイプラインについては、references/playwright-first-mile-guide.md を参照してください。

不具合

uip tm defects create | list | get | update | delete | get-external-issue | get-related | attachments list|download — 失敗した結果から不具合を登録し、ステータス／優先度／トラッカーのリンクを変更して、追跡します。不具合は UUID のみで識別されます。executions testcaselogs list の DefectId を使って、結果に関連付けられた不具合を検索してください。defects を呼び出す前に、必ず references/defects-guide.md を読んでください。update と delete は 10～40 秒かかることが多いため、シェルのタイムアウトは少なくとも 120 秒に設定する必要があります。

待機とユーザー

uip tm wait --execution-id <EXECUTION_ID> は終端状態になるまで待機します。必要に応じて --project-key、--test-set-key、--timeout <SECONDS> を指定できます。uip tm user get は認証済みユーザーのプロフィールを取得します。

カスタムフィールド

プロジェクトスコープのカスタムフィールド定義（Requirement／TestCase／TestSet に関連付け）と、オブジェクトごとの label および value 行を、uip tm customfield … で操作できます。コマンドの全容（スコープ、--object-type／--data-type の列挙値（大文字と小文字を区別：Requirement|TestCase|TestSet、Text|Label）、--values の JSON セマンティクス、すべての label／value 操作）：references/custom-fields-guide.md。

オブジェクトラベル

Requirement、TestCase、TestSet、TestExecution、TestCaseLog のメタデータに、uip tm objectlabel … でタグを付けます。アンチパターン（ラベル ID とオブジェクト ID の混同、--remove-other-labels による非表示の内部ラベルの削除）については、references/object-labels-guide.md を参照してください。

重要なルール

1. 必ず最初にログインを確認してください： Test Manager の操作を行う前に、uip login status --output json を実行してください。未認証の場合は、uip login を実行してください。
2. すべての uip コマンドに、例外なく必ず --output json を指定してください。
3. 失敗した uip コマンドの再試行は最大3回までです。 3回失敗したら停止してエラーを報告してください。REST API を直接使用してはいけません。
4. リストが空の場合は、null キーで処理を続行せず、操作を停止してユーザーに知らせてください。例外：空の tm testcases list --filter は、プレフィックスが一致していない可能性があります。ルール8のプレフィックスフォールバックを使用し、それでも何も見つからない場合にのみ停止してください。フィルターを適用したプロジェクトまたはカスタムフィールドの検索結果が空の場合は、実際に結果が空であるため、通常どおり停止してください。
5. 削除前に確認してください： ユーザーがその削除を明示的に許可済みでない限り、対象リソースのキーを確認してください。削除には必ず --yes または -y が必要です。指定がない場合、削除せずに終了してください。
6. フォルダーキーが必要な場合、ユーザーがフォルダーを指定しているときは uip or folders list -n <folder-name> --all --output json を使用してください。自分で選ぶ場合は --all を省略し、メンバーフォルダーのみを一覧表示してください。フォルダー管理の詳細については /uipath-platform を実行してください。
7. 推測する前に調べてください： オートメーション名、フォルダーキー、プロジェクト ID、テストケースキーを推測してはいけません。uip tm testcases list-automations や uip or folders list -n <folder-name> --all など、該当する一覧コマンドを最初に実行してください。
8. 名前付きエンティティの一覧取得は、サーバー側で絞り込んでください： 名前、キー、ラベル、タグが指定された場合は、絞り込みフラグを確認するために uip tm <resource> list --help または uip or <resource> list --help を調べ、それを使用してください。すべてを一覧表示してからクライアント側で絞り込んではいけません。これは uip tm と uip or のすべてのエンティティに適用されます。例外：tm testcases list --filter はプレフィックス一致です。名前の途中の語句で検索して結果が0件の場合は、より広い文脈的なプレフィックスで再試行してください。使用可能なプレフィックスがない場合に限り、--filter なしで再度一覧表示し、ルール11に従ってすべてのページを確認してから、該当項目がないと判断してください。
9. 既定フォルダーの復旧： uip tm testcases run と uip tm testsets run には、プロジェクトの既定フォルダーが必要です。まず実行を試みてください。失敗メッセージに "Message": "HTTP 400: Please assign folder to project level before executing testcases." が正確に含まれ、かつ errorCode: itemNotFound の場合に限り、uip tm project set-default-folder --project-key <PROJECT_KEY> --folder-key <FOLDER_KEY> --output json を実行してから、1回だけ再試行してください。キーは uip or folders list -n <folder-name> --all --output json で取得してください。他のエラーをフォルダー不足と解釈してはいけません。使用できない既定値の場合は、内容が不明瞭な HTTP 5xx になります。存在しないフォルダーキーの場合は、errorCode: unknown を伴う "HTTP 400: Internal Server Error." になります。どちらもルール10に従って停止してください。動作中の既定フォルダーを上書きしてはいけません。任意のフォルダーは Test Manager に拒否され、後続の実行に支障をきたす可能性があります。これはルール10に対する、実行時に名前が指定された場合の唯一の例外です。それ以外の実行失敗はすべて停止してください。
10. uip の失敗または曖昧さがあれば、必ず停止してユーザーに確認してください： これには、コマンドエラー、不正な出力、不明瞭なフラグや値、複数の一致、識別子の欠落、予期しないスキーマが含まれます。REST にフォールバックしてはいけません。次の、正確に特定された想定内の結果のみ例外です。(a) ルール9に記載されたフォルダー不足エラー。該当ルールに従って処理してください。(b) uip tm wait が終了コード2で終了し、Timed out after <N>s waiting for execution '<EXECUTION_ID>'. Last status: <status>. が表示された場合。これは、設定されたタイムアウトが正常に機能したことを意味します。未完了であることを報告し、残りの手順を続けてください。Polling failed/interrupted/aborted ... と終了コード1は、実際の待機失敗です。(c) 要件 AI コマンドが ErrorCode: timeout を伴って終了コード2で終了した場合。ジョブはまだ実行中です。新たに開始するのではなく、Instructions に記載された --activity-id … --wait コマンドで再開してください。(d) uip tm run --type package が終了コード1で終了し、"Code": "RunPackageTestsFailed" または "RunPackageCancelled" と "ErrorCode": "execution_failed" が返された場合。これは、実行が失敗またはテストなしで終了したか、キャンセルされたことを意味します。Data（件数、OutputPath、ExecutionUrl）を報告し、再試行してはいけません。それ以外の失敗はすべて停止してください。
11. 項目がないと結論付ける前に、すべてのページを確認してください： 一覧レスポンスには Data のみが含まれ、合計数、カーソル、次のページがあるかどうかを示すフラグはありません。--limit（デフォルトは50）と同数の行が返されたページには、さらに結果がある可能性があります。必要な項目がそのページにない場合は、ページサイズ分だけ --offset を増やして同じ一覧コマンドを再実行し、行数がページサイズを下回るページが返されるまで続けてください。ページサイズの上限は100です。--limit に100を超える値を指定すると、HTTP 400 … Page size cannot be greater than 100. で失敗します。tm testcases list のように --limit／--offset がない一覧では、代わりにフィルターフラグを使って絞り込んでください（ルール8）。

クイックスタート

1. 認証状態を確認します：uip login status --output json を実行します。未認証の場合は、uip login を実行します。必要に応じて、uip login tenant set <TENANT_NAME> --output json でテナントを設定します。認証の詳細については、/uipath-platform を実行してください。
2. Test Manager を呼び出す前に、プロジェクト名またはキーを確認します。複数のプロジェクトがある場合は、すべての名前またはキーを 1 つのプロンプトで収集します。各プロジェクトについて、uip tm project list --filter <NAME_OR_KEY> --output json で解決します。一致するものがない場合は処理を中断して質問し、複数一致する場合は候補を提示してユーザーに選択を求めます。以降は確認済みの PROJECT_KEY を再利用します。
3. 必要に応じて、次のコマンドを使用します：uip tm testsets list --project-key <PROJECT_KEY> --filter <TEST_SET_NAME_OR_KEY> --output json；uip tm testsets list-testcases --project-key <PROJECT_KEY> --test-set-key <TEST_SET_KEY> --output json；uip tm executions list --project-key <PROJECT_KEY> --test-set-id <TEST_SET_ID> --limit 100 --output json；uip tm executions testcaselogs list --execution-id <EXECUTION_ID> --project-key <PROJECT_KEY> --output json；uip tm testcaselog list-assertions --project-key <PROJECT_KEY> --test-case-log-id <TEST_CASE_LOG_ID> --output json；uip tm teststeplog list --project-key <PROJECT_KEY> --test-case-log-id <TEST_CASE_LOG_ID> --output json。

トラブルシューティング

REST API で 401 Unauthorized が発生した場合は、uip login を実行して再認証します。予期しないコマンドエラーが発生した場合は、まず uip tm <command> --help で構文を確認し、次に uip login status --output json で認証状態を確認します。続行するかどうかは、引き続き重要ルール 10 に従って判断します。

ワークフローを選ぶ

• テストケースログの読み取り、修正（override）、割り当て、手動記録、および Result と OriginalResult の違い：references/testcaselog-guide.md
• 1 つのテナント内またはテナントや環境をまたいで、プロジェクトをバックアップ、コピー、移動する方法（uip tm project export → import）：references/project-migration-guide.md
• 実行のライフサイクル（手動での開始／記録／終了）、フィルターを使った読み取り、キャンセル、削除、xlsx エクスポート、レポートの日付（uip tm executions）：references/executions-guide.md
• 失敗した実行の根本原因、アサーション、ステップログ、証跡、および不安定なテストとリグレッションの分析：references/failure-triage-guide.md
• 失敗結果から不具合を起票し、テストケース／要件まで追跡して、トラッカーの課題にリンクする方法（uip tm defects）：references/defects-guide.md
• 要件に対する AI の利用：テストケースの提案と作成、要件の評価、古くなったテストケースの検索とリンク解除または削除（uip tm requirements generate-testcases、evaluate、find-obsolete-testcases）：references/requirement-ai-guide.md
• テスターやリリースマネージャーと共有できるレポート：references/test-result-report-guide.md
• プロジェクトをパブリッシュして Test Manager のテストケースにリンクする方法（Studio/RPA）：references/publish-and-link-guide.md
• サーバーレス環境での Playwright のパッケージ化、取り込み、ラベル付け、実行：references/playwright-first-mile-guide.md
• スケジュールに沿ったテストセットの実行、cron 形式、単一バッチと一括バッチの動作（uip tm schedules）：references/schedules-guide.md
• カスタムフィールドの定義、ラベル、値（uip tm customfield）：references/custom-fields-guide.md
• テストエンティティのオブジェクトラベル／タグメタデータ（uip tm objectlabel）：references/object-labels-guide.md
• プロジェクトのタイムゾーン、実行名の形式、読み取り専用の項目（uip tm project settings）：references/project-settings-guide.md

アンチパターン

• 認証に失敗した場合は処理を続行しないでください： Test Manager API の呼び出しには有効なベアラートークンが必要です。後続の 401 エラーを引き起こすのではなく、すぐに失敗させてください。
• コマンド名を推測しないでください： 動詞と名詞を組み合わせた形式が必要です。動詞のみのコマンドは存在しません。uip tm <resource> --help --output json で確認してください。
• パッケージ実行を手動で組み立てないでください： アップロードしたパッケージのすべてのテストを実行するには、link-package → testsets create → testcases add → testsets run → wait → result download ではなく、uip tm run --type package を使用してください。
• Playwright のテストケースに link-automation を実行しないでください： 取り込み時に自動的にリンクされます。手動でのリンクは、Studio/RPA パイプライン専用です。