我一直在使用Ruby 1.8.7中的Selenium WebDriver。大多数项目都可以通过brwsr.find_element(:link, 'Click Here')轻松找到，但并非所有内容都可以通过这种方式访问（至少不能使用我知道的：link，：tag_name等集合）。
因此，在浪费了数小时和数小时试图找到具有上述策略的元素之后，我偶然发现了一些示例xpath。我以前从来没有费心去调查它，因为我看到很多帖子（主要是在StackOverflow上）对于xpath是负面的。
我在优点和缺点上发现了一个Google网上论坛帖子，唯一确定的是它在IE中速度较慢。由于我现在正在Linux环境（以及Firefox和Chrome）中完成所有工作，所以我并不关心它在IE中的速度较慢。
我现在已经使用xpath大约2周了，我的测试脚本的开发时间可能是它的一半。使用带有find_element的xpath似乎总是抓住正确的元素，因为我曾经遇到过上述非xpath方法的一些问题。
考虑到'我真的想避免使用xpath，如果我能'我已经看到的评论，我想知道我错过了什么。或者像正则表达式那样的xpath和理解它的人都爱，所有那些从不费心去学习它的人对它有些神秘感？
答案 0 :(得分：3)
XPath本质上可能很慢，但这并不能让它完全禁止。
问题通常倾向于性能和IE。所有版本的IE都在XPath上吮吸。好事？您已经确定IE不是自动化测试的核心部分，因此您可以删除它。
至于性能，我倾向于只注意到使用复杂的XPath查询时性能下降。基本的那些往往跟ID等搜索一样快，而当你计算时它可能会慢一些，我没有看到太明显的区别。
如果需要，我倾向于使用XPath。如果你有一个复杂的HTML结构，我不明白为什么你不会使用XPath。它将使测试运行。如果它很慢，请在之后查看，但只有在你得到一个漂亮的绿色标记后才能说测试已经过去了。
使用XPath查询时，Firefox和Chrome可能会很好。
XPath查询的另一个坏处是，如果使用非常具体的位置，你可能会陷入混乱。例如，使用此XPath在复杂表中找到“test”一词：
//div[1]/table[1]/tr[3]/td[1]/div[1]/a[text()='test'][1]
如果在第三个表格上方添加额外的表格行怎么办？测试将失败。
然而，它可以缩短为，不依赖于底层结构的位置：
//table/descendant::a[text()='text']
如果你知道XPath查询在前面，并且可以优化它们，我不明白为什么不使用它们。