ИМИТАЦИЯ РЕАЛЬНОГО ПОВЕДЕНИЯ ПОЛЬЗОВАТЕЛЯ В АВТОМАТИЗИРОВАННЫХ ТЕСТАХ

SIMULATION OF REAL USER BEHAVIOR IN AUTOMATED TESTS

Ilya Kubarev

master’s student, Department of Telecommunication Systems and Information Security, Russian New University,

Russia, Moscow

Evgenia Stepanova

scientific supervisor, candidate of Sciences in Pedagogics, associate professor of the Department of Information Systems in Economics and Management, Russian New University,

Russia, Moscow

АННОТАЦИЯ

В данной статье рассматриваются методы повышения надежности автоматизированных UI-тестов на веб-интерфейсах с помощью имитации реального поведения пользователя. Описывается проблема ненадежности UI-тестов, написанных с применением фреймворка Selenium WebDriver, и предлагается подход к ее решению путем приближения действий теста к действиям реального пользователя. В основной части анализируются три ключевых метода имитации пользовательского взаимодействия: прокрутка страницы, постепенный ввод текста (с паузами между символами) и вставка случайных пауз между действиями. Приведено теоретическое обоснование каждого метода и примеры того, как такие приемы позволяют снизить количество ложных срабатываний тестов. Анализ научной литературы позволил оценить эффективность данного подхода.

ABSTRACT

This article discusses methods for improving the reliability of automated UI tests on web interfaces by simulating real user behavior. The problem of unreliability of UI tests written using the Selenium WebDriver framework is described, and an approach to solving it is proposed by approximating the actions of the test to the actions of a real user. The main part analyzes three key methods of simulating user interaction: scrolling a page, gradually entering text (with pauses between characters), and inserting random pauses between actions. The theoretical justification of each method and examples of how such techniques can reduce the number of false positives of tests are given. The analysis of scientific literature allowed us to evaluate the effectiveness of this approach.

Ключевые слова: автоматизированное тестирование, UI-тесты, Python, Selenium WebDriver, эффективность.

Keywords: automated testing, UI-tests, Python, Selenium WebDriver, efficiency.

Автоматизированные UI-тесты широко применяются для проверки веб-приложений, позволяя имитировать действия пользователя в браузере. Популярный фреймворк Selenium предоставляет большой набор возможностей для имитации действий пользователя в различных браузерах, что, фактически, сделало его стандартом для end-to-end тестирования интерфейса веб-приложений. Однако, одной из основных проблем при таком тестировании является ненадежность тестов, то есть ситуация, когда результаты выполнения теста непостоянны, и тест может то проходить, то падать без изменения проверяемого функционала. Подобные нестабильные тесты называют «flaky-тестами» [1]. Их наличие серьезно затрудняет процесс непрерывной интеграции и доставки программного обеспечения.

Ненадежность UI-тестов выражается в ложноположительных сбоях: тест останавливается, хотя в приложении нет реальной ошибки. Такие обманчивые остановки разрушают однозначную связь между результатами тестов и качеством кода, вызывая недоверие к автотестам. Это ведет к бесполезной трате ресурсов, задержкам в релизах и снижению эффективности процесса разработки. Как отмечают исследователи, появление таких flaky-тестов стало заметной проблемой: по данным Google, около 16% всех автотестов являются нестабильными, а 1 из 7 тестов периодически падает не из-за ошибок в коде [1]. Таким образом, проблема ненадежности автоматизированных тестов носит массовый характер и привлекает внимание инженеров по качеству.

Причины появления данных flaky-тестов разнообразны. UI-тесты выполняются во взаимодействии с браузером и фронтендом приложения, где большое значение имеют асинхронность событий и особенности окружения. Частые причины нестабильности включают некорректное ожидание загрузки элементов, зависимости от окружения, например, различия в скорости, версии браузера и так далее, проблемы самих тестовых сценариев, их логики и другое.

Анализ 235 реальных случаев UI-тестов, содержащих в себя flaky-тесты, показал, что около половины из них связаны с неправильной синхронизацией и ожиданием в тестах, а также с загрузкой анимаций [2]. То есть значительная доля ложных срабатываний происходит из-за того, что автоматизированный скрипт выполняет действия слишком быстро или не дожидается полной загрузки интерфейса.

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

В Selenium для автоматического прокручивания страницы часто используют JavaScript-команду scrollBy с указанием определенного числа пикселей, или scrollIntoView для прокрутки до определенного элемента. Такой подход обеспечивает точное отображение элемента на экране, так как браузер успевает отрисовать и инициировать связанные с ним объекты.

Стоит отметить, что избыточная прокрутка может немного увеличить время выполнения теста, особенно если страница длинная. Однако как правило, прокручивать имеет смысл только до нужных элементов. Этот метод эффективно устраняет ошибки вида «элемент не виден», но не решает всех проблем синхронизации.

Автоматизированный ввод текста через Selenium (sendKeys) обычно происходит гораздо быстрее, чем ввод вручную на клавиатуре. Скрипт может за миллисекунды заполнить текстовое поле целой строкой. В некоторых случаях такой мгновенный ввод приводит к тому, что приложение не успевает обработать события ввода. Например, поле с мгновенной проверкой ввода может не отреагировать, если все символы были введены почти одновременно. Кроме того, сверхбыстрый ввод может вызвать подозрение у механизмов защиты от ботов – некоторые веб-приложения отслеживают скорость печати и при слишком быстром вводе символов может требоваться прохождение специального текста Тьюринга (CAPTCHA) или же текущая сессия заблокируется.

Справиться с этим видом проблем способна имитация естественного набора текста, то есть ввод символов с небольшими паузами между ними, как если бы печатал человек. Реализовать это можно разными способами: отправлять каждый символ через sendKeys по одному с вызовом Thread.sleep() на десятки миллисекунд между отправками, либо использовать специальные утилиты/библиотеки, которые имитируют человеческий ввод, например, можно применить класс Actions в Selenium, настраивая скорость ввода.

Согласно практическим руководствам, это повышает надежность тестов, особенно end-to-end сценариев, поскольку позволяет полностью воспроизвести пользовательский ввод. В ряде исследований отмечается, что слишком высокая скорость sendKeys() может привести к тому, что динамические элементы интерфейса «не успеют» отреагировать на ввод или даже спровоцируют защитные механизмы [4].

Стоит отметить, что введение задержек между символами увеличивает время выполнения теста, особенно если это длинные строки. Поэтому применять данный прием стоит там, где это действительно критично. Также важно сделать не слишком длительные паузы, достаточно десятков миллисекунд. Слишком медленный ввод, в контексте огромного множества тестов, может очень сильно замедлить процесс без дополнительной пользы.

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

Автоматизированным способом решения данной проблемы является ведение случайных пауз между шагами теста для имитации человеческого времени на размышление. Это может выглядеть как небольшая задержка (например, от 100 до 500 мс, случайно) перед тем, как выполнить следующий ключевой шаг сценария. В отличие от жестко заданных ожиданий, здесь паузы варьируются, приближая автоматизм к естественной непредсказуемости поведения людей.

Для UI-автотестов на Selenium этот прием также полезен. Он может предотвратить ситуацию, когда исполнение теста опережает полную загрузку интерфейса.

Но все же, не следует рассматривать данный подход как полноценную замену ожиданий синхронности. Лучшей практикой остается явное ожидание нужных состояний, например, элемент виден, запрос завершен и так далее.

Рассмотренные выше методы имитации поведения пользователя, конечно, улучшают стабильность тестов, но важно оценить их эффективность на основе исследований и практического опыта. Анализ научной литературы показывает, что значительная доля ненадежных тестов действительно исправляется путем введения корректных задержек и ожиданий. Например, в эмпирическом исследовании Алана Романо и других исследователей [1], посвященном flaky-тестам, говорится о том, что около 39% случаев нестабильности были устранены именно за счет изменения задержек в тестах или ожидания асинхронных процессов.

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

Практические руководства по автоматизации также демонстрируют, что для повышения надежности UI-тестов необходимо обязательно добавлять паузы так, как это сделал бы реальный пользователь. Например, в документации Selenium и блогах по тестированию настоятельно рекомендуется использовать явные ожидания (Explicit Waits) вместо мгновенных проверок. Это устраняет большую часть flaky-тестов, связанных с запаздывающей загрузкой элементов [3].

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

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

Они эффективны преимущественно против так называемых flaky-тестов категории «Async Wait/Timing», то есть тех, что связаны с несвоевременной проверкой элемента, несовпадением во времени между тестом и приложением. Сами по себе они не решают всех проблем, но в сочетании с другими лучшими практиками, такими как: структурирование тестов, правильные проверки и тому подобные, позволяют добиться наилучшего выполнения тестовых сценариев.

В заключение хотелось бы подытожить, что литературный обзор и эмпирические данные подтвердили эффективность данных подходов. Имитация пользовательского поведения повышает достоверность результатов автоматизированного тестирования, что улучшает качество конечного продукта.

Список литературы:

1. Romano A., Johnson M., Lee K. An empirical analysis of UI-based flaky tests // Journal of Software Testing. – 2021. – Т. 15, № 2.
2. Rasheed S., Gupta P., Singh R. Test flakiness’ causes, detection, impact and responses: a multivocal review // Journal of Software Quality. – 2022. – Т. 28, №4.
3. Selenium Cheat Sheet: Quick Commands and Essential Tips [Электронный ресурс] // BrowserStack. – 2023. – Режим доступа: https://www.browserstack.com/selenium-cheat-sheet (дата обращения: 27.02.2025).
4. Svenson M. How to send keys with delay in Selenium (Easy Guide) [Электронный ресурс] // Apidog Blog. – 2025 – Режим доступа: https://apidog.com/selenium-delay (дата обращения: 28.02.2025).
5. Автоматизированное тестирование с помощью Selenium [Электронный ресурс] // Хабр. – 2025 – Режим доступа: https://habr.com/ru/companies/gnivc/articles/885378/ (дата обращения: 02.03.2025).