我听说,使用Selenium时,CSS Locator的性能优于XPath Locator。

您在测试中使用哪个定位器?

使用CSS定位器时,您是否看到了很大的性能提升?

是否有时需要使用XPath而不是相应的CSS Locator?

#1 楼

不要忘记,不仅CSS定位器的性能更好,而且兼容性也很重要。

我们正在使用IE,SAFARI,FIREFOX,CHROME的多浏览器环境进行测试。

在IE上,XPath几乎无法工作,或者它是如此缓慢以至于无法管理。因此,我们会尽可能使用CSS。不幸的是,IE不支持许多CSS逻辑,如上一项,下一项,计数器等。但这可以安排...

您必须告诉您的开发人员为您正在使用的每个元素提供独特的ID。它将大大提高您的性能,因为您不需要太多的XPath魔术来达到元素。在其他浏览器上,我并没有发现任何区别。

评论


“ IE不支持许多CSS逻辑,例如上一项,下一项,计数器等。但是可以安排...”您如何安排?

–塔伦
2011年5月6日8:44



是的,很抱歉..下一行继续进行。你必须告诉你...等等,等等。但是,如果需要关键部分,您仍然可以使用XPATH,只需将其最小化即可。 :)

–汉尼拔
2011年5月6日晚上10:37

说CSS是答案的上半部分中最好的定位器策略,然后说要使其正常工作,您需要让开发人员修改第二部分中的源代码,这肯定表明CSS并不是全部案件。尽管在IE上运行缓慢,但XPath不需要开发人员进行修改即可允许您查找元素,因此实际上您可以说XPath作为定位策略更好,除非您主要进行IE测试。恕我直言,这不是一个很好的答案。

– Ardesco
2011年7月1日在14:03

我同意XPATH在IE上不是很好。但是我不要求开发人员添加一些独特的ID来争论。您如何使用xpath?您是否通过元素在DOM中的位置找到元素(带有xpath)?我将竭尽所能获取唯一的ID。

– yoosiba
2011年7月7日14:12

#2 楼

好吧,实际上我正在使用xpath。最好的方法是为要引用的元素添加一个静态(当然是唯一的)id。

评论


同意,但是大多数时候,您获得的应用程序没有这样的测试钩子,您需要使脚本工作并查找缺陷

–塔伦
2011年5月6日晚上8:57

我知道。我们有一个生成动态ID的应用程序。我为Firefox下的firebug和firefinder使用了不同的插件。另一个技巧是使用样式类名称,该名称对于要查找的元素是唯一的。

–Luixv
2011年5月6日在9:05

甚至样式类有时也会重复

–塔伦
2011年5月6日9:10



@Luixv我认为您是指样式ID,而不是样式类名称(出于唯一性)。实际上,我可以同时使用这两种方法(组合使用)来标识给定的元素。有时可以将多个类的类名一起使用以唯一地标识元素,例如table#primary / tr.header / td.cost

–迈克尔·杜兰特(Michael Durrant)
16-3-20在10:57



#3 楼

您只能在XPATH中执行的操作的一个示例是转到当前节点的父节点。因此,尽管我建议您尽可能使用CSS,但有时XPATH是唯一的方法。

编辑:
实际上,我放屁了。以下站点有两个非常有用的图表,它们比较了CSS和XPATH定位器(如果存在)以及DOM定位器(用于很好的测量),所有这些都特别注意了Selenium: /dotnet/.net-framework/xpath,-css,-dom-and-selenium-the-rosetta-stone/

非常有用的东西。

#4 楼

以我的经验,xpath可能非常不稳定,因为它依赖于UI的当前结构进行导航。更改页面结构和飞快移动,然后进行测试。

因此,我更喜欢css选择器的稳定性。

评论


我不同意,CSS定位器还取决于用于导航的UI的当前结构。如果UI更改,CSS定位器也应该损坏。

–塔伦
2011年5月6日10:13



我完全同意@CBA的观点。我们最初对所有选择器都使用了xpath,很快就发现,使用class_name或id是编写测试的唯一方法,因为无需对html进行任何小改动就可以将其固定

–杰森·沃德(Jason Ward)
2011年5月6日14:26

如果UI更改,则xpath和css具有几乎相同的中断概率。两者都取决于UI的当前结构。如果可以很好地标识UI元素,即可以使用一个或多个属性来唯一标识UI元素,则可以非常可靠的方式创建xpath和css。如果不是从根目录创建它们中的任何一个,则它们都可以在UI更改后幸免。

– Suchit Parikh
2011年5月6日17:04

@Jason我建议您使用构造较差的XPath,然后,格式良好的Selenium XPath不会比CSS定位器脆弱。

– Ardesco
2011年5月18日,12:50

我认为在此问题的两种独立解释之间存在混淆:1)通过哪种方式标识元素(标识,类或DOM路径)和2)使用哪种语言(和定位器引擎),XPath或CSS

– reinierpost
2012-09-19 14:57

#5 楼

我曾经使用过css和xpath定位器。

通常,首选的第一个工具是css。语法更紧凑,所有浏览器都有基本功能,有些则有高级功能。使用浏览器功能(例如,单击鼠标右键)或提供用于复制的xpath(包括整个页面结构)的工具的趋势也越来越少,该页面结构会随着时间而变化。具体来说,使用css往往会导致选择器,例如span[name='cars']而不是//body//div/spn/span/table/tr/tr/tr/td/td/td/td/span[@name='cars']。对于特殊情况,我的第二个选择是xpath。一旦我需要找到一个元素然后``备份''几个相同级别的元素,并且xpath似乎是绕过DOM的唯一方法,即相对寻址。但是,选择器倾向于具有更多的字符,从而使意图更难以阅读。

除语法外,这两种方法都面临着类似的挑战,即以确保唯一性但不会通过将代码硬编码到当前页面而使测试变得脆弱和容易破坏的最佳方式来标识元素布局。

类似地,元素ID对于以简单且唯一(正确编程的)识别元素的方式非常有用。这需要与开发人员进行协调,然后可以由css和xpath选择器利用。 -css仅显示很小的改进,而如果忽略Opera,则基本上没有改善。

css还支持通配符,例如


“以类开头” class^=

“以id结尾”-id$=
“名称包含文字-name*=



#6 楼

但是,当CSS和ID唯一时,上面的两种方法不能帮助解决查找唯一节点的问题,那么不要害羞地使用'relative xpath'


使用相对xpath与感兴趣的html部分中的标记
使用xpath的通配符功能,始终wrt标记
使用xpath引擎提供的功能,例如包含文本..
短。提示:相对xpath可能包含


标记+通配符
标记+通配符的相对路径+通配符



参考文献:
http://www.simple-talk.com/dotnet/.net-framework/xpath,-css,-dom-and-selenium-the-rosetta-stone/

更多提示:
如果使用了相对xpath,并且如果相对xpath是可读的,那么应该这样做,因为我们使用xpath在whtml上找到了标记,因此,浏览器足以解决它们,在2016年。

当然,可能存在一些性能问题,但没有办法,当前的xpath引擎在任何浏览器中都将失败

其他信息:
相对xpath与在命令控制台或bash上相对于当前文件夹导航文件夹一样简单或相似。

不当实践:
询问开发人员提供额外的ID或不同的CSS(仅用于测试)可能看起来更简单,但会污染前端组件使用仅用于质量检查的标记多数民众赞成在基础上。从长远来看,这不是正确的方法

应用程序计数的可测试性,但是请确保已探究了所有选项

CSS和ID可能无用的情况:
当使用javascript包(例如extjs示例)时,在这种情况下生成的html,基于CSS选择唯一元素可能会导致多个节点(从10到100)。此外,ID会根据extjs更新和浏览器进行更改(奇怪的情况,但为true)

@michael durrant:提供了一个很好且非常简单的案例:css更好或等同于xpath以及涉及“可读性”问题。当然,不应使用“绝对xpath”,因为它会变长。在上面我一直只坚持“相对” xpath