このセクションは、WebKing ユーザーまたはバージョン 5.x 以前の SOAtest ユーザー向けの一般的な移行ガイドです。このセクションの内容:

この移行ガイドについて

この移行ガイドの目的は、 WebKing ユーザーまたはバージョン 5.x 以前の SOAtest ユーザーが最新バージョンの SOAtest にスムーズに移行できるよう支援することです。

この移行ガイドは、すでに SOAtest または WebKing の使用経験があるユーザーを対象としています。新規ユーザーはまず「SOAtest チュートリアル」を参照してください。

既存のテストのためのプロジェクトの設定

SOAtest のインターフェイスは SOAtest バージョン 6.0 から Eclipse フレームワークに統合されたため、 Eclipse フレームワークの階層に従ってテスト資産を管理するようになりました。そのため、毎回個別に .tst ファイルを開く必要がなくなりました。代わりに、すべての .tst ファイルをワークスペース内のプロジェクトで管理できます。

• ワークスペースはローカル マシンのディレクトリに対応します。ユーザーはSOAtest の起動時に任意の場所のワークスペースを指定できます。指定した場所は記憶され、今後の SOAtest の実行で使用されます。SOAtest 9.x 以降を起動すると以降と、Eclipse ワークスペースが <user_home_dir>/parasoft/workspace に自動的に作成されます。例: /home/username/parasoft/workspace (Linux), C:\Users\username\parasoft\workspace (Windows)

• ワークスペースには複数のプロジェクトを格納することができます。各プロジェクトは、ローカル マシンのワークスペース内のディレクトリに対応します。プロジェクトには複数の .tst ファイルと関連ファイルおよび成果物を格納できます。たとえばデータ ソースの Excel シートやキーストアなどです。
• プロジェクト中の .tst ファイルは、以前のバージョンの SOAtest で「プロジェクト ファイル」と呼ばれていたものと同じ役割を果たします。

適切なプロジェクト構成方法の選択

このセクションでは、既存の SOAtest/WebKing ユーザーにとって有用な、新規プロジェクトの作成方法をいくつか取り上げます。WSDL からの作成など、他の方法で新規プロジェクトを作成する方法については「SOAtest チュートリアル」で説明しています。

組織全体で簡単にテストを共有できるようにするために、指定されたチームメンバー ( 通常はチームのリーダーまたはマネージャー) はどのプロジェクト構成方法を採用するかを決定しなければなりません。その後、チーム全体で同じ方法を採用します。

ソース管理システム中のテストからプロジェクトを作成

デフォルトで、SOAtest 9.x には CVS によるソース管理サポートが附属しています。Eclipse にプラグインを追加することで、他のソース管理を追加できます。

ソース管理システムにチェックインされたテスト スイートから構成されるプロジェクトを作成するには、次の操作を行います。

1. [ファイル] > [インポート] をクリックします。
2. 表示されたウィンドウで、 SVN や CVS など、使用するソース管理システムに対応するフォルダーを展開します。
3. [< ソース管理システム名> からのプロジェクト] を選択し、[次へ をクリックします。
4. テストを格納しているソース管理フォルダーについて、必要なリポジトリ ロケーション情報を入力した後、[終了] をクリックします。
5. プロジェクトがワークスペースで利用可能になったら、ソース管理システムに .project および .parasoft ファイルを追加します。  これらのファイルは [ナビゲーター] ビューに表示され、チーム全体で共有されます。
   • ソース管理システムに .metadata フォルダーを追加してはいけません。

ソース管理されていないテストからプロジェクトを作成

ソース管理システムに格納されていないテストの場合、もっとも強く推奨するオプションは新しいワークスペースに古いテストをコピーすることです。そうすることによって、ハードドライブをバックアップするのに似た方法で古いテストが保存されます。この方法については「Copying Tests to a New Location」で説明します。

2 番目のオプションは、[ 既存の SOAtest または WebKing テストスイートからのプロジェクト] ウィザードを使用する方法です。この方法では、ワークスペース内にオリジナル ファイルが表示されますが、ファイル システム上の同じ場所にファイルを残すことができます。この方法については「Leaving Tests in the Original Location」で説明します。

新しい場所へテストをコピーする

既存のテストスイートをファイル システム上の別の場所にコピーするプロジェクトを作成するには、次の操作を行います。

1. [ファイル] > [新規] > [プロジェクト] を選択します。
2. 表示されたウィンドウで [一般] を展開して [プロジェクト] を選択し、[次へ] をクリックします。
3. プロジェクトの名前を指定して [ 終了] をクリックします ( このプロジェクトは複数の .tst ファイルを格納します)。ワークスペースに空のフォルダーが作成されます。
4. [ファイル] > [インポート] をクリックします。
5. 表示されたウィンドウで [一般] を展開して [ファイルシステム] を選択し、[次へ] をクリックします。
6. [次のディレクトリから] フィールドで、テストがあるディレクトリを指定します。
7. [インポート先フォルダ] フィールドで、ステップ 3 で作成したプロジェクトを選択し、[終了] をクリックします。
8. (任意、強く推奨) ソース管理システムを取得し、プロジェクト全体、.project フォルダー、および .parasoft ファイルをソース管理システムに追加します。これらのファイルは [ナビゲーター] ビューに表示され、チーム全体で共有されます。
   • ソース管理システムに .metadata フォルダーを追加してはいけません。

同じ場所にテストを保管する

「ファイル システム上の同じ場所に既存のテスト スイートを保管するプロジェクト」を作成するには、次の操作を行います。

1. 次のいずれかの操作を行って、新規プロジェクトウィザードを開きます。
   • [ファイル] > [新規] > [既存の SOAtest または WebKing テストスイートからのプロジェクト] を選択します。
     
     
     
     
   • 左上にある [新規] ツールバーボタンのプルダウンメニューを展開し [既存の SOAtest または WebKing テストスイートからのプロジェクト] をクリックします。
     
     
     
     
2. 表示されたウィザードでプロジェクト名を入力し、既存のテスト スイートのルートディレクトリを指定します。
3. [終了] ボタンをクリックします。選択したテストがテスト ケース エクスプローラーに表示されます。

チーム プロジェクト セット ファイル (.psf) を使用してチームで新規プロジェクトを共有

チーム メンバーは、プロジェクトを作成した後チーム プロジェクト セット ファイル (.psf) を作成することができます。このファイルは、チーム内の他のメンバーが共有できます。チーム プロジェクト セット ファイル (.psf) を共有することによって、各チーム メンバーが同じ方法で Eclipse プロジェクトを作成できます。これは、夜間自動テスト プロセスからタスクをインポートするために必要なステップです。

CVS から作成したプロジェクトのためのチーム プロジェクト セット ファイルを作成するには、次の操作を行います。

1. [ファイル] > [エクスポート] を選択します。[エクスポート] ウィザードが表示されます。
2. [エクスポート] ウィザードで [チーム] > [ チーム・プロジェクト・セット] を選択し、[次へ] をクリックします。
3. チームプ ロジェクト セット ファイルに含めるプロジェクトのチェック ボックスをオンにしてプロジェクトを選択します。
4. チーム プロジェクト セット ファイルを保存する場所を入力し、[終了] ボタンをクリックします。

チーム プロジェクト セット ファイルからプロジェクトを作成するには、次の操作を行います。

1. [ファイル] > [インポート] を選択します。[インポート] ウィザードが表示されます。
2. [インポート] ウィザードで [チーム] > [チーム・プロジェクト・セット] を選択し、[次へ] ボタンをクリックします。
3. [参照] ボタンをクリックして チーム プロジェクト セット ファイルを選択し、[次へ] ボタンをクリックします。選択したテストがテスト ケース エクスプローラーに表示されます。

SOAtest 9.x 以降のインターフェイス

Eclipse ベースになったため、SOAtest のルックアンドフィールのスタイルはやや異なります。ただし、このセクションで説明する変更点を除いて、ユーザー インターフェイスのデザイン レイアウト、フォームおよび設定はほとんど変わっていません。既存ユーザーにとってはなじみがあるもののはずです。

テスト ケース エクスプローラー

テスト ケース エクスプローラーは、複数の Eclipse プロジェクトを同時に開くことができます。各プロジェクトは、複数のテスト スイートを同時に持つことができます。以前のバージョンの SOAtest では、常に 1 つのテスト スイートしか開くことができませんでした。

テスト ケース エクスプローラーのメニュー ボタン

テスト ケース エクスプローラーの右上には次のメニュー ボタンがあります。

• リフレッシュ: テス トケース エクスプローラーの内容をリフレッシュします。
• すべて閉じる: テスト ケース エクスプローラー内のすべてのノードを閉じます。
• 検索: テスト ケースエクスプローラー内でノード (テスト スイート、テスト、接続されたツールなど) を検索します。[検索] ボタンをクリックすると、次のオプションが表示されます。
  • 含まれる文字列: テスト内に含まれる文字列を入力します。
  • すべてのツリー内: ツリー全体に対して、指定の文字列を検索します。
  • 選択されたノード内のみで検索: 選択したノードに対して、指定の文字列を検索します。
  • 循環検索: 循環検索を実行します。
  • 大文字/小文字を区別した検索: 大文字と小文字を区別して検索します。
• フィルター: 特定のプロジェクトまたはテストをテスト ケース エクスプローラーで非表示に します。
• 統計: テスト ケース エクスプローラーの各テスト スイート ノードの隣に、統計 (テストの成功、失敗、エラー、スキップ、実行の数) を表示します。

エディター

ダブル クリックまたはシングル クリックでエディターを開く

以前のバージョンでは、たとえば Editor など、テスト ノードに対する設定パネルを表示するには [Tests] タブでそのノードを選択しました。SOAtest 9.x では、テスト ケース エクスプローラーでノードをダブルクリックしてそのノードのエディターを表示できます。

デフォルトのダブルクリックで開く動作をシングルクリックに変更するには、次の操作を行います。

1. [ウィンドウ] > [設定] を選択します。[設定] ダイアログが表示されます。
2. [設定] ダイアログで、左側の [一般] を選択し、右側の GUI パネルで [クリック方法] を[ダブルクリック] から [シングルクリック] に変更します。
3. [一般] > [エディタ] を選択し、[エディタを自動的に閉じる] を有効にして [OK] をクリックします。

この設定によって、シングルクリックでエディターを開くことができるようになります。

複数のエディターを開く

以前のバージョンの SOAtest および WebKing では、一度に表示できるエディターは 1 つだけでした。  SOAtest 9.x では、複数のエディターを同時に開くことができます。 

エディターでの変更を保存する

SOAtest 9.x 以降では、エディターが変更されると、エディターのタブにアスタリスク “*” が表示されます。これは保存されていない変更があることを意味します。エディターに対する変更は、ツールバーの [保管] ボタンまたはキーボード ショートカットの Ctrl + S を使って明示的に保存しなければなりません。

環境

バージョン 5.5 以前の SOAtest では、環境は [Tests] タブの下の別のタブに表示されていました。SOAtest 9.x では、環境はテスト ケース エクスプローラーのツリー ビューの一部になりました。

テストの実行

テストを実行するには、テストのノードを右クリックし、ショートカット メニューの ["Example Configuration" を使用したテスト] をクリックします。  別の方法として、F9 キーを押すかツールバーの [テストの実行] ボタンをクリックして実行する方法もあります。

テスト スイート (.tst) ファイルの保存

以前のバージョンの SOAtest および WebKing では、テスト スイート ファイル (.tst) を明示的に保存する必要がありました。SOAtest 6.x 以降、テスト ケース エクスプローラーにおけるユーザー アクションは自動的に保存されます。たとえば、テスト ケース エクスプローラーへの新規テストの追加は自動的に保存されます。

最新バージョンの SOAtest で保存されたテストを、古いバージョンの SOAtest で開くことはできません。

[品質タスク] ビューと [コンソール] ビュー

テストの実行中に発生した失敗は [品質タスク] ビューに表示されるようになりました。以前のバージョンで Messages Log に表示されていた内容は、SOAtest 9.x では [コンソール] ビューに表示されます。

ソース管理の統合

適切なソース管理プラグインを Eclipse 環境にインストールしている場合、次の操作を行ってテスト スイートをソース管理に直接チェックインすることができます。

• テスト スイート ノードを右クリックし、ショートカット メニューの [チーム] > [コミット] を選択します。

新しいプロジェクトをチェックインするには、次の操作を行います。

• プロジェクト ノードを右クリックし、ショートカット メニューの [チーム] > [プロジェクトの共用] を選択します。

コマンド ラインの使用による夜間自動プロセスの設定

コマンド ラインからの夜間自動ビルドを設定するには、次の操作を行います。

1. テスト マシンで SOAtest を起動します。ワークスペースを作成し、夜間テストプロセスの一部にするすべてのプロジェクトとテスト スイートを追加します。詳細については上記の「Setting Up Projects for Existing Tests」のセクションを参照してください。
2. テストに必要なグローバル設定を使って SOAtest の設定を行います。SOAtest の設定画面を表示するには、[Parasoft] メニューの [設定] をクリックします。ワークスペース中のテスト スイートがソース管理システムからインポートされたものである場合、[Parasoft] > [ソース管理] も設定してください。 
3. (オプション) 夜間のテスト実行に使用するテスト コンフィギュレーションを作成します。テスト コンフィギュレーションには、テストの実行方法に影響する設定があります。SOAtest には、ユーザー定義のテスト コンフィギュレーションを作成したくない場合に使用できる Example Configuration というテスト コンフィギュレーションがあらかじめ用意されています。テスト コンフィギュレーションは [Parasoft] メニューの [テストコン フィギュレーション] を選択して管理することができます。ワークスペース中のプロジェクトがソース管理システムからインポートされたものである場合、テスト コンフィギュレーションの [共通] タブをクリックし、[ソース管理システムからプロジェクトを更新] オプションを有効にしてください。
4. (オプション) ローカル設定ファイル (オプション)を作成します。このファイルは、レポート、電子メール、Report Center、Team Server、License Server、作成者、およびソース管理の設定を制御できるテキスト ファイルです。
5. コマンド ライン オプションを使って SOAtest を起動する日次プロセスをスケジュールします。この作業は、Windows のタスク スケジューラや UNIX の cron などのジョブ スケジューラ メカニズムを使って行うことができます。たとえば、ワークスペース内のすべてのプロジェクトを実行するには、次のコマンドを使用できます。
   
   soatestcli.exe -data "c:\mySOAtestWorkspace" -showdetails -config "user://Example Configuration" -report "c:\mySOAtestReports" -publish -localsettings c:\mySOAtestWorkspace\mylocalsettings.properties" 

-publish 引数は DTP にレポートを追加し、テストおよび解析データのマージ、関連付け、分析を行って、深く隠された欠陥パターンを明らかにできます。DTP はデータを処理する際、実用的な指摘事項を作成します。それらの指摘事項をダウンロードして IDE にインポートできます (DTP 5.3.x 以降が必要)。

-publishteamserver オプションを使用して Team Server にレポートをパブリッシュすることもできます。このオプションは Concerto および古いバージョンの DTP との後方互換性を提供します。

変更点の詳細については「コマンドラインインターフェイス (cli) の移行」のセクションを参照してください。 

HP Quality Center の統合

HP QC Integration は 6.2 から 9.x へアップグレードしました。正しい動作の継続を確実にするために、2 つの製品に接続するステップを再実行する必要があります。

非推奨機能

• 負荷テスト: 負荷テストは、Parasoft Load Test 製品で利用できるようになりました。現在のバージョンでは、新規に負荷テストを作成するだけでなく、既存の SOA および Web の負荷テストを実行することも可能です。また、Web インターフェイスからサービス、データベースまで、完全なエンドツー エンドテスト シナリオに対して負荷テストを実行できます。Parasoft SOAtest で利用可能なプロトコルとテスト タイプが Parasoft Load Test でサポートされます。
  • Parasoft Load Test には完全な SOAtest 製品が含まれます。機能テストと負荷テストの両方に興味がある場合、Parasoft Load Test をインストールしてください。
• WebKing のパス: WebKing のパス ビューは、 Browser Playback ツールを使ったテスト スイートベースの機能テストに置き換えられました。主な利点は、テスト スイートベースの機能テストは、RIA アプリケーションや AJAX アプリケーションなど、ずっと複雑な Web アプリケーションをサポートすることです。さらに、この新しい実装は、エンドツーエンド テストをサポートする一貫したテスト コンフィギュレーション パラダイムに従います。既存の .wkj ファイル中のパスは、SOAtest 9.x で実行することはできますが、編集したり拡張したりすることはできません。
• WebKing のパブリッシュ: この機能は SOAtest 9.x には適用されません。
• Capture HTTP Traffic ツール: このツールはもうサポートされません。この機能が必要な場合、WireShark などのフリー ツールを使って HTTP トレースをファイルに保存し、[トラフィックからテストを作成] オプションを使ってこのファイルからテストを作成できます。
• 特定の XML Validator オプション: XML DTD の設定と DTD オプションに対する検証は利用できなくなりました。
• 管理レポート: レポートの拡張が計画されています。将来的には、SOAtest がすべてのメタデータを Report Center にレポートし、Report Center からさまざまな種類のレポートを生成できる予定です。
• CLI コマンド:
  • -run: このカスタム Jython スクリプトを SOAtest 中で実行するためのコマンドは 非推奨になりました。バージョン 9.x 以降にスクリプトを移行するための支援については、テクニカル サポートにご連絡ください。
  • -runtest: このコマンドは新しい CLI オプションに置き換えられました。詳細については「コマンドラインインターフェイス (cli) の移行」を参照してください。
  • -wsdl
  • -reportAllTraffic
  • -traffic