В чем разница между css-selector и Xpath? что лучше(в соответствии с производительностью и для перекрестного тестирования браузера)?

Я собираюсь провести непопулярный на так selenium tag мнение, что XPATH желательно в CSS в долгосрочной перспективе.

позвольте мне сначала заняться "слоном в комнате" - xpath медленнее, чем css.

С текущей мощностью процессора (читай: что-нибудь, произведенное за последние 5 лет), даже на BrowserStack/saucelabs VMs, и развитие браузеров (читай: все популярные за последние 5 лет), что вряд ли так. Двигатели браузера разработанный, поддержка xpath является однородной, т. е. выходит из картины (надеюсь, для большинства из нас). Это сравнение в другом ответе цитируется повсюду, но оно очень контекстуальное – сколько работает – или заботится – против IE8?

если есть разница, то в долю миллисекунды.

тем не менее, большинство фреймворков более высокого уровня добавляют по крайней мере 1 мс накладных расходов по вызову raw selenium в любом случае (обертки, обработчики, хранение состояния etc); мое личное оружие выбора-robotframework-добавляет по крайней мере 2ms, которое я более чем счастлив пожертвовать за то, что оно обеспечивает. Сетевое путешествие от AWS us-east-1 до концентратора BrowserStack обычно 11 мс.

поэтому с удаленными браузерами, если есть разница между xpath и css, она затеняется всем остальным.

там не так много публичных сравнений (я видел один), так вот грубо одноместный, фиктивный и простой. Целевая-целевая страница BrowserStack, и это кнопка "Зарегистрироваться"; скриншот html:

вот тестовый код (python):

from selenium import webdriver
import timeit


if __name__ == '__main__':

    xpath_locator = '//div[@class="button-section col-xs-12 row"]'
    css_locator = 'div.button-section.col-xs-12.row'

    repetitions = 1000

    driver = webdriver.Chrome()
    driver.get('https://www.browserstack.com/')

    css_time = timeit.timeit("driver.find_element_by_css_selector(css_locator)", 
                             number=repetitions, globals=globals())
    xpath_time = timeit.timeit('driver.find_element_by_xpath(xpath_locator)', 
                             number=repetitions, globals=globals())

    driver.quit()

    print("css total time {} repeats: {:.2f}s, per find: {:.2f}ms".
          format(repetitions, css_time, (css_time/repetitions)*1000))
    print("xpath total time for {} repeats: {:.2f}s, per find: {:.2f}ms".
          format(repetitions, xpath_time, (xpath_time/repetitions)*1000))

для тех, кто не знаком с python – он открывает страницу и находит элемент – сначала с локатором css, затем с xpath; операция поиска повторяется 1,000 раз. Выход-общее время в секундах на 1000 повторах, и среднее время в миллисекундах.

локаторы - для xpath - "элемент div, имеющий это точное значение класса, где – то в DOM"; css аналогичен - "элемент div с этим классом, где-то в DOM". Преднамеренно выбран не быть настроенным; кроме того, селектор класса цитируется для css как "второй самый быстрый после идентификатора".

окружающая среда-Chrome v66.0.3359.139, chromedriver v2.38, процессор: ULV Core M-5Y10 обычно работает на 1,5 ГГц (да, "текстовая обработка", даже не обычный зверь i7).

вот вывод:

css общее время 1000 повторов: 8.84 s, за находку: 8.84 ms

xpath общее время для 1000 повторов: 8.52 s, за находку: 8.52 ms

очевидно, что тайминги per find довольно близки; разница 0.32 МС. Не прыгайте – xpath быстрее – иногда это так, иногда это стиль CSS.

давайте попробуем с другим набором локаторов, немного сложнее-атрибут, имеющий подстроку (общий подход, по крайней мере для меня, идущий после класса элемента, когда часть его имеет функциональное значение):

xpath_locator = '//div[contains(@class, "button-section")]'
css_locator = 'div[class~=button-section]'

два локатора снова семантически одинаковы – "найти элемент div, имеющий в своем классе атрибут этой подстроки". Вот результаты:

css общее время 1000 повторов: 8.60 s, за находку: 8.60 ms

xpath общее время для 1000 повторов: 8.75 s, за находку: 8.75 ms

разница в 0,15 МС.

С более сложным DOM результаты те же; у меня нет общедоступных URL-адресов под рукой, чтобы дать пример, но снова видели аналогичные результаты для xpath и css.

как упражнение-тот же Тест, что и в блог в комментариях / другой ответ -тестовая страница публично, и так тестирование кода.

они делают пару вещей в коде-щелчок по столбцу для сортировки по нему, а затем получение значений и проверка сортировки пользовательского интерфейса верны. Я вырежу его - просто достану локаторы, после всего этого это корневой тест, верно?

один и тот же код, что и выше, с этими изменениями в:

url теперь http://the-internet.herokuapp.com/tables; есть 2 теста.

локаторы для первого - "поиск элементов по ID и Class" - являются:

css_locator = '#table2 tbody .dues'
xpath_locator = "//table[@id='table2']//tr/td[contains(@class,'dues')]"

результат:

css общее время 1000 повторов: 8.24 s, за находку: 8.24 ms

xpath общее время для 1000 повторов: 8.45 s, за находку: 8.45 ms

разница в 0,2 миллисекунды.

"Поиск Элементов Путем Обхода":

css_locator = '#table1 tbody tr td:nth-of-type(4)'
xpath_locator = "//table[@id='table1']//tr/td[4]"

результат:

css общее время 1000 повторов: 9.29 s, за находку: 9.29 ms

xpath общее время для 1000 повторов: 8.79 s, per find: 8.79 ms

на этот раз это 0.5 ms (в обратном порядке, xpath получился "быстрее" здесь).

Итак, из xpath и css, какой из двух выбрать для производительности? Ответ прост-выберите поиск по id.

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

с производительностью вне картины, почему я думаю, что xpath лучше? Просто-многосторонность, и сила.

Xpath-это язык, разработанный для работы с XML-документами; таким образом, он позволяет создавать гораздо более мощные конструкции, чем css.
Например, навигация в каждом направлении в дереве-найдите элемент, затем перейдите к его дедушке и найдите его потомка, имеющего определенные свойства. Это позволяет встроенным булевым условиям – cond1 и not(cond2 или not (cond3 и cond4)); встроенные селекторы – "найдите div, имеющий этих детей с этими атрибутами, а затем перейдите в соответствии с ним". Он позволяет осуществлять поиск на основе значения узла-однако эта практика не одобряется, особенно в плохо структурированных документах (без определенных атрибутов, таких как динамические идентификаторы и классы).

шаг в css, безусловно, проще – можно начать писать селекторы в течение нескольких минут; но после нескольких дней использования, мощность и возможности xpath быстро преодолевает css.
И чисто субъективно-сложный css гораздо сложнее читать, чем сложное выражение xpath.

наконец, опять же очень субъективно - что выбрать? ИМХО, нет правильного или неправильного выбора - это разные решения одной и той же проблемы, и что больше подходит для работы должны быть подобраны. Будучи поклонником xpath, я не стесняюсь использовать в своих проектах смесь обоих-черт возьми, иногда гораздо быстрее просто бросить css, если я знаю, что он будет делать работу просто отлично.