探査結果の評価

テスト・ステージに進む前に、探査結果を確認します。これは、探査ステージでサイトの重要な領域が見逃された場合、テスト・ステージではそれらの領域がテストされないためです。

このタスクについて

探査ステージの結果は、3 つのデータ・ビュー・ペインに表示されます。探査ステージでの処理が正常に実行され、アプリケーションの十分な範囲がカバーされているかどうかを評価するためのいくつかのヒントを以下に示します。
注: このステージで構成変更を行った場合は、テスト・ステージを開始する前にアプリケーションを再探査する必要があります。

手順

  1. スキャン・ログ機能を実行します。この機能は、AppScan が頻繁にセッション外になっていないかどうかを確認する場合に使用します。
    1. 「表示」>「スキャン・ログ」をクリックします。
    2. ログ項目をスクロールして、AppScan が頻繁にセッション外になっていないかどうかを確認します。

    AppScan が 5 分間に数回を超えてセッション外になっている場合は、セッション内検出構成に特に注意して、記録されたログインの再記録と再構成を行うことをお勧めします。

  2. アプリケーション・ツリーを使用します。これは、検出および探査された、サイトのすべての領域を示すグラフィカル表現です。サイトがどの程度カバーされているかを確認するために使用します。
    1. アプリケーション・ツリーは、アプリケーションの階層構造とメインページを正確に示していますか?
    2. ツリー内にログイン URL はありますか? (存在しない場合、ログインは送信されていません)
    3. アクセスした URL の総数 (左下隅に表示) は、把握している実際のサイト・サイズに一致していますか?
    4. テスト・ステージで送信するための妥当な数のテストが作成されていますか? (URL の数の 5 倍以上のテストが必要です)
  3. 送信された要求を確認します。探査ステージで送信された要求の確認と検証を行います。
    1. データ・ペインで「要求」ビューを選択して、送信されたすべての要求を表示します。
    2. このリストにログイン URL が表示されていることを確認します (特に、セッション内要求と、ユーザー資格情報が含まれたログイン要求)。
    3. ログイン手順で、ログイン要求の後に表示されている要求のいくつかを確認します。応答にエラーが含まれていないことを確認します。これを行うには、詳細ペインの検索フィールドに単語「error」を入力してから、上部パネルで URL を 1 つずつ選択します。特定の応答に単語「error」が含まれている場合は、検索フィールドの色が赤 (「見つからない」) から緑 (「見つかった」) に変わり、応答本文で単語「error」が強調表示されます。
    4. これらの要求にエラー・ストリングが含まれている場合は、ユーザーがセッション外になったため、ログイン手順が正しく記録されなかったことを示しています。その場合は、ログイン手順をもう一度記録します。
  4. 「アプリケーション・データ」ビューを使用します。これはテスト・ステージのデフォルト・ビューで、ペインの上部に並んだフィルターをクリックすると、各種ビューが表示されます。
    1. F2 をクリックするか、ツールバーの右側にあるデータ・アイコンをクリックして、このビューを開きます。
    2. データ・ペインの上部でフィルターを選択して情報を表示します。
    3. データ・ペイン内の項目をクリックして、その項目の詳細を詳細ペインに表示します。
  5. エラー・ページ。4xx 応答は、エラー・ページとして自動的に識別されます。サイトがエラー・ページを使用して 2xx 応答を返す場合は、この応答を認識するように AppScan を構成する必要があります。この情報は、テストの成功を判断する上で必要不可欠な情報です。エラー・ページを構成しないと、誤検出と検出漏れの両方が発生し、結果が不正確なものになります。そのため、応答に単語「エラー」が含まれているにもかかわらず、エラー・ページとして分類されなかったページが前のステップで見つかった場合は、そのページをここで構成します。
    1. 詳細ペインで「ブラウザーで表示」をクリックして、対象のページが実際にエラー・ページであることを確認します。
    2. 「エラー・ページとして設定」をクリックします。
      注: または、エラー・ページを定義するには、「スキャン構成」 > 「エラー・ページ」に移動して、プラス (+ 追加) アイコンをクリックし、ストリングまたは正規表現を指定します。この識別情報は、応答内容、またはパス (またはこれら両方) のエラー・ページが選択されたことを認識するために使用されます。
  6. フィルタリングされた URL を確認します。送信されなかった 要求のリストを確認して、送信する必要があった 要求が含まれていないことを確認します。
    1. データ・ペインで「フィルタリングされた URL」ビューを選択して、フィルタリングされた URL が実際にフィルタリングする必要がある URL であることを確認し、正しく分類されていることを確認します。
    2. ドメインが原因で URL が間違って除外されている場合は (「テストされていない Web サーバー」)、そのドメインをスキャンに追加します (「構成」>「URL およびサーバー」>「追加のサーバーおよびドメイン」>「+」)。
    3. 「パスの制限」に到達したことが原因で URL が間違って除外されている場合は、以下の構成変更のいずれかを行うことをお勧めします。

      - 冗長なパスの制限を増やす (「構成」>「探査オプション」>「冗長なパスの制限」)

      - デフォルトの冗長性調整を調節する (「パラメーターおよび Cookie」>「冗長性調整のデフォルト」)

      - 個別パラメーターの冗長性調整を調節する

  7. パラメーター・ベースの移動サイトのすべてまたは一部で単一の URL を送信するが、異なるパラメーターでコンテンツと構造を制御する場合は、パラメーター・ベースの移動を使用するサイトを参照してください。
  8. パラメーターを確認します。データ・ペインで、探査ステージで検出されたパラメーターを確認します。
    1. データ・ペインで「パラメーター」ビューを選択して、探査ステージで検出されたすべてのパラメーターを表示します。
    2. 必要に応じて、定義を更新します (「構成」>「パラメーターおよび Cookie」)。
  9. 失敗した要求。これは、応答状態が 4xx (「エラー」) の要求です。このリストを確認して、適切な要求が予期せずエラー応答を受け取っていないかどうかを確認します。
    1. 「データ」ペインで「失敗した要求」ビューを選択します。
    2. 404 Not Found: 「ブラウザーで表示」をクリックして、URL が存在しないことを確認します。
    3. Timeout または Connection Failed: スキャンのタイムアウト (「構成」>「通信およびプロキシー」>「タイムアウト」) を長くする必要があるのか、サイトのサーバーまたは環境を改善する必要があるのか、接続の問題の原因が要求が同時に送信されていることにあるのか (「構成」>「通信およびプロキシー」>「スレッドの数」を選択して、設定を「1」に減らす)、あるいは、一定時間に送信される要求が多すぎることにあるのか (「構成」>「通信およびプロキシー」>「要求率の制限」) を判断します。
    4. 401 または 407 Authentication Required: これは、HTTP 認証を必要とするアプリケーション領域が存在することを意味します (「構成」>「プラットフォーム認証」で設定)。
    5. その他の 4xx 状況: ユーザーがログインしていないためにサイトがエラーを返したかどうかを確認します。必要に応じて、ログイン手順を再度記録します (「構成」 > 「ログイン管理」)。
  10. 初期探査結果の確認後にその範囲が不十分であると感じた場合は、考えられる構成変更について次のセクションを参照してください。追加の構成を参照してください。