被误读的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的文章，豁然开朗。

参考文章：

Selenium中被误用的XPath

导航

公告