被误读的xpath

Selenium中被误用的XPath

用Selenium实现自动化测试的过程中,如果选择页面上的元素并且对之进行各种操作,是一个常见的任务。Selenium提供了多种定位方法:

  • id:最有效、最方便的方法
  • name:跟id类似的
  • class name:对某些具有相同类的元素一网打尽的好方法
  • link text 和 partial link text: 用在定位超链接上比较多
  • tag name:与class name有点类似
  • css selector:如果你试用jQuery,这个一定是你喜欢的方法
  • xpath:。。。 /html/body/div/div[2]/div[2]/div[2]/div[5]/div/p[2]

网上很多Selenium的介绍文章,在讲述如何利用XPath定位元素的时候,通常都是这样子说的“打开Firefox浏览器,安装Firebug插件,然后就能方便地获得该元素的XPath了”。由于不求甚解,在一段时间内我真以为这些看起来没什么意义,中间穿插着各种数组操作,读起来反人类反社会的所谓XPath就是真的XPath,同志们大家都被误导了。

什么是XPath:http://www.w3.org/TR/xpath/
XPath基础教程:http://www.w3schools.com/xpath/default.asp

XPath在Selenium测试中有好些缺点:1. 性能差,定位元素的性能比起大多数其他方法要差;2. 不够健壮,XPath会随着页面元素布局的改变而改变;3. 兼容性不好,在不同的浏览器下对XPath的实现是不一样的。如此多的弱点,为什么它还存在于Selenium中呢?Selenium提供了这7个元素定位的工具,就好像工具箱里面有锤子有老虎钳有螺丝刀,每个工具都能完成特定的任务,前提是要在正确的前提下,正确地使用。

XPath通常会在如下场景:一个写自动化测试的人,发现他想要操作的元素不能通过id, name, link text等比较方便有效的方法来进行定位,苦逼的他没能说服开发这个页面的人把他想要的id加上,他开始用所谓的XPath来定位元素,代码中充满了各种让人摸不着头脑的XPath(/html/body/div/div[3]/div[2]/div[4]/p[2]),在我看来这样的代码跟录制出来的脚本没有任何区别。可读性差,几乎不能维护。XPath理论上可以这样使用,但是实际上应该避免这样的使用。

XPath的一些优点是大家需要知道的,例如:1. XPath可以通过某个元素找到它的祖先(Ancestors);2. 可以做布尔逻辑判断,例如/button[@value=’submit’ or @name=’tijiao’]

回到上面的场景,假如说那个苦逼的人想定位到页面上的一个提交按钮,这个按钮不能通过id或者name来定位。这个时候他要做的事情不是打开Firebug定位提交按钮右击鼠标再点“Copy XPath”。而是应该是找开发把id或者name加上。如果不行,解决思路可以是:1. 找到该按钮的特征,例如按钮的文字是 submit;2. 用XPath定位,可以这样写://button[@value=’submit’]。

我个人对使用XPath比较反感的,如果可能的话,尽可能使用id或者name。真的要用XPath,千万千万不要打开Firebug定位提交按钮右击鼠标再点“Copy XPath”。先认真学习XPath,后使用。在很长一段时间里面,我对XPath真的是恨之入骨,恨不得先杀之而后快,但是想到存在就是合理,那么多大牛们都没有把XPath摒弃与Selenium之外,XPath必然有它的价值。最近花了点时间学习了一下XPath,并且读了一些关于如何在Selenium里面正确使用XPath的文章,豁然开朗。

参考文章:

Related posts:

  1. WebDriver + TestNG 应用
  2. SST (selenium-simple-test) 介绍
  3. WebDriver测试失败后自动获取截图
  4. Hudson + WebDriver 组织自动化测试
时间: 2024-10-13 22:34:41

被误读的xpath的相关文章

雷军:风口论一直被误读 我不是机会主义者

新浪科技讯 4月23日上午消息,2016中国绿公司年会在山东济南举行.雷军在现场做了以“小米的明天:新国货运动”为主题的演讲. 雷军认为,国货不被信任的真正问题出在效率上.国货流通效率太低导致商品价格过高,为了降低商品价格只能降低生产成本,粗制滥造,而且用户体验不好. 为了提高商品流通效率,雷军选择做了小米网,以很低的价格直接卖到用户手上,在看准这个之后,才决定以智能手机作为突破口,也就是说,先有了“新国货运动”,再有了“为发烧而生”的MUI和小米手机. 在演讲中,雷军认为,小米的未来还是要踏踏

杂物论第二 我们一直在误读鲁迅

  杂物论第二 我们一直在误读鲁迅 原文见下面.这里摘引一段: "曾几何时,我们人生中关键的一根筋错乱了,将本是文学家的鲁迅前面硬加上革命家.思想家两大头衔,甚至还有政治家的嫌疑.殊不知,文学见政治就死,搞得鲁迅不会旁的,就会拿'匕首和投枪'扎人,成了'文学屠夫'了,其实不." 第一,  鲁迅所遭受的十年围剿是不可抹杀的,而且鲁迅至死对此一个也不宽恕.这种围剿,至今也没有停止过,尽管打着五颜六色的各种旗号.有些人们不断地给他封着各种各样的"封号",不断地往他的脸上涂

《谷歌宣布Chrome不再信任所有赛门铁克SSL证书》误读新闻的澄清说明

7月31日下午,各大媒体平台以及论坛发布的<Google宣布Chrome不再信任赛门铁克所有SSL证书>的新闻存在标题误读.夸大事实.不符合实际的情况. 关于新闻中的错误主要说明以下几点: 1.首先,赛门铁克的所有SSL证书都可以正常使用.之所以有这样的报道出现是因为:赛门铁克SSL证书签发的PKI系统要进行安全升级,谷歌为了督促赛门铁克此次更新,计划在2018年10月23号Chrome版本发布后,不信任赛门铁克未更新的PKI系统签发的证书,而非不信任赛门铁克所有的SSL证书,这是一个严重的误

对代理ARP技术的误读、无法完成代理ARP实验的故障分析

对代理ARP技术的误读.无法完成代理ARP实验的故障分析 问题的提出:     网络工程技术人员和或者学习者面对ARP代理技术时,通常能理解ARP代理的作用和技术要点是什么,但是无法根据技术描述去实现ARP代理的功能!   首先来看一般对代理ARP的定义: 通常根据上述文字的描述,就意味着在如图1所示的环境中,主机192.168.2.2/24可以在不配置默认网关的情况下成功的与路由器R2的192.168.3.2/24通信.其实这种理解是没有错的,但是当用户使用实验来证实代理ARP的作用时,结果却

容易被误读的IOSTAT

iostat(1)是在Linux系统上查看I/O性能最基本的工具,然而对于那些熟悉其它UNIX系统的人来说它是很容易被误读的.比如在HP-UX上 avserv(相当于Linux上的 svctm)是最重要的I/O指标,反映了硬盘设备的性能,它是指I/O请求从SCSI层发出.到I/O完成之后返回SCSI层所消耗的时间,不包括在SCSI队列中的等待时间,所以avserv体现了硬盘设备处理I/O的速度,又被称为disk service time,如果avserv很大,那么肯定是硬件出问题了.然而Linu

[PHP]误读支付宝接口可能引发的乌龙

------------------------------------------------------------------------------------ 之所以发现这个坑,源起项目中的支付宝页面跳转同步通知页return_url中的$verify_result始终返回false. $alipayNotify = new Alipaynotify($alipay_config); //支付宝通知处理类 $verify_result = $alipayNotify->verifyRe

微服务的误读与误解[转]

微服务确实很受欢迎,但是对于微服务的误解也是事实,本文对这些误解一一来介绍下: 一.微服务不够“微”? 尽管微服务定义的很明确,但是开发者社区对它的解释却颇有争议,主要的一些问题如下: 1.它是否是单体架构的代表? 2.它是否是单体服务的代表? 3.它是否是逻辑功能的组合? 下面让我们以银行应用为例来讨论一下:三层架构解决了技术组件之间的紧耦合问题,允许它们各自独立改变而不相互依赖.例如: Web端的改变不会影响到后端服务. 但是三层架构没有把基于组件分组的功能和特性考虑进去,为此我想出了一个“

那些年,曾经被我们误读的大数据 - Agenda - 世界经济论坛

body { font-family: Microsoft YaHei UI,"Microsoft YaHei", Georgia,Helvetica,Arial,sans-serif,宋体, PMingLiU,serif; font-size: 10.5pt; line-height: 1.5; } html, body { } h1 { font-size:1.5em; font-weight:bold; } h2 { font-size:1.4em; font-weight:bo

微服务的误读与误解

微服务确实很受欢迎,但是对于微服务的误解也是事实,本文对这些误解一一来介绍下: 一.微服务不够“微”? 尽管微服务定义的很明确,但是开发者社区对它的解释却颇有争议,主要的一些问题如下: 1.它是否是单体架构的代表? 2.它是否是单体服务的代表? 3.它是否是逻辑功能的组合? 下面让我们以银行应用为例来讨论一下:三层架构解决了技术组件之间的紧耦合问题,允许它们各自独立改变而不相互依赖.例如: Web端的改变不会影响到后端服务. 但是三层架构没有把基于组件分组的功能和特性考虑进去,为此我想出了一个“