Skip to main content
Splunk Lantern の記事が日本語で利用できるようになりました。.
Splunk Lantern

Selectors for multi-step browser tests


In CSS, selectors are patterns of elements and other terms that tell the browser which HTML elements should be selected to have the CSS property values inside a rule applied to them. When creating a browser test, it's important to choose selectors to test that are both specific enough to target the correct elements and robust enough to survive minor release changes. You aren't sure which ones you should use.

You can find all elements matching your selector by using the console. Learn more about using the console with the Console Utilities API reference and Learn HTML.


This article provides selector examples that you can add when creating the test from scratch in the Splunk Synthetic Monitoring GUI.

Splunk Synthetic Monitoring supports the import of JSON via API or through the GUI for Browser Tests. Use the built-in Chrome Recorder to create a test in an incognito browser window, re-run the test to validate it, and import into Splunk Synthetic Monitoring. Keep in mind that better selectors might be needed beyond what the recorder captures. See a demo here.

Inspecting the DOM to identify elements

In Chrome, on your webpage, right-click the object you're interested in and click Inspect. This opens the dev tools so you can see the markup.

Reading and choosing element selectors

  • As you read the markup you can begin to see the patterns to look for. In general, the pattern in HTML is: <element attribute="attributeValue">;content</element>
  • Some element identifiers are more reliable than others. Page elements can change with site redesigns, and even between user sessions. For example, if a page is rendered with React, you often see attribute values contain random strings that change with each page refresh. This means you need to be intentional with the selectors you pick so your tests are easier to maintain.
  • Avoid using vague elements like <div>.
  • Keep in mind that styles, architecture, and text can change between site releases, which will break your tests. For example, if you right-click an object and copy a selector that looks like /html/body/div/div[2]/div[3]/div/div/button[2], this is brittle and will break with any change to the page structure. Instead inspect the element, find something unique about it, and write an intentional selector using the syntax below.
  • Aria labels, ids, and data attributes are great to use, as they are designed to be unique and specific. It will take some practice inspecting the DOM and testing selectors within the Splunk Synthetic Monitoring GUI.
  • Remember that multiple elements can have the same attributes (for example, CSS class) so the test picks only the first element it encounters on the page that fulfills that criterion. You can find all elements matching your selector by using the console.
  • Scroll up the element tree to check if your target element is inside an iframe. If so, add a step to switch to iframe before interacting with the element. If you need to interact with elements outside of the iframe later, add switch to main to exit the iframe.

Selector examples

You can target the element, its attribute, and the value of that attribute, and sometimes the content within the element itself. You do this via css, xpath, id, JS path, and even javascript. When in doubt, use Google to find more help.

  • The id attribute should have no duplicate values per web page, in which case it's an ideal unique selector. Unfortunately that is not always the case, and not all elements require an id attribute. If your element has this attribute, and the value is static, this is a great choice.
  • Use a css selector where the element has a reliable, unique identifier, for example, a sign in button or major call to action. The format is element[attribute="attributeValue"]. For more information on this syntax, refer to the Mozilla docs about css attribute selectors. Examples: 
    • If your HTML element looks something like <button aria-label="Sign in" class="buttonPrimary">Access my account</button> the class could apply to any number of buttons on the page, and the button text could change at any time or with any A/B testing on that element. button[aria-label="Sign in"] is the most likely selector to reliably identify this element in your synthetic test if you know that this element will most likely remain a button and that the aria-label will remain static and unique.
    • If your HTML element looks something like <a href="" data-testid="header_CTA-text">Get this deal!</a> that's great, because data-testid is a reliable and unique attribute. A good selector for your Synthetics test could be: a[data-testid="header_CTA-text"]
  • The following examples use an xpath selector where the element has an attribute containing both static and dynamic values. Xpath can also be used similarly to css above, where the values are static. Learn more about XPath.
    • The format is generally //element[rule(attribute,'attributeValue')]
    • //input[starts-with(@id,'checkInDate')]
      Looks for the input element with an id starting with the string 'checkInDate'
      • For example, sometimes the attribute values will be appended with a character string that changes for each user session. So using "starts with" ensures that you target that element regardless of if it becomes checkInDate-3489, checkInDate-2467, etc.
    • //*[text()[contains(.,'Registration')]]
      Looks for any element containing the text string 'Registration'
      • This one is often too vague but can work on some sites.
      • This is case-sensitive.
    • xpath can also be used with static elements, targeting one or more attributes:  In this example there could be multiple buttons on the same page, but only one with both of these attribute values: //button[@aria-label='Sign in' and @data-link='alpha']
  • Use javascript where the element attribute contains a reliable string for a critical function, such as login or testout, or where using another type of selector is unreliable.
    • document.querySelector('a[href*="account/login?checkout"]').click();
      Looks for the anchor element with an href containing the string 'account/login?checkout'
  • Use conditional javascript where the element should be clicked if it appears, for example, with popups, which might be inconsistent.
    • if(document.querySelector('button[data-click="close"]')){document.querySelector('button[data-click="close"]').click();}
    • if(document.querySelector('[id^="close-button"]')){document.querySelector('[id^="close-button"]').click();}
      • Where the attribute value is expected to always contain "close-button" but might have some other string appended/ prepended
  • Sometimes elements are nested in what's known as the "shadow dom". This is common when developing at scale, so that you can have a reusable element tree that is protected from being affected by other js/css in whichever page it's used. See the Mozilla docs and this YouTube tutorial for more details.
    • If you inspect your code, and right click on the element to copy its JS Path, you might get something like document.querySelector("body > app-root > div > section > app-login").shadowRoot.querySelector("main > section > card > card-content > a.login-anchor"). A more robust selector for this element is document.querySelector("app-login").shadowRoot.querySelector("a.login-anchor") which does not rely on the nested elements to work.

Next steps

You might be interested in these additional processes related to running Splunk Synthetic Monitoring browser tests:

Splunk OnDemand Services: Use these credit-based services for direct access to Splunk technical consultants with a variety of technical services from a pre-defined catalog. Most customers have OnDemand Services per their license support plan. Engage the ODS team at if you require assistance.