Поиск оптимальных локаторов для начинающих

Что такое локаторы (краткий ликбез)

Локатор — это путь к элементу в интерфейсе, с помощью которого автоматизированный тест (автотест) сможет его найти. Локаторы используются в автотестах, имитирующих работу пользователя в интерфейсе, в любых системах, но мы сегодня будем говорить только о web-системах. Для других систем виды локаторов будут другими, но к ним можно применять тот же подход поиска, как и в вебе. 
Локаторы подразделяют на простые и сложные. Простые локаторы называются так, потому что они соответствуют простым атрибутам элементов: id, name, class и др. В сложных локаторах используются совокупности атрибутов или близлежащие элементы. В вебе 2 вида таких локаторов: css и xpath. 

Оптимальный локатор

Найти локатор элемента — половина задачи, куда сложнее найти самый оптимальный. Почему нельзя просто взять первый попавшийся локатор, если тест все равно зеленый? Автотесты пишут для того, чтобы переиспользовать их много раз. Если локаторы будут не очень хорошими, то при частых изменениях системы они быстро становятся неактуальными, и их приходится переписывать. Помимо этого, сами тесты будут падать, не доходить до нужных проверок,и можно пропустить критичную ошибку. Чтобы такого не было — ищем оптимальный локатор.
Какой локатор будем считать оптимальным?

Во-первых, он должен однозначно определять наш элемент, т.е. должен быть уникальным в пределах страницы (экрана). Конечно, иногда нам нужно найти группу однотипных элементов (например, разные элементы списка), но даже в этом случае мы ищем локатор, позволяющий найти только эти элементы и никакие больше.  
Во-вторых, в нем должно упоминаться как можно меньше соседних элементов. Таким образом, мы и обеспечиваем стабильность: соседние элементы могут часто меняться, а значит, чем их меньше в локаторе, тем реже нам придется что-то в локаторе менять. 
В-третьих, хороший локатор помогает ориентироваться в автотесте, т.е. нужно использовать такие атрибуты, которые что-то говорят об элементе. Чтобы мы только взглянули на локатор и сразу поняли, что это за элемент. Конечно, это условие выполняется реже всего, но будем к этому стремиться. 
И тут я сразу хочу предостеречь желающих использовать в локаторе видимый текст элемента. Вроде бы, что может лучше говорить о назначении элемента, чем его текст? Это конечно да, только вот все то, что видит конечный пользователь, меняется гораздо чаще, например, потому что так красивее, понятнее и сильнее привлекает внимание. Конечно, если совсем не за что зацепиться при составлении локатора, можно использовать текст.

Как подбирать локатор

Первым делом нужно открыть инструменты разработчика в браузере и посмотреть на верстку страницы (в браузере Chrome горячая клавиша F12). Выбираем на странице элемент, для которого будем строить локатор, и приступаем к анализу.
Алгоритм поиска локатора будет следующим:

1. Сначала ищем у элемента атрибут id или name и убеждаемся, что он уникален и не меняется. Эти атрибуты наиболее точно подходят под описание оптимального локатора, но иногда их делают динамическими, т.е. при обновлении страницы значение этих атрибутов не меняется.

Например, у текстового поля (input) есть и id, и name — комбо, можем использовать любой атрибут:

2. Если id и name нет, продолжаем анализировать другие атрибуты элемента. Часто разработчики добавляют свои уникальные атрибуты. Здесь также можно присмотреться и к атрибуту class элемента (если он есть), но помним, что классы далеко не всегда уникальны и могут часто меняться. В случае с классом достаточно простого локатора, но если это нестандартный атрибут — составляем css или xpath.
На примере ниже — разработчики добавили атрибут data-test для целей тестирования:

3. Элемент совсем ничем не примечателен? Переходим к элементу на уровень выше (родителю) и повторяем пункты 1 и 2. Тут уже простым локатором точно не обойтись, придется составлять сложный. 

4. У родителя опять ничего примечательного нет, куда смотреть дальше? Поднимаемся еще выше, смотрим всех предков элемента (элементов выше уровнем) в поиске уникальных атрибутов. Тут возникает два вопроса: когда остановиться и какие элементы потом включить в локатор. Каждый элемент находится внутри какого-то блока, а тот еще в каком-то блоке. «Подниматься» по предкам мы будем до тех пор, пока не достигнем того блока, который явно отображается на странице как бы “снаружи” нашего элемента. Всех тех предков, что мы отмели по этому пути, просто исключаем из локатора, они не влияют на поиск элемента.
Предположим, что нам нужно составить локатор строки ввода для поиска. Элемент для ввода текста (input) никакими атрибутами не выделяется. Начинаем подниматься выше — опять нет уникальных значений атрибутов. Поднимаемся еще выше, пока не доходим до предка 3, и видим там уникальный класс, сообщающий нам о назначении блока.

А теперь посмотрим, как этот div выглядит в интерфейсе: он определяет весь блок поиска на странице.

5. Так и не нашли локатор, начинаем шерстить по соседям (элементам, расположенным рядом с искомым на одном уровне) и потомкам (элементам внутри искомого), опять повторяя шаги 1 и 2. Здесь стараемся не уходить далеко от искомого элемента, т.к. такой локатор может быть самым нестабильным.
Например, у элемента чекбокса, на который можно кликнуть (span), нет никаких уникальных атрибутов. Зато у его соседа (input) есть уникальный атрибут data-show-special-first.

Дополнительно

Что делать, если совсем не за что зацепиться, и хороший локатор так и не был найден? Можно (и даже нужно) сходить к разработчикам и попросить их добавить какие-то идентификаторы элементам. Это вообще лучше сделать сразу, как пункты 1 и 2 не сработали. Если и здесь не получилось, придется смириться и составлять локаторы из того, что есть.
И самый частый вопрос, который задают начинающие автоматизаторы — что лучше: css или xpath локатор? Выбирайте тот, который вам удобнее. Оба вида локаторов взаимозаменяемы в большинстве случаев, но у xpath чуть больше возможностей. 

Метки
#Тестирование ПО (3)Android (1)Cache (1)Cookie (1)courses (1)css (1)HR (1)iOS (2)istqb (1)ISTQB FL (1)IT (2)java (1)Jedi Point (12)JSON (1)kaizen (2)pairwise (1)QA (25)QualityLab (1)REST API (1)selenium (1)SOAP UI (1)SOAPUI (1)softskills (1)softwaretesting (1)SQA Days-25 (1)sql (5)TestSuites (1)usability (2)web (1)XML (1)xpath (1)Анна Палей (1)БАГИ (1)Исследовательское тестирование (2)Истории поинт (10)История успеха (1)Команда разработки (1)Курс тестирования для начинающих (1)Кэш (1)Лаборатория Качества (1)Мнемоники (1)Мнемоники в тестировании (1)Наталья Руколь (1)Нина Агеева (4)ПОИНТ (43)ПРомо-вебинар (1)Подготовка к istqb (1)Роман Буданов (3)Сессионное тестирование (1)Скриншот (3)ТЗ (1)Таблица решений (1)Тестирование (27)Тестирование ПО (5)Тест менеджмент (2)Тренер (12)Туры (1)автоматизация (2)автотесты (1)алгоритмы (1)баг (1)багнапродакшене (1)безопасность (1)бесплатный вебинар (1)введение в тестирование (1)граничные значения (1)декомпозиция (1)домашки (1)займемсяпоинтом (1)игры (1)идеальный мир (1)интернет (1)истории выпускников (10)как надо тестировать (2)комбинаторика (1)конференция (2)котик (1)курс для начинающих тестировщиков онлайн (1)лайфхак (1)минутка юмора (1)мобилки (3)мобильное тестирование (4)настройка мозгов (1)начать карьеру (1)начать карьеру в IT (1)начинающий тестировщик (8)негативное тестирование (2)обучение тестированию (11)ограничения (1)организация тестирования (1)персонажи (1)планирование (1)постановка мозгов (2)работа над ошибками (1)рабочий процесс (1)радиоСаня (1)разработчик (1)режим разработчика (3)резюме (1)сертификация ISTQB FL (1)скринкаст (1)смена работы (2)сопроводительное письмо (1)стать тестировщиком (1)стратегия (1)тайм-менеджмент (1)тест-анализ (1)тест-кейс (1)тест дизайн (3)тестировани (1)тестирование usability (2)тестирование безопасности (1)тестирование веб (2)тестирование игр (3)тестирование мобильных приложений (1)тестировщик (6)тесткейс (1)удаленная работа (1)улучшайзинг (1)ученик (2)фреймворки (1)чеклист (4)чит-листы (1)чит лист (2)что должен делать тестировщик (1)ятренерпоинт (1)
С 19.10 по 5.01, ОНЛАЙН Зарегистрироваться