查找WebElement，最佳实践

一尘不染

查找WebElement，最佳实践

selenium

在我们当前的自动化中（使用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，名称，className，css，tagName，linkText，partialLinkText和xpath。

最近，我们的前端开发人员提议我们实现一个以’test
=’开头的新属性类。我认为这是一个好主意，因为我们可以仅通过查找文本内容而不是@FindBy固有使用的值来查找WebElement
。我的问题是，这将是更好地 扩大现有功能 的@FindByOR，创建搜索，我们在我们的测试中使用WebElements的一种新的方式？

阅读 280

2020-06-26

共1个答案

一尘不染

首先，没有“最佳实践”，只有在您的特定情况下效果良好的实践。抱歉，那是我的老乡了…

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

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

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

在某些情况下，您的开发人员可以通过将常量值追加或添加到动态生成的ID值来为您提供帮助。ASP.NET
Webforms使用动态生成的值来处理疯狂的事情，因此我多次使用后缀来发挥自己的优势。

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

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

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

那是我的0.02美元。

2020-06-26