Question

在我们当前的自动化（使用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 OR的现有功能会不会更好？创建一种搜索我们在测试中使用的WebElements的新方法？

Answer 1

首先，没有“最佳实践”，只有那些在您的特定环境中运作良好的实践。对不起，那是我的一个老抱怨......

除非您无法使用现有方法，否则我不会花费自定义属性。我更喜欢在可能的情况下使用现有的定位器（找到逻辑）。

尽可能使用ID属性。如果页面是有效的HTML，则页面上的ID是唯一的。它们在每个浏览器中的分辨率非常快，并且UI可以发生显着变化，但您的脚本仍然可以找到该元素。

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

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

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

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

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

这是我的0.02美元。

Answer 2

我认为这有助于Selenium Locators Best Practices

最美味的定位器： ID 名称类链接文字或部分文字

美味定位器 指数 XPath的儿童元素 CSS属性食用定位器 JS活动 DOM元素将KeyStroke 坐标

Answer 3

如果我理解正确，你可以继续使用带有css选择器的@FindBy注释，例如css =“[test ='...']”。

查找WebElements，最佳实践

3 个答案: