Причины, по которым локаторы SeleniumRC CSS могут работать медленнее, чем XPath? - PullRequest
2 голосов
/ 15 апреля 2011

У меня есть некоторый код, который выполняет имитацию обхода дерева рекурсии, чтобы вычистить материал из дерева HTML с помощью SeleniumRC.Я запустил код с использованием локаторов Xpath и CSS.

Дерево представлено в виде серии вложенных таблиц.Если это вообще имеет значение, часть содержимого дерева начинает невидима, поскольку ветви «свернуты».И для Xpath, и для CSS дерево находится в одном и том же состоянии с точки зрения видимого и невидимого.

Чтобы получить значения узлов, мой код начинается с выражения "root", добавляет токены "branch", которые могутувеличиваться для каждого последующего узла-брата, а затем использовать токен «узла» для получения текстового содержимого.

Все это работает, но гораздо медленнее, используя выражения CSS, которые я придумала.

Полагаю, это хитрый способ создания выражений локатора, хотя он работает для моих целей.Я просто пытаюсь выяснить, как наилучшим образом использовать CSS, чтобы приблизиться к временам, связанным с использованием Xpath.

Цикл проверяет множество недопустимых выражений (продолжает поиск n-го родственного брата, пока не найден), и выражения получают действительнодолго, из-за способа, которым я постепенно увеличиваю детализацию во вложенных таблицах.

Ниже следуют биты выражения и примеры, которые приходят из рекурсии.Если кто-то может дать некоторое представление о том, что я делаю, так это то, что CSS занимает намного больше времени, чем Xpath, это было бы очень полезно.

Я совершенно новичок в этом виде манипулирования контентом HTML,если вы видите что-то глупое с точки зрения того, как я перешел с Xpath на CSS, скажите, пожалуйста.

XPath «токены»:

final String rootbase = "//*[contains(@id,\"treeBox\")]/div";
// in next string, "{branchIncrement}" will be replaced with integer values from 2 to get to text content, and skip graphical elements
final String leveltoken = "/table/tbody/tr[{branchIncrement}]/td[2]";
final String nodetoken = "/table/tbody/tr/td[4]/span";

CSS «токены»:

final String rootbase = "css=[id*=treeBox]>div";
// in next string, "{branchIncrement}" will be replaced with integer values from 2 to get to text content, and skip graphical elements
final String leveltoken = ">table>tbody>tr:nth-child({branchIncrement})>td:nth-child(2)";
final String nodetoken = ">table>tbody>tr>td:nth-child(4)>span";

Первое выражение XPath для содержимого в «корне»:

//*[contains(@id,"treeBox")]/div/table/tbody/tr[2]/td[2]/table/tbody/tr/td[4]/span

Последнее выражение XPath для дерева из 40 узлов с четырьмя уровнями, по три брата на каждом уровне ниже корня (1 + 3 + 3x3 + 3x3x3):

//*[contains(@id,"treeBox")]/div/table/tbody/tr[2]/td[2]/table/tbody/tr[2]/td[2]/table/tbody/tr[3]/td[2]/table/tbody/tr[2]/td[2]/table/tbody/tr[2]/td[2]/table/tbody/tr/td[4]/span

Первое выражение CSS:

[id*=treeBox]>div>table>tbody>tr:nth-child(2)>td:nth-child(2)>table>tbody>tr>td:nth-child(4)>span

Последнее выражение CSS:

[id*=treeBox]>div>table>tbody>tr:nth-child(2)>td:nth-child(2)>table>tbody>tr:nth-child(2)>td:nth-child(2)>table>tbody>tr:nth-child(3)>td:nth-child(2)>table>tbody>tr:nth-child(2)>td:nth-child(2)>table>tbody>tr:nth-child(2)>td:nth-child(2)>table>tbody>tr>td:nth-child(4)>span

Ответы [ 3 ]

1 голос
/ 18 апреля 2011

В Firefox локаторы XPath Selenium RC обрабатываются встроенным в браузер движком XPath, а локаторы CSS - библиотекой JavaScript ( cssQuery.js Дина Эдвардса).В более поздних выпусках Selenium (, например, , серия 2.0b *) используется библиотека jQuery sizzle для CSS, но они все еще делают это на JavaScript.Помимо этой подразумеваемой разницы в скорости, вы выполняете сопоставление с образцом в корневом выражении ( т.е. , [id*=treeBox), которое требует перечисления всего дерева DOM, чтобы найти совпадения, даже до того, как вы спуститесьоттудаПодумайте, как бы вы написали это на чистом JavaScript, и вы начнете видеть проблему.

Если вам станет легче, IE все еще не имеет встроенной реализации XPath, поэтому Selenium использует ее.из нескольких реализаций JavaScript в этом браузере, и из-за этого скорость XPath в Firefox 3.6 составляет от половины до одной десятой.

Короче говоря, мало что можно сделать, чтобы сделать локаторы CSSбыстрее в этом конкретном случае.

0 голосов
/ 27 апреля 2011

Спасибо за этот отзыв.После прочтения вашей заметки мне стало интересно, смогу ли я получить материальное улучшение, используя крошечный кусочек кода, чтобы разрешить буквальное значение Id, чтобы заменить многократное выражение содержимого.

Вот четыре различных локатора, которые я использовал длятоже самое.Пара локаторов - XPath, а два - CSS.Для каждой из этих пар используется выражение «содержит», и сначала выполняется преобразование в литерал.В каждом случае пример локатора относится к последнему узлу дерева узлов с тремя уровнями 1307.

XPath с содержит:

//*[contains(@id,"treeBox")]/div/table/tbody/tr[2]/td[2]/table/tbody/tr[2]/td[2]/table/tbody/tr[2]/td[2]/table/tbody/tr[26]/td[2]/table/tbody/tr/td[4]/span

XPath, где заменяемый литерал содержит выражение:

id('ns_7_5R4GAB1A0GKQ50IQJQR7VV10M6__treeBox')/div/table/tbody/tr[2]/td[2]/table/tbody/tr[2]/td[2]/table/tbody/tr[2]/td[2]/table/tbody/tr[24]/td[2]/table/tbody/tr/td[4]/span

CSS с содержит:

css=[id*=treeBox]>div>table>tbody>tr:nth-child(2)>td:nth-child(2)>table>tbody>tr:nth-child(2)>td:nth-child(2)>table>tbody>tr:nth-child(2)>td:nth-child(2)>table>tbody>tr:nth-child(24)>td:nth-child(2)>table>tbody>tr>td:nth-child(4)>span

CSS, в котором заменители литерала содержат выражение:

css=[id=ns_7_5R4GAB1A0GKQ50IQJQR7VV10M6__treeBox]>div>table>tbody>tr:nth-child(2)>td:nth-child(2)>table>tbody>tr:nth-child(2)>td:nth-child(2)>table>tbody>tr:nth-child(2)>td:nth-child(2)>table>tbody>tr:nth-child(24)>td:nth-child(2)>table>tbody>tr>td:nth-child(4)>span

Работа с двумя деревьями разного размера, одним 102 узлом, другим 1307 узлами,Я нашел следующее.

102 узлов:
|содержит |литерал |
XPath |15 сек|13 сек|
CSS |19 сек|19 сек|

1307 узлов:
|содержит |литерал |
XPath |255 сек|145 сек. |
CSS |1893 сек.|1811 сек. |

Очевидно, что нативная реализация (XPath в Firefox с Se-RC) намного быстрее, чем реализация JScript.Компромисс в том, что он может работать не так хорошо во всех браузерах.

0 голосов
/ 15 апреля 2011

Обычно это не то, чем вы можете помочь. Механизм выбора XPath в Selenium использует инструменты браузера XPath. Даже в IE6 есть один из них. Я не знаю, какой браузер предоставляет инструменты выбора CSS через JavaScript, поэтому Selenium должен использовать свой собственный код. Поскольку их код полностью выполнен на JavaScript, а внутренний анализ XPath в браузере обычно выполняется в нативном коде, он намного медленнее (особенно в IE6).

...