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的文章,豁然开朗。

参考文章: