XPath примеры - шпаргалка для разбора страниц. Получить значение определенного span по классу
Само собой разумеется и во всех книгах проговаривают, что для нахождения элемента лучше всего и быстрее использовать локаторы id и name и, что характерно, основные примеры по использованию локаторов и по работе Selenium показывают именно с ними. Но в реальной жизни часто бывает так, что id элементов формируется динамически, а потому все привязки к нему бесполезны, class может иметь десятки представителей на странице, а name может отсутствовать. Как вы уже догадываетесь в этом случае нужно применять локаторы xpath и css. В данной статье я не собираюсь говорить о каком то превосходстве над css или сравнивать быстродействие, я лишь расскажу почему я использую именно xpath и как это нужно делать. Букв будет много, так как в свое время мне пришлось достаточно порыться в интернет, чтобы получить нужную мне информацию, я выкладываю все самое полезное, в надежде, что кому это поможет в использовании xpath-локаторов. Важно, что у тебя, мой читатель должно быть хоть небольшой представление о xpath, если его нет, то можешь .
Сначала о том, почему новички (и не только) не любят xpath:
- Со времен далекой, далекой Галактики, существует миф о том, что xpath во много раз медленнее css, что на данный момент времени не является правдой. Не знаю как обстояло дело раньше, но в наши дни я лично написал несколько тестов с использованием xpath и css и сравнивая их могу сказать, что никакого значительного преимущества нет, а порой даже xpath работает быстрее. Не собираюсь вступать в длительные баталии по поводу скорости, просто разница в несколько миллисекунд нельзя считать значительной, особенно при общей длительности УИ-тестов.
- Xpath неверно используют, во многом из-за того, что стандартные панели разработчика и плагины выдергивают xpath из страницы в совершенно непотребном виде, который неудобен и нечитаем. Потому у многих сложилось мнение, что xpath это тяжеловесная и непонятная ерунда.
- Нет или по меньшей мере мне не попался какой-нибудь вменяемый мануал по xpath, в основном предлагают ссылки на pdf файл где локаторы приведены всей кучей вместе с css, этакая выжимка, в которой я уверен мало кто разбирается просто из-за обилия информации.
А теперь о том, как обстоят дела на самом деле и в чем преимущества xpath, если его правильно использовать:
— он не уступает (или незначительно уступает) в скорости css
— он понятен и легко читаем, по нему можно понять о каком элементе идет речь
— он похож на язык программирования и его удобно использовать
— можно добраться до самых запрятанных элементов страницы, благодаря выстроенным цепочкам отношений
Итак, несколько правил использования xpath :
- Никогда не используй плагины или копирование xpath из кода страницы средствами браузера или веб-разработчика. Вот например как показывает одну ссылку плагин к Файрфокс: //header/div/ul/li/a . Разве из этой ссылки понятно, о каком элементе речь, что мы ищем? Ведь порой бывает, что взглянув на локатор в коде или в тексте исключения мы должны понять о каком элементе речь. Как это можно понять из такой строки? Я уже не говорю о том, что любой код, основанный на таких локаторах упадет при любом дуновении ветерка. Каждый раз, когда ты пишешь локатор подобный // div / div / ul / li (продолжать можно долго) в мире умирает что-то хорошее!!! Это, если хотите, говнокод тестировщика, который нужно выжигать каленым железом.
- Старайся написать xpath как можно короче и понятнее, используй его возможности и схожесть с языком программирования, чтобы и через месяц ты сам мог понять о каком элементе речь и что нужно поправить в случае изменения верстки
- Xpath’у время и место! Если есть возможность использовать id, name или внести в код id то сделай это!
- Вместо длинной цепочки слешей, как указано выше, используй отношения элементов: предок, потомок, сестринский элемент
- Можно и нужно использовать логические операции and, not , or
- Нормальный xpath всегда начинается с // и не использует фильтры с номером элемента в стиле (например // div )
Переходим к делу и практике, тот xpath, что указан выше (//header/div/ul/li/a ) на самом деле можно указать в виде //a . Согласись, что есть разница и в длине текста и в понимании его, ведь тут видно по тегу, что это ссылка и ее текст –Pricing. То есть ты можешь и сам найти этот элемент на странице визуально и в случае исключения с таким локатором сразу знаешь, что и где искать!
Теперь о тех командах, которые тебе реально пригодятся для написания грамотных и удобных локаторов:
Как видим id явно сгенерирован и привязаться к нему нельзя, класс тоже не внушает доверия, кроме того Selenium не разрешает использовать сложносоставные имена в локаторе className, но тут есть текст, который решает проблему: // a
- contains(параметр, искомое ) –возвращает элемент если он содержит искомое, знакомая команда не так ли? Ты ее видишь постоянно в языке программирования. Очень удобно использовать в связке с text() если составляем сложный локатор и не знаем точно всего текста, например: // div[@ class=’ buttons’ and contains(text(),’ Save’)] – как видишь, это некоторый элемент, который относится к кнопкам и на нем есть текст Save. Представь, что в твоем тестируемом веб-приложении есть несколько страниц, на которых есть кнопка сохранения, но с разными текстами –сохранить файл, сохранить диаграмму, сохранить отчет и так далее. Тебе не придется писать локаторы для них всех, хватит одного для всех кнопок сохранения и он описан выше. Обрати внимание на использовании в фильтре сразу двух условий!
Кроме того, очень полезная возможность – это искать элемент по одному из слов в названии класса.Пример:
Все решается вот так: //div , то есть мы ищем элемент, у которого в классе есть какое-то уникальное сочетание слов. Данная возможность contains очень помогает в самых разных ситуациях! Обрати внимание, что параметр и искомое идут через запятую, нельзя писать contains(text()=’smth’)
- starts- with(параметр, искомое) –все аналогично contains, только эта команда возвращает элементы начинающиеся с искомого. Если возвращаться к примеру с кнопками сохранения, то локатор можно переписать вот так // div[@ class=’ buttons’ and starts- with(text(),’ Save’)] у нас ничего не упадет, так как слово save обычно первое на кнопке и значит локатор опять же будет работать для всех кнопок сохранения. В общем это более узкая форма contains
Теперь пойдут команды отношения элементов (предок, родитель, ребенок, потомок, сестринский элемент), которые позволяют очень гибко найти практически любой элемент на странице при грамотном применении.
Формат использования //начальный элемент/отношение::тег(фильтр) конечного элемента. Обрати внимание на два двоеточия после отношения и не забывай после двоеточий указать тег, а лучше и фильтр искомого элемента, так как потомков может быть и много, а нам нужен какой-то конкретный.
Нам нужно ввести текст в input, но как видишь тут имеется ряд проблем – id динамический, классов и сгенеренных id со словом input на странице много, привязаться вроде не к чему. Но тут есть элемент с текстом, который уникален для страницы, вот к нему и прицепимся:
// div[ text()=’Тема’]/ preceding- sibling:: input — мы сначала находим уникальный элемент с текстом, а потом от него ищем предшествующий сестринский элемент, делая фильтр-уточнение, что ищем именно input. Еще пример:
Нам нужно кликнуть кнопку, на которой нет текста, только иконка, но как видишь у нее все те же проблемы с id плюс есть куча одноименных классов. Нас спасает то, что у предшествующего элемента есть уникальное название класса, вот от него и будем плясать: //div/following-sibling::div – находим элемент у которого есть уникальное слово в названии класса и от него уже ищем следующий сестринский элемент, с тегом div. Учитывай, что даже если сестринских последующих элементов с тегом div будет много вернется только самый первый!
То представим, что нам нужен непосредственно элемент с id=__vz4019, для всех на данной картинке он является родителем (parent) и поэтому его можно вытянуть через любой из них, например // div[ text()=’Тема’]/ parent:: div
Кстати, обращение к родительскому элементу, можно заменить двумя точками и без тега, вот так // div[ text()=’Тема’]/ ..
Так как все элементы в примере — дети, то можно любого из них найти от родителя вот так:
//div/child::input – находим родителя, а от него ищем ребенка с тегом input.
Нам нужна папка именно с определенным именем, но верстка организована так, что сам текст не содержится именно в элементе класса папка, поэтому нам надо найти сначала класс, а потом отфильтровать ту, у которой в потомках есть нужный текст:
// div[@ class=’ listitem Folder’]/ descendant:: span[ text()=’ Folder name’] – сначала находим класс папки, потом среди его потомков ищем тег span и нужный нам текст. Вы можете спросить –а почему просто по тексту не искать? Дело в том, что элементов с таким текстом на странице может быть больше одного, а нам нужна именно папка.
Кстати вместо descendant можно использовать двойной слеш // это означает -любой вложенный элемент. Пример выше превращается в
// div[@ class=’ listitem Folder’]/ / span[ text()=’ Folder name’]
- ancestor – предок, опять же отличающийся от parent тем, что может быть любой удаленности, то есть прадедушкой. Если возвращаться к предыдущему примеру, то найти элемент папки по тексту можно так // span[ text()=’ Folder name’]/ ancestor:: div[@ class=’ listitem Folder’]
Важно понимать, что можно, но крайне нежелательно использовать в одном локаторе несколько отношений, например:
// div[@ class=’ One]/ child :: div[@ class=’ Two’]/ descendant :: input[@ class=’ Three] . Такой локатор работать будет, но он уже сложно читается и скорее всего есть возможность подобрать другой, не нужно использовать такое без необходимости, помним правило номер 2. Совсем недопустимо использовать в одном локаторе обратные отношения то есть сначала искать потомка, потом его предка или наоборот.
Это все команды и отношения, которые вам пригодятся при написании локаторов! Да, есть еще и другие, вы можете с ними ознакомиться в мануале, прикрепленном в начале статьи, однако я их практически не использовал, а указанных в статье хватает мне и по сей день.
Итак, применяйте указанные команды, ищите правильные элементы, соблюдайте вышеозначенные правила и у вас не будет проблем с написанием грамотных локаторов, которые легко понять, прочесть, исправить. А главное вы поймете, что xpath очень удобен для написания локаторов к любым элементам.
Основы
XML имеет древовидную структуру. В документе всегда имеется корневой элемент (инструкция к дереву отношения не имеет). У элемента дерева всегда существуют потомки и предки, кроме корневого элемента, у которого предков нет, а также тупиковых элементов (листьев дерева), у которых нет потомков. Каждый элемент дерева находится на определенном уровне вложенности (далее - «уровень»). У элементов на одном уровне бывают предыдущие и следующие элементы.
Это очень похоже на организацию каталогов в файловой системе, и строки XPath, фактически, - пути к «файлам» - элементам.
Например, рассмотрим XHTML документ:
<html > <body > <div > Первый слой <span > блок текста в первом слое</ span > </ div > <div > Второй слой</ div > <div > Третий слой <span class = "text" > первый блок в третьем слое</ span > <span class = "text" > второй блок в третьем слое</ span > <span > третий блок в третьем слое</ span > </ div > <img / > </ body > </ html >
XPath-путь /html/body/*/span[@class] (полный синтаксис имеет вид /child::html/child::body/child::*/child::span ) будет соответствовать в нём двум элементам исходного документа - первый блок в третьем слое и второй блок в третьем слое .
Путь делится на шаги адресации, которые разделяются символом «косая черта» / . Каждый шаг адресации состоит из трех частей:
- ось (в данном примере child::), это обязательная часть;
- условие проверки узлов (в данном примере это имена элементов документа html, body, span, а символ * означает элемент с любым именем), также обязательная часть;
- предикат (в данном примере attribute::class), необязательная часть, заключаемая в квадратные скобки, в которой могут содержаться оси, условия проверки, функции, операторы (+, -, <, > и пр.).
Анализ ведется слева направо. Если первый символ это / , то путь адресации считается абсолютным (то есть от корня документа). При этом за узел контекста на первом шаге берется корневой элемент (html). Контекст - это некая точка отсчета, относительно которой рассчитывается следующий шаг адресации. Поэтому на каждом шаге адресации мы получаем новый набор узлов документа, и этот набор становится контекстом для следующего шага адресации.
На втором шаге адресации (child::body) контекстом становится html элемент. Ось child:: говорит о том, что необходимо найти все непосредственные потомки элемента html, а условие проверки body говорит о том, что в формируемый набор элементов нужно включить все узлы с именем body. В ходе второго шага адресации получаем набор узлов, состоящий всего из одного элемента body, который и становится элементом контекста для третьего шага.
Третий шаг адресации: child::* . Ось child:: собирает все непосредственные потомки элемента body, а условие проверки * говорит о том, что в формируемый набор нужно включить элементы основного типа с любым именем. В ходе этого шага получаем набор узлов, состоящий из трех элементов div и одного элемента img.
Четвёртый шаг адресации: child::span . Теперь контекстом является набор из четырёх элементов. И следующий набор узлов создается в четыре прохода (за четыре итерации). При первой итерации узлом контекста становится первый div. Согласно заданной оси child:: и правилу проверки span, в набор включаются непосредственные потомки div-а, имя которых равно span. При второй итерации в набор ничего добавлено не будет, так как у второго div нет потомков. Третья итерация добавит в набор сразу три элемента span, а четвёртая ничего не добавит, так как у элемента img нет потомков. Итак, в ходе проверки получен набор узлов, состоящий из четырёх элементов span. Это и будет контекстом для последующей обработки.
Следующего шага нет, поэтому будет производиться фильтрация отобранного набора. В этом и состоит отличие предикатов от шагов адресации. На каждом шаге адресации получаем новый набор, отталкиваясь от контекста, полученного на предыдущем шаге. В ходе же обработки предиката новый набор получается из текущего методом фильтрации, когда из набора исключаются узлы, не прошедшие условие проверки. В данном случае ось attribute:: говорит о необходимости проверить, если ли у узлов контекста атрибуты, а условие class требует оставить лишь те узлы, у которых задан атрибут с именем class. Фильтрация происходит за четыре итерации, но в окончательный набор попадают только два элемента span.
Оси
Оси - это база языка XPath.
- ancestor:: - Возвращает множество предков.
- ancestor-or-self:: - Возвращает множество предков и текущий элемент.
- attribute:: - Возвращает множество атрибутов текущего элемента.
- child:: - Возвращает множество потомков на один уровень ниже.
- descendant:: - Возвращает полное множество потомков.
- descendant-or-self:: - Возвращает полное множество потомков и текущий элемент.
- following:: - Возвращает необработанное множество, ниже текущего элемента.
- following-sibling:: - Возвращает множество элементов на том же уровне, следующих за текущим.
- namespace:: - Возвращает множество, имеющее пространство имён (то есть присутствует атрибут xmlns).
- parent:: - Возвращает предка на один уровень назад.
- preceding:: - Возвращает множество обработанных элементов исключая множество предков.
- preceding-sibling:: - Возвращает множество элементов на том же уровне, предшествующих текущему.
- self:: - Возвращает текущий элемент.
Существуют сокращения для некоторых осей, например:
- attribute:: - можно заменить на «@»
- child:: - часто просто опускают
- descendant:: - можно заменить на «.//»
- parent:: - можно заменить на «..»
- self:: - можно заменить на «.»
Дополнением к базе является набор функций, которые делятся на 5 групп:
Системные функции
node-set document (object, node-set?) Возвращает документ, указанный в параметре object. string format-number (number, string, string?) Форматирует число согласно образцу, указанному во втором параметре, третий параметр указывает именованный формат числа, который должен быть учтён. string generate-id (node-set?) Возвращает строку, являющуюся уникальным идентификатором. node-set key (string, object) Возвращает множество с указанным ключом (аналогично функции id для идентификаторов). string unparsed-entity-uri (string) Возвращает непроанализированный URI, если такового нет, возвращает пустую строку. boolean element-available (string) Проверяет, доступен ли элемент или множество, указанное в параметре. Параметр рассматривается как XPath. boolean function-available (string) Проверяет, доступна ли функция, указанная в параметре. Параметр рассматривается как XPath. object system-property (string) Параметры, возвращающие системные переменные, могут быть: * xsl: version - возвращает версию XSLT процессора. * xsl: vendor - возвращает производителя XSLT процессора. * xsl: vendor-url - возвращает URL, идентифицирующий производителя. Если используется неизвестный параметр, функция возвращает пустую строку. boolean lang (string) Возвращает истину, если у текущего тега имеется атрибут xml: lang, либо родитель тега имеет атрибут xml: lang и в нем указан совпадающий строке символ.Функции с множествами
- * - обозначает любое имя или набор символов, @* - любой атрибут
- $name - обращение к переменной, где name - имя переменной или параметра.
- - дополнительные условия выборки
- {} - если применяется внутри тега другого языка (например HTML), то XSLT процессор рассматривает содержимое фигурных скобок как XPath.
- / - определяет уровень дерева
Строковые функции
string string (object?) Возвращает текстовое содержимое элемента. По сути возвращает объединенное множество текстовых элементов на один уровень ниже. string concat (string, string, string*) Объединяет две или более строк number string-length (string?) Возвращает длину строки. boolean contains (string, string) Возвращает истину, если первая строка содержит вторую, иначе возвращает ложь. string substring (string, number, number?) Возвращает строку вырезанную из строки начиная с указанного номера, и если указан второй номер - количество символов. string substring-before (string, string) Если найдена вторая строка в первой, возвращает строку до первого вхождения второй строки. string substring-after (string, string) Если найдена вторая строка в первой, возвращает строку после первого вхождения второй строки. boolean starts-with (string, string) Возвращает истину если вторая строка входит в начало первой, иначе возвращает ложь. boolean ends-with (string, string) Возвращает истину если вторая строка входит в конец первой, иначе возвращает ложь. string normalize-space (string?) Убирает лишние и повторные пробелы, а также управляющие символы, заменяя их пробелами. string translate (string, string, string) Заменяет символы первой строки, которые встречаются во второй строке, на соответствующие позиции символам из второй строки символы из третьей строки. translate(«bar», «abc», «ABC») вернет BAr.Логические функции
- or - логическое «или»
- and - логическое «и»
- = - логическое «равно»
- < (<) - логическое «меньше»
- > (>) - логическое «больше»
- <= (<=) - логическое «меньше либо равно»
- >= (>=) - логическое «больше либо равно»
Числовые функции
- + - сложение
- − - вычитание
- * - умножение
- div - обычное деление (не деление нацело!)
- mod - остаток от деления
Ссылки
- XPath 1.0. Рекомендация W3C. (англ.)
- XPath 2.0. Рекомендация W3C. (англ.)
- XPath 2.1. Рекомендация W3C. (англ.)
- XPath учебник (нем.)
| Стандарты Консорциума Всемирной паутины | |
|---|---|
| Рекомендации |
Canonical XML CDF CSS DOM Geolocation API HTML ITS MathML OWL P3P PLS RDF (Schema) SISR SKOS SMIL SOAP SRGS SSML SVG SPARQL Timed Text VoiceXML WSDL XForms XHTML XHTML+RDFa XInclude XLink XML (Base Encryption Events Information Set namespace Schema Signature) XPath / 1.0 / 2.0 XPointer XProc XQuery XSL XSL-FO XSLT (элементы) XUP |
| Примечания |
XAdES XHTML+SMIL |
| Рабочие проекты | |
| Guidelines |
Web Content Accessibility Guidelines |
| Initiative |
Multimodal Interaction Activity Markup Validation Service Web Accessibility Initiative |
я решил озадачиться статьёй про XPath. Зачем мне нужен XPath? У меня есть задача организовать препроцессинг данных: Есть, например, набор операций, описываемых XML документом. Каждая операция — это либо веб-запрос либо запрос к базе данных. Мне необходимо поля из предшествующих операций, подставлять в последующие операции… Примерно так.
Попробую выразиться иначе. XPath — это язык запросов к XML, позволяющий выбирать из XML подмножества данных: как отдельные значения тегов и атрибутов, так и целые наборы значений. XPath запрос + соотвествующий API превращают любой XML документ в подобие базы данных, из которой можно делать выборки.
В моём случае, мне нужно было выбирать из XML некоторые поля, чтобы формировать другие XML документы, содержащие указанные поля. Конечно такая задача может быть решена и без XPath. Но тогда логика будет зашита в код программы. А XPath позволяет логику поиска внутри XML документов вынести во внешние конфигурационные данные. Т.е. для моей программы входными данными являются и XML документы и XPath выражения. В таком сочетании и проявляется мощь XPath.
P.S. Впоследствии, в дополнение к теоретической части, я написал пару постов с описанием практического применения XPath на Java:
Это предисловие. Приступаем к изучению. От добра-добра не ищут. На предмет XML-технологий пока самый интересный сайт: w3schools.org. Поэтому просто перевожу XPath tutorial оттуда.
-
- Применение XPath на Java
XPath используется для навигации по элементам и атрибутам XML документа. XPath занимает главенствующее место среди W3C XSLT стандартов. XQuery и XPointer — оба базируются на XPath expressions.
Что есть XPath?
- XPath — синтаксис для определения частей XML документа
- XPath использует path expressions для навигации в XML документах
- XPath содержит библиотеку стандартных функций
- XPath базовый элемент в XSLT
- XPath имеет статус W3C recommendation
XPath Path Expressions
XPath использует path expressions для выбора узлов или наборов узлов в XML документе. Path expressions сильно напоминают пути, которые вы используете при работе с традиционными компьютерными файловыми системами.
XPath Standard Functions
XPath включает более 100 встроенных функций. Эти функции для строковых значений, цифровых значений, сравнения времени и дат, манипуляции узлами и QName manipulation, манипуляции последовательностью, работы с boolean значениями и другие.
XPath является одним из ключевых моментов на дороге к пониманию XSLT. И на первых порах хочется получить какой-нибудь простой способ поэкспериментировать с ним, чтобы в деталях разобраться, как он работает. Способа такого, впрочем, не наблюдается. Приходится или качать совсем не бесплатные XML/XSLT редакторы, или довольствоваться статичными картинками с zvon.org . Может быть, я плохо искал. Но с моей колокольни все обстоит именно так. И когда передо мной в очередной раз встала задача «Объяснить XSLT», в голове и родилась идея крохотного сервиса. После того, как все заработало, было решено выкатить его для всеобщего пользования: наверняка не я один сталкивался с похожими проблемами.
Как это работает
Все просто до безобразия: вводим XML для экспериментов, пишем запрос и по ходу набора наблюдаем результат. Выглядит это примерно вот так:
Впрочем, чего разглядывать картинки, можно пойти и пощупать это все живьем .
Сервис, впрочем, может пригодиться не только в образовательных целях. Заковыристые запросы очень часто бывает удобно наблюдать визуально. Со своей задачей сервис справился. Буду рад, если поможет кому-нибудь еще.
