java – 查找WebElements,最佳做法

前端之家收集整理的这篇文章主要介绍了java – 查找WebElements,最佳做法前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
在我们当前的自动化(使用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的新方式吗?

解决方法

首先,没有“最佳实践”,只是在你的特定环境中工作得很好的人.对不起,这是我的一个老抱怨…

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

只要有可能,使用ID属性.如果页面是有效的HTML,那么ID在页面上是唯一的.它们在每个浏览器中的分辨率都非常快,UI可以大大改变,但脚本仍然可以定位元素.

有时,ID不是正确的选择.当您使用像网格控件这样的东西时,动态生成的ID几乎总是错误的选择.你依靠一个可能与特定行位置相关联的身份证件,然后如果你的行发生变化,那么你就会被钉住.

在其中一些情况下,您的开发人员可以通过将动态生成的ID值附加或保留常量值来帮助您. ASP.NET Webforms使用动态生成的值来创建疯狂的东西,所以我已经使用了一个后缀我的好几次.

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

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

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

那是我的0.02美元

原文链接:https://www.f2er.com/java/122935.html

猜你在找的Java相关文章