具体来说，这是我们在UI测试自动化项目中使用
ESLint强制执行的一些操作（使用Protractor）用于测试AngularJS应用程序）：CSS选择器内不使用引导类（想法是使用较少的UI /布局特定的东西来定位元素）
CSS选择器内部没有内部角度类-
ng-scope或ng-binding之类的内容纯属技术，因此不应在定位器内部使用。 /> 问题：
还有其他关于硒元素定位的建议吗？
#1 楼
一个很好的问题，尤其是人们是否会阅读它并停止使用XPath（我不屏住呼吸）。 css> xpathMozilla解释为什么IDs
Saucelabs解释为什么CSS定位器比XPath更受欢迎）
CSS vs XPath-带有基准测试
西蒙·斯图尔特（Simon Stewart）和视频
测试不稳定的原因是通过可变属性来定位元素。问题是，浏览器和Selenium都使用内部缓存来加速对属性的访问，因此破坏该缓存可能不会同步并导致断断续续。
CSS vs XPath：基准测试表明，与当前的浏览器（可悲的是，页面没有日期）的差异很小。但是因为页面是用CSS设置样式的，所以我们可以预期CSS比XPath更稳定。很少有用于后续考虑的链接。
XPath正常的异常：当前元素的父元素（如果父元素没有ID或名称）。
我的订单定位元素的首选项为：By.ID> By.NAME> By.CSS_SELECTOR> By.LINK_TEXT> By.CLASS_NAME> By.TAG_NAME> By.XPATH
评论
我几乎同意所有这些，但是我跳过了名称，转而使用CSS选择器。 CSS选择器在我测试过的浏览器中非常疯狂……到了它们比ID更快的地步，因此我考虑不再使用ID。但是，我认为只有一个ID的CSS选择器是……很奇怪。所以我的列表是id> css >>>> xpath。对于您的例外列表，您没有提到通过包含的文本查找元素……这是XPath可以做的。 XPath应该谨慎使用（出于您在回答中所述的原因），并且仅在通过包含的文本或进行DOM遍历查找元素时使用。
– JeffC
18年1月2日，下午5:04
@JeffC-假设只有XPath可以通过链接文本找到元素，那是错误的。 By.LINK_TEXT在Python中完成。实际上，我的优先顺序是：By.ID> By.NAME> By.CSS_SELECTOR> By.LINK_TEXT> By.CLASS_NAME> By.TAG_NAME> By.XPATH
–Peter M.-代表莫妮卡（Monica）
18年1月2日在15:09
我从未说过只有XPath可以通过链接文本找到元素。我说的是XPath是唯一可以通过包含的文本找到元素的定位器。 By.LINK_TEXT仅在A标签内找到一个元素。这是非常严格的。 XPath可以在A标签和其他所有标签中找到元素。
– JeffC
18年1月2日在16:18
@JeffC-我使用上述方法通过其他方式（XPath除外）查找元素列表，然后通过检查其他属性（包括文本）来查找元素列表。我相信，即使XPath几乎是编程语言，学习它的所有复杂性也是浪费时间，因为我已经掌握了相当不错的编程语言（其余的测试都用它编写）。当然，您可以在自己的空闲时间自由做任何事情，包括掌握XPath。我声称几乎总是有更好的简单方法来完成XPath的工作。
–Peter M.-代表莫妮卡（Monica）
18年1月2日，16：25
您肯定知道95％以上的测试人员不能只是将ID添加到他们想要的任何元素中，所以这不是现实的选择吗？而且，大多数人不会再找工作，因为他们可能需要学习一点XPath。并不是那么糟糕，并且在必要时您不必成为专家就可以使用它。
– JeffC
18年1月2日在22:29
#2 楼
选择一个好的定位器非常重要，要谨慎做-它会定义测试的可靠性，可读性，可维护性和持久性。它们将取决于用户界面和设计更改的程度。请记住：维护端到端测试通常是困难且昂贵的（对此主题有很好的阅读）。 >范围。与“面向布局”相比，更喜欢“面向数据”的元素和属性。换句话说，请尝试不依赖页面设计选择。通常，您不希望容器大小的无缝设计更改来破坏您的定位器：
更糟：
.col-md-1.col-xs-6 input .content input.email-input
对XPath说“否”。 XPath是最慢的定位技术。 XPath表达式通常更难以维护和调试（参考）。并且，当涉及到诸如
class之类的多值属性时，您需要执行额外的串联操作才能可靠地从多个类值中匹配一个类，这会增加复杂性并降低可读性：更糟糕：//*[contains(@class, 'some-class')//input[@type='text'] .some-class input.email-input
技术。尽量不要依赖于UI实现的基础技术。例如，对于AngularJS，请尽量不要使用内部的角度属性或类，例如
ng-scope或ng-binding /> HTML结构。尽量减少页面的HTML结构。您在到达所需元素的路径中拥有的元素越多，UI更改会突然使您的定位器突然中断的可能性就越大：
ID安全快捷。通过
.ng-scope.ng-binding搜索元素归结为使用针对速度进行了优化的.email-input方法的浏览器。而且，即使没有什么限制页面上重复的.content > table > tbody > tr:nth-child(2) > td.cell > input#email值，它们通常被假定并设计为唯一更糟糕： />
其他一些相关主题：
在使用Selenium时，是否在所有标准实践中都添加了ID？
哪个是使用webdriver查找元素的最佳和最快方法？ By.XPath或By.ID还是其他？又为什么呢
评论
尽管已证明XPath速度较慢，但差距正在缩小。我不太担心它们的速度，因为一旦在浏览器中加载单个页面，您将永远不会看到CSS选择器与XPath位置的差异（在常见情况下，最差情况可能不到100ms）。我之所以喜欢CSS选择器，是因为它们在浏览器中更加简单，简短，易于阅读并且得到了更加一致的支持。
– JeffC
18年1月2日，下午5:09
您的HTML结构示例包含一个ID，但是您没有使用它。尽管某些网站/页面不符合HTML标准（ID在页面上必须唯一），但它们应该如此。令我担心的是，有人会看到它，而不检查ID在页面上是否唯一，并使用它代替您拥有的CSS选择器。我见过（太多次无法计数）使用XPath且仅凭ID的人...
– JeffC
18年1月2日，下午5:11
#3 楼
我认为大多数答案都不错，但我想将重点放在这些问题的较高级别上，而不是细节上。是什么使硒定位器更好？
可读性：越短越好，最好使用清晰的唯一名称/ id来描述页面上的该唯一元素。可以随意更改类/名称/ id之类的代码，以使定位器和测试代码非常易于理解和可读。如果页面中元素的位置发生更改，则需要更新。除非功能发生了巨大变化，否则您应该能够最大程度地减少定位器和/或测试的更新。整洁的代码对于页面结构和测试也很重要。
还有其他建议在硒中定位元素吗？ br />将定位符集中在测试代码中，使其保持干燥。 PageObjects可能会有所帮助。
与开发人员一起创建好的定位器！更改您的过程，以便做到这一点。一个很好的技巧是，如果您是单独的质量检查人员，则可以与开发人员对测试进行配对编程，您俩都可以学到一些东西。
评论
我会说“ PageObjects会有所帮助”。除非您做错了，否则我看不到页面对象将无济于事。
– JeffC
18年1月2日，下午5:14
#4 楼
我的钱是CSS定位器。如果有ID和/或类，则使用ID，否则使用位置。此外，让Chrome提供CSS选择器并通过document.querySelector("yourCssSelectorHere")在DevTools的控制台选项卡中对其进行测试，或者在Elements选项卡上进行搜索并将其粘贴，都非常容易。大多数经验丰富的Selenium用户都建议将CSS作为他们的定位策略，因为它比XPath快得多，并且可以在内部HTML文档中找到最复杂的对象。 -SeleniumHQ.org 评论
是的CSS和ID，并使用chrome。请注意，我不同意更快的断言。有关某些信息，请参见elementalselenium.com/tips/32-xpath-vs-css。我觉得没有太大的区别，这是过早的优化，并且由于更少的字符和更多的空格，css通常对许多人可读性更强。但是我注意到上面引用的断言来自SeleniumHQ.org，这很有趣。收视率
–迈克尔·杜兰特（Michael Durrant）
17-6-28在12:35
#5 楼
什么才是一个好的硒选择器？使用css
短
描述性
给出这些质量属性在实践中会转化为：
xpath上的收藏夹css具有可读性在选择器的最后一个元素上优先使用“
form.new_user input.age”而不是“ //form[@class='new_user']/input[@class='age']” 例如，
form.new_user input#last_name 纯粹为了增加可读性和稳定性而考虑添加选择器作用域元素
，例如
form.new_user中的form.new_user input.last_name可以添加以后的表单尽可能避免使用布局元素
避免使用
div section.top_header 避免使用带有多个元素的较长选择器
，例如避免使用
div.details div.users span.user form.new_user input.last_name 尽量避免使用非英语的描述性文字
，例如避免
form.new_user56 input.lst_nm 请注意，这些都是良好实践准则，而不是最佳实践规则。
它们可能被故意破坏。一个常见的示例是使用定义值的框架时。
评论
您是否遇到了无法添加唯一定位符的框架？这是因为编码人员并不关心产品是否可测试。我希望可以关注主要框架。其他开关:)
– Niels van Reijmersdal
17年6月28日在14:16
是的，但是UX专家在我的经验中对待和命名的方式有所不同。首字母缩写词，数字，抽象字符等可能更常见。我在我使用的所有网站（例如cnn，天气等）的来源中看到了这一点。
–迈克尔·杜兰特（Michael Durrant）
17年6月28日在22:11
如果元素具有ID（并且该站点遵循HTML准则），则除了By.id（）外，您不需要任何其他内容。在第二个项目符号示例中。
– JeffC
18年1月2日，下午5:21
#6 楼
进一步说明如何使选择器更强大错误的选择器
如果使用的是选择器，则
table，选择器损坏br最好的选择器我通常会使用最小的选择器（最好的）
.content > table > tbody > tr:nth-child(2) > td.cell > input#email
这将足以处理任何DOM更改，除非存在
br />元素将更改其ID（测试中必须包含的现有变化
）
两个具有相同ID的电子邮件输入框（非大小写，ID必须唯一）
#7 楼
理想情况下，在Selenium WebDriver中识别网络元素的首选定位器是ID。它很短。
它是与其他定位器相比，速度最快，因为在后台
所要做的就是选择与提到的ID相匹配的元素。
这是最安全的，即使该元素的位置发生变化或更糟，即使类型发生变化，您的测试脚本仍应能够找到并识别该元素。
它很强大，因为周围元素的任何变化通常不会产生任何影响
，因此即使周围的所有内容元素发生变化
，但系统应该能够轻松地找到该元素。
然后，为什么许多Automation-QA使用其他定位器？在理想的世界中，每个元素都应该有一个ID，并且特定页面上的每个
单个元素都应该有一个唯一的ID，但是
总是或不一定。
自动生成的ID已使用ID定位器将无法使用以
检测。最坏的情况是在单个页面上重复ID。
在这种情况下该怎么办？这完全取决于AUT，设计AUT的模式开发人员，UI-UX的更改频率，UI-UX的更改幅度以及最后但并非最不重要的个人偏好。 > xpath虽然没有严格使用就被广泛使用，但是如果元素的位置发生变化，可能会导致问题，但是在此之前，它可以唯一地标识网页上最小的对象。同样，不同的浏览器对于xpath表达式的行为也有所不同。
CSS选择器和className定位器与xpath处于同一困境，因为位置是否可以不变，一个Web应用程序依赖其外观，外观的关键因素是UI。因此，CSS选择器和className定位器的更改可能比其他定位器更频繁。
tagName面临使多个对象与给定标签匹配的问题，因此它不是首选，至少不是我的最爱。
因此，除了ID，您完全可以选择作为选择器取决于我上面提到的因素，并且随着浏览器的发展，如今，我希望这些定位器在复杂的已开发Web应用程序中进行搜索所花费的执行时间差异可以忽略不计，从而使选择更加困难。
测试愉快！
评论
您声称id是最快的...我还没有看到。根据我的测试，CSS选择器是更快的定位器。在理想的世界中，每个元素都没有ID。当我们可能不需要90％的元素时，将ID放在所有内容上会浪费大量开发人员的工作。选定的少数几个上的ID就足够了，不会对开发人员造成负担。您仍然可以根据其格式查找自动生成的ID。
– JeffC
18年1月2日，下午5:25
评论
另请参见sqa.stackexchange.com/q/28027/8992类似于：sqa.stackexchange.com/questions/16995/…