複数ステップの Web テスト

  • [アーティクル]

複数ステップ Web テストを使用して、記録された一連の URL と Web サイトとのインタラクションを監視することができます。 この記事では、Visual Studio Enterprise を使用した複数ステップ Web テストを作成するプロセスについて説明します。

重要

複数ステップ Web テストは非推奨となっています。 カスタム可用性テストは、複数ステップ Web テストではなく、TrackAvailability() を使用して送信することをお勧めします。 TrackAvailability() とカスタム可用性テストを使用すると、任意のコンピューティングでテストを実行でき、また、C# を使用して容易に新しいテストを作成することができます。

複数ステップ Web テストはクラシック テストとして分類され、[可用性] ペインの [クラシック テストの追加] に表示されます。

注意

Azure Government クラウドでは、複数ステップ Web テストはサポートされていません。

複数ステップ Web テストの代替手段

複数ステップ Web テストは、Visual Studio の Web テスト ファイルに依存します。 Visual Studio 2019 が Web テスト機能を備えた最後のバージョンとなることが発表されました。 新しい機能は追加されませんが、Visual Studio 2019 の Web テスト機能は現在もサポートされており、製品のサポート ライフサイクルの間は引き続きサポートされます。

カスタム可用性テストは、複数ステップ Web テストではなく、TrackAvailability を使用して送信することをお勧めします。 このオプションは複数の要求または認証テストのシナリオで長期的にサポートされるソリューションです。 TrackAvailability() とカスタム可用性テストを使用すると、任意のコンピューティングでテストを実行でき、また、C# を使用して容易に新しいテストを作成することができます。

前提条件

必要なもの:

  • Visual Studio 2017 Enterprise 以降。
  • Visual Studio の Web パフォーマンスとロード テスト ツール。

テスト ツールの前提条件を見つけるには、[Visual Studio インストーラー]>[個別のコンポーネント]>[デバッグとテスト]>[Web パフォーマンスとロード テスト ツール]の順に選択します。

Web パフォーマンスとロード テスト ツール用の項目の横にあるチェックボックスを使用して個別のコンポーネントが選択されている Visual Studio インストーラー UI を示すスクリーンショット。

Note

複数ステップ Web テストには、それらに関連付けられた追加のコストが発生します。 詳細については、価格の公式ガイドを参照してください。

複数ステップ Web テストを記録する

警告

複数ステップ レコーダーの使用は推奨されなくなりました。 レコーダーは、基本的なインタラクションを伴う静的 HTML ページ用に開発されました。 最新の Web ページ向けの機能的なエクスペリエンスは提供されません。

Visual Studio Web テストの作成方法に関するガイダンスについては、公式の Visual Studio 2019 ドキュメントに関する記事を参照してください。

Web テストをアップロードする

  1. Application Insights ポータルの [可用性] ペインで、[クラシック テストの追加] を選択します。 次に、[SKU] として [複数ステップ] を選択します。
  2. 複数ステップ Web テストをアップロードします。
  3. テストの場所、頻度、およびアラートのパラメーターを設定します。
  4. ［作成］ を選択します

頻度と場所

設定 説明
[テスト間隔] 各テストの場所からテストを実行する頻度を設定します。 既定の間隔が 5 分で、テストの場所が 5 か所の場合、サイトは平均して毎分テストされます。
テストの場所 Web 要求の送信元。サーバーはこの場所から指定の URL に Web 要求を送信します。 Web サイトの問題とネットワークの問題とを確実に区別するために、テストの場所は 5 か所以上にすることをお勧めします。 最大 16 個の場所を選択できます。

成功の基準

設定 説明
テストのタイムアウト この値を引き下げると、応答が遅い場合に警告されます。 テストは、この期間内にサイトから応答が返されない場合に、エラーとしてカウントされます。 [従属要求の解析] をオンにした場合、すべての画像、スタイル ファイル、スクリプト、その他依存するリソースがこの期間内に受信される必要があります。
HTTP 応答 成功としてカウントされる、返される状態コード。 200 は、通常の Web ページが返されたことを示すコードです。
[内容検索] "Welcome!" などの文字列。それぞれの応答内に、大文字と小文字を区別した完全一致があるかどうかをテストします。 文字列は、(ワイルドカードを含まない) プレーン文字列である必要があります。 ページ コンテンツが変更された場合は、この文字列の更新が必要になる可能性があることに注意してください。 コンテンツの一致では、英字のみがサポートされています。

警告

設定 説明
ほぼリアルタイム (プレビュー) 準リアルタイムのアラートを使用することが推奨されます。 この種類のアラートの構成は、可用性テストの作成後に実行されます。
アラートの場所のしきい値 少なくとも 3/5 の場所にすることをお勧めします。 アラートの場所のしきい値とテストの場所の数の最適な関係は、アラートの場所のしきい値 = テストの場所の数 - 2 です。テストの場所は、少なくとも 5 か所にします。

構成

次の構成手順に従ってください。

時間とランダムな数をテストに組み込む

外部からフィードされる株価など、時間に依存するデータを取得するツールをテストするとします。 Web テストを記録するときに、特定の時刻を使用する必要があります。それらは、StartTime と EndTime というテストのパラメーターとして設定します。

株価アプリを示すスクリーンショット。

テストを実行するときは、EndTime を常に現在の時刻にする必要があります。 StartTime は 15 分前にする必要があります。

Web Test Date Time Plug-in によって、パラメーター時間を処理する方法が提供されます。

  1. 目的の各変数のパラメーター値に対して Web テスト プラグインを追加します。 Web テスト ツール バーで、[Web テスト プラグインを追加する] を選択します。

    [Web テスト プラグインを追加する] を示すスクリーンショット。

    この例では、日時プラグインというインスタンスを 2 つ使用します。 1 つのインスタンスが "15 分前" 用、もう 1 つは "現在" 用です。

  2. 各プラグインのプロパティを開きます。 名前を付け、現在の時刻を使用するように設定します。 いずれかの[分の追加] に [-15] を設定します。

    コンテキスト パラメーターを示すスクリーンショット。

  3. Web テスト パラメーターで、{{plug-in name}} を使用して、プラグイン名を参照します。

    StartTime を示すスクリーンショット。

ここでテストをポータルにアップロードします。 テストを実行するたびに、動的な値が使用されます。

サインインを検討する

ユーザーがアプリにサインインする場合、サインインの背後にあるページをテストできるように、サインインをシミュレートするためのさまざまなオプションがあります。 使用する方法は、アプリで提供されるセキュリティの種類によって異なります。

いずれの場合も、テスト用にのみアプリケーションにアカウントを作成してください。 可能であれば、実際のユーザーが Web テストの影響を受けないように、このテスト アカウントのアクセス許可を制限します。

単純なユーザー名とパスワード

通常の方法で Web テストを記録します。 まず Cookie を削除します。

SAML 認証

プロパティ名 説明
対象ユーザー URI SAML トークンの対象ユーザー URI です。 この URI は、Access Control 名前空間とホスト名を含む、Access Control サービス用です。
Certificate password 埋め込まれた秘密キーへのアクセスを許可するクライアント証明書のパスワード。
クライアント証明書 Base64 でエンコードされた形式の秘密キーを持つクライアント証明書の値。
名前識別子 トークンの名前識別子。
有効期間の終了時刻 トークンが有効な期間。 既定値は 5 分です。
期間の開始時刻 過去に作成されたトークンの有効期間 (時間のずれを解決するため)。 既定値は (マイナス) 5 分です。
ターゲット コンテキスト パラメーター名 生成されたアサーションを受け取るコンテキスト パラメーター。

クライアント シークレット

アプリにクライアント シークレットを含むサインイン ルートがある場合は、それを使用します。 クライアント シークレット サインインを提供するサービスの例として、Azure Active Directory (Azure AD) が挙げられます。 Azure AD の場合、クライアント シークレットはアプリ キーです。

アプリ キーを使用した Azure Web アプリのサンプル Web テストを次に示します。

サンプルを示すスクリーンショット。

  1. クライアント シークレット (アプリ キー) を使用して、Azure AD からトークンを取得します。
  2. 応答からベアラー トークンを抽出します。
  3. 承認ヘッダーにベアラー トークンを使用して API を呼び出します。
  4. Web テストが実際のクライアントであることを確認します。 これは、Azure AD に独自のアプリがあるということを意味します。 クライアント ID とアプリ キーを使用します。 テスト対象のサービスには、Azure AD に独自のアプリも含まれます。 このアプリのアプリ ID URI は、リソース フィールドの Web テストに反映されます。

開かれた認証

オープン認証の例としては、Microsoft または Google アカウントを使用したサインイン作業が挙げられます。 OAuth を使用する多くのアプリがクライアント シークレットに代わる機能を提供しているため、その可能性を調査することが最初の方法です。

テストで OAuth を使用してサインインする必要がある場合に、一般的な方法を次に示します。

  1. Fiddler などのツールを使用して、Web ブラウザー、認証サイト、アプリケーション間のトラフィックを調べます。
  2. 異なるコンピューターやブラウザーを使用するか、または長い間隔 (トークンを期限切れにさせる) で複数のサインインを実行します。
  3. 異なるセッションを比較して、認証サイトから返され、次にサインイン後にアプリケーション サーバーに渡されるトークンを識別します。
  4. Visual Studio を使用して Web テストを記録します。
  5. トークンをパラメーター化します。 トークンが認証システムから返されたときに、パラメーターを設定し、サイトへのクエリでそれを使用します。 (Visual Studio は、テストのパラメーター化を試みますが、トークンを正しくパラメーター化しません。)

トラブルシューティング

トラブルシューティングのヘルプについては、専用のトラブルシューティングに関する記事を参照してください。

次のステップ