Введение
Selenium WebDriver является фактически стандартом для автоматизации end-to-end (E2E) тестирования веб-интерфейсов благодаря кроссплатформенной поддержке браузеров, развитой экосистеме инструментов и глубокой интеграции в конвейеры непрерывной интеграции и доставки (CI/CD). Однако ценность E2E-покрытия, обеспечивающего проверку системы в целом, сопряжена с высокими рисками нестабильности тестов. Основные источники этой нестабильности включают асинхронную природу Document Object Model (DOM), высокую динамику одностраничных приложений (SPA) и инфраструктурные факторы, такие как задержки в сети или нагрузка на серверы. В современных исследованиях отмечается, что стабильность тестов критически зависит от качества локаторов и стратегий ожидания элементов [1, 2]. Официальная документация Selenium подчеркивает, что ключом к созданию устойчивых тестов является применение корректных стратегий ожидания загрузки элементов и использования надежных методов их поиска.
Проблема надежности автоматизированных тестов является центральной в обеспечении качества программного обеспечения, и ее ключевым аспектом выступает феномен нестабильных, или так называемых flaky-тестов. Flaky-тест определяется как тест, который способен демонстрировать как успешный, так и неуспешный исход при абсолютно неизменном коде тестируемого приложения и самом коде теста. Эта недетерминированность напрямую подрывает возможность однозначной интерпретации результатов тестирования и разрушает доверие разработчиков к процессу непрерывной интеграции (CI/CD пайплайну) [3].
В последние годы наблюдается рост исследований, направленных на изучение причин возникновения flaky-тестов и методов повышения стабильности E2E-тестов в реальных промышленных проектах [4, 5]. Эти работы подчеркивают важность применения корректных стратегий ожидания, устойчивых локаторов и мониторинга метрик стабильности для обеспечения доверия к результатам автоматизированного тестирования.
Цель исследования – анализ коренных причин нестабильности Selenium-скриптов и разработка практических рекомендаций по повышению их устойчивости в промышленных проектах, включая стратегическое применение явных ожиданий, построение стабильных локаторов и мониторинг метрик стабильности тестов [1, 6, 7].
Материал и методы исследования
Исследование выполнено в формате систематизированного обзора литературы, направленного на обобщение современных подходов к повышению стабильности Selenium-скриптов и снижению числа нестабильных тестов в проектах с CI/CD-интеграцией. Поиск источников проводился с использованием ключевых слов на русском и английском языках: «нестабильные тесты», «flaky tests», «Selenium WebDriver reliability», «explicit waits», «stable locators», «CI/CD test automation». Отбор публикаций осуществлялся в международных и отечественных библиографических базах данных – ACM Digital Library, IEEE Xplore, SpringerLink, Scopus, eLibrary и CyberLeninka. В анализ включались работы, опубликованные в период с 2016 по 2025 г., что позволило учесть как фундаментальные исследования, так и практические решения последних лет, применяемые в промышленной автоматизации тестирования. В общей сложности рассмотрено 52 источника, из которых 15 были отобраны для детального анализа. В обзор включались статьи, содержащие результаты эмпирических исследований, статистику по нестабильности тестов, а также описания практических методик по повышению надежности тестовых сценариев. В поле внимания вошли публикации, посвященные выбору и настройке локаторов, управлению ожиданиями элементов, влиянию инфраструктурных факторов (задержек, загрузки браузера), а также интеграции стратегий стабилизации тестов в конвейеры непрерывной интеграции. Исключались источники, ограниченные модульным тестированием, не содержащие экспериментальной части или конкретных практических рекомендаций. Для подготовки настоящего систематического обзора использованы современные принципы, изложенные в протоколе PRISMA 2020 [8].
Результаты исследования и их обсуждение
Многочисленные эмпирические исследования систематически анализируют коренные причины нестабильности. Установлено, что основные источники нестабильности заключаются в проблемах асинхронности и состояний гонки (race conditions), связанных с некорректными стратегиями ожидания загрузки элементов в пользовательском интерфейсе. Эти выводы подтверждаются обзором T. Amjed, где UI- и инфраструктурные причины флейков классифицированы в многоголосом обзоре [4]. Дополнительно, анализ последних промышленных кейсов показывает, что использование data-атрибутов и CSS-селекторов позволяет добиться наибольшей устойчивости тестов без ущерба для покрытия [1]. Значительный вклад вносят нестабильные и хрупкие локаторы элементов, которые теряют свою актуальность при изменениях в структуре DOM-дерева [9]. Дополнительными факторами риска являются неконтролируемые зависимости от внешней инфраструктуры, состояния сети, сторонних сервисов, а также взаимное влияние тестов друг на друга при определенном порядке их выполнения. Следует особо подчеркнуть, что для UI-тестов, в особенности веб-приложений, совокупное негативное влияние этих факторов является наиболее выраженным по сравнению с другими уровнями тестирования [10].
Для эффективного управления проблемой нестабильных тестов необходима комплексная система метрик, позволяющая количественно оценивать уровень стабильности и эффективность применяемых мер. В таблице приведен комплексный подход к устранению нестабильности тестов, включая стратегические направления, конкретные меры и соответствующие метрики эффективности. Ряд современных исследований и практических руководств подчеркивает необходимость использования метрик Flaky Test Rate (FTR), Retry Rate и MTTR для объективной оценки стабильности тестов в CI/CD [4, 11]. В работе Olianas et al. (2025) демонстрируется, что визуализация FTR и Retry Rate в CI-дэшбордах повышает скорость реагирования команд на флейковые тесты [12].
Ключевые метрики включают:
‒ Flaky Test Rate (FTR): процент тестов, проявляющих нестабильное поведение за определенный период времени.
‒ Retry Rate: среднее количество повторных запусков, необходимых для получения стабильного результата.
‒ Mean Time To Detect (MTTD): среднее время обнаружения нестабильного теста.
‒ Mean Time To Repair (MTTR): среднее время устранения коренной причины нестабильности.
‒ False Positive Rate: процент ложных срабатываний в общем количестве падений.
‒ Регулярный мониторинг этих метрик позволяет объективно оценивать эффективность стратегий борьбы с нестабильностью и принимать обоснованные решения по оптимизации тестовых процессов.
Практические последствия распространения flaky-тестов носят крайне негативный характер и имеют серьезные операционные издержки. К ним относится значительное увеличение времени обратной связи (feedback time) для разработчиков из-за необходимости многократных перезапусков тестовой сборки для верификации результатов, а также рост числа ложных срабатываний (false positives), которые требуют бесполезной траты времени на анализ несуществующих дефектов. Это подтверждается отчетами индустриальных компаний по CI/CD, где массовые повторные прогоны приводят к значительной потере доверия к автотестам [4, 5].
Широко распространенная практика маскировки проблемы путем массового использования повторных прогонов приводит к накоплению большого количества избыточной статистики, которая затрудняет анализ реальных проблем. Как следствие, кульминацией этих проблем становится полная или частичная потеря доверия разработчиков к автотестам как к надежному инструменту.
Для обеспечения стабильности тестовых скриптов настоятельно рекомендуется системное использование механизмов явных ожиданий, таких как WebDriverWait в сочетании с ExpectedConditions (или их аналогами на выбранном языке программирования). Ключевой принцип заключается в том, чтобы дожидаться достижения конкретного целевого инварианта состояния элемента, а не произвольной задержки. К наиболее критически важным ожидаемым условиям относятся: visibilityOf (видимость элемента), elementToBeClickable (готовность элемента к взаимодействию), presenceOfElementLocated (присутствие элемента в DOM-дереве), invisibilityOf (исчезновение элемента) и stalenessOf («устаревание» элемента, например, при обновлении DOM). Категорически не рекомендуется смешивать данный подход с неявными ожиданиями (implicit waits) на уровне сессии, так как это приводит к непредсказуемому наложению таймаутов и существенно снижает детерминированность поведения теста [7].
Комплексный подход к устранению нестабильности тестов
|
Стратегическое направление |
Конкретные меры |
Метрики эффективности |
|
Стабильные локаторы |
Использование data-атрибутов (data-testid), приоритет CSS над XPath, избегание позиционных селекторов |
Снижение количества StaleElement ReferenceException [1, 7] |
|
Явные ожидания |
Применение WebDriverWait с ExpectedConditions, отказ от Thread.sleep() |
Уменьшение времени выполнения тестов [1, 13] |
|
Контролируемые ретраи |
Ограниченное количество попыток (2–3), экспоненциальная задержка между попытками |
Снижение Retry Rate [4, 11] |
|
Мониторинг и анализ |
Регулярный расчет FTR, ведение реестра flaky-тестов, анализ root-причин |
Снижение MTTR, уменьшение количества тестов в карантине [4, 12] |
Примечание: составлена автором на основе анализа литературных источников, официальной документации Selenium и собственных наблюдений в рамках исследования
Рекомендации по правильной настройке ожиданий подробно описаны в официальной документации Selenium и индустриальных best-practice руководствах [1, 2].
Пример корректной реализации на Java:
WebDriverWait wait = new WebDriverWait(driver, Duration.ofSeconds(10));
WebElement btn = wait.until(ExpectedConditions.elementToBeClickable(
By.cssSelector(“[data-testid=’checkout-submit’]”)));
btn.click();
К числу распространенных антипаттернов, которых следует избегать, относятся: использование «жестких» пауз (Thread.sleep), попытки взаимодействия с невидимыми элементами, ожидание лишь факта присутствия элемента в DOM без проверки его готовности к клику, а также смешение стратегий неявных и явных ожиданий, что ведет к непредсказуемым суммарным задержкам.
Стратегия повторных запусков реализуется на двух основных уровнях: локально на уровне тестового фреймворка и глобально на уровне конвейера CI/CD. На уровне фреймворка для Python-проектов, использующих pytest, применяется плагин pytest-rerunfailures с указанием количества повторов (--reruns) и, опционально, задержки между ними через конфигурацию в pytest.ini. В экосистеме Java для TestNG типичным решением является реализация интерфейса IRetryAnalyzer или использование специализированных listener’ов для автоматизации прогонов.
Крайне важен принцип ответственного применения данной стратегии. Прогоны позволяют смягчить «шум» от случайных флейков, но они не должны маскировать реальные дефекты в коде. Это подтверждается анализом причин флейковости и практических рекомендаций по их смягчению, а также в обзорах по best-practice масштабируемой автоматизации, где подчеркивают ответственность за настройку ретраев и ограничение их использования [2, 4]. Для оценки влияния внешних факторов на проявление флейков и корректной интерпретации повторов полезно учитывать результаты экспериментов по влиянию вычислительных ресурсов [11]. Кроме того, исследования по анализу UI-flaky тестов рекомендуют обязательно фиксировать нестабильные тесты (с помощью меток или помещения в карантин) и проводить их триаж и root-cause анализ до того, как ретраи станут повсеместной практикой [14]. Необходимо обязательно фиксировать факт нестабильности теста (через систему меток или карантин), собирать статистику по срабатываниям, ограничивать максимальное количество попыток (N) и использовать экспоненциальную задержку (back-off) между ними, а также проводить постоянный триаж и анализ коренных причин флейковости.
Выбор и конструирование устойчивых локаторов базируется на нескольких ключевых принципах. Наивысший приоритет имеют стабильные и уникальные атрибуты элемента: в первую очередь ID (при условии его гарантированной стабильности), а затем CSS-селекторы, основанные на неизменяемых атрибутах. Наиболее эффективной практикой является включение в продуктовый код специальных атрибутов-хуков для тестирования (таких как data-testid или data-qa), что полностью развязывает тест от изменений в верстке или стилях. Следует избегать сложных XPath-выражений, жестко завязанных на структуру DOM-дерева и позиционные индексы; допускается использование лишь относительно коротких XPath, построенных от стабильных «якорных» элементов [7].
Данные рекомендации напрямую поддержаны официальной документацией Selenium и best-practice руководствами ведущих индустриальных провайдеров.
Корректная настройка временных параметров является необходимым компонентом стабильности. Необходимо явно и адекватно настраивать таймауты загрузки страницы (pageLoadTimeout) и выполнения асинхронных скриптов (scriptTimeout). В сценариях, предполагающих динамическое обновление интерфейса (например, после AJAX-запроса или навигации), следует избирательно использовать ожидание условия stalenessOf(element) по отношению к старому элементу непосредственно перед попыткой поиска его обновленной версии в DOM. Это гарантирует, что последующие операции будут выполняться с актуальным состоянием элемента, а не с его устаревшей ссылкой, что предотвращает классические ошибки типа StaleElementReferenceException.
Для устойчивого управления качеством тестирования и достижения предсказуемости процессов непрерывной интеграции необходимы операциональные и объективно измеряемые метрики. Ключевой количественной мерой является Flake Rate (FR) – процент запусков, в которых тест демонстрировал нестабильное поведение, вычисляемый как отношение числа флейковых исходов к общему числу запусков, умноженное на 100 %. Альтернативной оценкой может служить Flakiness Rate, определяемый как доля неконсистентных результатов на заданном интервале наблюдения, методология которого варьируется в зависимости от поставщика аналитики. Для глубинного анализа необходимо отслеживать Failure Rate применительно именно к флейковым тестам, а также строить тренды проявления нестабильности в разрезе отдельных тестов, модулей или компонентов системы, что поддерживается современными системами CI-телеметрии.
Метрика MTTR-test-flake (Mean Time To Repair) отражает среднее время, затрачиваемое на устранение причины флейка или перевод теста в карантин с момента его обнаружения, что характеризует скорость реакции команды. Retry ratio, или среднее количество повторных запусков, необходимое для достижения успешного прохождения тестов, служит индикатором общей стабильности пайплайна; его рост является четким сигналом деградации надежности. Quarantine count, или количество тестов, временно исключенных из основного прогона, также требует мониторинга. Длительное нахождение теста в карантине без анализа и устранения первопричин указывает на системные риски, которые маскируются, а не решаются. Современные исследования подчеркивают необходимость регулярного анализа этих метрик в контексте CI/CD, поскольку именно визуализация MTTR и Retry Ratio позволяет оперативно выявлять деградацию стабильности пайплайна [2, 13].
Для стратегического планирования тестового покрытия критически важна метрика Coverage-vs-Stability, анализирующая соотношение доли end-to-end тестов к модульным и интеграционным, а также их соответствующий вклад в общий Flake Rate; это позволяет следовать рекомендациям по сокращению доли «тяжелых» E2E-тестов, вносящих наибольший вклад в нестабильность. Подобные подходы активно применяются в промышленной практике крупных компаний, где осуществляется приоритизация тестов на основе показателя Coverage-vs-Stability [12, 15].
Все перечисленные метрики должны собираться автоматически непосредственно в процессе CI (с использованием build scans или дашбордов) и быть доступными для детального анализа с декомпозицией по типам тестов, используемым фреймворкам, компонентам системы и тестовым окружениям. Для автоматизированного сбора таких показателей используются встроенные средства CI-платформ (например, Jenkins Build Scans, GitLab Analytics, Azure DevOps Insights) а ключевые метрики (FR, MTTR-flake, Retry Ratio, Quarantine Count) должны регулярно отображаться на дашбордах и анализироваться командами на совещаниях по качеству для своевременного принятия корректирующих действий [14, 15].
Для системного повышения стабильности автотестов командам рекомендуется придерживаться следующих принципов [16]. При проектировании тестов необходимо использовать исключительно явные ожидания (explicit waits), настроенные на конкретные и проверяемые инварианты состояния пользовательского интерфейса (например, кликабельность, видимость), и полностью избегать смешения стратегий неявных (implicit) и явных ожиданий в рамках одной сессии. Краеугольным камнем устойчивости является применение стабильных локаторов, поэтому для этого целесообразно внедрять в продуктовый код специализированные атрибуты (такие как data-testid или data-qa) для ключевых элементов, что обеспечивает полную независимость тестов от изменений в верстке, и избегать использования хрупких XPath-выражений, зависящих от абсолютной позиционной структуры DOM. Инженерия тестовых окружений должна включать эмуляцию реалистичных сетевых условий (через DevTools Protocol) и обеспечение контроля над ресурсами (CPU, память) раннеров в CI-системе для минимизации внешнего шума.
В результате тестовый контур становится не только технически устойчивым, но и управленчески предсказуемым, что напрямую снижает риск сбоев в поставке продукта.
Конфликт интересов
Библиографическая ссылка
Кочетов Д.О. АНАЛИЗ НАДЕЖНОСТИ SELENIUM-СКРИПТОВ В РЕАЛЬНЫХ ПРОЕКТАХ // Международный журнал прикладных и фундаментальных исследований. 2025. № 11. С. 39-44;URL: https://applied-research.ru/ru/article/view?id=13771 (дата обращения: 14.12.2025).
DOI: https://doi.org/10.17513/mjpfi.13771