检测复杂的CSS选择器

Question

这是什么使一个好的硒定位器？的后续行动。

动机

我一直在考虑静态地检测CSS选择器的复杂性。

我使用的范围是测试自动化和网刮，选择可靠的CSS选择器非常重要，尽可能减少对UI/标记/布局更改的依赖。

目前，我可以通过css-selector-parser解析CSS选择器的“深度”，并简单地计算节点数。如果节点数超过5个，我的结论是这是一个潜在的复杂CSS选择器。这背后的原因是，选择器在路径中拥有的节点越多，就越依赖于页面的HTML结构--越脆弱。例如，这个CSS选择器将被视为“脆弱”(6个节点)：

.content > table > tbody > tr:nth-child(2) > td.cell > input#email

最后，我正在考虑开发一个度量，其中每个选择器将得到一个特殊的“分数”值，它将衡量一个选择器是否更坚固、更耐用。受著名代码复杂性度量(如圈复杂度或维修性指数 )的启发。

问题

您会考虑哪些参数来确定CSS选择器是否能够抵抗更改？什么使一个可靠的CSS定位器？

Thoughts

• 在CSS选择器中使用面向布局的bootstrap类将是错误定位器的信号。
• 特定于实现的类和属性会降低选择器的可靠性。(例如AngularJS - ng-scope或ng-binding类)
• 使用id或name属性可能是可取的

Answer 1

您会考虑哪些参数来确定CSS选择器是否能够抵抗更改？什么使一个可靠的CSS定位器？我会考虑一些因素：

首先，基本内容是：

• 定位器不应包括页面布局结构。
• 不要将选择器以实际页面文本为基础
• 在你现有的框架内工作(S)
• 更喜欢css而不是xpath，以提高可读性
• 唯一不变的css id(s)是最好的。

然后..。

• 是否使用嵌套表
• 是否使用data-属性标识符
• 给定的css id是否实际上是唯一的
• 选择器中是否使用文字内容文本
• 重复元素的使用，例如div div div
• 第一个选择器元素的DOM嵌套深度
• 选择器中单独的html元素的数目。
• 历史上任何现有的选择器被更改的频率
• 选择器字符串的长度(不同元素的数目)
• 选择器字符串的长度(不同字符的数目)
• 在DOM中有多少级别的嵌套与之相反
• 是否在定位器中使用部分和通配符内容文本？
• 是否使用表，如果使用，行是如何排序/重新排序的
• 使用索引标识符，例如css :nth-child(number)或xpath[]
• 使用唯一属性(如id或name )和限定标识符
• 对选择器中的元素使用css id的次数。
• 在选择器中存在多少个标识符实例，如css类
• 一些id是否都是数字的和唯一的，这意味着数据库支持
• 某些css元素id是否是动态的，例如唯一资源记录id的
• 选择器的每个单独元素出现在DOM中的次数。
• 选择器元素是直接嵌套的还是仅仅是“在”其他元素中
• 与其他选择器比较时，是否可以看到一致的方法？
• 如果选择器中使用了多个table、td或tr，则是否在一个表中使用？
• 使用泛型属性(如span和div )，而不对它们进行限定标识符
• DOM元素是直接相邻的还是嵌套在其他元素中？
• 使用Ruby on Rails这样的框架，为db相关元素提供唯一标识符

最困难的是，要知道这些因素中的每一个都有多大的权重。有些将受到开发和ux框架使用的严重影响，在某些情况下与其他情况或多或少相关。

判断元素权重和可预见性的一种方法是逆向工程和检查由于DOM更改而导致的过去的测试中断，以查看关系。在实践中，我发现在提交代码之前，作为devs修复测试，很难做到这一点。像谷歌这样的大公司也许能够更好地研究这个问题。

同样重要的是要区分变化的应用程序代码和具有这种复杂性的自动化选择器。对给定选择器的排序或评级可能为自动开发用于自动测试的选择字符串提供良好的反馈，但不适合ux组开发的页面内容本身。

Answer 2

我已经能够降低您描述的复杂性如下：

将代码视为数据，将数据视为代码；使用集合。这避免了将复杂路径定义到网页中的使用。有了集合和适当的过滤技术，我们只能依靠页面上看到的文本。

示例

var day = 12;
var calendar = calenderElement.Click();  //opens the calendar
//finds the link with the number 12 (in the text) for each link.
var ele= calendar.FindElements.By.TagName("a").Select(i=>i.Text == day).First(); 
ele.Click() //sets the date in the calendar

这种代码样式应该可以用于C#、Java和Javascript解决方案。这三种语言都支持集合查询，FindEements将从当前的IWebElement (如果选择器不是全局的)工作。通过使用当前元素中的FindElement，可以进行精细的优化演练，以达到所需的目的。

如果上面的代码被重构到我们想要的那一天注入.那么我们就有了一个可重复使用的部件。

这允许我们以不同的方式来思考网页。我们真正需要的是ID、链接或CSS作为我们的主要检索点。从这里，我们使用集合过滤和或FindEement(s)从这些点，过滤我们想要的东西。最好的部分是它只能基于我们看到的文本，而不是隐藏的属性等等。然而，如果我们需要更细粒度的搜索，所有属性也可以以相同的方式进行过滤。

示例2

我们知道类选择器会返回(最常见的方式是太多的元素)，所以让我们根据我们看到的仅使用classNames的文本在一个过滤器中拨号。

var specificTextWanted = "Something we see";
                      //too many elements here               //filtered here
var theSingleElement = wd.FindElements(By.ClassName("alpha").Where(i=>i.text == specificTextWanted).First();

我们现在可以使用基于返回集合的基于文本的筛选来绕过复杂的选择器。这甚至对于动态内容也很好，但是有时会在Where子句中抛出一个陈旧的元素引用，它很容易修复(尝试、捕捉)并忽略元素，毕竟，它不再存在了！