How to locate an element on the page
Try our free SeleniumIDE replacement
There’s a good chance you arrived here because you encountered an Element Not Found error when replaying a real-browser testcase. If so, you are at the right place!
Locating the correct element to interact with is the biggest challenge when developing real-browser testcases with Load Tester. Mastering element location makes everything else easy, so read on!
What is an Element?
Everything you see on the page is an element. Every field, link, image, text and many things you don’t see are all elements. An element is equivalent to a tag in HTML, though there can be elements on a page that did not come from the HTML source. To study elements in more detail, read here.
What is an Element Locator?
An element locator, usually referred to as simply a locator, is a method for finding an element on a page. There are many different types of locators. Deciding which one to use depends on a lot of different factors and there is no correct answer other than the one that works for you. In many cases, several different locators could all be used to accomplish the same task. See step 3 (below) for some starting advice.
How does each step get a locator?
There are two ways:
- Any step that was recorded in the browser will have a locator created by the recorder
- You can configure locators manually in the UI for any step. This is required for manually-created steps.
Debugging during a Replay
The most productive way to diagnose a locator failure (and configure a better locator) is during a replay – when you have both the browser and the testcase paused (typically at the point of failure). This article will proceed under that scenario and show how to find an alternate locator.
Below is an example of what Load Tester shows when a locator fails:
Step 1: Why did the locator fail?
Before you can configure a better locator, it is important to first understand why the locator failed. In some cases, the problem might not even be with the locator…so changing the locator would not help.
Here are some of the common causes. Follow the links for help deciding if that case applies and what to do about it.
- Element attributes changed in a way that invalidated the locator strategy
- Element does not exist (yet)
- Element not visible/click-able
- Testcase proceeding too fast
- Element is in an IFrame
In the example screenshot above, the step used an Element ID locator. But it appears that the ID changes each time the page is presented in this application, so the solution is to use a different locator type (this is the Element attributes changed cause, in the above list).
Step 2: Find and inspect the element
We need to know what we are working with – so the next step is always to look at the element in the page to see what other properties it has that we can use to identify it. The browser (or a plugin) will help you do that – we have some notes to help you get started here.
Here is what we find for the example above:
This shows that the id of the element (a password field) has changed since the locator was configured – so the Element ID locator could not find it.
Step 3: Choose a new locator
After inspecting the element and the surrounding elements, this example provides several ways we could try to locate this element.
The ID attribute: The password field has an ID attribute (id=”user_pass”), which would normally be the first choice. But since we already determined that the ID changes for each iteration, we know this won’t work in this case.
The name attribute: This element is an input element in a form and has a name attribute (name=”pwd”). A field name is generally a good second choice, after the element id. Try a field name locator using the name “pwd”.
The class attribute: The element has a CSS class (attribute). If this is the first (or only) element on the page using that class, then the element can be located CSS Class locator with class “input”.
XPath: An XPath is always available for an element – in fact there are usually numerous valid XPaths for an element. XPath is a powerful and flexible feature – if you are new to XPath, take a look at the XPath resources linked on our Types of Element Locators page as well as our XPath Examples page. As described on the How to Inspect an Element page, we know the browser can supply an XPath. However, since this element has an ID, the browser will generate an XPath based on the ID – which we already know we can’t use in this case. We can see that the parent form also has an ID – if that ID does not change, then an XPath from that element to the password field should work. You can write an XPath from scratch for this, or you can trick the browser into doing it for you by deleting the ID attribute from the password field and then asking the browser for the XPath to the element again.This results in an XPath that starts at the form (by using the form’s Element ID) and then follows a path down the DOM to the password field:
//*[@id="loginform"]/p[2]/label/input
This XPath still uses an ID, but the ID of the form rather than the password field. If the ID of the form also changes with each page view, then this won’t work either and a different type of located should be considered.
If you deleted the ID attribute from the field as described above – don’t forget to undo the change you made to the page (CTRL-Z). The application may not work correctly without the ID attribute on the password field.
CSS Selector: Many elements can be easily selected using CSS Selectors. In the example above, the element has a CSS class of input and is likely the only input field on the page with attribute type=’password’, so this CSS Selector could work:
[type='password'].input
CSS Selectors are a powerful and flexible feature – a full description is out of scope for this document. See the resources listed for CSS Selectors on our Types of Element Locators page for more about CSS Selectors.
Link Text: Links can be located by matching the link text to the provided parameter.
Text: Commonly-used elements that have a visible label or text can frequently be located using this simple locator.
Step 4: Test the Locator
After choosing a locator, the next step is to try it. You can edit the locator in the step editor at the top of the browser testcase editor (after selecting the step), as shown below. However, if you are not confident that the new locator is correct, then continue reading for some productivity tips.
If you try a locator by editing the step as shown above and it fails to find any element, then you can simply try again. However, if it finds the wrong element and proceeds to click it (if it was a click step), you may not be able to simply try again. If you can press the back button to get back to the same state, then you can try again, otherwise, you might have to stop the replay, restart it from the beginning and allow it to proceed back to the failed locator.
Step 5: Don’t panic!
If you are unable to get a locator working for your testcase, there are several resources available to you. Because Load Tester is built on Selenium/WebDriver, a popular open-source browser control framework, there is lots of advice out there already:
- StackOverflow – search for combinations of “selenium” and/or “webdriver” with something related to your element, like “xpath” or “find link”.
- The WebDriver group – they won’t be able to answer questions about Load Tester-specific difficulties, but reading/searching that group will provide lots of examples of how to locate elements, as it is one of the more common questions.
- Your favorite search engine: search for something like “selenium webdriver how to locate element using XXX”
- If you are in Load Tester’s evaluation period or have a support contract, you can ask us for help by choosing Support Request from the Help menu in Load Tester. Don’t forget to attach your testcase!