В чем разница между cssSelector и Xpath и что лучше с точки зрения производительности при кроссбраузерном тестировании?

Question 1

Я работаю с Selenium WebDriver 2.25.0 над многоязычным веб-приложением и в основном тестирую содержимое страницы (для разных языков, таких как арабский, английский, русский и т. Д.).

Для моего приложения, которое лучше по производительности, и убедитесь, что оно должно поддерживать все браузеры (например, IE 7,8,9, FF, Chrome и т. Д.).

Заранее благодарим за ценные предложения.

Question 2

Селекторы CSS работают намного лучше, чем Xpath, и это хорошо задокументировано в сообществе Selenium. Вот несколько причин,

Механизмы Xpath различны в каждом браузере, поэтому делают их несовместимыми
IE не имеет собственного механизма xpath, поэтому selenium внедряет свой собственный механизм xpath для совместимости своего API. Следовательно, мы теряем преимущество использования встроенных функций браузера, которые по своей сути продвигает WebDriver.
Xpath имеет тенденцию становиться сложным и поэтому, на мой взгляд, его трудно читать

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

Вы можете прочитать блог Саймона здесь . Он также рекомендует CSS вместо Xpath.

Если вы тестируете содержимое, не используйте селекторы, зависящие от содержимого элементов. Это будет кошмар обслуживания для любого региона. Попробуйте поговорить с разработчиками и использовать методы, которые они использовали для экстернализации текста в приложении, такие как словари или пакеты ресурсов и т. Д. Вот мой блог, в котором это подробно объясняется.

редактировать 1

Благодаря @parishodak вот ссылка, которая предоставляет цифры, доказывающие, что производительность CSS лучше

Question 3

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

Этот длинный пост состоит из двух разделов - сначала я сделаю доказательство того, что разница в производительности между ними составляет 0,1-0,3 миллисекунды (да, это 100 микросекунд ) , а затем я поделюсь своим мнением, почему XPath более мощный.

Разница в производительности

Давайте сначала займемся «слоном в комнате» - этот xpath медленнее, чем css.

С текущей мощностью процессора (читайте: все, что x86 произведено с 2013 года) , даже на виртуальных машинах browserstack / saucelabs / aws, и с развитием браузеров (читайте: все популярные за последние 5 лет) это вряд ли имеет место. Разработаны движки браузера, поддержка xpath едина, IE не используется (надеюсь, для большинства из нас) . Это сравнение в другом ответе цитируется повсюду, но оно очень контекстно - сколько из них запускают или заботятся об автоматизации против IE8?

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

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

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

Измерения

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

Цель - целевая страница 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; операция поиска повторяется 1000 раз. Результатом является общее время в секундах для 1000 повторений и среднее время для одной находки в миллисекундах.

Локаторы:

для xpath - «элемент div, имеющий это точное значение класса, где-то в DOM»;
css аналогичен - «элемент div с этим классом где-то в DOM».

Сознательно выбран, чтобы не перестраиваться; Кроме того, селектор класса указан в CSS как «второй по скорости после идентификатора».

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

Вот результат:

css total time 1000 repeats: 8.84s, per find: 8.84ms

xpath total time for 1000 repeats: 8.52s, per find: 8.52ms

Очевидно, что время нахождения довольно близко; разница составляет 0,32 миллисекунды . Не прыгайте «xpath быстрее» - иногда это так, иногда css.

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

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

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

css total time 1000 repeats: 8.60s, per find: 8.60ms

xpath total time for 1000 repeats: 8.75s, per find: 8.75ms

Разница 0,15 мс .

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

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

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

Теперь URL-адрес http://the-internet.herokuapp.com/tables; есть 2 теста.
Локаторы для первого - «Поиск элементов по идентификатору и классу»:

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

И вот результат:

css total time 1000 repeats: 8.24s, per find: 8.24ms

xpath total time for 1000 repeats: 8.45s, per find: 8.45ms

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

«Поиск элементов путем обхода»:

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

Результат:

css total time 1000 repeats: 9.29s, per find: 9.29ms

xpath total time for 1000 repeats: 8.79s, per find: 8.79ms

На этот раз это 0,5 мс (наоборот, xpath здесь оказался "быстрее").

Итак, 5 лет спустя (улучшенные движки браузеров) и сосредоточение внимания только на производительности локаторов (без таких действий, как сортировка в пользовательском интерфейсе и т. Д.), Та же тестовая площадка - практически нет разницы между CSS и XPath.

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

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

Тем не менее, уникальные и постоянные (например, не генерируемые автоматически) идентификаторы не всегда доступны, что подводит нас к вопросу «зачем XPath, если есть CSS?»

Преимущество XPath

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

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

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

Outro;)

Наконец, снова очень субъективно - какой выбрать?

ИМО, нет правильного или неправильного выбора - это разные решения одной и той же проблемы, и следует выбрать то, что больше подходит для работы.

Будучи «фанатом» XPath, я не стесняюсь использовать в своих проектах и то, и другое - черт возьми, иногда гораздо быстрее просто использовать CSS, если я знаю, что он отлично справится со своей работой.

Question 4

Споры между cssSelector и XPath останутся одним из самых субъективных споров в сообществе Selenium . То, что мы уже знаем, можно резюмировать следующим образом:

Люди в пользу CSSSelector сказать , что он является более читаемым и быстрее (особенно при работе с Internet Explorer).
В то время как сторонники XPath рекламируют его способность перемещаться по странице (в то время как cssSelector не может).
Обход DOM в старых браузерах, таких как IE8, не работает с cssSelector, но подходит для XPath .
XPath может проходить вверх по DOM (например, от дочернего к родительскому), тогда как cssSelector может проходить только вниз по DOM (например, от родителя к дочернему)
Однако невозможность обхода DOM с помощью cssSelector в старых браузерах не обязательно плохо, поскольку это скорее показатель того, что ваша страница имеет плохой дизайн и может извлечь выгоду из некоторой полезной разметки.
Бен Бертон упоминает, что вам следует использовать cssSelector, потому что именно так создаются приложения. Это упрощает написание тестов, их обсуждение и поддержку других.
Адам Гоучер советует использовать более гибридный подход - сосредотачиваясь сначала на идентификаторах, затем на cssSelector , и используя XPath только тогда, когда он вам нужен (например , при переходе по DOM), и что XPath всегда будет более мощным для продвинутых локаторов.

Дэйв Хаффнер провел тест на странице с двумя таблицами данных HTML , одна таблица написана без полезных атрибутов ( ID и Class ), а другая с ними. Я подробно проанализировал процедуру тестирования и результат этого эксперимента в обсуждении. Почему я должен использовать селекторы cssSelector вместо XPath для автоматического тестирования? . Хотя этот эксперимент продемонстрировал, что каждая стратегия локатора в достаточной степени эквивалентна для разных браузеров, он не дает нам полной картины. Дэйв Хеффнер в другом обсуждении Css Vs. X Path, под микроскопомупоминалось, в тесте с конца до конца, было много других переменных при игре запуска Соус , браузер запуска и латентность и от тестируемого приложения. Неудачный вывод из этого эксперимента может заключаться в том, что один драйвер может быть быстрее другого (например, IE против Firefox ), хотя на самом деле это совсем не так. Чтобы ощутить разницу в производительности между cssSelector и XPath, нам нужно было копать глубже. Мы сделали это, запустив все с локального компьютера с помощью утилиты для тестирования производительности. Мы также сосредоточились на конкретном действии Selenium, а не на всем тестовом прогоне, и запускали все несколько раз. Я подробно проанализировал конкретную процедуру тестирования и результат этого эксперимента в обсуждении cssSelector vs XPath для селена . Но в тестах по-прежнему не хватало одного аспекта, а именно большего охвата браузером (например, Internet Explorer 9 и 10) и тестирования на более крупной и глубокой странице.

Дэйв Хеффнер в другом обсуждении Css Vs. X Path, Under a Microscope (Часть 2) упоминает, что для того, чтобы убедиться, что требуемые тесты выполняются наилучшим образом, нам нужно рассмотреть пример, демонстрирующий большую и глубокую страницу .

Испытательная установка

Чтобы продемонстрировать этот подробный пример, была установлена виртуальная машина Windows XP и установлен Ruby (1.9.3) . Также были установлены все доступные браузеры и эквивалентные им драйверы для Selenium. Для тестирования использовалась стандартная библиотека Ruby benchmark.

Код теста

require_relative 'base'
require 'benchmark'

class LargeDOM < Base

  LOCATORS = {
    nested_sibling_traversal: {
      css: "div#siblings > div:nth-of-type(1) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3)",
      xpath: "//div[@id='siblings']/div[1]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]"
    },
    nested_sibling_traversal_by_class: {
      css: "div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1",
      xpath: "//div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]"
    },
    table_header_id_and_class: {
      css: "table#large-table thead .column-50",
      xpath: "//table[@id='large-table']//thead//*[@class='column-50']"
    },
    table_header_id_class_and_direct_desc: {
      css: "table#large-table > thead .column-50",
      xpath: "//table[@id='large-table']/thead//*[@class='column-50']"
    },
    table_header_traversing: {
      css: "table#large-table thead tr th:nth-of-type(50)",
      xpath: "//table[@id='large-table']//thead//tr//th[50]"
    },
    table_header_traversing_and_direct_desc: {
      css: "table#large-table > thead > tr > th:nth-of-type(50)",
      xpath: "//table[@id='large-table']/thead/tr/th[50]"
    },
    table_cell_id_and_class: {
      css: "table#large-table tbody .column-50",
      xpath: "//table[@id='large-table']//tbody//*[@class='column-50']"
    },
    table_cell_id_class_and_direct_desc: {
      css: "table#large-table > tbody .column-50",
      xpath: "//table[@id='large-table']/tbody//*[@class='column-50']"
    },
    table_cell_traversing: {
      css: "table#large-table tbody tr td:nth-of-type(50)",
      xpath: "//table[@id='large-table']//tbody//tr//td[50]"
    },
    table_cell_traversing_and_direct_desc: {
      css: "table#large-table > tbody > tr > td:nth-of-type(50)",
      xpath: "//table[@id='large-table']/tbody/tr/td[50]"
    }
  }

  attr_reader :driver

  def initialize(driver)
    @driver = driver
    visit '/large'
    is_displayed?(id: 'siblings')
    super
  end

  # The benchmarking approach was borrowed from
  # http://rubylearning.com/blog/2013/06/19/how-do-i-benchmark-ruby-code/
  def benchmark
    Benchmark.bmbm(27) do |bm|
      LOCATORS.each do |example, data|
    data.each do |strategy, locator|
      bm.report(example.to_s + " using " + strategy.to_s) do
        begin
          ENV['iterations'].to_i.times do |count|
         find(strategy => locator)
          end
        rescue Selenium::WebDriver::Error::NoSuchElementError => error
          puts "( 0.0 )"
        end
      end
    end
      end
    end
  end

end

Полученные результаты

ПРИМЕЧАНИЕ . Выходные данные указаны в секундах, а результаты относятся к общему времени выполнения 100 выполнений.

В виде таблицы:

В форме диаграммы:

Хром :

Firefox :

Internet Explorer 8 :

Internet Explorer 9 :

Internet Explorer 10 :

Опера :

Анализ результатов

Chrome и Firefox явно настроены для более быстрой работы cssSelector .
Internet Explorer 8 - это набор cssSelector , который не работает, неконтролируемый обход XPath, который занимает ~ 65 секунд, и обход таблицы за 38 секунд без результата cssSelector для сравнения.
В IE 9 и 10 XPath в целом быстрее. В Safari это несложно, за исключением пары более медленных прогонов обхода с XPath . И через почти все браузеры, вложенный родственный Обход и ячейка таблицы обход сделан с помощью XPath является дорогостоящей операцией.
Это не должно вызывать особого удивления, поскольку локаторы хрупкие и неэффективные, и нам нужно их избегать.

Резюме

В целом есть два обстоятельства, при которых XPath заметно медленнее, чем cssSelector . Но их легко избежать.
Разница в производительности немного в пользу css-селекторы для браузеров, отличных от IE, и немного в пользу xpath для браузеров IE.

Мелочи

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

Answer 1

Я работаю с Selenium WebDriver 2.25.0 над многоязычным веб-приложением и в основном тестирую содержимое страницы (для разных языков, таких как арабский, английский, русский и т. Д.).

Для моего приложения, которое лучше по производительности, и убедитесь, что оно должно поддерживать все браузеры (например, IE 7,8,9, FF, Chrome и т. Д.).

Заранее благодарим за ценные предложения.

Answer 2

107

Селекторы CSS работают намного лучше, чем Xpath, и это хорошо задокументировано в сообществе Selenium. Вот несколько причин,

Механизмы Xpath различны в каждом браузере, поэтому делают их несовместимыми
IE не имеет собственного механизма xpath, поэтому selenium внедряет свой собственный механизм xpath для совместимости своего API. Следовательно, мы теряем преимущество использования встроенных функций браузера, которые по своей сути продвигает WebDriver.
Xpath имеет тенденцию становиться сложным и поэтому, на мой взгляд, его трудно читать

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

Вы можете прочитать блог Саймона здесь . Он также рекомендует CSS вместо Xpath.

Если вы тестируете содержимое, не используйте селекторы, зависящие от содержимого элементов. Это будет кошмар обслуживания для любого региона. Попробуйте поговорить с разработчиками и использовать методы, которые они использовали для экстернализации текста в приложении, такие как словари или пакеты ресурсов и т. Д. Вот мой блог, в котором это подробно объясняется.

редактировать 1

Благодаря @parishodak вот ссылка, которая предоставляет цифры, доказывающие, что производительность CSS лучше

нилеш
источник

7

Селекторы CSS не допускают текст. "содержит" не рекомендуется в CSS. Как я уже сказал выше, селекторы должны быть независимы от содержимого. Контент может находиться снаружи. Вы можете поговорить с разработчиками. Они должны были экстернализовать текст. В большинстве случаев у них есть словари для каждой локали. Таким образом, ключи в словарях такие же, но значения меняются в зависимости от локали. Вы можете использовать эти файлы для проверки содержимого. Обратите внимание, что вам нужно преобразовать собственные символы в символы ascii с помощью инструмента nativ2ascii из JDK. Я должен написать об этом блог. Я тестировал много мест, используя эту технику.

nilesh

1

@Chetan चेतन Я добавил ссылку на свой блог в ответ. Извините, это заняло некоторое время. Надеюсь, это вам поможет.

nilesh 07

8

@Nilesh: Я не согласен с вашим ответом. 1.) Механизмы CSS также различны в каждом браузере. Это не аргумент. 3.) Имея некоторый опыт, XPath очень прост для понимания и предлагает больше функциональных возможностей, чем CSS. Если вы ищете очень вложенный элемент, они оба сложны: XPath и CSS. По моему опыту, любой общий ответ на этот вопрос будет неправильным. Решение CSS / XPATH нужно принимать индивидуально. Первоначальный вопрос был о производительности. Ваш ответ в основном состоит из предположений и личного мнения. Настоящим доказательством будет ИЗМЕРЕНИЕ производительности и размещение результатов здесь.

Elmue

2

Очень хорошая статья, которая противоречит вашему первому предложению: «Селекторы CSS работают намного лучше, чем Xpath». Все не так просто, может быть даже наоборот. И: «IE не имеет собственного механизма xpath, поэтому selenium внедряет свой собственный механизм xpath для совместимости своего API». Здесь Selenium страдает ошибкой дизайна. Конечно, было бы лучше реализовать движок XPath на C ++ вместо java-скрипта. Но IE мертв, теперь приходит Edge. За всеми вопросами производительности нельзя забывать, что в CSS отсутствуют очень важные функции, такие как поиск текста элемента.

Elmue

2

elementalselenium.com/tips/32-xpath-vs-css предоставляет тесты, которые показывают, что css3 больше не работает значительно быстрее.

mc0e

Answer 3

7

Селекторы CSS не допускают текст. "содержит" не рекомендуется в CSS. Как я уже сказал выше, селекторы должны быть независимы от содержимого. Контент может находиться снаружи. Вы можете поговорить с разработчиками. Они должны были экстернализовать текст. В большинстве случаев у них есть словари для каждой локали. Таким образом, ключи в словарях такие же, но значения меняются в зависимости от локали. Вы можете использовать эти файлы для проверки содержимого. Обратите внимание, что вам нужно преобразовать собственные символы в символы ascii с помощью инструмента nativ2ascii из JDK. Я должен написать об этом блог. Я тестировал много мест, используя эту технику.

nilesh

Answer 4

1

@Chetan चेतन Я добавил ссылку на свой блог в ответ. Извините, это заняло некоторое время. Надеюсь, это вам поможет.

nilesh 07

Answer 5

8

@Nilesh: Я не согласен с вашим ответом. 1.) Механизмы CSS также различны в каждом браузере. Это не аргумент. 3.) Имея некоторый опыт, XPath очень прост для понимания и предлагает больше функциональных возможностей, чем CSS. Если вы ищете очень вложенный элемент, они оба сложны: XPath и CSS. По моему опыту, любой общий ответ на этот вопрос будет неправильным. Решение CSS / XPATH нужно принимать индивидуально. Первоначальный вопрос был о производительности. Ваш ответ в основном состоит из предположений и личного мнения. Настоящим доказательством будет ИЗМЕРЕНИЕ производительности и размещение результатов здесь.

Elmue

Answer 6

2

Очень хорошая статья, которая противоречит вашему первому предложению: «Селекторы CSS работают намного лучше, чем Xpath». Все не так просто, может быть даже наоборот. И: «IE не имеет собственного механизма xpath, поэтому selenium внедряет свой собственный механизм xpath для совместимости своего API». Здесь Selenium страдает ошибкой дизайна. Конечно, было бы лучше реализовать движок XPath на C ++ вместо java-скрипта. Но IE мертв, теперь приходит Edge. За всеми вопросами производительности нельзя забывать, что в CSS отсутствуют очень важные функции, такие как поиск текста элемента.

Elmue

Answer 7

2

elementalselenium.com/tips/32-xpath-vs-css предоставляет тесты, которые показывают, что css3 больше не работает значительно быстрее.

mc0e

Answer 8

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

Этот длинный пост состоит из двух разделов - сначала я сделаю доказательство того, что разница в производительности между ними составляет 0,1-0,3 миллисекунды (да, это 100 микросекунд ) , а затем я поделюсь своим мнением, почему XPath более мощный.

Разница в производительности

Давайте сначала займемся «слоном в комнате» - этот xpath медленнее, чем css.

С текущей мощностью процессора (читайте: все, что x86 произведено с 2013 года) , даже на виртуальных машинах browserstack / saucelabs / aws, и с развитием браузеров (читайте: все популярные за последние 5 лет) это вряд ли имеет место. Разработаны движки браузера, поддержка xpath едина, IE не используется (надеюсь, для большинства из нас) . Это сравнение в другом ответе цитируется повсюду, но оно очень контекстно - сколько из них запускают или заботятся об автоматизации против IE8?

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

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

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

Измерения

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

Цель - целевая страница 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; операция поиска повторяется 1000 раз. Результатом является общее время в секундах для 1000 повторений и среднее время для одной находки в миллисекундах.

Локаторы:

для xpath - «элемент div, имеющий это точное значение класса, где-то в DOM»;
css аналогичен - «элемент div с этим классом где-то в DOM».

Сознательно выбран, чтобы не перестраиваться; Кроме того, селектор класса указан в CSS как «второй по скорости после идентификатора».

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

Вот результат:

css total time 1000 repeats: 8.84s, per find: 8.84ms

xpath total time for 1000 repeats: 8.52s, per find: 8.52ms

Очевидно, что время нахождения довольно близко; разница составляет 0,32 миллисекунды . Не прыгайте «xpath быстрее» - иногда это так, иногда css.

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

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

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

css total time 1000 repeats: 8.60s, per find: 8.60ms

xpath total time for 1000 repeats: 8.75s, per find: 8.75ms

Разница 0,15 мс .

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

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

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

Теперь URL-адрес http://the-internet.herokuapp.com/tables; есть 2 теста.
Локаторы для первого - «Поиск элементов по идентификатору и классу»:

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

И вот результат:

css total time 1000 repeats: 8.24s, per find: 8.24ms

xpath total time for 1000 repeats: 8.45s, per find: 8.45ms

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

«Поиск элементов путем обхода»:

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

Результат:

css total time 1000 repeats: 9.29s, per find: 9.29ms

xpath total time for 1000 repeats: 8.79s, per find: 8.79ms

На этот раз это 0,5 мс (наоборот, xpath здесь оказался "быстрее").

Итак, 5 лет спустя (улучшенные движки браузеров) и сосредоточение внимания только на производительности локаторов (без таких действий, как сортировка в пользовательском интерфейсе и т. Д.), Та же тестовая площадка - практически нет разницы между CSS и XPath.

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

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

Тем не менее, уникальные и постоянные (например, не генерируемые автоматически) идентификаторы не всегда доступны, что подводит нас к вопросу «зачем XPath, если есть CSS?»

Преимущество XPath

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

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

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

Outro;)

Наконец, снова очень субъективно - какой выбрать?

ИМО, нет правильного или неправильного выбора - это разные решения одной и той же проблемы, и следует выбрать то, что больше подходит для работы.

Будучи «фанатом» XPath, я не стесняюсь использовать в своих проектах и то, и другое - черт возьми, иногда гораздо быстрее просто использовать CSS, если я знаю, что он отлично справится со своей работой.

Answer 9

Сколько узлов имеет страницу входа? Страницы входа обычно очень простые, поэтому вы могли заметить небольшую разницу.

pagep

Answer 10

Другие тесты производительности показывают гораздо большую разницу в разных браузерах.

pagep

Answer 11

1

На ваш первый вопрос - в ответе присутствует снимок экрана DOM, а страница является общедоступной и общедоступной. Для первого и второго, если вы внимательно прочитаете ответ, я повторил тот же тест, что и elementalselenium, одно из немногих доступных сравнений, которое довольно часто цитируется, с использованием тех же целей и локаторов, что и они, но только с более новыми браузерами на 5 лет. .

Тодор Минаков

Answer 12

3

@TodorMinakov БОЛЬШОЙ ПОЧТ !!! Я согласен с вами на 100%. Я также считаю, что синтаксис XPath также более естественен (по крайней мере, для меня), потому что он напоминает то, что мы все очень хорошо знаем. И это пути к файлам / папкам. Поэтому я думаю, что человеку с нулевым знанием CSS или XPath будет намного легче изучить XPath. Поскольку разница в производительности незначительна, я думаю, что кривая обучения заслуживает серьезного внимания.

hfontanez

Answer 13

1

Спасибо @hfontanez; отличная аналогия со структурой файловой системы, я об этом не подумал. Я должен немного не согласиться с простотой ввода - синтаксис XPath поначалу может быть немного пугающим, к тому же в нем есть некоторые подводные камни (например, индекс []после //) . Но после первого дня изучения и использования почти каждый пересекает критическую точку в кривой обучения :) (шаг в css, по общему признанию, проще, ИМХО) .

Тодор Минаков

Answer 14

Споры между cssSelector и XPath останутся одним из самых субъективных споров в сообществе Selenium . То, что мы уже знаем, можно резюмировать следующим образом:

Люди в пользу CSSSelector сказать , что он является более читаемым и быстрее (особенно при работе с Internet Explorer).
В то время как сторонники XPath рекламируют его способность перемещаться по странице (в то время как cssSelector не может).
Обход DOM в старых браузерах, таких как IE8, не работает с cssSelector, но подходит для XPath .
XPath может проходить вверх по DOM (например, от дочернего к родительскому), тогда как cssSelector может проходить только вниз по DOM (например, от родителя к дочернему)
Однако невозможность обхода DOM с помощью cssSelector в старых браузерах не обязательно плохо, поскольку это скорее показатель того, что ваша страница имеет плохой дизайн и может извлечь выгоду из некоторой полезной разметки.
Бен Бертон упоминает, что вам следует использовать cssSelector, потому что именно так создаются приложения. Это упрощает написание тестов, их обсуждение и поддержку других.
Адам Гоучер советует использовать более гибридный подход - сосредотачиваясь сначала на идентификаторах, затем на cssSelector , и используя XPath только тогда, когда он вам нужен (например , при переходе по DOM), и что XPath всегда будет более мощным для продвинутых локаторов.

Дэйв Хаффнер провел тест на странице с двумя таблицами данных HTML , одна таблица написана без полезных атрибутов ( ID и Class ), а другая с ними. Я подробно проанализировал процедуру тестирования и результат этого эксперимента в обсуждении. Почему я должен использовать селекторы cssSelector вместо XPath для автоматического тестирования? . Хотя этот эксперимент продемонстрировал, что каждая стратегия локатора в достаточной степени эквивалентна для разных браузеров, он не дает нам полной картины. Дэйв Хеффнер в другом обсуждении Css Vs. X Path, под микроскопомупоминалось, в тесте с конца до конца, было много других переменных при игре запуска Соус , браузер запуска и латентность и от тестируемого приложения. Неудачный вывод из этого эксперимента может заключаться в том, что один драйвер может быть быстрее другого (например, IE против Firefox ), хотя на самом деле это совсем не так. Чтобы ощутить разницу в производительности между cssSelector и XPath, нам нужно было копать глубже. Мы сделали это, запустив все с локального компьютера с помощью утилиты для тестирования производительности. Мы также сосредоточились на конкретном действии Selenium, а не на всем тестовом прогоне, и запускали все несколько раз. Я подробно проанализировал конкретную процедуру тестирования и результат этого эксперимента в обсуждении cssSelector vs XPath для селена . Но в тестах по-прежнему не хватало одного аспекта, а именно большего охвата браузером (например, Internet Explorer 9 и 10) и тестирования на более крупной и глубокой странице.

Дэйв Хеффнер в другом обсуждении Css Vs. X Path, Under a Microscope (Часть 2) упоминает, что для того, чтобы убедиться, что требуемые тесты выполняются наилучшим образом, нам нужно рассмотреть пример, демонстрирующий большую и глубокую страницу .

Испытательная установка

Чтобы продемонстрировать этот подробный пример, была установлена виртуальная машина Windows XP и установлен Ruby (1.9.3) . Также были установлены все доступные браузеры и эквивалентные им драйверы для Selenium. Для тестирования использовалась стандартная библиотека Ruby benchmark.

Код теста

require_relative 'base'
require 'benchmark'

class LargeDOM < Base

  LOCATORS = {
    nested_sibling_traversal: {
      css: "div#siblings > div:nth-of-type(1) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3) > div:nth-of-type(3)",
      xpath: "//div[@id='siblings']/div[1]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]/div[3]"
    },
    nested_sibling_traversal_by_class: {
      css: "div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1 > div.item-1",
      xpath: "//div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]/div[contains(@class, 'item-1')]"
    },
    table_header_id_and_class: {
      css: "table#large-table thead .column-50",
      xpath: "//table[@id='large-table']//thead//*[@class='column-50']"
    },
    table_header_id_class_and_direct_desc: {
      css: "table#large-table > thead .column-50",
      xpath: "//table[@id='large-table']/thead//*[@class='column-50']"
    },
    table_header_traversing: {
      css: "table#large-table thead tr th:nth-of-type(50)",
      xpath: "//table[@id='large-table']//thead//tr//th[50]"
    },
    table_header_traversing_and_direct_desc: {
      css: "table#large-table > thead > tr > th:nth-of-type(50)",
      xpath: "//table[@id='large-table']/thead/tr/th[50]"
    },
    table_cell_id_and_class: {
      css: "table#large-table tbody .column-50",
      xpath: "//table[@id='large-table']//tbody//*[@class='column-50']"
    },
    table_cell_id_class_and_direct_desc: {
      css: "table#large-table > tbody .column-50",
      xpath: "//table[@id='large-table']/tbody//*[@class='column-50']"
    },
    table_cell_traversing: {
      css: "table#large-table tbody tr td:nth-of-type(50)",
      xpath: "//table[@id='large-table']//tbody//tr//td[50]"
    },
    table_cell_traversing_and_direct_desc: {
      css: "table#large-table > tbody > tr > td:nth-of-type(50)",
      xpath: "//table[@id='large-table']/tbody/tr/td[50]"
    }
  }

  attr_reader :driver

  def initialize(driver)
    @driver = driver
    visit '/large'
    is_displayed?(id: 'siblings')
    super
  end

  # The benchmarking approach was borrowed from
  # http://rubylearning.com/blog/2013/06/19/how-do-i-benchmark-ruby-code/
  def benchmark
    Benchmark.bmbm(27) do |bm|
      LOCATORS.each do |example, data|
    data.each do |strategy, locator|
      bm.report(example.to_s + " using " + strategy.to_s) do
        begin
          ENV['iterations'].to_i.times do |count|
         find(strategy => locator)
          end
        rescue Selenium::WebDriver::Error::NoSuchElementError => error
          puts "( 0.0 )"
        end
      end
    end
      end
    end
  end

end

Полученные результаты

ПРИМЕЧАНИЕ . Выходные данные указаны в секундах, а результаты относятся к общему времени выполнения 100 выполнений.

В виде таблицы:

В форме диаграммы:

Хром :

Firefox :

Internet Explorer 8 :

Internet Explorer 9 :

Internet Explorer 10 :

Опера :

Анализ результатов

Chrome и Firefox явно настроены для более быстрой работы cssSelector .
Internet Explorer 8 - это набор cssSelector , который не работает, неконтролируемый обход XPath, который занимает ~ 65 секунд, и обход таблицы за 38 секунд без результата cssSelector для сравнения.
В IE 9 и 10 XPath в целом быстрее. В Safari это несложно, за исключением пары более медленных прогонов обхода с XPath . И через почти все браузеры, вложенный родственный Обход и ячейка таблицы обход сделан с помощью XPath является дорогостоящей операцией.
Это не должно вызывать особого удивления, поскольку локаторы хрупкие и неэффективные, и нам нужно их избегать.

Резюме

В целом есть два обстоятельства, при которых XPath заметно медленнее, чем cssSelector . Но их легко избежать.
Разница в производительности немного в пользу css-селекторы для браузеров, отличных от IE, и немного в пользу xpath для браузеров IE.

Мелочи

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

В чем разница между cssSelector и Xpath и что лучше с точки зрения производительности при кроссбраузерном тестировании?

Ответы:

редактировать 1

Разница в производительности

Измерения

Преимущество XPath

Outro;)

Испытательная установка

Код теста

Полученные результаты

Анализ результатов

Резюме

Мелочи