Structures and how to choose one | Ranorex
Help CenterUser GuideHands-on application topics

構成のタイプとその選択方法

このセクションでは、Ranorex Studio における 3 つの基本的なテスト構成と、テスト要件に応じた、その選択方法について説明します。

サンプルのテスト要件

異なるテスト構成を比較するため、以下のテスト要件を使用します。

最初に、2 つのスモーク テスト により、テスト対象アプリが正しくインストールされ、Ranorex Studio で起動および終了できることを確認します。

次に、2 つのサニティ テスト により、テスト対象アプリの正しいバージョンが使用されており、すべての UI 要素が実装されていて、仕様に沿って動作することを確認します。

最後に、3 つの機能 UI テスト により、テスト対象アプリの管理機能、データベース機能、ファイル インポート機能が正しく動作することを確認します。

3 つの基本的なテスト構成

ここでは、それぞれの構成の長所と短所を挙げ、また、上記のテスト要件を各構成に変換した場合にどのようになるか、例を挙げます。

繰り返しますが、ベストな唯一の構成というものはありません。すべてはテスト要件に依存します。以降で説明する内容によって、どの構成が自分に適しているのかを選択できるようになるはずです。

ソリューションベースの構成

このタイプでは、3 つの異なるテスト タイプごとに、それぞれソリューションを作成します。実際のテストは、プロジェクトごとに 1 つのテスト スイートで構成されます。

スモーク テストのソリューション
サニティ テストのソリューション
機能テストのソリューション

長所

  • トップ レベルで非常に明確な構成。巨大で複雑なテスト要件の場合に有用。
  • フロントエンドとバックエンドの UI のテストなど、異なる UI を持ち、複数のリポジトリを必要とするテスト対象をテストする場合に特に有用。
  • テスト スイートの構成を、シンプルかつ効率的に維持することが容易。
  • テスト実行時間を短縮可能。

短所

  • メンテナンス コストが高い。各ソリューションには、それぞれ独自の設定、リポジトリ、モジュール ライブラリがあり、それらを管理する必要がある。
  • Ranorex Studio からは、3 つのソリューションを連続して自動的に実行することができない。CI などの環境が必要になる。
  • ソリューションごとにレポートが生成されるため、結果の収集などが難しくなる。
  • 3 つの機能テスト間で、データをやり取りする簡単な方法がない。

プロジェクトベースの構成

このタイプでは、3 つの異なるテスト タイプごとに作成したプロジェクトを含む、1 つのソリューションで構成されます。実際のテストは、1 つのテストにつき 1 つのテスト スイートが対応する、複数のテスト スイートで構成されます。

3 つのプロジェクトを含む AuT_Testing ソリューション
3 つの機能テストを実装した FunctionalTest プロジェクト
2 つのサニティ テストを実装した SanityTest プロジェクト
2 つのスモーク テストを実装した SmokeTest プロジェクト

長所

  • 1 つのソリューションにすべてのテストが含まれていて便利。
  • メンテナンスが簡単。異なる設定がなく、通常は 1 つのモジュール ライブラリとリポジトリのみ。
  • 構成がソリューション レベルでは明確ではない一方、プロジェクト レベルでは非常に明確。シンプルで効率的なテスト スイート構成の長所を維持。
  • Ranorex Studio のテスト シーケンス機能を利用して、プロジェクトとそれに含まれるテスト スイートを順番に実行可能。

短所

  • プロジェクト/テスト スイートごとに、レポートが生成されるため、結果の収集などが難しい。
  • 3 つの機能テスト間で、データをやり取りする簡単な方法がない。

テスト スイートベースの構成

このタイプでは、1 つのプロジェクトを含む 1 つのソリューションを作成します。このプロジェクトは、3 つの異なるテスト タイプごとに 1 つのテスト スイートを含みます。実際のテストは、これらのテスト スイート内のテスト ケースで構成されます。

1 つのプロジェクトを含む AuT_Testing ソリューション
テスト タイプごとに 1 つのテスト スイートを含む AuT_Testing プロジェクト
実際のテストがテスト ケースとして含まれる、各テスト スイート

長所

  • ひとつのソリューションにすべてのテストが含まれていて便利。
  • メンテナンスが簡単。異なる設定がなく、通常はひとつのモジュール ライブラリとリポジトリのみ。
  • Ranorex Studio のテスト シーケンス機能を利用して、テスト スイートを順番に実行可能。
  • 3 つの機能テスト間でのデータのやり取りが容易な一方、異なるテスト タイプ間でのデータのやり取りは困難。

短所

  • テスト スイートの構成がすぐに肥大化/複雑化し、メンテナンス、トラブルシューティング、コラボレーションが難しくなる。また、テスト パフォーマンスに悪い影響を与える。

どの構成を選択するべきか

このセクションでは、テスト構成を選択する際に考慮すべき事項について説明します。

極端な構成を避ける

多くの場合、プロジェクトベースの構成が適しています。

優れた組織化、シンプルなテスト ロジック、高い利便性を備えた、柔軟なアプローチを提供します。

ソリューションベースの構成とテストスイートベースの構成は、どちらも極端な構成です。テスト要件が完全に適合する場合にのみ、使用することをおすすめします。

非常に大規模で複雑なテストの場合には、ソリューションベースの構成を使用してください。メンテナンスが大変であることが、このアプローチのもっとも重大な短所です。ソリューションごとに異なる設定、リポジトリ、モジュール ライブラリが必要になります。

小規模で単純なテストの場合には、テストスイートベースの構成を使用してください。テストスイートベースの構成をセットアップして、すぐにテストを実行できるようにするのは簡単です。メンテナンスも少なくてすみますが、これは、テストが小さくシンプルなものである場合に限ります。テストが複雑になると、構成がすぐに肥大化し、管理するのが難しくなります。

UI 要素を考慮する

テストに含まれる UI 要素は、構成を選択する際の、重要な判断基準のひとつです。テストがフロントエンドやバックエンドのように、複数の異なる UI を扱う場合には、複数のリポジトリを扱うことは理にかなっています。

複数のリポジトリがある場合、ソリューションベースの構成は考慮に値します。しかしながら、他の構成タイプでも複数のリポジトリを使用することはできます。そのため、2 つの異なる UI があるにも関わらず、テストがそれほど複雑ではない場合には、2 つのリポジトリを持つ、プロジェクトベースの構成の方が適しているかもしれません。

要件としてのデータのやりとりの必要性

テスト間でデータをやり取りするのは、同じテスト スイートに配置されていないと困難です。しかし多くの場合、テスト間でデータをやり取りする必要性は必ずしもありません。参照するデータとテスト ケースを別々になるよう設計することで、データのやり取りを避けることができます。