查找WebElements，最佳实践
在我们当前的自动化（使用Selenium / WebDriver / Java）中，我们非常广泛地使用@FindBy 。 例如：
@FindBy(css="a[name='bcrumb']") protected List breadCrumbLinks; @FindBy(id="skuError") protected WebElement skuError; @FindBy(className="reducedPrice") protected List 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可以使用以下@FindBy定位选择器：using，id，name，className，css，tagName，linkText，partialLinkText和xpath。
最近，我们的前端开发人员建议我们实现一个以’test =’开头的新属性类。 我认为这是一个好主意，因为我们可以通过查找文本的@FindBy来找到WebElements，而不是@FindBy固有使用的值。 我的问题是， 扩展 @FindBy OR 的现有function会更好@FindBy ，创建一种搜索我们在测试中使用的WebElements的新方法？
首先，没有“最佳实践”，只有在您的特定环境中运行良好的实践。 对不起，那是我的一个老抱怨……
除非您无法使用现有方法，否则我不会花费自定义属性。 我更喜欢在可能的情况下使用现有的定位器（找到逻辑）。
尽可能使用ID属性。 如果页面是有效的HTML，则页面上的ID是唯一的。 它们在每个浏览器中的分辨率非常快，并且UI可以发生显着变化，但您的脚本仍然会找到该元素。
有时ID不是正确的选择。 当您使用网格控件之类的东西时，动态生成的ID几乎总是错误的选择。 您依赖于可能与特定行位置相关联的ID，然后如果您的行发生更改，则会被搞砸。
在某些情况下，您的开发人员可以通过将常量值附加或添加到动态生成的ID值来帮助您。 ASP.NET Webforms使用动态生成的值做了疯狂的事情，所以我多次使用后缀。
链接文本，名称属性值和CSS选择器（JQuery样式）是您无法获得稳定，可靠的ID或一个不可用的ID的第二选择。
XPath是我几乎所有情况下的最后选择。 它很慢，可能非常脆弱，并且当它是一个复杂的XPath时很难处理。 也就是说，如果您需要为定位器上下移动DOM，那么这是唯一的选择。
使用现有的FindBy方法之一意味着您将使用一个易于理解，支持良好的定位器策略。 当你试图找出一个旧的测试，或者当你的团队成为新人时，这是一个很大的好处。
这是我0.02美元。
我认为这将有助于Selenium定位器最佳实践
最美味的定位器： ID名称类链接文本或部分文本
美国定位器索引XPath子元素CSS属性可用定位器JS事件DOM元素KeyStrokes坐标
如果我理解正确，你可以继续使用带有css选择器的@FindBy注释，例如css =“[test =’…’]”。