Skip to main content


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 right elements and robust enough to withstand 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 describes some common selectors that you can add when creating the test from scratch in the Splunk Synthetic Monitoring GUI.

In Chrome, right-click the element you are targeting and click Inspect. This opens the dev tools so you can see the markup.

Understanding basic HTML is helpful, but as you read the markup, you can begin to see the patterns to look for. In general, the pattern is: <element attribute="attributeValue">some content</element>

Best practices

  • Avoid using vague elements like <div>.
  • Page elements can change with site redesigns, and even between user sessions. Often seeing a random character string in the attribute value is a clue that it will change between user sessions. You can validate this by opening a new session in an uncached or incognito browser window and inspecting the code.
  • Styles, architecture, and text can change between site releases. These changes will break your tests. Therefore, it can be valuable to run synthetic tests in your pre-PROD environments to catch those changes before they flag as failures in your PROD tests post-release.
  • Aria labels and data attributes are great to target, as they are designed to be intentionally specific. It will take some practice inspecting the document object model (DOM) and testing selectors within the Synthetics GUI.
  • Remember that multiple elements can have the same attributes, for example css class - so the test will pick only the first element it encounters on the page that fulfills that criterion.


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.

  • 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.
  • css where the element has a reliable, unique identifier, for example, a sign in button or major call to action (CTA). The format is element[attribute="attributeValue"]. For more information on this syntax, please refer to the Mozilla docs about css attribute selectors.
    • button[aria-label="Sign in"]
    • a[data-testid="homepage-sidekick_header_CTA-text"]
  • xpath where the element has an attribute containing both static and dynamic values.
    • The format is generally //element[rule(attribute,'attributeValue')]
      Looks for the input element with an id starting with the string 'checkInDate'
    • //input[starts-with(@id,'testInDate')]
      • 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 testInDate-3489, testInDate-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, for example, //button[@aria-label='Sign in']
  • 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?testout"]').click();
      Looks for the anchor element with an href containing the string 'account/login?checkout'
  • 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

Next steps

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

Still need help with this use case? Most customers have OnDemand Services per their license support plan. Engage the ODS team at if you require assistance.