Как найти неработающий тестовый пакет Selenium

Поскольку Selenium является наиболее популярным выбором, автоматизация тестирования стала неизбежной частью любого проекта по разработке программного обеспечения. Благодаря непрерывному тестированию, конвейерам CI/CD и DevOps, организации вкладывают огромные средства в создание автоматически запускаемых тестов в надежде сэкономить время, затраты и усилия в долгосрочной перспективе.

Хорошо спланированный и закодированный тест автоматизации окажет огромную помощь в выявлении ошибок на ранней стадии разработки. Но есть проблема, с которой часто сталкиваются Selenium-тестировщики и которая может нарушить всю продуктивность работы — Flaky Tests!

Что именно означает иметь Flaky Selenium test suite? В этой статье о Flaky Selenium test suite мы обсудим flaky тесты, общие причины flaky Selenium test, как их изолировать, найти и некоторые практические советы по их минимизации.

Давайте начнем!

Что такое «шелушащиеся» тесты?

**Детерминизм** — это фундаментальное свойство автоматизированного теста (или всего набора тестов Selenium), которое помогает обнаружить ошибки. Тест является детерминированным, если он всегда дает один и тот же результат при условии, что в код не внесено никаких изменений. Нерешительный тест — это тест, который проходит или не проходит случайным образом для одного и того же кода, поэтому дает противоречивые результаты. В один раз он пройдет, в другой раз провалится, а в следующий раз снова пройдет, без внесения каких-либо изменений в сборку. Такой недетерминированный результат противоречит основной цели автоматизированного тестирования.

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

Популярным решением для преодоления ограничений устройств является переход от локального тестирования к облачным платформам тестирования. Платформа LambdaTest Selenium Automation позволяет выполнять сценарии автоматизированного тестирования на масштабируемой и безопасной инфраструктуре Selenium.

Насколько распространены некачественные тесты?

К сожалению, некачественные тесты встречаются чаще, чем вы думаете.

Недавний опрос разработчиков программного обеспечения показал, что 59% утверждают, что сталкиваются с неработающими тестами ежемесячно, еженедельно или ежедневно.

Собрав большую выборку результатов внутренних тестов за один месяц, компания Google выпустила презентацию «Состояние тестирования непрерывной интеграции @Google», в которой раскрыла некоторые интересные факты.

• 84% переходов тестов из состояния «Прошел -> Провалился» были вызваны некачественными тестами.

• Только 1,23% тестов когда-либо обнаруживали поломку

• Почти 16% из 4,2 миллионов тестов показали определенный уровень флейкинга

• Сбои в работе часто блокируют и задерживают релизы

• От 2 до 16% их вычислительных ресурсов тратилось на повторное выполнение нестабильных тестов.

В Google пришли к выводу, что:

«Системы тестирования должны быть способны справляться с определенным уровнем флуктуации».

Почему Flaky-тесты плохи?

Flaky-тесты генерируют противоречивые результаты. Они не дают четкого указания на наличие ошибок в программном обеспечении и, следовательно, ограничивают надежность сборки. Они нежелательны. Но нестабильные тесты могут быть хуже, чем вы думаете!

Вот некоторые из причин:

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

• Они влияют на производительность инженеров, поскольку все время уходит на повторное написание, повторное выполнение и повторную проверку тестов. Ложные срабатывания отнимают много ресурсов, которые можно было бы направить на гораздо более ценную работу.

• Некачественные тесты стоят дорого. Они сопряжены с множеством скрытых затрат, таких как затраты на создание, исправление, выполнение, исправление, бизнес и психологические затраты.

• По мере того, как набор тестов становится все более обширным и не поддерживается своевременно, растет и коэффициент «шелухи». Поскольку никто не хочет иметь дело с большим flaky test suite с недостоверными результатами, тестировщики могут перейти на ручное тестирование. Это замедляет процесс разработки.

Нестабильные тесты могут нарушить процесс разработки, замедляя прогресс и продуктивность команды. Мы все согласны с тем, что обидно тратить время на повторное выполнение и отладку кода, в котором потенциально нет ошибок. В следующем разделе этой статьи о Flaky Selenium test suite мы подробно рассмотрим распространенные причины flakiness в автоматизированном тестировании Selenium.

Примечание: функции URL Parse сосредоточены на разделении строки на ее компоненты или на объединении ее компонентов в строку.

Что вызывает «шелушение» тестового набора Selenium?

Вам может быть интересно, откуда именно берется эта шелушимость? Является ли Selenium нестабильным как инструмент? Ответ — нет. Selenium не является нестабильным. Это ваши тесты нестабильны. Давайте немного разберемся в этой ситуации.

Языковые привязки Selenium WebDriver — это лишь тонкая обертка вокруг протокола W3C WebDriver Protocol, используемого для автоматизации браузеров. Selenium WebDriver реализует набор REST API, предоставляемых протоколом W3C Webdriver Protocol для выполнения соответствующих действий браузера, таких как запуск браузера, нажатие на элементы, ввод в поля и т.д., в соответствии со спецификациями.

Последняя версия Selenium 4 вносит значительные архитектурные изменения, стандартизируя W3C API Webdriver и полностью отказываясь от протокола JSON. Сам протокол W3C является детерминированным, следовательно, Selenium WebDriver также является детерминированным. Основные браузерные драйверы, такие как Geckodriver и Chromedriver, также полностью перешли на протоколы W3C. Одним словом, с Selenium 4 кросс-браузерные тесты стали более надежными и эффективными, чем когда-либо!

Так откуда же берется шелушение тестов?

Общие причины «шелушения» в тестовом наборе Selenium

Ниже перечислены основные проблемы, приводящие к нестабильности тестов, и соответствующие решения для обеспечения стабильности сборки:

1. Нестабильная среда тестирования

• Нестабильность среды AUT.

• Ограничения машины, на которой выполняется тест, такие как скорость обработки, память и т.д.

• Проблемы, связанные с браузером

• Неправильные версии программного обеспечения, используемого для запуска тестов.

• Нестабильное подключение к сети или медленное соединение,

2. Интеграция с ненадежными сторонними инструментами и приложениями

• Системные ошибки сторонних производителей

• Изменения в контракте сторонней организации

• Ненадежные сетевые подключения

3. Отсутствие синхронизации

• Загрузка страницы занимает время из-за фронтальной обработки, загрузки тяжелых компонентов, фреймов, контента и т.д.

• Задержка ответа от API или базы данных

• Асинхронная обработка

• Неиспользование правильных стратегий «ожидания». Фактическое время задержки зависит от множества внешних факторов, и тестовый сценарий может пройти или не пройти тест в зависимости от того, была ли достаточной задержка, указанная в коде.

4. Плохо написанные тесты

• Тест большой и содержит много логики.

• Тест зависит от предыдущих тестов.

• Тест использует фиксированное время ожидания.

5. Зависимость данных

• Отсутствие надлежащей подготовки тестовых данных

• Жесткое кодирование данных

• Использование одних и тех же данных в нескольких тестах может привести к повреждению данных.

• Повреждение данных вызывается другими коллегами, которые используют и изменяют их.

• Пользователь заходит на портал.

• Пользователь меняет пароль.

6. Стратегия локатора

• Неэффективная забота о динамических элементах и использование динамических локаторов, которые меняются в зависимости от рендеринга AUT

• Использование странного, длинного или жестко запрограммированного XPath.

  /html/body/div[3]/div/div[4]/div/div/div/div/section/div/div/article/div/form/div/div[4]/div/label

7. Непреднамеренное использование нагрузочного тестирования

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

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

1. Другие причины

• Неправильная конфигурация модулей, используемых во фреймворке

• Использование устаревших модулей

• Использование несовместимых инструментов для тестирования приложений. (Например: для приложений Angular Protractor будет лучшим выбором, чем Selenium) и т.д.

Как найти неработающий Selenium-тест и исправить его?

Теперь, когда вы знаете общие причины, по которым в вашем тестовом наборе возникают проблемы, давайте рассмотрим, как найти неработающий тест Selenium и исправить его.

Примечание: Base64-кодирование или декодирование — это простой способ защиты или отображения конфиденциальных данных.

Распространенные ошибки, возникающие при сбое теста из-за «шелушения

Прежде всего, давайте рассмотрим некоторые ошибки или исключения, которые часто встречаются, когда тест не работает из-за нестабильности.

Шаги по исправлению нестабильного набора тестов Selenium

Возможно, вам не удастся полностью устранить шелушение в тестовом наборе Selenium. Однако вы можете минимизировать влияние и негативные последствия «шелушащегося» теста, выполнив следующие шаги.

1. Примите правильные методы проектирования для вашего проекта

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

Рассмотрите такие подходы, как объектная модель страницы (POM), чтобы сделать вашу структуру надежной и многократно используемой. POM — это широко используемый в Selenium шаблон проектирования, который создает хранилище объектов для хранения всех веб-элементов. Основная цель этого паттерна — избежать дублирования кода и повысить удобство его повторного использования.

1. Пишите небольшие и независимые автоматизированные тесты

При написании автоматизированных тестов придерживайтесь следующего принципа:

• Каждый тест должен быть небольшим.

• Каждый тест должен иметь только одну цель — проверить одну конкретную функциональность.

• Тесты должны быть независимы друг от друга.

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

1. Выявление и изоляция неработающих тестов

Первый шаг к исправлению неработающих тестов — это их выявление. Регулярно запускайте набор тестов много раз и выявляйте тесты, дающие нестабильные результаты — желательно ежедневно или хотя бы еженедельно. Один из эффективных способов сделать это — использовать любой CI-сервис.

Использование CI-сервиса поможет вам запускать весь набор тестов чаще, чем на локальной машине. Если вы хотите обнаружить неработающие тесты в своем наборе, их нужно запускать много раз. Используя CI-тестирование, вы можете запланировать запуск сборки на разное время в течение дня, и, возможно, вам удастся обнаружить некоторую закономерность сбоя тестов. Например, тест дает сбой в период с 16 до 18 часов. Это идеально подходит для внедрения CI-сервиса в начале самого проекта.

После анализа вы можете разделить ваши тесты на два разных пути: стабильные тесты (зеленый) и нестабильные flaky-тесты (красный). Вы можете настроить свой CI-сервис на регулярное планирование сборки для ветки, содержащей нестабильные тесты, чтобы выявить & исправить проблемы. Таким образом, вы сможете легко разделить внимание между стабильными и нестабильными сборками.

Цель — сделать максимум тестов зелеными, чтобы доказать, что автоматизация приносит пользу.

1. Документируйте нестабильные тесты

Документирование является частью отличной практики тестирования. Как только вы определили все «флэковые» тесты в наборе, задокументируйте их. Один из популярных подходов — создание тикетов.

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

1. Определите причину неудач

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

Вы можете реализовать хуки, которые сработают, когда тест не пройдет. Соберите данные о сбое теста, например, скриншоты веб-страниц, журналы ошибок, состояния приложения и т.д., которые могут помочь найти виновника «шелушения». Проанализируйте, почему одни и те же тесты периодически то проходят, то не проходят.

1. Исправляйте неработающие тесты по одному.

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

Вы можете отлаживать проблему, комментируя код, отслеживая журналы, добавляя при необходимости операторы ожидания и точки останова и т.д.

1. Добавьте тесты обратно в стабильный набор тестов

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

Советы по уменьшению «шелушения» в тестовом наборе Selenium

Несколько основных стратегий для устранения «шелушения» и достижения стабильности сборки:

1. Стабилизируйте тестовое окружение

Как уже говорилось, нестабильное окружение вносит свой вклад в нестабильность набора тестов selenium. Неудивительно, что при этом обычно упускаются из виду такие аспекты, как сетевая задержка, проблемы с кэшем, ошибки сервера, сбои браузера и т.д. В статье блога Fix Your Unstable Automated UI Tests Эмануил Славов утверждает, что стабилизация тестовой среды помогла ему увеличить процент прохождения с 50% до 100%.

Одним из популярных решений для стабилизации тестовой среды является использование облачных платформ тестирования. Основными преимуществами облачного тестирования являются:

• Экономическая эффективность

• Высокая производительность

• Более быстрое выполнение тестов

• Масштабируемость

• Персонализация

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

2. Синхронное ожидание

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

По словам Алана Ричардсона, проблема синхронизации является главной причиной неудач автоматизации, и синхронизация на основе состояний — это решение для того, чтобы заставить ее работать.

3. Использование надежных локаторов

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

Несколько лучших практик таковы:

• Всегда ищите уникальные локаторы.

• Используйте статические идентификаторы, добавляемые разработчиками.

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

• Если вы работаете с XPath или CSS Selectors в Selenium, делайте их короткими.

Заключение

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

В этой статье, посвященной flaky Selenium test suite, мы обсудили flaky Selenium test suite, общие причины и оптимальные подходы к поиску и устранению flakiness, чтобы повысить стабильность сборки путем устранения первопричины сбоя тестирования. Даже если вы не можете полностью исключить «шелушение» из своего набора тестов, меры, о которых мы узнали, помогут вам свести его к минимуму. Кроме того, переход на совместимый с W3C Selenium 4 поможет вам значительно уменьшить случайность тестов.

Надеемся, что эта статья оказалась полезной.

Счастливого тестирования!