複数手順の Web テストMulti-step web tests

複数ステップ Web テストを使用して、記録された一連の URL と Web サイトとのインタラクションを監視することができます。You can monitor a recorded sequence of URLs and interactions with a website via multi-step web tests. この記事では、Visual Studio Enterprise を使用した複数ステップ Web テストを作成するプロセスについて説明します。This article will walk you through the process of creating a multi-step web test with Visual Studio Enterprise.

注意

複数ステップ Web テストは、Visual Studio の Web テスト ファイルに依存します。Multi-step web tests depend on Visual Studio webtest files. Visual Studio 2019 が Web テスト機能を備えた最後のバージョンとなることが発表されました。It was announced that Visual Studio 2019 will be the last version with webtest functionality. 新しい機能は追加されませんが、Visual Studio 2019 の Web テスト機能は現在もサポートされており、製品のサポート ライフサイクルの間は引き続きサポートされることを理解しておくことが重要です。It is important to understand that while no new features will be added, webtest functionality in Visual Studio 2019 is still currently supported and will continue to be supported during the support lifecycle of the product. Azure Monitor 製品チームでは、複数ステップ可用性テストの今後に関するご質問に対して、こちらで回答しています。The Azure Monitor product team has addressed questions regarding the future of multi-step availability tests here.

前提条件Pre-requisites

  • Visual Studio 2017 Enterprise 以降。Visual Studio 2017 Enterprise or greater.
  • Visual Studio の Web パフォーマンスとロード テスト ツール。Visual Studio web performance and load testing tools.

前提条件であるテスト ツールを見つけるために、To locate the testing tools pre-requisite. [Visual Studio インストーラー] > [個別のコンポーネント] > [デバッグとテスト] > [Web パフォーマンスとロード テスト ツール] を起動します。Launch the Visual Studio Installer > Individual components > Debugging and testing > Web performance and load testing tools.

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

注意

複数ステップ Web テストには、それらに関連付けられている追加のコストがあります。Multi-step web tests have additional costs associated with them. 詳細については、価格の公式ガイドをご覧ください。To learn more consult the official pricing guide.

複数ステップ Web テストを記録するRecord a multi-step web test

複数手順のテストを作成するには、Visual Studio Enterprise を使用してシナリオを記録してから、その記録を Application Insights にアップロードします。To create a multi-step test, you record the scenario by using Visual Studio Enterprise, and then upload the recording to Application Insights. Application Insights では、設定された間隔でそのシナリオが再生され、応答が検証されます。Application Insights replays the scenario at set intervals and verifies the response.

重要

  • テストでは、コード化された機能またはループは使用できません。You can't use coded functions or loops in your tests. テストは .webtest スクリプトに完全に含まれている必要があります。The test must be contained completely in the .webtest script. ただし、標準的なプラグインは使用できます。However, you can use standard plugins.
  • 複数ステップ Web テストでは、英語文字のみがサポートされます。Only English characters are supported in the multi-step web tests. 他の言語で Visual Studio を使用している場合、Web テスト定義ファイルを更新して、英語以外の文字を翻訳/除外してください。If you use Visual Studio in other languages, please update the web test definition file to translate/exclude non-English characters.

Web セッションを記録するには、Visual Studio Enterprise を使用します。Use Visual Studio Enterprise to record a web session.

  1. Web パフォーマンスとロード テストのプロジェクトを作成します。Create a Web performance and Load Test Project. [ファイル] > [新規] > [プロジェクト] > [Visual C#] > [テスト]File > New > Project > Visual C# > Test

    Visual Studio の新しいプロジェクトの UI

  2. .webtest ファイルを開き、記録を開始します。Open the .webtest file and start recording.

    Visual Studio のテスト記録の UI

  3. 記録の一部としてシミュレートするテストのステップをクリックします。Click through the steps you want your test to simulate as part of the recording.

    ブラウザーの記録の UI

  4. テストを編集します。Edit the test to:

    • 受信したテキストと応答コードを確認するための検証を追加します。Add validations to check the received text and response codes.
    • 不必要なインタラクションをすべて削除します。Remove any uneccesary interactions. 画像に依存している要求を削除したり、テストの成功に関係しないと思われる追跡サイトを追加したりできます。You could also remove dependent requests for pictures or add tracking sites which aren't relevant to you considering your test a success.

    テスト スクリプトの編集のみを実行できることを忘れないでください。カスタム コードの追加や他の Web テストを呼び出すことができます。Keep in mind that you can only edit the test script - you can add custom code or call other web tests. テストにループを挿入しないでください。Don't insert loops in the test. 標準的な Web テスト プラグインを使用することができます。You can use standard web test plug-ins.

  5. Visual Studio でテストを実行して検証を行って、動作することを確認します。Run the test in Visual Studio to validate and make sure it works.

    Web テスト ランナーは、web ブラウザーを開き、記録したアクションを繰り返します。The web test runner opens a web browser and repeats the actions you recorded. すべてが期待どおりに動作することを確認します。Make sure everything behaves as expected.

Web テストをアップロードするUpload the web test

  1. Application Insights ポータルの [可用性] ウィンドウで、 [テストの作成] > [テストの種類] > [複数ステップ Web テスト] を選択します。In the Application Insights portal on the Availability pane select Create Test > Test type > Multi-step web test.

  2. テストの場所、頻度、およびアラートのパラメーターを設定します。Set the test locations, frequency, and alert parameters.

頻度と場所Frequency & location

SettingSetting 説明Explanation
テスト間隔Test frequency 各テストの場所からテストを実行する頻度を設定します。Sets how often the test is run from each test location. 既定の間隔が 5 分で、テストの場所が 5 か所の場合、サイトは平均して毎分テストされます。With a default frequency of five minutes and five test locations, your site is tested on average every minute.
テストの場所Test locations 指定の URL にサーバーによって Web 要求が送信される送信元の場所です。Are the places from where our servers send web requests to your URL. Web サイトの問題とネットワークの問題とを確実に区別するために、最低でもテストの場所を 5 か所にすることが推奨されますOur minimum number of recommended test locations is five in order to insure that you can distinguish problems in your website from network issues. 最大 16 個の場所を選択できます。You can select up to 16 locations.

成功の基準Success criteria

SettingSetting 説明Explanation
テストのタイムアウトTest timeout この値を引き下げると、応答が遅い場合に警告されます。Decrease this value to be alerted about slow responses. テストは、この期間内にサイトから応答が返されない場合に、エラーとしてカウントされます。The test is counted as a failure if the responses from your site have not been received within this period. [従属要求の解析] をオンにした場合、すべての画像、スタイル ファイル、スクリプト、その他依存するリソースがこの期間内に受信される必要があります。If you selected Parse dependent requests, then all the images, style files, scripts, and other dependent resources must have been received within this period.
HTTP 応答HTTP response 成功としてカウントされる、返される状態コード。The returned status code that is counted as a success. 200 は、通常の Web ページが返されたことを示すコードです。200 is the code that indicates that a normal web page has been returned.
コンテンツの一致Content match "Welcome!" などの文字列。A string, like "Welcome!" それぞれの応答に大文字小文字を区別した完全一致があるかどうかをテストします。We test that an exact case-sensitive match occurs in every response. 文字列は、(ワイルドカードを含まない) プレーン文字列である必要があります。It must be a plain string, without wildcards. ページ コンテンツが変更された場合は、この文字列も更新する必要がある可能性があることに注意してください。Don't forget that if your page content changes you might have to update it. コンテンツの一致では、英語のみがサポートされています。Only English characters are supported with content match

アラートAlerts

SettingSetting 説明Explanation
準リアルタイム (プレビュー)Near-realtime (Preview) 準リアルタイムのアラートを使用することが推奨されます。We recommend using Near-realtime alerts. この種類のアラートの構成は、可用性テストの作成後に実行されます。Configuring this type of alert is done after your availability test is created.
クラシックClassic 新しい可用性テストでクラシック アラートを使用することはもう推奨されていません。We no longer recommended using classic alerts for new availability tests.
アラートの場所のしきい値Alert location threshold 少なくとも 3/5 の場所にすることをお勧めします。We recommend a minimum of 3/5 locations. アラートの場所のしきい値とテストの場所の数の最適な関係は、アラートの場所のしきい値 = テストの場所の数 - 2 です。テストの場所は、少なくとも 5 か所にします。The optimal relationship between alert location threshold and the number of test locations is alert location threshold = number of test locations - 2, with a minimum of five test locations.

詳細な構成Advanced Configuration

テストに対する時間とランダムな数の組み込みPlugging time and random numbers into your test

外部からフィードされる株価など、時間に依存するデータを取得するツールをテストするとします。Suppose you're testing a tool that gets time-dependent data such as stocks from an external feed. Web テストを記録するときに、特定の時刻を使用する必要があります。ただし、その時刻は、StartTime と EndTime というテストのパラメーターとして設定しました。When you record your web test, you have to use specific times, but you set them as parameters of the test, StartTime and EndTime.

myawesomestockapp のスクリーンショット

テストを実行するときに、EndTime を現在の時刻に、StartTime を 15 分前に常に設定する必要があるとします。When you run the test, you'd like EndTime always to be the present time, and StartTime should be 15 minutes ago.

Web Test Date Time Plugin によって、パラメーター化された時間を処理する方法が提供されます。The Web Test Date Time Plugin provides the way to handle parameterize times.

  1. 目的の各変数のパラメーター値に対して Web テスト プラグインを追加します。Add a web test plug-in for each variable parameter value you want. Web テスト ツールバーで、 [Web テスト プラグインを追加] を選択します。In the web test toolbar, choose Add Web Test Plugin.

    Web テスト プラグインを追加する

    この例では、日時プラグインというインスタンスを 2 つ使用します。In this example, we use two instances of the Date Time Plug-in. 1 つのインスタンスが "15 分前" 用、もう 1 つは "現在" 用です。One instance is for "15 minutes ago" and another for "now."

  2. 各プラグインのプロパティを開きます。Open the properties of each plug-in. 名前を付け、現在の時刻を使用するように設定します。Give it a name and set it to use the current time. いずれかのプロパティに、「Add Minutes = -15」を設定します。For one of them, set Add Minutes = -15.

    コンテキスト パラメーター

  3. Web テスト パラメーターで、{{プラグイン名}} を使用して、プラグイン名を参照します。In the web test parameters, use {{plug-in name}} to reference a plug-in name.

    StartTime

ここでテストをポータルにアップロードします。Now, upload your test to the portal. テストを実行するたびに、動的な値が使用されます。It will use the dynamic values on every run of the test.

サインインの処理Dealing with sign-in

ユーザーがアプリにサインインする場合、サインインの背後にあるページをテストできるように、サインインをシミュレートするためのさまざまなオプションがあります。If your users sign in to your app, you have various options for simulating sign-in so that you can test pages behind the sign-in. 使用する方法は、アプリで提供されるセキュリティの種類によって異なります。The approach you use depends on the type of security provided by the app.

どの場合も、アプリケーションでテスト目的のみのアカウントを作成する必要があります。In all cases, you should create an account in your application just for the purpose of testing. 可能であれば、実際のユーザーが Web テストの影響を受けないように、このテスト アカウントのアクセス許可を制限します。If possible, restrict the permissions of this test account so that there's no possibility of the web tests affecting real users.

単純なユーザー名とパスワード 通常の方法で Web テストを記録します。Simple username and password Record a web test in the usual way. まず Cookie を削除します。Delete cookies first.

SAML 認証SAML authentication

プロパティ名Property name 説明Description
対象ユーザー URIAudience Uri SAML トークンの対象ユーザー URI です。The audience URI for the SAML token. これは Access Control Service (ACS) の URI で、ACS 名前空間とホスト名を含みます。This is the URI for the Access Control Service (ACS) – including ACS namespace and host name.
証明書のパスワードCertificate Password 埋め込まれた秘密キーへのアクセスを許可するクライアント証明書のパスワード。The password for the client certificate which will grant access to the embedded private key.
クライアント証明書Client Certificate Base64 でエンコードされた形式の秘密キーを持つクライアント証明書の値。The client certificate value with private key in Base64 encoded format.
名前識別子Name Identifier トークンの名前識別子The name identifier for the token
有効期間の終了時刻Not After トークンが有効な期間。The timespan for which the token will be valid. 既定値は 5 分です。The default is 5 minutes.
期間の開始時刻Not Before 過去に作成されたトークンの有効期間 (時間のずれを解決するため)。The timespan for which a token created in the past will be valid (to address time skews). 既定値は (マイナス) 5 分です。The default is (negative) 5 minutes.
ターゲット コンテキスト パラメーター名Target Context Parameter Name 生成されたアサーションを受け取るコンテキスト パラメーター。The context parameter that will receive the generated assertion.

クライアント シークレット アプリにクライアント シークレットを含むサインイン ルートがある場合は、そのルートを使用します。Client secret If your app has a sign-in route that involves a client secret, use that route. クライアント シークレット サインインを提供するサービスの例として、Azure Active Directory (AAD) が挙げられます。Azure Active Directory (AAD) is an example of a service that provides a client secret sign-in. AAD の場合、クライアント シークレットはアプリ キーです。In AAD, the client secret is the App Key.

アプリ キーを使用した Azure Web アプリのサンプル Web テストを次に示します。Here's a sample web test of an Azure web app using an app key:

サンプルのスクリーン ショット

クライアント シークレット (AppKey) を使用して AAD からトークンを取得します。Get token from AAD using client secret (AppKey). 応答からベアラー トークンを抽出します。Extract bearer token from response. 承認ヘッダーにベアラー トークンを使用して API を呼び出します。Call API using bearer token in the authorization header. Web テストが実際のクライアントであること、つまり、専用のアプリが AAD に登録されていることを確認し、その clientId と appkey を使用します。Make sure that the web test is an actual client - that is, it has its own app in AAD - and use its clientId + app key. テスト対象のサービスの独自のアプリも AAD に登録されている場合: Web テストのリソース フィールドにはこのアプリの appID URI が反映されます。Your service under test also has its own app in AAD: the appID URI of this app is reflected in the web test in the resource field.

オープン認証Open Authentication

オープン認証の例としては、Microsoft または Google アカウントを使用したサインインが挙げられます。An example of open authentication is signing in with your Microsoft or Google account. OAuth を使用する多くのアプリがクライアント シークレットに代わる機能を提供しているため、その可能性を調査することが最初の方法です。Many apps that use OAuth provide the client secret alternative, so your first tactic should be to investigate that possibility.

テストで OAuth を使用してサインインする必要がある場合に、一般的な方法を次に示します。If your test must sign in using OAuth, the general approach is:

Fiddler などのツールを使用して、Web ブラウザー、認証サイト、アプリケーション間のトラフィックを調べます。Use a tool such as Fiddler to examine the traffic between your web browser, the authentication site, and your app. 異なるコンピューターやブラウザーを使用するか、または長い間隔 (トークンを期限切れにさせる) で複数のサインインを実行します。Perform two or more sign-ins using different machines or browsers, or at long intervals (to allow tokens to expire). 異なるセッションを比較して、認証サイトから返され、次にサインイン後にアプリケーション サーバーに渡されるトークンを識別します。By comparing different sessions, identify the token passed back from the authenticating site, that is then passed to your app server after sign-in. Visual Studio を使用して Web テストを記録します。Record a web test using Visual Studio. トークンをパラメーター化し、トークンが認証システムから返されたときに、パラメーターを設定し、サイトへのクエリでそれを使用しますParameterize the tokens, setting the parameter when the token is returned from the authenticator, and using it in the query to the site. (Visual Studio は、テストのパラメーター化を試みますが、トークンを正しくパラメーター化しません)。(Visual Studio attempts to parameterize the test, but does not correctly parameterize the tokens.)

トラブルシューティングTroubleshooting

専用のトラブルシューティングに関する記事をご覧ください。Dedicated troubleshooting article.

次の手順Next steps