用于硒的 cssSelector 与 XPath [英] cssSelector vs XPath for selenium

问题描述

据我了解，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

还请分享使用 cssSelector 而不是 XPath 的其他好处.

Also please share other benefit of using cssSelector over XPath.

反之亦然，在哪个领域 XPath 比 cssSelector 更好

And vice versa in which area XPath are better then cssSelector

推荐答案

我看了很多文章，也看到了一些像 this 和 this 有数据表明 CSS 选择器更快，我做了一些测试并得出了相同的结论.2016 年 12 月，我与 elementalselenium.com 的作者 Dave Haeffner 进行了交谈，并询问了他网站上的性能数字(在我上面链接的帖子中)，因为它们已经很老了.他为我链接了一个演示文稿(参见 pp18-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 选择器的广泛使用，CSS 选择器引擎与 XPath 引擎相比可能是一款经过微调的机器.

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 与 XPath的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！