Parasoft SOAtest は Eclipese IDE 上に構築されているので、ワークスペース の概念を持っています。 これは、Microsoft Visual Studio の "ソリューション" にあたるものです。 ワークスペースはローカル ファイル システム上のディレクトリに対応します。このディレクトリの場所は大抵は重要ではありません。SOAtest はローカル マシン上の決まった場所をデフォルトとしますが、各ユーザーやチームは希望する場所に変更できます。

ワークスペースには複数の プロジェクト を含めることができ、それぞれのプロジェクトはローカル マシン上のワークスペース内のディレクトリに対応します。プロジェクトには複数の .tst ファイルと共に Excel シートのデータ ソース、キーストアなどといった関連するファイルや成果物を含めることができます。これらの成果物はプロジェクトのディレクトリ下に属するか、プロジェクト内のサブフォルダーに構成されます。 

チームで共有するにはプロジェクト レベルで共有するのが一般的には適しています。したがって、プロジェクトの .tst ファイルや依存するファイル リソースのレイアウトが重要となります。

プロジェクト設計パターン

開発者重視のチーム

組織での SOAtest の主たるユーザーが開発者の場合、Eclipse IDE プラグインとしてパッケージ化されている SOAtest の恩恵を受けるかもしれません。開発者は、ソース プロジェクトを扱っている IDE の内部から直接 SOAtest の機能を生かすことが可能です。 

この場合、SOAtest 関連のファイルはソース プロジェクトの下に格納できるため、ソース コードと共に維持することができます。ソース コード プロジェクト中の "テスト" ディレクトリには、すべての .tst ファイルとその従属物を含むことができます。

このアプローチのもうひとつのメリットは、スクリプトなどで SOAtest にユーザー独自の Java 拡張を構築した場合、またはメッセージング テストがベンダーの jar ファイル (JMS、MQ などのために) を必要とする場合に、SOAtest のクラスパス システム プロパティは Java プロジェクトのクラスパスを直接継承するように構成できます。そうすることで、テストの目的に応じて jar ファイルを分離したり複製したりして管理する必要がありません。

開発者重視のチーム

SOAtest の主たるユーザーが、通常はソース コードにアクセスしない品質保証エンジニアである場合、明確に SOAtest を使用する目的で作成されたプロジェクトで管理されているテストを用意したほうが良いでしょう。

SOAtest テスト ファイル構成

ここに SOAtest .tst ファイルと関連リソースの構成方法の一例を示します。

カテゴリのフォルダーには共有リソースを格納できます。共有リソースは多数の .tst ファイルに広く適用できる、データ ソース ファイル、環境設定ファイル (後ほど詳細について説明します)、またはキーストアとなる傾向があります。たとえばこのカテゴリには、データ ソースと認証データ、データベース接続設定ファイルなどが含まれる可能性があります。

カテゴリのフォルダーはテストの集合に固有なリソースを含みます。たとえば、 MyTests3 は独自の従属物とデータ セットとともに Web GUI テストを格納したディレクトリで、MyTest4 は Web サービス テストを格納したディレクトリであるとします。このカテゴリのフォルダーは A カテゴリのフォルダーと同じ名前である可能性があります。

.tst ファイルで作業をする場合、相対パスの参照整合性を維持しながら、プロジェクト内のどのレベル (上下階層) に格納されているリソースでも参照できます。

[相対パスで保存] オプションは現行の設定ファイルに相対するパス (絶対パスではなく) を作成するのに使用できます。このオプションが有効な場合、必要に応じて Eclipse 変数 (たとえば {project_loc:MyProject}/ReferencedTest.tst など) が挿入されます。相対パスの使用は複数のマシンでテストを共有することを簡単にします。