Каким способом будешь находить локатор какого-нибудь элемента?

Поиск и выбор локаторов элементов в автоматизации тестирования

Как опытный QA Automation Engineer, я подхожу к поиску локаторов системно и с приоритетом надежности. Мой процесс включает несколько этапов и стратегий, которые минимизируют хрупкость автотестов.

Основная стратегия выбора: приоритет типов локаторов

Я всегда стремлюсь использовать локаторы в следующем порядке предпочтения (от наиболее надежных к наименее):

1. ID — уникальный идентификатор, самый стабильный и быстрый.
2. Name — часто используется для форм и также достаточно устойчив.
3. CSS Selector — мощный, гибкий и обычно быстрее XPath в современных браузерах.
4. XPath — максимальная гибкость, но может быть хрупким и медленнее.
5. Class Name, Tag Name, Link Text — используются, когда другие варианты недоступны или для конкретных задач (например, поиск по тексту ссылки).

Процесс поиска и анализа локатора на практике

Когда мне нужно найти локатор для элемента, я действую по следующему алгоритму:

• Визуальный осмотр в DevTools: Открываю инструменты разработчика браузера (F12), нахожу элемент с помощью Inspector, анализирую его HTML. Смотрю на наличие атрибутов id, name, data-testid или других уникальных data-* атрибутов.
• Проверка уникальности: Найдя потенциальный атрибут (например, id="submitBtn"), проверяю его уникальность на всей странице через поиск в DevTools (Ctrl+F в Elements tab). Локатор должен находить ровно один элемент.
• Выбор устойчивого атрибута: Отдаю предпочтение атрибутам, которые с меньшей вероятностью изменятся при рефакторинге фронтенда. Идеальны специальные атрибуты для тестирования, например data-qa или data-testid, которые команда фронтенда добавляет по договоренности.
• Построение CSS Selector: Если нет уникальных атрибутов, строю CSS Selector, комбинируя классы, атрибуты и иерархию. Стараюсь избегать излишней вложенности.

  /* Плохо: хрупкий и перегруженный */
  div.container > div.row > div.col-md-6 > form > button.btn-primary
  
  /* Лучше: используем уникальный класс или атрибут */
  button.submit-button
  button[type='submit'][data-action='save']
  

• Использование XPath как крайняя мера: Прибегаю к XPath, когда CSS не справляется, например, для поиска по тексту или сложной иерархии. Избегаю абсолютных путей (/html/body/div...) и использую относительные, с упором на уникальные атрибуты.

  // Относительный путь с атрибутом - хорошо
  //button[@id='loginBtn']
  
  // Поиск по тексту (если текст стабилен) - осторожно
  //*[text()='Сохранить']
  
  // Использование contains для частичного совпадения
  //button[contains(@class, 'primary')]
  

Инструменты и расширения для помощи

Для ускорения процесса я использую:

• SelectorsHub, ChroPath — плагины для браузера, которые предлагают и проверяют локаторы (CSS и XPath).
• Встроенный Console браузера — для быстрой проверки работоспособности локатора прямо на странице:

  // Проверка CSS Selector
  document.querySelectorAll("button.submit-button").length
  
  // Проверка XPath (в Chrome)
  $x("//button[@data-qa='submit']")
  

Критерии "хорошего" локатора

Мой итоговый выбор всегда должен соответствовать критериям:

• Уникальность — находит один и только один элемент.
• Устойчивость — не зависит от изменений в структуре DOM, не связанных с этим элементом.
• Читаемость — понятен коллегам при ревью кода.
• Производительность — CSS обычно предпочтительнее XPath по скорости.

Пример полного цикла анализа

Допустим, мне нужно найти кнопку "Войти".

1. В DevTools вижу: <button class="btn auth-btn primary" data-testid="login-submit">Войти</button>.
2. Приоритет 1: Уникальный data-testid="login-submit" — идеально! Проверяю в консоли: document.querySelectorAll('[data-testid="login-submit"]').length → возвращает 1. Это лучший выбор.
3. Альтернатива: Если бы data-testid отсутствовал, рассмотрел бы CSS по классам: button.auth-btn.primary. Проверил бы уникальность.
4. Крайний случай: Если бы классы были неуникальны, построил бы XPath, использующий текст как последний вариант: //button[text()='Войти'], с оговоркой в комментарии к коду о потенциальной хрупкости.

В итоге, в Page Object я бы записал это так:

// Пример на Java + Selenium WebDriver с использованием стабильного data-testid
public class LoginPage {
    private final WebDriver driver;

    @FindBy(css = "[data-testid='login-submit']")
    private WebElement loginButton;

    public void clickLoginButton() {
        loginButton.click();
    }
}

Такой системный подход обеспечивает долгосрочную стабильность автотестов и снижает затраты на их поддержку.