10

在我们当前的自动化（使用 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=”开头的新属性类。@FindBy我认为这是一个好主意，因为我们可以通过查找文本简介而不是固有使用的值来找到 WebElements 。我的问题是，扩展 OR 的现有功能，@FindBy创建一种搜索我们在测试中使用的 WebElements 的新方法会更好吗？

4

3 回答 3

15

首先，没有“最佳实践”，只有在您的特定环境中运作良好的实践。对不起，这是我的老毛病...

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

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

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

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

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

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

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

那是我的 0.02 美元。

于 2013-07-04T19:23:49.093 回答
4

我认为这将有助于Selenium 定位器最佳实践

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

Yummy Locators Index XPath Child Elements CSS Properties Edible Locators JS Events DOM Elements KeyStrokes Coordinates

于 2013-07-05T12:55:55.667 回答
1

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

于 2013-07-03T18:47:15.230 回答