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美元 （编辑：李大同） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |