3

我一直在使用 Ruby 1.8.7 中的 Selenium WebDriver。大多数项目都可以通过某些东西轻松找到，brwsr.find_element(:link, 'Click Here')但并非所有内容都可以通过这种方式访问​​（至少不能使用我所知道的 :link、:tag_name 等集合）。

因此，在浪费了数小时试图找到具有上述策略的元素之后，我偶然发现了一些示例 xpath。我以前从来没有费心去研究它，因为我看过很多关于 xpath 的帖子（主要是在 StackOverflow 上）。

我在 Pros and Cons 上找到了一篇 Google Groups 帖子，唯一的缺点是它在 IE 中速度较慢。由于我现在在 Linux 环境（以及 Firefox 和 Chrome）中完成所有工作，我不在乎它在 IE 中的速度较慢。

我已经使用 xpath 大约 2 周了，我的测试脚本的开发时间可能是它的一半。并且使用带有 find_element 的 xpath 似乎总是能抓住正确的元素，因为我曾经在上面描述的非 xpath 方法中遇到一些问题。

鉴于我看到的“如果可以的话，我真的想避免使用 xpath”评论的数量，我想知道我错过了什么。还是 xpath 像正则表达式，理解它的人喜欢它，所有那些从不费心学习它的人都被它迷惑了？

4

1 回答 1

3

XPath 可能天生就很慢，但这并不意味着它完全不行。

问题通常倾向于性能和IE。所有版本的 IE 在 XPath 上都很糟糕。好事？您已经确定 IE 不是自动化测试的核心部分，因此您可以将其删除。

至于性能，我倾向于只在使用复杂的 XPath 查询时才注意到性能下降。基本的往往与通过 ID 等搜索一样快，而当你计时时它可能会更慢，我看不出有什么明显的区别。

如果需要，我倾向于使用 XPath。如果你有一个复杂的 HTML 结构，我不明白你为什么不使用 XPath。它将使测试运行。如果它很慢，请在之后查看它，但只有在你得到一个漂亮的绿色勾号表示测试已通过之后。

Firefox 和 Chrome 倾向于使用 XPath 查询。

XPath 查询的另一个坏处是，如果使用非常特定的位置，您可能会陷入混乱。例如，使用此 XPath 在复杂表中查找单词“test”：

//div[1]/table[1]/tr[3]/td[1]/div[1]/a[text()='test'][1]

如果您在第三个表格上方添加一个额外的表格行怎么办？测试将失败。

然而，它可以缩短为，不依赖于底层结构的位置：

//table/descendant::a[text()='text']

如果您从头到尾了解 XPath 查询，并且可以优化它们，我不明白为什么不使用它们。

于 2012-10-07T21:16:52.190 回答