通知を受け取る

UiPath Test Suite

UiPath Test Suite

Test Automation のベスト プラクティス

概要


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

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

1 年前に更新


Test Automation のベスト プラクティス


改善の提案は、API リファレンスのページでは制限されています

改善を提案できるのは Markdown の本文コンテンツのみであり、API 仕様に行うことはできません。