寻找 WebElements，最佳实践答案

【问题标题】：Finding WebElements, best practices寻找 WebElements，最佳实践
【发布时间】：2013-07-01 12:09:53
【问题描述】：

在我们当前的自动化（使用 Selenium/WebDriver/Java）中，我们广泛使用@FindBy非常。例如：

@FindBy(css="a[name='bcrumb']")    protected List<WebElement> breadCrumbLinks;
@FindBy(id="skuError")         protected WebElement skuError;  
@FindBy(className="reducedPrice")  protected List<WebElement> reducedPrice;
@FindBy(partialLinkText="Injinji RUN 2.0")  protected WebElement playButton;
@FindBy(linkText="annual member refund")    protected WebElement annualMemberRefund;
@FindBy(xpath="//li[@itemprop='price']")    protected WebElement productPrice;

根据定义，@FindBy 可以使用以下内容定位选择器：using、id、name、className、css、tagName、linkText、partialLinkText 和 xpath。

最近，我们的前端开发人员建议我们实现一个以“test=”开头的新属性类。我认为这是一个好主意，因为我们可以通过查找文本简介来找到 WebElements，而不是 @FindBy 固有使用的值。我的问题是，扩展@FindBy 的现有功能 或者创建一种新方法来搜索我们在测试中使用的 WebElement 会更好吗？

【问题讨论】：

标签： java selenium automation selenium-webdriver ui-automation

【解决方案1】：

首先，没有“最佳做法”，只有在您的特定环境中运作良好的做法。抱歉，这是我的老毛病……

除非您无法使用现有方法，否则我不会花精力在自定义属性上。我更喜欢尽可能使用现有的定位器（查找逻辑）。

尽可能使用 ID 属性。如果页面是有效的 HTML，则 ID 在页面上是唯一的。它们在每个浏览器中的解析速度都非常快，并且 UI 可能会发生巨大变化，但您的脚本仍会找到该元素。

有时 ID 不是正确的选择。当您使用诸如网格控件之类的东西时，动态生成的 ID 几乎总是错误的选择。您依赖一个可能与特定行位置相关联的 id，然后如果您的行发生更改，您就会被搞砸。

在某些情况下，您的开发人员可以通过将常量值附加或附加到动态生成的 ID 值来帮助您。 ASP.NET Webforms 使用动态生成的值做一些疯狂的事情，所以我多次使用后缀来发挥我的优势。

链接文本、名称属性值和 CSS 选择器（JQuery 样式）是当您无法获得稳定、可靠的 ID 或某个 ID 不可用时很好的第二选择。

XPath 是我几乎在所有情况下的最后选择。它很慢，可能非常脆弱，并且当它是一个复杂的 XPath 时很难处理。也就是说，如果您需要为定位器上下移动页面 DOM，那么这是唯一的选择。

使用现有的 FindBy 方法之一意味着您将使用易于理解、支持良好的定位器策略。当您试图找出一个旧测试时，或者当您的团队新入职时，这是一个很大的好处。

这是我的 0.02 美元。

【讨论】：

说得好，吉姆。这是我的答案。

【解决方案2】：

我认为这会有所帮助Selenium Locators Best Practices

最美味的定位器： ID 姓名班级关联文字或部分文字

美味的定位器 指数 XPath 子元素 CSS 属性食用定位器 JS 事件 DOM 元素击键坐标

【讨论】：

试试这个LINK 或者只是谷歌查询“Watir 和 Selenium 定位器的最佳实践 - 定位器生命之树”
链接已移动there

【解决方案3】：

如果我理解正确，您可以继续将 @FindBy 注释与 css 选择器一起使用，例如 css = "[test='...']"。

【讨论】：

是的，我知道。不过，我的具体问题是，扩展 FindBy 还是创建一个可以处理搜索不遵循当前 FindBy 约定的属性/元素的新类更好。