このセクションでは、SOAtest のテスト コンフィギュレーションの設定について説明します。

このセクションの内容:

[スコープ] タブ: テスト対象のコードを定義する

ソース コードの静的解析のみ。

SOAtest のテストでは、テスト コンフィギュレーション のスコープ基準を満たす、選択されたリソース中のすべてのコードに対して、指定のアクションが実行されます。デフォルトでは、 テスト コンフィギュレーションの実行時に選択されていたリソース中のすべてのコードがチェックされます。ただし、[スコープ] タブを使って以下のような制限をかけることもできます。

• 指定の日付以降に追加/変更されたファイルまたは行だけをテストする。
• ローカル マシンで追加/変更されたファイルまたは行だけをテストする。
• 特定のユーザーによって変更されたファイルだけをテストする。
• 特定のフィルター条件に一致するファイルだけをテストする。

なお、一部のファイル フィルターと行フィルターは、サポート対象のソース管理システムで管理されているプロジェクトにだけ適用されます。

[スコープ] タブには以下の設定があります。

• ファイル フィルター: 指定されたタイムスタンプあるいは作成者条件に一致しないファイルをテストから除外します。
  • 時間オプション: 指定の時間条件に合わないファイルをテスト対象から外します。以下のオプションがあります。
    • 時間フィルターなし: 最終変更日に基づいてファイルをテスト対象から除外しません。
    • 締め切り後に追加または変更されたファイルだけをテスト: 指定の日付以降に追加または変更がなかったファイルがテスト対象から外されます。
    • 指定した期間に追加または変更されたファイルだけをテスト: 指定の期間に追加または変更されなかったファイルがテスト対象から外されます。
    • 作業ブランチと次のブランチの間に更新されたファイルだけをテストする: 開発者の作業ブランチ (ワークスペース) と指定されたブランチ (または当該オプションが有効な場合、検出されたデフォルトの統合ストリーム) の間で変更されなかったファイルをテスト対象から除外します。ストリーム名は、開発者の作業ストリームの親の階層にあるストリームです。デフォルトの統合ストリームは、開発者の作業ストリームの親ストリームです。たとえば、[Main] --- [Integration] --- [Developer] という階層がある場合、Integration が Developer ストリームのデフォルトの統合ストリームです。現在これは SVN、AccuRev、 および Clear Case についてサポートされています。
    • ローカルで追加または変更されたファイルだけをテスト: ローカル マシンで追加または変更がなかったファイルをテスト対象から除外します。この機能が適用されるのは、SOAtest がサポートするソース管理システムで管理されているプロジェクトだけです。
  • 作成者オプション : 指定の作成者条件に合わないファイルをテスト対象から外します。次のオプションがあります。
    • 作成者フィルターなし: ファイル作成者に基づいてファイルをテスト対象から除外しません。
    • ユーザーが作成したファイルだけをテスト: 指定のユーザーが作成者ではないファイルをテスト対象から除外します (つまり、別のユーザーが作成したファイルを除外します)。
  • パス オプション:  指定したフィルター条件に一致するファイルをフィルタリングするよう SOAtest を構成します。含めるファイル タイプを指定するには [承認] フィルターを使用します。除外するファイル タイプを指定するには [拒否] フィルターを使用します。なお、Code Review カテゴリのテスト コンフィギュレーションの場合は一般的なフィルタリング オプションがあらかじめ設定されています。

• 行フィルター: SOAtest のテスト対象のコード行を制限します。行フィルターよりもファイル フィルターの方が先に適用されるので、行フィルターに到達するコードは、ファイル フィルターを通過している必要があります。行フィルターで利用できるオプションは次のとおりです。
  • 時間オプション: 指定の時間条件に合わないコード行/ファイルをテスト対象から除外します。以下のオプションがあります。
    • 時間フィルターなし: 最終変更日に基づいてコード行をテスト対象から除外しません。
    • 締め切り後に追加または変更された行だけをテスト: 指定の日付以降に追加/変更がなかったコード行は、テストの対象から外されます。この機能が適用されるのは、SOAtest がサポートするソース管理システムで管理されているプロジェクトだけです。
    • 指定した期間に追加または変更された行だけをテスト: 指定の期間に追加または変更されなかったコード行は、テストの対象から外されます。
    • ローカルで追加または変更された行だけをテスト: ローカル マシンで追加/変更がなかったコード行はテストの対象から外されます。この機能が適用されるのは、SOAtest がサポートするソース管理システムで管理されているプロジェクトだけです。
  • 作成者オプション : 指定の作成者条件に合わないコード行をテスト対象から外します。次のオプションがあります。
    • 作成者フィルターなし: ファイル作成者に基づいてコード行をテスト対象から除外しません。
    • ユーザーが作成した行だけをテスト: 指定のユーザーが作成していないコード行を、テスト対象から除外します。たとえばこのオプションを使って、自分 (あるいは選択したグループ) が作業しているファイルだけに集中することができます。複数のユーザーを指定するには、ユーザー名をカンマで区切って入力します。

[静的] タブ: 静的解析の方法を定義する

テストの実行中、SOAtest はそのテストが使用するテスト コンフィギュレーションのパラメーターに基づいて静的解析を実行します。 

[静的] タブには以下の設定があります。

• 静的解析を有効にする: 静的解析を実行するかどうかを指定します。テスト コンフィギュレーションで有効化されている静的解析ルールに、選択されたリソースが準拠しているかどうかをチェックします。
• 1 ルールにレポートするエラーの最大数: 各静的解析ルールについて、1 回のテストでレポートする違反 (タスク) の数を、指定の値に制限します。たとえば、各ルールにつきレポートされる違反の数を 5 以下に制限するには、このパラメーターに 5 を設定します。デフォルトは 1,000 です。
• 抑制を適用しない: 抑制を適用するかどうかを設定します。抑制を適用しない場合、検出されたすべての違反がレポートされます。
• ルール ツリー: 静的解析の実行中にどのルールをチェックするかを指定します。ルール ツリーとそれに関連するコントロールを使って、静的解析でチェックするルールとルール カテゴリを指定します。
  • ルールの説明を参照するには、ルールのノードを右クリックし、ショートカット メニューの [ルール ドキュメントの参照] をクリックします。
  • ルール カテゴリの説明を参照するには、ルール カテゴリのノードを右クリックし、ショートカット メニューの [カテゴリの説明を参照] をクリックします。

  • 特定のルール カテゴリのすべてのルールを有効または無効にするには、そのカテゴリを右クリックし、[ルールを有効にする] または [ルールを無効にする] を選択して [すべての表示ルール] をクリックします。

  • ルールを検索するには、[フィルター] フィールドを使用します。
  • 無効なルールを非表示にするには、[有効なルールのみ表示] ボタンをクリックします。後で再びすべてのルールを表示するには、[すべて表示] をクリックします。

[実行] タブ: テストの実行方法を定義する

テストの実行中、SOAtest は [実行] タブで定義されたパラメーターに基づいてテスト ケースを実行します。どのレベルの実行でも、最上位レベルの [テスト実行を有効にする] オプションを必ず有効にしなければなりません。

[機能性] タブ

[実行] > [機能性] タブには、次の設定があります。

• 機能テストの実行: 機能テストを実行するかどうかを指定します。
• イベント ロギングを有効化する: テストの開始から終了までに発生した全イベントの詳細な時間的順序を提供するために必要なデータを、ログに記録するかどうかを指定します (たとえば、送られたすべてのリクエスト、受け取られたレスポンス、使用されたデータ ソース行、待ち時間、ナビゲーション タスクなど)。詳細については「テスト イベントの詳細の確認」を参照してください。
• 負荷テスト モードで実行: 負荷テスト モードでテストを実行し、負荷テストに影響するかもしれない問題を通知するかどうかを指定します。たとえば、不正に構成された HTTP リクエストなどです。詳細については、「テストの検証」を参照してください。
  • 負荷テストのための自動設定: ブラウザーがない負荷テスト環境で実行するようにブラウザー ベースの Web シナリオを構成するかどうかを指定します。詳細については、「テストの構成」を参照してください。
• オープン中のテスト スイート (.tst) のみ実行 (コマンドライン モードの時は常にオフ): 現在アクティブではないテスト スイート (つまり現在作業していないテスト) を実行するかどうかを指定します。
• すべてのテストのトラフィックをレポートする: レポートに "Test Traffic [All Tests]" セクションを含めるかどうかを指定します。このセクションには、テストが成功だったかどうかに関係なく、各テスト実行のトラフィックが含まれます。このオプションが有効の場合、トラフィックの制限も設定できます。テストごとではなくテスト実行のセッションの最中に保存されるトラフィックの量を制限できます。デフォルトは 500 KB です。
• アプリケーションを起動: テスト コンフィギュレーションの実行開始時に Eclipse の起動構成を実行するよう、SOAtest テスト コンフィギュレーションを設定できます。たとえば、Eclipse 内で開始して実行するアプリケーションの複製に対してテスト シナリオを実行するものとします。  シングル ステップでアプリケーションを開始してテストを実行したい場合、テストを実行するのに加えてアプリケーションも起動するようにテスト コンフィギュレーションを設定できます。
• テスト実行中はデフォルト環境を上書く: このテスト コンフィギュレーションを使ったテストを実行するときに、テスト ケース エクスプローラーでアクティブな環境に関係なく、指定した環境を常に使用するよう SOAtest を構成できます。
  たとえば、次の環境があるものとします。
  
  
  
  常に "staging server" 環境を使用するようテスト コンフィギュレーションを設定するには、次のように指定します。
  
  
  
  
• 再生エンジンを使用する: テスト実行時にテストの再生エンジン設定を上書きできます。デフォルトでは、テスト コンフィギュレーションはテスト スイート レベルで指定された再生エンジンを使用して Web シナリオを再生するよう設定されています。これによって、Selenium を使用するよう設定されたテストと、レガシー エンジンを使用するよう設定されたテストを、1 つのテスト コンフィギュレーションで実行できます。ここでドライバーを選択すると、シナリオ レベルで構成されたエンジンにかかわらず、そのドライバーが使用されます。詳細については「Selenium WebDriver を使用した既存のブラウザー記録シナリオの実行」および「Selenium の代わりに従来のネイティブ ドライバーを使用」を参照してください。
• 使用するブラウザー: テストの実行時に、テストのブラウザー再生の設定を上書きできます。詳細については、「ブラウザー再生オプションの設定」 を参照してください。
• 静的解析の適用: 静的解析とテスト実行の両方をテスト コンフィギュレーションが実行する場合 (たとえば Web シナリオに対して静的解析を実行する場合)、この設定は静的解析を HTTP レスポンスに対して実行するのかブラウザーの内容に対して実行するのかを決定します。
  • HTTP レスポンス: データ モデルを構築するためにブラウザーが作成した個々の HTTP メッセージを参照します。あらゆるブラウザー処理の前に、サーバーによってそのまま返された内容です。
  • ブラウザー内で生成した HTML: すべての HTML、JS、CSS、およびブラウザーがロードした他のファイルからブラウザーが構築したリアルタイムのデータ モデルを参照します。

[セキュリティ] タブ

[実行] > [セキュリティ] タブでは、侵入テストの設定を行うことができます。詳細については「侵入テスト」を参照してください。

[実行時エラー検出] タブ

[実行] > [実行時エラー検出] タブでは、実行時エラーの検出を設定することができます。詳細については「実行時エラー検出の実施」を参照してください。

[変更影響度] タブ

[実行] > [変更影響度] タブでは、テストの実行中に変更影響度分析を実行するかどうかを指定できます。詳細については、「変更アドバイザーでメッセージを更新」 を参照してください。

[API カバレッジ] タブ

[実行] > [API カバレッジ] タブには、テストの実行中に API カバレッジを計測するためのオプションがあります。詳細については「API カバレッジ」を参照してください。

[アプリケーション カバレッジ] タブ

[実行] > [アプリケーション カバレッジ] タブには、アプリケーション カバレッジのデータを収集するためのオプションがあります。SOAtest のテストがどの程度コード カバレッジを達成したかが可視化されます。詳細については「アプリケーション カバレッジ」を参照してください。

[共通] タブ: 複数の解析タイプに影響する共通オプションを定義する  

[共通] タブは、複数の解析タイプに影響するアクションのテスト設定をコントロールします。

[共通] タブには以下の設定があります。

• セッション タグのオーバーライド: 現在のテスト コンフィギュレーションを使って実行されたテストの結果に、指定のセッション タグを割り当てます。この設定は、[Parasoft] メニューの [設定] > [Parasoft] > [レポート] で指定されたセッション タグを上書きします。この値は Team Server にサマリー結果をアップロードするために使用されます。セッション タグは、解析プロセス中にチェックされたモジュールの識別子です。異なるモジュールのレポートは、異なるタグでマークするべきです。この設定には、Parasoft Test の環境設定オプションで有効な変数と同じ変数を使用できます。
• テスト前 > プロジェクトのリフレッシュ: テスト前にプロジェクトをリフレッシュするかどうかを指定します。プロジェクトをリフレッシュすると、SOAtest は外部ツールがローカル ファイル システム上のプロジェクトを変更したかどうかをチェックし、変更があった場合はそれを適用します。注意: コマンドラインでテストする場合、プロジェクトは常にテスト前にリフレッシュされます。
• テスト前 > ソース管理システムからプロジェクトを更新: サポートされるソース管理システムを使用している場合に、テスト前にソース管理システムからプロジェクトを更新するかどうかを指定します。
• ビルド: テストの前にプロジェクトをビルドするかどうかを指定します。注意: この設定は GUI でのテストにだけ適用されます。コマンドラインでのテストには適用されません。 以下のオプションがあります。
  • フル (全ファイルのビルド): すべてのプロジェクト ファイルを常にビルドします。
  • インクリメンタル (最終ビルド後に変更されたファイルをビルド): 前回のビルド後に更新されたプロジェクト ファイルだけをリビルドします。
  • ビルド エラー時にテストを停止する: ビルドの最中にエラーが発生した後、テストを実行するかどうかを指定します。
• テスト後 > タスクがレポートされなかった場合、追加/変更されたファイルをソース管理システムにコミットする: テストとソース管理へのチェックインを 1 つのステップにまとめることができます。たとえば、ファイルを解析した後、静的解析違反も単体テストの失敗もレポートされなかった場合に、変更されたファイルを自動的にチェックインする場合、このオプションをオンにします。機能テストであれば、このオプションは、変更したテストを実行してテストが成功した場合、変更したテストをソース管理にチェックインします。

[コード レビュー] タブ: コード レビューのオプションを定義する

[コード レビュー] タブには、ピア レビュー プロセスの準備、通知、記録を自動化するための設定があります。これは、組織の品質ポリシーのコンテキストで重要な SDLC 成果物 (ソース ファイル、テスト、その他) を評価するために使用できます。

コード レビューの設定と [コード レビュー] タブのオプションの詳細については、「コード レビュー」を参照してください。 

[ゴール] タブ: エラー レポートと解決ターゲットを定義する

チーム マネージャーは、「1 人の開発者につき 1 日にレポートされる違反を 25 個までにする」といったレポートの制限を指定したり、「すべての静的解析違反を 2 ヶ月で修正しなければならない」といった品質ゴールを指定することができます。指定された条件に従って、SOAtest は各開発者が毎日実行するテスト タスクのサブセットを選択します。これらのゴールは [ゴール] タブで指定します。ゴールへの到達度をレポートでモニタリングできます。

別の方法として、「タスク ゴールの設定」にあるようにグローバル チーム ゴールを設定できます。グローバル チーム ゴールは、複数のテスト コンフィギュレーション間で共有できるほか、複数の Parasoft テスト ツールの間でさえも共有できます。この設定には Team Server と Parasoft Test Automation ライセンスが必要です。グローバル チーム ゴールを設定した場合、テスト コンフィギュレーションの [ゴール] タブは使用不可になります。

[ゴール] タブには以下の設定があります。

[静的] タブ

• すべてのタスクを処理する: すべての推奨される静的解析タスクをレポートし、チームが直ちにすべてのタスクを処理するべきであることを指定します。
• タスクを処理しない: 検出されたすべての静的解析タスクをレポートするが、直ちにすべてのタスクを処理する必要はないことを指定します。たとえば、すべての静的解析タスクを参照したいが、チームには静的解析違反よりも先に単体テストの問題を修正させたい場合、このオプションが役立ちます。
• 開発者ごとのタスクを指定した日付までに n 以下にする: 指定の日付までに、各開発者が担当する静的解析タスクの数を n 個以下にしたいことを指定します。
• 推奨されるタスクの最大数: テスト実行で各開発者が受け取る静的解析タスクの数を制限します。表示されるタスクはランダムに選択されるため、テスト実行のたびに異なるタスクが表示されます。たとえば 50 に設定した場合、各テスト実行の後に表示される 1 番目のタスクがランダムに選択されます。表示される残りの 49 個のタスクは、完了レポートで 1 番目のタスクの後に表示されるタスクです。

[例外] タブ

• すべてのタスクを処理する: 機能テストのすべてのタスクをレポートし、チームが直ちにすべてのタスクを処理するべきであることを指定します。
• タスクを処理しない: 機能テストのすべてのタスクをレポートするが、チームが直ちに全タスクを処理する必要はないことを指定します。たとえば、すべての機能テスト タスクを参照したいが、チームには機能テストの問題よりも先に静的解析違反を修正させたい場合、このオプションが役立ちます。
• 開発者ごとのタスクを指定した日付までに n 以下にする: 指定の日付までに、各開発者が担当する機能テストのタスクを n 個以下にしたいことを指定します。
• 推奨されるタスクの最大数: テスト実行で各開発者が受け取る機能テスト タスクの数を制限します。表示されるタスクはランダムに選択されるため、テスト実行のたびに異なるタスクが表示されます。たとえば 50 に設定した場合、各テスト実行の後に表示される 1 番目のタスクがランダムに選択されます。表示される残りの 49 個のタスクは、完了レポートで 1 番目のタスクの後に表示されるタスクです。