硒的cssSelector vs XPath [英] cssSelector vs XPath for selenium

查看:103
本文介绍了硒的cssSelector vs XPath的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

据我了解,CSS选择器遍历DOM.因为CSS文件将没有有关元素位置的任何信息,所以为什么 cssSelector XPath 更快(理论上).

As per my understanding, CSS selector traverses through the DOM. Because CSS files will not have any info about element position then why cssSelector is faster then XPath (theoretically).

理论上 cssSelector 花费的时间少于 XPath ,因为 XPath 需要遍历HTML DOM. XPath 我们可以在DOM层次结构中向后或向前搜索元素,而 CSS 仅在向前的方向上工作.

Theoretically cssSelector taking less time then XPath as XPath need to traverse through HTML DOM. XPath we can search elements backward or forward in the DOM hierarchy while CSS works only in a forward direction.

但是,如果 cssSelector 也遍历HTML DOM,那么它将如何使 cssSelector 更快.

But if cssSelector also traverse through HTML DOM then how it make cssSelector faster.

换句话说, cssSelector 在内部的实际工作方式以及为什么它总是被/然后被 xpath

In other words how cssSelector actually works internally and reason why it always preferable/recommended to use by everyone then xpath

另外,请分享与 XPath 相比,使用 cssSelector 的其他好处.

Also please share other benefit of using cssSelector over XPath.

反之亦然,在该区域中 XPath cssSelector

And vice versa in which area XPath are better then cssSelector

推荐答案

我已经阅读了很多文章,并且看到了类似为我链接了一个演示文稿(请参阅第18-23页)他在其中更新了测试,并且CSS选择器仍然更快,但是XPath在一些配置上赶上了.

I've read a lot of articles and I've seen some like this and this that have data that show that CSS selectors are faster and I've done a little testing and have come to the same conclusion. I talked to Dave Haeffner, author of elementalselenium.com, in Dec 2016 and asked him about the perf numbers on his site (in the post I linked above) since they were pretty old. He linked me a presentation (see pp18-23) where he updated the tests and CSS selectors are still faster but XPath is catching up in a few configs.

所以我们可以看到证据是真的,但是我从未见过有人谈论为什么的技术细节.如果我猜到了,那是因为为了优化页面渲染的速度,已经在不同的浏览器中进行了大量工作.使CSS选择器快速工作可以使页面渲染更快,并且由于浏览器驱动程序利用了浏览器定位元素的能力,因此CSS选择器通常会获胜.我已经读到一些浏览器已经提高了XPath定位器的速度,但是我认为它可能总是落后于CSS选择器,因为它比CSS选择器要少得多.

So we can see evidence that it's true but I've never seen anyone talk about the technical details of why. If I were to guess, it would be because a lot of work has gone into the different browsers to optimize the speed of page rendering. Having CSS selectors work quickly makes the page render faster and since the browser drivers take advantage of the browser's ability to locate elements, that means CSS selectors generally win. I've read that some browsers have improved their XPath locator speed but I think it will likely always lag behind CSS selectors because it's just much less common than CSS selectors.

CSS选择器和XPath都必须遍历DOM,因此除了进行遍历的引擎速度之外,没有其他实际区别.由于CSS选择器的广泛使用,与XPath引擎相比,目前CSS选择器引擎可能是一种微调的机器.

Both CSS selectors and XPath have to traverse through the DOM so there's no real difference there other than the speed of the engine that does the traversing. The CSS selector engine is likely a fine tuned machine by this point vs the XPath engine because of the wide spread use of CSS selectors.

我的一般定位器策略是首先使用ID,其他所有内容都使用CSS选择器.如果没有其他效果,我将使用XPath.每个站点的位置不同,但以我的经验来看,ID可能占我定位器的10%左右. CSS选择器大概是80%,最后10%是XPath.我通常在需要通过包含的文本(很少有DOM遍历)定位元素时使用XPath.我使用XPath的一个示例可能是我需要在TABLE中相对于行标签找到一个元素,例如表格行中奶酪的价格,其中第一个单元格包含奶酪",第三个单元格包含价格.

My general locator strategy is ID first, CSS selector for everything else. When nothing else works I use XPath. It will vary from site to site but in my experience, IDs are maybe ~10% of my locators. CSS selectors are probably ~80% and the last 10% is XPath. I generally use XPath for when I need to locate an element by the contained text and very rarely DOM traversal. An example of my XPath usage might be I need to find an element in a TABLE relative to a row label, e.g. the price of cheese in a table row where the first cell contains "cheese" and the third cell contains the price.

我认为XPath易于访问,因此在SO之类的网站和许多博客上都可以看到它.我要做的就是右键单击devtools中的一个元素,然后复制XPath.问题很多时候会生成不良的,脆弱的XPath.手工制作的XPath更好,但是手工制作好的XPath或CSS选择器需要时间和经验.很多人都不愿投入的时间.设计不当的CSS选择器或XPath也会使事情变慢.很多时候,可以使用多种方式定位元素,有些方式比其他方式更高效...这取决于定位器的效率以及如何使用它.格式错误的CSS选择器不会自动比格式良好的XPath快.

I think XPath is seen a lot on sites like SO and many blogs because of its easy access. All I have to do is right-click an element in the devtools and Copy XPath. The problem is many times that generates a bad, brittle XPath. A handcrafted XPath is better but it takes time and experience to handcraft a good XPath or CSS selector. Time that many aren't willing to put in. A badly crafted CSS selector or XPath will make things slower also. Many times there are any number of ways that an element could be located, some are way more efficient than others... it comes down to the efficiency of the locator and how you use it. A badly formed CSS selector isn't automatically going to be faster than a well formed XPath,.

这篇关于硒的cssSelector vs XPath的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆