ブラウザテストをセットアップする 🔗

ブラウザテストを使用して、提供するURLの合成テストを実行することにより、単一ページまたは複数ステップのユーザーフローのユーザーエクスペリエンスをモニターします。このタイプのテストは、コンバージョン経路、または複数のステップを必要とする経路、あるいはJavaScriptを実行する経路を監視するために使用します。例については、シナリオ：ブラウザテストを使用するマルチステップワークフローを監視するを参照してください。

ブラウザテストでチェックされた各ページについて、Splunk Synthetic Monitoring は HTTP Archive (HAR) ファイルをキャプチャし、ウォーターフォールチャートで表します。ブラウザテストでは、40以上のメトリクスも取得できます。詳しくはウォーターフォールチャートとブラウザテストメトリクスを参照してください。

注釈

監視対象のサイトやアプリケーションが、訪問者の許可リストやブロックリスト、またはトラフィックを測定するための分析ツールを使用している場合は、Splunk Synthetic Monitoring からのトラフィックに対応するように設定されていることを確認してください。手順については Get your site ready to run synthetic tests を参照してください。

ブラウザテストをセットアップする 🔗

For optimal experience, synthetics browser tests use a stable version of Google Chrome: 116.0.5845.96-1 to simulate user activity.

以下の手順に従って、ブラウザテストをセットアップしてください：

Splunk Observability Cloud のランディングページから、Splunk Synthetic Monitoring に移動します。
Tests で Add New Test を選択し、ドロップダウンリストから Browser Test を選択します。テスト作成ビューが開きます。
Name フィールドに、テストの名前を入力します。
ブラウザテストにステップと合成トランザクションを追加するには、Edit steps or synthetic transactions を選択します。詳しくはブラウザテストに合成トランザクションを追加するを参照してください。
テストを構築するときに、Try now を使用して、テストの構成が有効であることを確認できます。Try now の結果は一時的であり、永続化された run メトリクスには影響しません。詳細については、try nowでテスト設定を検証するを参照してください。
(オプション) ステップが実行されるまでの待ち時間を追加します。待ち時間を参照してください。
(Optional) Turn on 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 メニューを選択し、このテストの編集、一時停止、複製、削除を行います。

こちらも参照してください 🔗

テストを実行できる場所については、パブリックロケーションを参照してください。
ディテクターのオプションについては、Splunk Synthetic Monitoring でディテクターとアラートを設定するを参照してください。

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ファイルをインポートする 🔗

注釈

Google Chrome Recorder の録画には、録画で使用したブラウザウィンドウのビューポートサイズが含まれています。インポートした場合、この記録されたビューポートは Synthetics Browser テストにはインポートされません。Synthetics Browserテストのデバイス選択が、録画されたブラウザウィンドウで使用されているビューポートサイズを正確に表していることを確認してください。

Google Chrome Recorderから新規または既存のブラウザテストにJSONファイルをインポートするには、以下の手順に従ってください。

Splunk Synthetic Monitoring で、既存のブラウザテストで Edit を選択してテスト設定ページを開くか、新しいテストを作成します。
インポートを選択します。
Google Chrome RecorderのJSONファイルをアップロードします。
ステップがサポートされていない場合は、テスト設定ページでステップを編集または削除する必要があります。
（オプション）各ステップに名前を付けます。
変更を保存します。

サポートされていないステップをトラブルシューティングする 🔗

記録に未対応のステップが含まれている場合は、そのステップを編集して、サポートされている Synthetic Browser ステップタイプのいずれかにフォーマットし直す必要があります。次の表は、Google Chrome Recorder のステップ名とコードスニペットが、Splunk Synthetic Browser テストでどのように対応するかを示しています。これらの例では、Buttercup Games という架空のゲーム会社を使用しています。

{
 // 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
}

ブラウザテストを表示する 🔗

テストを作成して保存したら、期待通りにデータが収集されているかどうかをチェックします：

Tests リストから、3つのドットの Actions メニューを選択し、Play 矢印のアイコンを選択して、手動でテストのライブ実行を開始するか、またはテストが実行されデータが収集される時間があるように、設定したテスト頻度の少なくとも1つの継続時間を待ちます。
関心のあるテストを選択すると、Test history のビューが表示され、最近のテスト結果とメトリクスの視覚化を見ることができます。
ブラウザのテスト結果については、Interpret Browser test results を参照してください。

ブラウザテストを編集する 🔗

ブラウザテストを編集するには、以下のようにします：

Tests リストで編集したいテストの行を選択し、Test history ビューを開きます。
Edit test を選択し、テスト設定を編集します。

テスト名や合成トランザクション名を変更した場合、更新された名前がチャートとディテクターに表示されるまでに最大20分かかることがあります。

ブラウザテストの詳細設定 🔗

合成テストに高度な設定をしたくなる理由はたくさんあります。ここではそのいくつかを紹介します：

ランダムに表示され、テストの流れを中断するモーダルでサイトにアクセスする。たとえば、マーケティングモーダルで、ユーザーにポイントプログラムへの登録を促す場合があります。この問題を回避するには、Cookie を設定して、ポップアップモーダルが表示されず、テストが妨害されないようにします。
ユーザーがサイトにアクセスするためにログインする必要があるサイトでテストを実行します。
リクエストに User-Agent ヘッダーを設定することにより、テストを実行するデバイスのタイプを指定します。
CDNのテスト。例えば、ブラウザでHTMLページをロードしたいが、一部またはすべてのリクエストのホストを新しいホストに書き換えたい場合があります。
リクエストに特定のヘッダーを送信することで、バックエンドの分析からのリクエストをフィルタリングします。
自己署名証明書を持つ本番前のサイトでテストを実行します。

インタラクティブメトリクスの収集 🔗

Interactive metrics are collected by default for each page in the test flow, but this can result in longer run durations depending on how long it takes for the page to become fully interactive. You can turn off interactive metrics in advanced settings to speed up run durations and see results faster. If you turn off interactive metrics then the following metrics might be missing from your test:

最初のCPUアイドル：ページが最低限インタラクティブになり、ユーザー入力に反応するまでの時間。
Time to interactive: This measures the time until the page responds to user input quickly. It is used to identify when the page is actually usable, not just when the page load looks complete.
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.

Auto-retry 🔗

Run a test again automatically if it fails without any user intervention. It’s a best practice to turn on auto-retry to reduce unnecessary failures from temporary interruptions like network issues, timeouts, or intermittent issues on your site. Auto-retry runs do not impact subscription usage, only the completed run result counts towards your subscription usage. Auto-retry requires at least runner version 0.9.29.

TLS/SSL validation 🔗

When activated, this feature is used to enforce the validation of expired, invalid hostname, or untrusted issuer on TLS/SSL certificates.

注釈

When testing pre-production environments that have self-signed or invalid certificates, it’s best to leave TLS/SSL validation feature deactivated.

認証 🔗

Add credentials to authenticate with sites that require additional security protocols, for example from within a corporate network. To use Authentication, a username and password need to be provided. The username can be entered as plain text or be defined by a global variable, but the password must be defined using a global variable. It is recommended to use a concealed global variable for your password to create an additional layer of security for your credentials. For more, see グローバル変数を隠すとどうなりますか？.

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, it is only configured in the browser. At this time, Chrome supports the following authentication protocols:

基本認証
NTLM
Kerberos
ダイジェスト

More details on Chrome authentication are available here list .

Custom headers 🔗

Specify custom headers to send with each request. For example, you can add a header in your request to filter out data from back-end analytics. To add a custom header, a name and value are required. You may optionally provide a domain to scope the header to. If a domain is specified, only requests sent to that domain will include the header. Otherwise the header will be included in requests to all domains.

You can also use headers to change the user agent. The default user agent is the given one for the selected device, which updates whenever the Chrome version changes for synthetic runners. To customize the user agent header for all domains, turn off the 「Use device default」 toggle next to the user agent field and then enter the new value. To change the user agent for specific domains, add a custom header and provide the domain you wish to apply that user agent to. If a domain is not specified, the top-level user agent setting takes precedence.

Custom headers can be used to set cookies, but we recommend using the Cookies settings instead outlined in the section below.

Cookies 🔗

Set cookies in the browser before the test starts. For example, your site may respond to a cookie to circumvent a popup modal from randomly appearing and interfering with your test flow.

To set a cookie, a key and value must be provided. A domain and path may optionally be provided to only apply the cookie to requests to the given domain and/or path. By default, the cookie will aply to the to the domain of the starting URL of the check and all paths on that domain. Splunk Synthetics Monitoring uses the public suffix list to determine the domain.

ホストオーバーライド 🔗

ホストオーバーライドルールを追加して、リクエストをあるホストから別のホストに再ルーティングします。たとえば、開発サイトまたは特定のCDNエッジノードからロードされたページリソースに対して、既存の本番サイトをテストするホストオーバーライドを作成できます。

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). It is activated by default.

待ち時間 🔗

カスタム待ち時間を追加してテストカバレッジを最適化し、より長いページロードをキャプチャして、実行結果の精度を向上させます。ロード時間の長いアプリケーションは、ブラウザテストを失敗させる可能性があります。ワークフローに 10 秒以上かかる特定のステップがあることがわかっている場合は、ブラウザテストにカスタム待ち時間を追加します。

待ち時間はブラウザテストでのみ使用できます。
The maximum custom wait time for each test is 200 seconds.

以下の手順に従って、ブラウザテストのカスタム待機時間を設定してください：

Splunk Synthetic Monitoring で、ブラウザテストの編集を選択し、設定パネルを開きます。
ステップタイプのドロップダウンから新規ステップ > 待機を選択します。
名前と待ち時間（ミリ秒）を追加します。
テストのインストルメンテーションが終了したら、ワークフローを保存します：テストに戻る > 保存.

次の画像は、あるURLにアクセスし、10秒間待ってからログインするようにテストを設定する方法を示しています。

この画像は3つのステップからなるブラウザテストを示しています。URL に移動し、20秒待ってからログインしてください。

Limits and defaults for configurable wait times 🔗

Here are the limits for each type of wait time. The maximum limit for a run is 30 minutes, after which it times out.

説明	Limit
Assert steps	90 seconds
Wait for navigation	20 seconds

説明	デフォルト
Wait time for assert	10 seconds
Wait for navigation	2 seconds

Chrome flags 🔗

Google Chrome flags are a helpful tool for troubleshooting. Activate browser features that are not available by default to test custom browser configurations and specialized use cases, like a proxy server.

For more, see What are Chrome flags? in the Google Chrome Developer guide.

Note: Global variables are incompatible with Chrome flags.

These are the flags available:

Chrome flag	説明
`--disable-http2`	Requests are made using using `http/1.1` instead of `http/2.0`. This HTTP version is viewable in the HAR file.
`--disable-quic`	Deactivates QUIC, which also deactivates HTTP3.
`--disable-web-security`	Deactivate enforcement of same origin policy.
`--unsafely-treat-insecure-origin-as-secure=http://a.test,http://b.test`	Treat given insecure origin as secure. Multiple origins can be supplied in a comma-separated list.
`--proxy-bypass-list=".google.com;foo.com;127.0.0.1:8080"`	Proxy bypass list for any specified proxy for the given semi-colon-separated list of hosts. This flag must be used with `--proxy-server`.
`--proxy-server="foopy:8080"`	Uses a specified proxy server to override default settings.
`--no-proxy-server`	Don’t use a proxy server, always make direct connections. This flag can be used to override any other proxy server flags that you may have set up in a private location.

カスタムプロパティ 🔗

詳細設定のテスト作成ページでカスタムプロパティを追加します。キーと値のペアを使用してカスタムプロパティを作成し、ダッシュボード、チャートをフィルタリングおよびグループ化し、アラートを作成します。テストに関連付けられているタグに基づいて、テストごとにカスタムプロパティの候補リストが表示されます。例: env:test、role:developer、product:rum。複数のキーと値のペアがある場合、ロジックは結果間の AND になります。つまり、この場合、環境テストで開発者ロールを持つ RUM 製品のすべてのテストが結果に表示されます。

カスタムプロパティは単一値であり、region:eu, us のような複数値には対応していません。各テストで使用できるキーは一意です。例えば、env1:test と env:test を同じテスト内に持つことはできますが、env:test と env:prod を持つことはできません。

主な要件：

キーは大文字または小文字で始めなければなりません。特殊文字や数字でキーを始めることはできません。

キーの残りの部分には、文字、数字、アンダースコア、ハイフンを含めることができます。

キーに test_id や test という名前を付けることはできません。

キーサイズは128文字以内です。

カスタムプロパティを参照してください。

例 🔗

例については、シナリオ：ブラウザテストを使用するマルチステップワークフローを監視するを参照してください。

This page was last updated on 2024年11月13日.

Related Topics

ブラウザテストをセットアップする 🔗

ブラウザテストをセットアップする 🔗

テストの詳細をカスタマイズする 🔗

こちらも参照してください 🔗

Google Chrome Recorderから生成されたJSONファイルをインポートする 🔗

Google ChromeレコーダーJSONファイルを作成する 🔗

Google Chrome RecorderのJSONファイルをインポートする 🔗

サポートされていないステップをトラブルシューティングする 🔗

ブラウザテストを表示する 🔗

ブラウザテストを編集する 🔗

ブラウザテストの詳細設定 🔗

インタラクティブメトリクスの収集 🔗

Auto-retry 🔗

TLS/SSL validation 🔗

認証 🔗

Custom headers 🔗

Cookies 🔗

ホストオーバーライド 🔗

待ち時間 🔗

Limits and defaults for configurable wait times 🔗

Chrome flags 🔗

カスタムプロパティ 🔗

例 🔗

Was this topic useful?

Splunk

Related Topics