During automated testing with Selenium, it is a common task to select elements on a page and perform various operations on them. Selenium provides a variety of positioning methods:
- Id: the most efficient and convenient method
- Name: similar to id
- Class name: A good way to catch all elements that have the same class
- Link text and partial link text: Used to locate hyperlinks
- Tag name: similar to class name
- CSS Selector: If you’ve tried jQuery, this is your favorite method
- Xpath:… /html/body/div/div[2]/div[2]/div[2]/div[5]/div/p[2]
Many Selenium articles on the web, when describing how to use XPath to locate elements, often say something like, “Open the Firefox browser, install the Firebug plugin, and get an XPath for that element.” I really thought for a while that all of this didn’t make any sense because I didn’t understand it very well, that there were all these array operations in between, that the so-called XPath that sounded anti-human and anti-social was the real XPath, and that you guys were being misled.
What is XPath:www.w3.org/TR/xpath/ XPath basic tutorial: www.w3schools.com/xpath/defau…
XPath has several disadvantages in Selenium testing: 1. Poor performance. The performance of locating elements is worse than most other methods. 2. Not robust, XPath changes as the layout of page elements changes; 3. Compatibility is not good. XPath is implemented differently in different browsers. So many weaknesses, why does it still exist in Selenium? Selenium provides these seven element positioning tools, like a toolbox of hammers, vice and screwmen, each of which can accomplish a specific task, provided it is used correctly and in the right context.
XPath typically works in the following scenarios: A guy writing automated tests found that the elements he wanted to operate on could not be located by id, name, link text and other convenient and effective methods. Frustrated that he could not convince the developer of the page to add the id he wanted, he began to locate the elements using what is called XPath. The code is full of all sorts of confusing XPaths (/ HTML /body/div/div[3]/div[2]/div[4]/p[2]), and it looks to me like a recorded script. Poor readability and almost impossible to maintain. XPath can be used this way in theory, but should be avoided in practice.
Some of the advantages of XPath are things you need to know, for example: 1. XPath can find its ancestor using an element (rooted); /button[@value= ‘submit’ or @name= ‘tijiao’]
Going back to the above scenario, let’s say the frustrated person wants to locate a submit button on the page that can’t be located by ID or name. All he needs to do at this point is not open the Firebug location submit button, right click and click “Copy XPath.” Instead, ask the developer to add id or name. 1. Find the features of the button, for example, the text of the button is Submit. //button[@value= ‘submit’] I’m personally averse to using XPath, so use id or name if possible. If you really want to use XPath, never, ever open Firebug locate submit and right click “Copy XPath.” Learn XPath carefully first, then use it. For a long time, I really hated XPath and wanted to kill it first, but it makes sense to think that it exists and that so many people have not written it off as Selenium. XPath must have its value. Recently, I spent some time learning about XPath and reading some articles on how to use XPath properly in Selenium.
Reference article:
- www.theautomatedtester.co.uk/tutorials/s…
- Wiki.openqa.org/display/SEL…
- Stackoverflow.com/questions/5…
- Community. Neustar. Biz/community/w…
- Automationtricks.blogspot.com/2010/09/how…