查找WebElements,最佳实践

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本身使用的值.我的问题是,这将是更好地扩大现有功能的@FindByOR,创建搜索,我们在我们的测试中使用WebElements的一种新的方式？

Answer 1

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

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

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

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

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

链接文本,名称属性值和CSS选择器(JQuery样式)是您无法获得稳定,可靠的ID或一个不可用的ID的第二选择.

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

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

这是我的0.02美元.