Set up a browser test 🔗
Use a browser test to monitor the user experience for a single page or a multi-step user flow by running a synthetic test of the URLs you provide. Use this type of test to monitor conversion paths or any path that requires multiple steps or runs JavaScript. For an example, see シナリオ：ブラウザテストを使用するマルチステップワークフローを監視する.
For each page checked in a browser test, Splunk Synthetic Monitoring captures an HTTP Archive (HAR) file, represented in a waterfall chart, which illustrates the performance of specific resources within the page. Browser tests also capture a set of 40+ metrics. See ウォーターフォールチャート and ブラウザテストメトリクス to learn more.
注釈
監視対象のサイトやアプリケーションが、訪問者の許可リストやブロックリスト、またはトラフィックを測定するための分析ツールを使用している場合は、Splunk Synthetic Monitoring からのトラフィックに対応するように設定されていることを確認してください。手順については 合成テストを実行できるようにサイトを準備する を参照してください。
Set up a browser test 🔗
For optimal experience, browser tests use a stable version of Google Chrome: 116.0.5845.96-1 to simulate user activity.
Follow these steps to set up a browser test:
Splunk Observability Cloud のランディングページから、Splunk Synthetic Monitoring に移動します。
Under Tests, select Create new test and then select Browser test from the drop-down list. The test creation view opens.
Name フィールドに、テストの名前を入力します。
To add steps and synthetic transactions to your browser test, select Edit steps or synthetic transactions. See ブラウザテストに合成トランザクションを追加する to learn more.
As you build your test, you can use Try now to check that the configuration of your test is valid. Try now results are ephemeral and don’t impact persisted run metrics. See try nowでテスト設定を検証する.
(Optional) Add a wait time before a step executes. See 待ち時間.
(Optional) Enable automatic test retry in the event a test initially fails.
テストを保存します。
テストの詳細をカスタマイズする 🔗
以下の手順を使用して、テスト設定をカスタマイズし、テストの作成を完了します：
Locations フィールドに、URLをテストする場所を入力します。1つまたは複数の場所を選択できます。
Device Type フィールドで、テストを実施するデバイスをリストから選択します。
Frequency フィールドで、希望するテスト頻度をリストから選択します。
（オプション） Round Robin セレクターを使用して、オプションを切り替えます。ラウンドロビンを有効にすると、選択した場所を1つずつテストが循環します。ラウンドロビン実行を無効にすると、選択した頻度で選択したすべての場所から同時にテストが実行されます。
このテストからアラートを受信したい場合は、+ Create detector を選択して、テストにディテクターを設定します。ダイアログボックスを使用してディテクターをカスタマイズします。
Submit を選択します。すると、新しいテストの「テスト履歴」ページにリダイレクトされます。このテストを作成したばかりの場合は、テストが合成データの収集を開始するまで、少なくとも1回のテスト頻度間隔を空けてください。
（オプション） Edit test またはテストの行にある3つのドットの Actions メニューを選択し、このテストの編集、一時停止、複製、削除を行います。
こちらも参照してください 🔗
テストを実行できる場所については、パブリックロケーション を参照してください。
ディテクターのオプションについては、ディテクターとアラート を参照してください。
Google Chrome Recorderから生成されたJSONファイルをインポートする 🔗
テスト作成プロセスを簡素化するために、Google Chrome Recorder を使用して記録を作成します。その後、JSON ファイルを Splunk Synthetic Monitoring にインポートすると、追跡したい個々のインタラクションを追加する代わりに、ワークフローのステップを自動的にインポートできます。記録は、複雑なユーザーフローや、ステップ数が多いテストに特に役立ちます。
Google ChromeレコーダーJSONファイルを作成する 🔗
Google Chrome の記録の作成手順については、Google ドキュメントの Chrome Developer ユーザーガイド の 「ユーザーフローの記録、再生、測定」 を参照してください。
要件
Google Chrome Recorderで、記録するセレクターのタイプにCSSまたはXPATHを選択します。
ブラウザテストは1つのブラウザタブのみで実行されます。複数のタブにまたがって記録することはできません。
Google Chrome RecorderのJSONファイルをインポートする 🔗
注釈
Recordings from Google Chrome Recorder include the specific viewport size of the browser window used in the recording. When you import a recording, Splunk RUM doesn’t import the viewport size into the browser test. Therefore, you must check that the test’s device setting matches the viewport size used by the recorded browser window.
Follow these steps to import a JSON file from Google Chrome Recorder to a new or existing browser test.
Splunk Synthetic Monitoring で、既存のブラウザ テストで Edit を選択してテスト設定ページを開くか、新しいテストを作成します。
Select Import.
Google Chrome RecorderのJSONファイルをアップロードします。
If a step is not supported, edit or delete that step in the test configuration page.
（オプション）各ステップに名前を付けます。
変更を保存します。
サポートされていないステップをトラブルシューティングする 🔗
If your recording contains unsupported steps, you need to edit the step to reformat it into one of the supported browser step types. The following table shows how Google Chrome Recorder step names and code snippets map to their counterparts in browser tests. These examples use Buttercup Games, a fictitious gaming company.
{
// Google Chrome Recorder
"type": "navigate",
"url": "www.buttercupgames.com",
"assertedEvents": [
{
"type": "navigation",
"url": "www.buttercupgames.com",
"title": "Buttercup Games"
}
]
}
{
// Splunk Synthetic Monitoring code snippet
"name": "Go to URL",
"type": "go_to_url",
"url": "www.buttercupgames.com",
"wait_for_nav": true
}
{
// Google Chrome Recorder
"type": "click",
"target": "main",
"selectors": [
[
"div:nth-of-type(2) > div:nth-of-type(2) a > div"
],
[
"xpath//html/body/main/div/div/div[2]/div[2]/div/a/div"
]
],
"offsetY": 211,
"offsetX": 164,
"assertedEvents": [
{
"type": "navigation",
"url": "www.buttercupgames.com/product/example",
"title": "Buttercup Games"
}
]
}
{
// Splunk Synthetic Monitoring code snippet
"name": "",
"type": "click_element",
"selector_type": "css",
"selector": "div:nth-of-type(2) > div:nth-of-type(2) a > div",
"wait_for_nav": true
}
{
// Google Chrome Recorder
"type": "click",
"target": "main",
"selectors": [
[
"div:nth-of-type(2) > div:nth-of-type(2) a > div"
],
[
"xpath//html/body/main/div/div/div[2]/div[2]/div/a/div"
]
],
"offsetY": 211,
"offsetX": 164,
"assertedEvents": []
}
{
// Splunk Synthetic Monitoring code snippet
"name": "",
"type": "click_element",
"selector_type": "css",
"selector": "div:nth-of-type(2) > div:nth-of-type(2) a > div",
"wait_for_nav": false
}
{ // Google Chrome Recorder "type": "change", "value": "5", "selectors": [ [ "#quantity" ], [ "xpath///*[@id=\"quantity\"]" ] ], "target": "main" }
{
// Splunk Synthetic Monitoring code snippet
"name": "",
"type": "enter_value",
"selector_type": "id",
"selector": "quantity",
"option_selector_type": "index",
"option_selector": "5",
"wait_for_nav": false
}
{
// Google Chrome Recorder
"type": "waitForElement",
"selectors": [
[
"body",
"#homepage_example",
".css-4t2fjl",
".eanm77i0"
]
]
}
{
// Splunk Synthetic Monitoring code snippet
"name": "",
"type": "assert_element_present",
"wait_for_nav": false,
"selector_type": "css",
"selector": "body,#homepage_example, .css-4t2fjl, .eanm77i0"
}
{
// Google Chrome Recorder
"type": "waitForElement",
"selectors": [
[
"body",
"#homepage_product_brand-example",
".css-4t2fjl",
".eanm77i0"
]
],
"visible": false
}
{
// Splunk Synthetic Monitoring code snippet
"name": "",
"type": "assert_element_not_present",
"wait_for_nav": false,
"selector_type": "css",
"selector": "body,#homepage_product_brand-example"
}
{
// Google Chrome Recorder
"type": "customStep",
"timeout": 5000,
"target": "main",
"name": "customParam",
"parameters": {}
}
{
// Splunk Synthetic Monitoring code snippet
"name": "Unsupported step customStep",
"type": "run_javascript",
"value": "",
"wait_for_nav": false
}
View your browser test 🔗
テストを作成して保存したら、期待通りにデータが収集されているかどうかをチェックします：
Tests リストから、3つのドットの Actions メニューを選択し、Play 矢印のアイコンを選択して、手動でテストのライブ実行を開始するか、またはテストが実行されデータが収集される時間があるように、設定したテスト頻度の少なくとも1つの継続時間を待ちます。
関心のあるテストを選択すると、Test history のビューが表示され、最近のテスト結果とメトリクスの視覚化を見ることができます。
See ブラウザテスト結果を解釈する to learn more about browser test results.
Edit your browser test 🔗
To edit your browser test, do the following:
Tests リストで編集したいテストの行を選択し、Test history ビューを開きます。
Edit test を選択し、テスト設定を編集します。
テスト名や合成トランザクション名を変更した場合、更新された名前がチャートとディテクターに表示されるまでに最大20分かかることがあります。
Advanced settings for browser tests 🔗
合成テストに高度な設定をしたくなる理由はたくさんあります。ここではそのいくつかを紹介します：
ランダムに表示され、テストの流れを中断するモーダルでサイトにアクセスする。たとえば、マーケティング モーダルで、ユーザーにポイント プログラムへの登録を促す場合があります。この問題を回避するには、Cookie を設定して、ポップアップ モーダルが表示されず、テストが妨害されないようにします。
ユーザーがサイトにアクセスするためにログインする必要があるサイトでテストを実行します。
リクエストに
User-Agentヘッダーを設定することにより、テストを実行するデバイスのタイプを指定します。CDNのテスト。例えば、ブラウザでHTMLページをロードしたいが、一部またはすべてのリクエストのホストを新しいホストに書き換えたい場合があります。
リクエストに特定のヘッダーを送信することで、バックエンドの分析からのリクエストをフィルタリングします。
自己署名証明書を持つ本番前のサイトでテストを実行します。
インタラクティブメトリクスの収集 🔗
インタラクティブメトリクスは、テストフロー内の各ページに対してデフォルトで収集されますが、ページが 完全にインタラクティブになるまでの時間によっては、実行時間が長くなることがあります。詳細設定でインタラクティブメトリクスをオフにすると、実行時間が短縮され、結果が早く表示されます。インタラクティブメトリクスをオフにした場合、次のメトリクスがテストから失われる可能性があります：
最初のCPUアイドル：ページが最低限インタラクティブになり、ユーザー入力に反応するまでの時間。
インタラクティブまでの時間：ページがユーザーの入力に素早く反応するまでの時間を測定します。ページのロードが完了したように見えるだけでなく、ページが実際に使用できるようになるタイミングを特定するために使用されます。
Lighthouse score: A weighted aggregation of several browser test metric values calculated using v10 of the Lighthouse desktop scoring algorithm. See https://developer.chrome.com/docs/lighthouse/performance/performance-scoring#lighthouse_10 in the Google developer documentation to learn more about Lighthouse scoring.
自動再試行 🔗
テストが失敗した場合、ユーザーの介入なしに自動的に再実行します。ネットワークの問題、タイムアウト、サイトの断続的な問題など、一時的な中断による不要な失敗を減らすために、自動再試行をオンにするのがベストプラクティスです。自動リトライの実行はサブスクリプションの使用量には影響せず、完了した実行結果のみがサブスクリプションの使用量にカウントされます。自動リトライには、少なくともランナーバージョン0.9.29が必要です。
TLS/SSL検証 🔗
この機能を有効にすると、TLS/SSL証明書において、期限切れ、無効なホスト名、または信頼できない発行者の検証を強制するために使用されます。
注釈
自己署名証明書や無効な証明書がある本番前の環境をテストする場合は、TLS/SSL検証機能を無効にしておくのが最善です。
認証 🔗
追加のセキュリティプロトコルを必要とするサイト（企業ネットワーク内など）で認証するための資格情報を追加します。認証を使用するには、ユーザー名とパスワードを入力する必要があります。ユーザー名はプレーンテキストで入力することも、グローバル変数で定義することもできますが、パスワードはグローバル変数を使用して定義する必要があります。パスワードに隠されたグローバル変数を使用して、資格情報にセキュリティの追加レイヤーを作成することが推奨されます。詳細は、グローバル変数を隠すとどうなりますか？ を参照してください。
When executing the browser test, the Chrome browser is configured with the credentials defined in the test configuration. Authentication is not integrated at the OS level, and no authentication processing happens in the runner itself. Credentials are passed directly to Chrome for handling.
At this time, Chrome supports the following authentication protocols:
基本認証
NTLM
Kerberos (with limitations)
ダイジェスト
Chrome supports Kerberos authentication only when it can infer the correct Kerberos service principal name (SPN) based on standard conventions. This support doesn’t include Kerberos Credentials Delegation (Forwardable Tickets) .
カスタムヘッダー 🔗
各リクエストで送信するカスタムヘッダーを指定します。例えば、リクエストにヘッダーを追加して、バックエンドのアナリティクスからのデータをフィルタリングすることができます。カスタムヘッダーを追加するには、名前と値が必要です。オプションで、ヘッダーをスコープするドメインを指定することもできます。ドメインが指定された場合は、そのドメインに送られたリクエストのみがヘッダーを含みます。そうでなければ、ヘッダーはすべてのドメインへのリクエストに含まれます。
ヘッダーを使用してユーザーエージェントを変更することもできます。デフォルトのユーザーエージェントは、選択したデバイスに対して指定されたエージェントであり、合成ランナーの Chrome バージョンが変更されるたびに更新されます。すべてのドメインのユーザーエージェントヘッダーをカスタマイズするには、ユーザーエージェントフィールドの横にある「デバイスのデフォルトを使用」トグルをオフにしてから、新しい値を入力します。特定のドメインのユーザーエージェントを変更するには、カスタムヘッダーを追加し、そのユーザーエージェントを適用するドメインを指定します。ドメインが指定されていない場合は、最上位のユーザーエージェント設定が優先されます。
カスタムヘッダーを使用してクッキーを設定することもできますが、代わりに以下のセクションで説明されているクッキー設定を使用することをお勧めします。
ホストオーバーライド 🔗
Add host override rules to reroute requests from one host to another. For example, you can create a host override to test an existing production site against page resources loaded from a development site or from a specific CDN edge node.
You can also indicate whether to retain the original HOST header by activating Keep host headers. If activated, the original request’s headers remain intact (recommended). If deactivated, a change in the HOST header to the new host might occur, potentially leading to an internal direct (307). Keep host headers is activated by default.
注釈
Host overrides apply only to the exact hostname you specify. They don’t automatically apply to subdomains. In other words, host overrides don’t support wildcards. If you need to override any subdomains, you must create a separate host override for each subdomain’s fully qualified domain name (FQDN). For example, if you create a host override for domainA.com to domainB.com, requests to domainA.com are redirected to domainB.com, but requests to mail.domainA.com are not automatically redirected to mail.domainB.com. You must explicitly create a separate host override for mail.domainA.com.
待ち時間 🔗
Optimize your test coverage by adding custom wait times to capture longer page loads and improve the accuracy of run results. Applications with long load times can cause a browser test to fail. If you know that there are certain steps in a workflow that take longer than 10 seconds, add a custom wait time to your browser test.
Wait times are available with browser tests only.
各テストの最大カスタム待ち時間は200秒です。
Follow these steps to configure custom wait times for your browser tests:
In Splunk Synthetic Monitoring, select Edit on the browser test to open the configuration panel.
Select New step > Wait, from the step type drop down.
名前と待ち時間（ミリ秒）を追加します。
When you finish instrumenting your test, save the workflow: Return to test > Save.
次の画像は、あるURLにアクセスし、10秒間待ってからログインするようにテストを設定する方法を示しています。
設定可能な待ち時間の制限とデフォルト 🔗
各タイプの待機時間の制限を以下に示します。runの上限は30分で、それを過ぎるとタイムアウトとなります。
説明 |
Limit |
|---|---|
アサートステップ |
90秒 |
ナビゲーションの待機 |
20秒 |
説明 |
デフォルト |
|---|---|
アサートの待ち時間 |
10秒 |
ナビゲーションの待機 |
2秒 |
Chromeフラグ 🔗
Google Chrome のフラグはトラブルシューティングに役立つツールです。デフォルトでは利用できないブラウザの機能を有効にして、カスタムブラウザの設定やプロキシサーバーのような特殊なユースケースをテストします。
詳しくは、Google Chrome Developer Guide の Chrome フラグとは？ を参照してください。
注意：グローバル変数は Chromeフラグと互換性がありません。
これらは利用可能なフラッグです：
Chromeフラグ |
説明 |
|---|---|
|
リクエストは |
|
QUICを無効にします。これによりHTTP3も無効になります。 |
|
同一オリジンポリシーの強制を無効にします。 |
|
指定された安全でないオリジンを安全なものとして扱います。複数のオリジンは、カンマ区切りのリストで指定することができます。 |
|
与えられたセミコロン区切りのホストリストの任意の指定プロキシのプロキシバイパスリスト。このフラグは |
|
指定したプロキシサーバーを使用してデフォルト設定を上書きします。 |
|
プロキシサーバーを使用せず、常に直接接続を行います。このフラグは、プライベートロケーションに設定した他のプロキシサーバーフラグを上書きするために使用できます。 |
Excluded files 🔗
You can configure your browser test to ignore specific file types or patterns so that it skips all HTTP requests that match those file types or patterns.
Exclusion rules are useful to:
Prevent false alerts from test analytics.
Test the performance of a page with or without specific resources loading.
Prevent specific third-party services from loading, such as random pop-ups from third-party services.
Ignore files that are known to cause performance problems.
To create an exclusion rule:
On the browser test’s configuration page, select the Advanced toggle.
Scroll down to the Custom content section.
Select Add excluded file.
Select a value in File type:
To exclude all files of a common predefined type, select that type.
To exclude all file types except those that match the value you specify, select All Except and specify a value or regular expression.
To use regular expressions, select Custom and specify a value or regular expression. For example:
To exclude a specific domain, including all of its subdomains, enter
domainname\.comTo exclude only the subdomains of a specific domain, but not the domain itself, enter
.+\.domainname\.comTo exclude a JavaScript app, enter
domainname\.com/appname\.jsTo exclude entire directories, enter
domainname\.com/directoryname\/.+
注釈
All Except inclusions take precedence over other exclusions. The order in which you specify exclusions doesn’t matter except when you’re using a combination of All Except and Custom.
カスタムプロパティ 🔗
詳細設定のテスト作成ページでカスタムプロパティを追加します。キーと値のペアを使用してカスタムプロパティを作成し、ダッシュボード、チャートをフィルタリングおよびグループ化し、アラートを作成します。テストに関連付けられているタグに基づいて、テストごとにカスタムプロパティの候補リストが表示されます。例: env:test、role:developer、product:rum。複数のキーと値のペアがある場合、ロジックは結果間の AND になります。つまり、この場合、環境テストで開発者ロールを持つ RUM 製品のすべてのテストが結果に表示されます。
Custom properties are single valued and don’t support multiple values, like region:eu, us. For each test, you can only use one and unique key. For example, you can have env1:test and env:test in the same test, but you can’t have env:test, and env:prod.
主な要件：
キーは大文字または小文字で始めなければなりません。特殊文字や数字でキーを始めることはできません。
キーの残りの部分には、文字、数字、アンダースコア、ハイフンを含めることができます。
Keys can’t be named
test_idortest.キーサイズは128文字以内です。
カスタムプロパティ を参照してください。
例 🔗
例については、シナリオ：ブラウザテストを使用するマルチステップワークフローを監視する を参照してください。