Test Suite
v2023.4
バナーの背景画像
Test Suite User Guide
最終更新日 2024年2月28日

テスト オートメーション

最大限効果的なテスト作業とするために、アプリケーション テストであるか RPA テストであるかに応じて、以下のテスト オートメーションのベスト プラクティスを検討します。

アプリケーション テスト

  • Test Automation Framework テンプレートを使用して、スケーラブルで安定したオートメーション プロジェクトを実装します。
  • 各テスト ケースは互いに独立している必要があります。あるテスト ケースを実行するために別のテスト ケースの実行が必要になる状況が発生しないようにします。
  • 1 つのテスト ケースに設定する具体的な目的は 1 つのみとします。各テスト ワークフローで実行する検証は 1 つのみとします。
  • 機能ごとに単体テストを行います。例外が許可される場合は、テスト ケースごとに個別のテストと例外を作成します。
  • Given-When-Then のテスト ケース構造で、特定の部分の範囲が広すぎて管理しにくい場合は、テスト ケースの再定義を試みてください。より詳細な設定やリファクタリングが必要なことがあります。
  • 現在のテスト ケースを維持し、変更リクエストがあれば更新します。
  • テスト ケースの定義方法が 1 つのみとなるようにテストの管理ロジックを構築することを検討します。
  • 個々のテスト プロジェクト間、およびテスト プロジェクトと RPA プロジェクト間で高い再利用性を実現するには、可能な限り、ライブラリとオブジェクト リポジトリを使用します。
  • CI/CD パイプラインにテストを追加します。
  • ビルドに遅れが発生しないように、CI パイプラインの過程で機能テストを可能な限り早期に実行する必要があります。したがって、できる限り多くのロボットで、これらのテストを並列実行します。
  • アクティビティ名は、実行するアクションがわかるようなものとします。分かりづらいアクションについては、アクティビティに注釈を追加することを検討します。
  • 詳細なログと例外処理を使用してプロセスをデバッグし、バグの検出漏れの発生を防止します。
  • 失敗を回避するために、各ステージでエラーから回復する計画またはリトライする計画を作成します。
  • テスト専用のフォルダー構造を使用すること、および各プロジェクトにわたって同じテスト ケース命名規則を使用することを検討します。
  • 変更の可能性が高く、使用頻度が高い変数には、アセットを使用します。
  • プロセスの特定のステップに進む前に、アプリケーションの状態を検証する必要がある場合は、検証方法を適用することを検討します。検証方法では、他のインタラクションの前に、アプリケーションが望ましい状態になるまで待機する追加のアクティビティを使用できます (ハードコードされた待機時間は適切な方法とは見なされません)。
  • 可能な限り、模擬的なクリック操作や入力操作、Windows メッセージの模擬的な送信動作の使用を検討します。
  • Studio 以外でテスト ケースの削除、移動、名前変更をしないようにします。これらの操作は、Studio でのみ実行します。参照先とする他のプロジェクトのテスト ケースがある場合は、[テスト ケースをインポート] を使用します。

RPA テスト

  • 各テスト ケースは互いに独立している必要があります。あるテスト ケースを実行するために別のテスト ケースの実行が必要になる状況が発生しないようにします。
  • できる限り少ない数のアクションを扱う、小規模なワークフローの作成を検討します。これにより、単体テストがわかりやすくなり、実行しやすくなります。
  • 1 つのテスト ケースに設定する具体的な目的は 1 つのみとします。各テスト ワークフローで実行する検証は 1 つのみとします。
  • 機能ごとに単体テストを行います。例外を許可する場合は、テスト ケースごとに別々のテストを作成します。
  • 個々のテスト プロジェクト間、およびテスト プロジェクトと RPA プロジェクト間で高い再利用性を実現するには、可能な限り、ライブラリとオブジェクト リポジトリを使用します。
  • Given-When-Then のテスト ケース構造で、特定の部分の範囲が広すぎて管理しにくい場合は、テスト ケースの再定義を試みてください。より詳細な設定やリファクタリングが必要なことがあります。モジュール性は、優れた単体テストを実現するための要点です。テストの書き込みが、開発でのフィードバックやコード レビューとして機能することがあります。
  • テスト ケースの目的とは関係のない複雑なステップがあり、それが置き換え可能な場合は、モックを使用します。
  • テスト ケースの定義方法が 1 つのみとなるようにテストの管理ロジックを構築することを検討します。
  • 現在のテスト ケースを維持し、変更リクエストがあれば更新します。
  • CI/CD パイプラインにテストを追加します。
  • RPA の内容を変更する場合は、必ずテスト ケースを実行して、バグが発生しないことを確認します。
  • 環境変更 (Windows Update など) の展開を計画する場合は、運用前環境で IT 部門が実行できる RPA テスト セットを作成し、運用環境に展開する前に潜在的な問題を把握できるようにします。
  • アクティビティ名は、実行するアクションがわかるようなものとします。分かりづらいアクションについては、アクティビティに注釈を追加することを検討します。
  • 失敗を回避するために、各ステージでエラーから回復する計画またはリトライする計画を作成します。
  • テスト専用のフォルダー構造を使用すること、および各プロジェクトにわたって同じテスト ケース命名規則を使用することを検討します。
  • 変更の可能性が高く、使用頻度が高い変数には、アセットを使用します。
  • プロセスの特定のステップに進む前に、アプリケーションの状態を検証する必要がある場合は、検証方法を適用することを検討します。検証方法では、他のインタラクションの前に、アプリケーションが望ましい状態になるまで待機する追加のアクティビティを使用できます (ハードコードされた待機時間は適切な方法とは見なされません)。
  • 可能な限り、模擬的なクリック操作や入力操作、Windows メッセージの模擬的な送信動作の使用を検討します。
  • Studio 以外でテスト ケースの削除、移動、名前変更をしないようにします。これらの操作は、Studio でのみ実行します。参照先とする他のプロジェクトのテスト ケースがある場合は、[テスト ケースをインポート] を使用します。

有人オートメーションの RPA テスト

このページでは、特定のテスト シナリオに基づいて、有人オートメーションの RPA テストを実行する方法について説明します。

Note: Make sure that you have a working license for both Orchestrator and Test Manager.

有人のユーザー受け入れテスト

テストを実行するユーザー

テスト手順

テスト結果のキャプチャ

ライセンス要件

• 手動テスター

• UAT または業務の内容領域専門家 (SME)

  1. 以下のように、QA チームが Test Manager で手動テスト用のテスト ケースを定義します。

    a. 前提条件の手順

    b. オートメーションの実行

    c. アサーション

  2. UAT のテスターが Test Manager で手動テスト用のテスト ケースを実行します。
  3. UAT のテスターが、「手順 1a. 前提条件の手順」で定義されたとおり、テストする必要のある特定のシナリオに基づいて有人オートメーションの環境を準備します。
  4. UAT testers execute the attended automation through UiPath Assistant.
  5. UAT のテスターが、オートメーションが実行された後にアサーションを検証します。

UAT のテスターは、スクリーンショットやドキュメントを含む結果を Test Manager で確認できます。

UAT のテスターには Attended Automation ライセンスが必要です。ライセンスは、デプロイの種類に応じて管理できます。

次の 2 つのシナリオが考えられます。

• UAT のテスターに Attended Automation ライセンスが割り当てられている Orchestrator の運用環境にオートメーション パッケージをパブリッシュします。

• Attended User ライセンスのサブセットを Orchestrator の非運用環境に割り当てます。

無人の回帰テスト

テストを実行するユーザー

テスト手順

テスト結果のキャプチャ

ライセンス要件

  1. 以下のように、QA チームが Test Manager でテスト ケースを定義します。

    a. 前提条件の手順

    b. オートメーションの実行

    c. アサーション

  2. オートメーション開発者が既存のオートメーションを使用してテスト ケースを作成します。有人ユーザーの操作は RPA のモック テストを使用してシミュレートされます。
  3. オートメーション開発者が Studio から Test Manager にテスト ケースをリンクします。
  4. オートメーション開発者がテスト ケースを Orchestrator にパブリッシュした後、(ビジネス要件に基づいて) それらをグループ化してテスト セットにします。
  5. 無人テストは OrchestratorTest Manager を使用して手動で実行するか、Orchestrator でスケジュール設定して実行します。
  6. (任意) CI/CD ツールを使用できる場合、そのツールを活用して完全に自動化されたテストやデプロイを実現できます。UiPath では、次のような CI/CD 連携機能を提供しています。

Unattended Testing ロボットにより実行の詳細とイベントが提供されますTesting ランタイム

Was this page helpful?

サポートを受ける
RPA について学ぶ - オートメーション コース
UiPath コミュニティ フォーラム
UiPath ロゴ (白)
信頼とセキュリティ
© 2005-2024 UiPath. All rights reserved.