Содержание

8 лучших фреймворков для тестирования с помощью Python в 2021 году / Хабр

Если вы когда-нибудь думали: «С какого же языка программирования мне следует начать свое путешествие в тестирование?» Ваш ответ – Python. Но он подойдет не только начинающим! В недавнем опросе, который я провела в LinkedIn, мы видим, что среди опытных программистов 35% проголосовали за то, что Python является их самым любимым языком программирования (немного опередив всеми любимую Java, которая заняла 2-е место с 32%).

На протяжении многих лет Python действительно набирает обороты как среди тестировщиков, так и среди разработчиков, да и в целом является самым динамично развивающимся языком программирования (как видно на диаграмме трендов Stack Overflow), и мы прекрасно понимаем, что это значит. Популярность = релевантность!

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

Что хорошего в Python для автоматизации тестирования?

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

Есть довольно много причин, по которым популярность Python растет в области автоматизации тестирования и версий, почему он считается лучшим вариантом для нее. Среди них вы найдете: Дзен Python (19 основополагающих принципов философии проектирования на Python), удобство для начинающих, но мощность для профессионалов; Python – одновременно объектно-ориентированный и функциональный, у него есть большая библиотека пакетов для тестирования, серьезное сообщество по всему миру и многое другое! Я рекомендую прочитать вам чуть больше об этом в блоге AutomationPanda.

Фреймворк для тестирования на Python, который вам подходит

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

  1. Как выбрать правильный инструмент для автоматизации тестирования

  2. Как выбрать лучший инструмент – процесс поиска

  3. Критерий выбора правильного функционального инструмента для тестирования

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

Преимущества и недостатки 8 лучших фреймворков для тестирования на Python

  1. Robot Framework

  2. Pytest

  3. TestProject

  4. PyUnit (Unittest)

  5. Nose2

  6. Behave

  7. Lettuce

  8. Testify

Robot Framework (RF)

Robot Framework (RF) – открытый фреймворк автоматизации тестирования для приемочного тестирования, ATDD и RPA. Его ядро написано на Python, но может запускаться на Jython (Java-реализация Python) и IronPython (Python для .NET framework). Для начала работы вам потребуется установить Python версии 2.7.14 или выше.

Преимущества:

  • Основывается на подходе Keyword-driven testing (KDT), что позволяет нам легко создавать тест-кейсы с использованием удобных для восприятия человеком ключевых слова (не требует опыта написания кода).

  • Поддерживает все операционные системы (Windows, Linux или macOS) и все приложения (веб, мобильные и десктопные приложения).

  • Предоставляет понятные и удобные данные HTML-отчетов (включая скриншоты).

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

  • Поддерживает синтаксис If/Else, начиная с RF v4.0.

  • Отлично поддерживается сообществом и имеет множество онлайн-ресурсов.

  • Основывается на подходе Keyword-driven testing (KDT), что позволяет нам легко создавать тест-кейсы с использованием удобных для восприятия человеком ключевых слова (не требует опыта написания кода).

  • Поддерживает все операционные системы (Windows, Linux или macOS) и все приложения (веб, мобильные и десктопные приложения).

  • Предоставляет понятные и удобные данные HTML-отчетов (включая скриншоты).

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

  • Поддерживает синтаксис If/Else, начиная с RF v4.0.

  • Отлично поддерживается сообществом и имеет множество онлайн-ресурсов.

Недостатки:

  • Из коробки не поддерживается параллельное тестирование, но его можно использовать с помощью Selenium Grid (https://www.selenium.dev/documentation/en/grid/) или через Pabot (https://pabot.org/) (параллельный исполнитель для RF).

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

  • Создание ключевых слов-дженериков может занять больше времени, чем обычное написание кода.

  • Сложно настроить отчеты.

Итог: Если вы хотите внедрить фреймворк на основе keyword-driven подхода, который позволит ручным тестировщикам и бизнес-аналитикам создавать автоматизированные тесты, RF станет для вас отличным решением. Он предоставляет множество расширений и библиотек, а также прост в использовании. Однако, если вы ищете возможности для разработки сложных сценариев, вам придется кастомизировать фреймворк самостоятельно.

Pytest

Pytest – это открытый фреймворк для тестирования, который является одним из широкоиспользуемых в Python. Pytest также поддерживает модульное, функциональное и тестирование API. Для его запуска вам понадобится Python версии 3.5 или выше.

Преимущества:

  • Позволяет создавать компактные и простые наборы тестов.

  • Легко расширяется с помощью таких плагинов как: pytest-randomly, pytest-cov, pytest-django, pytest-bdd.

  • Еще вы можете добавить в свой проект плагин pytest html для печати HTML-отчетов с помощью одного просто флага в командной строке.

  • Можно выполнять тесты параллельно с помощью плагина pytest-xdist. Больше о нем можно узнать здесь.  

  • Имеет очень большое сообщество.

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

Недостатки:

Совместимость – не ключевой фактор для Pytest, поскольку вы хоть и можете с легкостью писать тест-кейсы на Pytest, но не можете использовать их в другом фреймворке из-за использования уникальных для Pytest процедур.

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

TestProject

TestProject – это полностью бесплатный фреймворк для автоматизированного тестирования с облачными и локальными HTML-отчетами. С помощью TestProject вы можете с легкостью собрать автоматизацию для тестирования мобильных, веб или иных приложений с помощью открытого SDK. Он поддерживает Python версии 3. 6 и выше, а также фреймворки Pytest и Unittest (узнать больше можете здесь). TestProject включает в себя все зависимости, необходимые для обеспечения единственного кроссплатформенного тестирующего агента (посмотрите этот вебинар, чтобы узнать больше).

Преимущества:

  • Агент, включающий все сторонние библиотеки, необходимые для выполнения и разработки автоматизации тестирования для мобильных, веб или generic-тестов. 

  • Бесплатные автоматические отчеты в форматах HTML/PDF (со скриншотами).

  • История выполнения доступна через RESTful API.

  • Всегда актуален за счет последних и стабильных версий драйверов Selenium/Appium.

  • Единый SDK для Web, Android, iOS и Generic-тестов.

  • Встроенный раннер и функционал для составления отчетов.

  • Кроссплатформенная поддержка для Mac, Windows, Linux и Docker.

  • Большое сообщество и поддержка: форум, блог и встроенный чат.

Недостатки:

  • Агент выполняет по одному тесту за раз, поэтому для параллельного тестирования вам понадобятся агенты Docker.  

  • Функции коллаборации из гибридного облака ограничены при работе в автономном режиме. То есть в отличие от бесшовной совместной работы в гибридном облаке, при использовании локальной опции «on-prem» вам нужно будет реализовать совместную работу самостоятельно, сохранив тесты на общем сетевом диске/git.

Итог: Если вы ищете один фреймворк, который покрывает все ваши задачи по автоматизации от начала до конца, то TestProject определенно подходит для вас и идеально подходит для команд со смешанными навыками, от новичков до экспертов в автоматизации. 

PyUnit (Unittest)

PyUnit (Unittest) – фреймворк для модульного тестирования на Python, вдохновлённый JUnit. Является частью стандартной библиотеки Python, таким образом, большинство разработчиков начинают свой путь в тестирование с него.

Преимущества:

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

  • Предлагает простое и гибкое выполнение тест-кейсов. 

  • Быстрая генерация отчетов о тестах в XML и unittest-sml-reporting.

Недостатки:

  • Цель кода теста порой становится неясной ввиду поддержки абстракции.

  • Большое количество шаблонного кода.

  • Из-за того, что фреймворк основан на Junit, для именования используется camelCase, а не snake_case, характерный для Python.

Итог: Если вам нужно базовое модульного тестирование и вы знакомы с xUnit-фреймворками, вам будет легко начать работать с PyUnit, и вероятно, для вас это будет наиболее удобно, и не нужно будет подтягивать дополнительные зависимости.

Nose2

Nose2 – это преемник Nose, который основан на PyUnit (Unittest), но с плагинами. Nose2 расширяет возможности PyUnit с помощью различных плагинов, которые добавляют поддержку выполнения тестов, обнаружение тестов, декораторы, фиктуры, параметризацию и т. д.

Преимущества:

  • Легко начать, поскольку он расширяет фреймворк PyUnit (Unittest), который поставляется из коробки в стандартной библиотеке Python.

  • Включает в себя большое количество встроенных плагинов, которые могут упростить и ускорить тестирование.

  • Поддерживает параллельное тестирование с помощью плагина mp.

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

Недостатки:

Итог: если вы уже пользуетесь PyUnit, можете попробовать Nose2 и понять, как он расширяет PyUnit.

Behave

Behave – один из самых популярных фреймворков BDD-тестирования (behavior-driven development) на Python. Несмотря на то, что он официально не является частью проекта Cucumber, он функционирует очень схоже с фреймворками Cucumber. 

Преимущества:

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

  • Имеется большой объем документации и поддержка, которая поможет вам начать работу.

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

  • Есть интеграция с Django и Flask.

Недостатки:

Итог: Если ваша команда придерживается BDD-подхода и у вас уже есть какие-то знания о нем (например, о Cucumber, SpecFlow и т.д.) и вам нужно black-box тестирование, то обязательно обратите внимание на Behave. Также рассмотрите другие BDD-фреймворки, такие как Pytest-bdd, Lettuce (поговорим о нем ниже), Radish и остальные, о которых рассказывается в этой статье о сравнении BDD-фреймворков. Если вам нужно нечто большее, чем black-box тестирование, то лучше найти что-то иное.

Lettuce

Lettuce – другой BDD-фреймворк Python, основанный на Cucumber. Требует Python 2.7.14 или выше.

Преимущества:

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

  • По аналогии с Behave, он в основном для black-box тестирования, но может использоваться и для большего количества видов тестирования. Например, Lettuce может тестировать различные модели поведения и взаимодействия серверов и баз данных.

Недостатки:

  • Не хватает некоторого функционала из других фреймворков, поэтому Lettuce больше подходит для небольших проектов.

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

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

Итог: Если у вас небольшой BDD-проект, Lettuce – отличный вариант для простого создания тестов на естественном языке, доступный всем членам команды.

Testify

Testify создан на замену Unittest и Nose и обладает расширенным функционалом по сравнению со стандартным Unittest.

Преимущества:

  • Используется для модульного, интеграционного и системного тестирования.

  • Для тех, кто знаком с Unittest, Testify очень прост в работе.

  • Наличие большого количества плагинов.

  • Подобно Nose2, Testify умеет обнаруживать тесты.

  • Простой синтаксис фикстур.

Недостатки:

Итог: Если у вас есть опыт работы с Unittest, вам будет довольно легко перестроить существующие тесты для работы с Testify, так что определённо уделите этому время.

Заключение

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

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

Надеюсь, эта статья помогла вам не только понять, насколько Python хорош для автоматизированного тестирования, но и облегчила путь к более простому тестированию на Python!

Расскажите в комментариях о своем любимом фреймворке. Вы также можете рассказать о тех фреймворках, которые я пропустила!

Материал подготовлен в рамках курса «Python QA Engineer». Если вам интересно узнать подробнее о формате обучения и программе, познакомиться с преподавателем курса — приглашаем на день открытых дверей онлайн. Регистрация здесь.

личный опыт и новые методы / Хабр

Привет, Хабр! Меня зовут Сергей Радченко, и мы с командой профессионально занимаемся тестированием уже несколько лет. Сегодня я посчитал количество автотестов, которые мы подготовили для веб-интерфейсов, десктопных приложений, API, систем двухфакторной авторизации и так далее (их оказалось более 5000). И мне захотелось рассказать о нашем опыте создания экосистемы для автоматизированного тестирования. В этом посте вы найдете описание полезных для комплексного тестирования фреймворков, а также исходный код некоторых дополнительных методов, которые мы дописали самостоятельно, чтобы написание тестов происходило быстрее, и тестирование приносило больше пользы. 

Иногда кажется, что тесты — это очень просто. Нередко в инструментах инфраструктурного мониторинга предусмотрена возможность отслеживания доступности веб ресурсов по простым http-запросам: ответ пришел — значит сервис доступен, нет ответа или код ответа отличается от «200» — значит недоступен. Но таким способом не получается проверить что-то более специфичное, например, корректность работы системы авторизации или обнаружить проблемы с синхронной подгрузкой данных, ну и удостовериться, что все бизнес услуги предоставляются пользователям корректно. 

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

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

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

Тесты проще писать на Python. Это факт

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

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

Быстрый старт

Чтобы быстрее начинать работу по проекту, мы создали один базовый класс Python со всеми необходимыми методами и постоянно дополняем его новыми. Далее для тестирования конкретного сайта создаем классы-наследники. В них выносим общие данные, элементы и метод. Благодаря этому приступить к началу тестирования получается достаточно быстро.

Простота входа

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

Работа с разными окружениями

Учитывая, что тестированием мы занимаемся давно, у нас есть старый код, который написан на Python 2.7. Основная часть тестов была подготовлена для версии Python 3. Все они должны работать вместе на одной рабочей машине автоматизатора тестирования. Виртуальные окружения Python позволяют развернуть готовое окружения за несколько минут с использованием нескольких команд в консоли. Также несколько минут уходит на установку всех необходимых пакетов ещё одной консольной командой. 

Браузерные тесты удобно запускать через Selenium

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

Исторически Selenium использует свой закрытый протокол для взаимодействия с браузером: запросы упаковываются в JSON и передаются через http. Но сейчас же во все основные браузеры внедрен протокол, позволяющий обращаться к ним напрямую: Remote Debugging Protocol для Firefox, Chrome DevTools Protocol для chromium. С помощью этих протоколов можно управлять браузерами на более низком уровне, например, отслеживать запросы. Эти возможности, должны появиться в Selenium версии 4, которая сейчас находится в разработке (очень ждём…).  

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

Изначально за основу для разработки тестов был взят wrapper (https://pypi.org/project/seleniumwrapper/). Мы предполагали, что его методов будет достаточно для написания любых сценариев. Но в процессе работы возможностей wrapper стало не хватать: во многих местах появилось дублирование кода, было много провалов, которые приходилось обходить костылями. Для решения этих проблем мы начали добавлять свои методы такие как: 

  • переключение между вкладками,

  • ожидание исчезновения элемента со страницы, 

  • имитация нажатий клавиш и использование ActionChains, 

  • ожидание скачанного файла

  • и так далее

Вот некоторые примеры этих методов в коде:

class Page(SeleniumWrapper):
    def switch_to_window(self, title_name, close_others=False):
        windows = self. window_handles
        windows_title = {}
        for window in windows:
            self.switch_to.window(window)
            windows_title[self.title] = window
        for window in windows_title:
            if re.search(title_name, window):
                self.switch_to.window(windows_title[window])
                break
        if close_others:
            self.close_all_other_windows()
    def get_current_window_index(self):
        return self.window_handles.index(self.current_window_handle)
    def switch_to_next_window(self):
        current_index = self.get_current_window_index()
        self.switch_to.window(self.window_handles[current_index + 1])
    def switch_to_previous_window(self):
        current_index = self.get_current_window_index()
        self.switch_to.window(self.window_handles[current_index - 1])
    def close_all_other_windows(self):
        windows = self.window_handles
        current_window = self.current_window_handle
        for window in windows:
            if window != current_window:
                self.
 
 
 switch_to.window(window)
                self.close()
        self.switch_to.window(current_window)
    def is_xpath_present(self, xpath, eager=False, timeout=1, presleep=0):
        time.sleep(presleep)
        self.silent = True
        elements = self.xpath(xpath, eager=eager, timeout=timeout)
        self.silent = False
        if eager:
            return elements
        if not elements:
            return []
        if elements.is_displayed():
            return True
        return []
   @_wait_until
    def wait_for_not_displayed(self, xpath):мента.
        """
        assert not bool(self.is_xpath_present(xpath)), f'Элемент {xpath} не исчез'
        return True
   def press_keys(self, keys):
        """
        Ввод символов нажатиями на клавиши
        :param keys: Строка символов для ввода
        """
        for key in keys:
            ActionChains(self).key_down(key).key_up(key).perform()
            time.sleep(0.01)
    def press_backspaces(self, count=20):
        keys = [Keys.
 
 
 BACKSPACE for _ in range(count)]
        self.press_keys(keys)
    def get_downloaded_file_names(self):
        if settings.run_local:
            return []
        response = requests.get(self.download_url)
        result = re.findall(r'>(.*?)</a>', response.text)
        print(f'Downloaded response: {response.text}')
        print(f'Downloaded result: {result}')
        return result
    @_wait_until
    def wait_for_downloaded_file(self, filename):
        assert not settings.run_local, 'Can not check downloaded file on local running'
        assert filename in self.get_downloaded_file_names(), f"Файл {filename} не скачан"
        return True
    @_wait_until
    def wait_for_downloaded_file_by_substring(self, filename_part):
        assert not settings.run_local, 'Can not check downloaded file on local running'
        matches = [filename for filename in self.get_downloaded_file_names() if filename_part in filename]
        assert len(matches) > 0, f'Нет файла содержащего `{filename_part}` в названии'
        return True

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

Это очень важно в реальных тестах. Например, чтобы начать вводить в поле ввода данные, нужно сперва дождаться появления элемента на странице, затем проверить его видимость, доступность для ввода, и только после этого начать вводить данные. Если использовать чистый Selenium, то придется в каждом тесте прописывать эти действия, удобнее вынести это всё в отдельный метод и просто его использовать. 

А вот и исходный код метода:

  def send_keys(self, xpath, value, name="", timeout=None, wait_interactable=True, postsleep=0):
    	timeout = timeout or self.timeout
    	element = self.xpath(xpath, name, timeout=timeout)
    	if wait_interactable:
        	    self.can_click(xpath, timeout=timeout)
    	try:
        	    element.send_keys(value)
    	except WebDriverException:
        	    message = f"В поле ввода `{name or xpath}`не удалось ввести значение `{value}` за `{timeout}` секунд"
        	    raise WebDriverException(message)
    	time.
 
 sleep(postsleep)
   def click(self, xpath_or_dict="", name="", timeout=None, presleep=0, postsleep=0, ignored_exceptions=None):
        xpath, name = Page.get_xpath_and_name(xpath_or_dict, name)
        timeout = timeout or self.timeout
        ignored_exceptions = ignored_exceptions or tuple()
        # Сначала ждем появления элемента
        element = self.xpath(xpath_or_dict, timeout=timeout)
        time.sleep(presleep)
        errors = list()
        end_time = time.time() + timeout
        while time.time() < end_time:
            try:
                element.click(timeout=timeout / 10)
                break
            except ignored_exceptions:
                continue
            except InvalidSessionIdException:
                message = "Потеряно соединение с браузером. Возможно браузер был закрыт или аварийно завершил работу"
                raise InvalidSessionIdException(message)
            except StaleElementReferenceException as e:
                element = self.xpath(xpath_or_dict, timeout=timeout)
                errors.
 
 
 append(e)
                continue
            except WebDriverException as e:
                errors.append(e)
                continue
        else:
            if errors:
                message = f"Не удалось выполнить клик по элементу `{name or xpath}` в течение {timeout} секунд(ы)\n{errors}"
                raise TimeoutException(message)
        time.sleep(postsleep)

Кстати, на Хабре уже есть статьи про Selenium. И если вы хотите почитать про этот фреймворк подробнее, можно посмотреть материалы по этим ссылкам: (

https://habr.com/ru/post/248559/  https://habr.com/ru/post/329256/  https://habr.com/ru/post/208638/  https://habr.com/ru/post/152653/  https://habr.com/ru/post/327184/  https://habr.com/ru/post/322742/)

Распознавание изображений с PyAutoGUI

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

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

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

class RecognitionClient(abc.ABC):
    def __init__(self, project_dir):
        self.project_dir = Path(project_dir)
        self.process = None
        self. wait_time = 25   
    def _find_image_path(self, img_file):
        parent_img_path = self.project_dir.parent.joinpath('img', img_file)
        if parent_img_path.is_file():
            return str(parent_img_path)
        img_path = self.project_dir.joinpath('img', img_file)
        if img_path.is_file():
            return str(img_path)
        return ImageNotRecognized(f'Not found image file: {img_path}')
   @sleeper
    def find_one_of(self, *imgs, wait_time=None, confidence=0.9, raise_errors=True):
        """
        Поиск координат одного скрина из списка.
        """
        wait_time = wait_time or self.wait_time
        timeout = time.time() + wait_time
        while time.time() < timeout:
            for img in imgs:
                position = self.find_screen(img, wait_time=0.1, raise_errors=False, confidence=confidence)
                if position:
                    return position
        else:
            if raise_errors:
                for img in imgs:
                    img_path = self. _find_image_path(img)
                    with open(img_path, "rb") as image_file:
                        img_obj = image_file.read()
                        allure.attach(img, img_obj, type=AttachmentType.PNG)
                raise ImageNotRecognized(f"Images not recognized: {', '.join(map(str, imgs))}")

Запуск тестов с PyTest

PyTest — действительно мощный фреймворк для тестирования. Он имеет массу возможностей и расширений в виде пакетов. С его помощью можно реализовать автоматический перезапуск тестов, визуализацию отчетов и многое другое.

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

К тому же в PyTest есть несколько дополнительных пакетов, которые расширяют его функциональность. Мы используем Allure и Rerunfailures.

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

пример — скриншот отчета

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

Первым решением было оборачивание кода внутри теста в блок try. В итоге это привело к увеличению количества строк кода теста и повсеместному дублированию. Тогда мы решили сделать свой класс наследник StepContext. Сначала решение показалось удобным, но внутри класса получилось много лишних строк и условных блоков. На текущий момент мы перешли к варианту использования декоратора contextmanager из библиотеки contextlib и реализовали обращение к глобальному объекту браузера. А поскольку декоратор преобразует генератор в дескриптор его можно использовать в блоке with.

Описание метода

@contextmanager
def allure_step(name, wait_time: int = None):
    from web.register import pages
    with allure.step(name):
        try:
            if wait_time:
                pages.browser.wait_time = wait_time
        	yield
        	pages.browser.wait_time = settings.wait_time
        	make_screen('screen')
        except Exception:
            make_screen('error')
        	raise

Применение метода

from utils.allure import allure_step
def test_1(pages):
    with allure_step('Шаг 1. Загрузка главной страницы', 50):
        pages.main_page.open()

Кроме этого мы используем библиотеку Rerunfailures, которая обеспечивает удобный перезапуск тестов при провале. Этот набор методов позволяет настраивать количество перезапусков, интервал ожидания перед перезапуском после провала. В общем — полезная штука для тестировщика, у которого действительно много работы.

Изоляция тестов с Selenoid

Тесты необходимо запускать изолированно друг от друга, чтобы результат выполнения предыдущего никак не влиял на следующий. Тесты надо прогонять на разных браузерах различных версий. И для этого идеально подходит Selenoid в связке с Selenoid GGR и Selenoid UI.

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

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

Запуск тестов через Jenkins

Вообще Jenkins создавался (и используется) для CI/CD. Но мы применяем его как систему для запуска тестов, используя те же плюсы, которые эта платформа дает при деплое приложений. 

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

На стенде, где установлен Jenkins, может быть создано несколько окружений Python и размещены разные репозитории с тестами. Тесты обычно берутся с локального диска стенда, а не из Git, потому что одновременно работают десятки проектов, и каждый раз делать Pull оказывается накладно с точки зрения ресурсов. Впрочем, сами тесты могут не меняться месяцами, а иногда и годами, так что это не очень страшно. )

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

Создание проектов мы автоматизировали через отдельный скрипт. На основе шаблона скрипт создает проект почти со всеми необходимыми настройками, чтобы свести к минимуму ввод дополнительных параметров. 

Заключение

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

платформ автоматизации тестирования | SmartBear

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

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

Что такое тестовая среда?

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

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

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

Преимущества платформы автоматизации тестирования

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

  • Повышенная эффективность тестирования
  • Снижение затрат на техническое обслуживание
  • Минимальное ручное вмешательство
  • Максимальное тестовое покрытие
  • Повторное использование кода

Распространенной тенденцией к минимизации рисков является раннее тестирование в Test Automation Framework. Используя такие инструменты, как TestLeft, вы можете проводить тестирование в собственной среде IDE. Загрузите бесплатную 30-дневную пробную версию для автоматизации в своей среде IDE уже сегодня!

Типы сред автоматизированного тестирования

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

  1. Платформа линейной автоматизации
  2. Модульная среда тестирования
  3. Платформа тестирования архитектуры библиотеки
  4. Платформа управления данными
  5. Платформа, управляемая ключевыми словами
  6. Платформа гибридного тестирования
Linear Automation Framework

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

Преимущества линейного фреймворка:

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

Недостатки:

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

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

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

Преимущества модульной структуры:

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

Недостатки модульной структуры:

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

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

Преимущества платформы тестирования с архитектурой библиотеки:

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

Недостатки:

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

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

Настройка среды тестирования, управляемой данными, позволит тестировщику сохранять и передавать входные/выходные параметры для тестовых сценариев из внешнего источника данных, например электронных таблиц Excel, текстовых файлов, файлов CSV, таблиц SQL или репозиториев ODBC.

Сценарии тестирования подключаются к внешнему источнику данных и при необходимости считываются и заполняются необходимыми данными.

Преимущества Data-Driven Framework:

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

Недостатки

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

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

При таком подходе ключевые слова также хранятся во внешней таблице данных (отсюда и название), что делает их независимыми от инструмента автоматического тестирования, используемого для выполнения тестов. Ключевые слова — это часть сценария, представляющая различные действия, выполняемые для тестирования графического интерфейса приложения. Они могут быть помечены просто как «щелчок» или «вход» или со сложными ярлыками, такими как «перейти по ссылке» или «подтвердить ссылку». объект или часть пользовательского интерфейса, над которой выполняется действие. Чтобы этот подход работал должным образом, необходим общий репозиторий объектов для сопоставления объектов с их связанными действиями.

Таблица ключевых слов:

Номер шага Описание Ключевое слово Объект Действие
Этап 1 Щелкните ссылку пользовательского портала на главной странице ссылка Кнопка входа в систему
Шаг 2 Введите имя пользователя Входные данные Имя пользователя для входа
Этап 3 Введите пароль Входные данные Пароль для входа
Этап 4 Проверка информации для входа пользователя проверка входа
Этап 5 Войдите в приложение логин Кнопка отправки

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

Преимущества фреймворков, управляемых ключевыми словами:

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

Недостатки:

  • Первоначальная стоимость установки фреймворка высока. Это трудоемко и сложно. Необходимо определить ключевые слова и настроить репозитории/библиотеки объектов.
  • Вам нужен сотрудник с хорошими навыками автоматизации тестирования.
    • Поддержка ключевых слов
  • может стать проблемой при масштабировании тестовой операции. Вам нужно будет продолжить создание репозиториев и таблиц ключевых слов.
Гибридная среда автоматизации тестирования

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

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

Заключение

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

TestComplete поддерживает широкий спектр языков сценариев, таких как Python, JavaScript, Java и VBScript, и поставляется с обширной библиотекой объектов, которая содержит более пятидесяти тысяч свойств объектов и более пятисот типов элементов управления. Функция записи и воспроизведения инструмента позволяет непрограммистам создавать сложные тесты, не написав ни одной строки кода. Благодаря этим функциям любая команда может легко создать гибридную среду, которую поддерживает TestComplete, и позволит командам реализовать множество типов тестирования, включая тестирование на основе данных и тестирование на основе ключевых слов.

Популярные платформы автоматизации тестирования: как выбрать

Содержание

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

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

Преимущества сред автоматизации тестирования

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

Типы платформ автоматизации тестирования

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

1. Платформа тестирования на основе данных

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

2. Платформа тестирования на основе ключевых слов

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

3. Гибридная среда тестирования

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

4. Linear Scripting Framework

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

5. Платформа тестирования на основе модулей

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

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

Популярные платформы автоматизации тестирования

Вот некоторые из лучших сред автоматизации тестирования, используемых разработчиками по всему миру:

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

1. Selenium

Selenium давно существует в мире автоматизации. Это инструмент автоматизации с открытым исходным кодом, который упрощает автоматизацию тестирования современных веб-приложений с помощью недавнего Selenium 4. Функции Selenium 4 включают заметную интеграцию с Chrome CDP и многое другое для повышения эффективности тестирования. Вот почему многие тестировщики переходят с Selenium 3 на Selenium 4.

Компоненты Selenium Test Automation

  • Selenium IDE : Selenium IDE помогает записывать и воспроизводить ваши тесты.
  • Selenium Grid : Помогает запускать тесты на нескольких машинах параллельно.
  • Selenium WebDriver : Selenium WebDriver наиболее полезен при запуске тестов Selenium в браузере.
  • Selenium RC : Selenium RC помогает писать тестовые примеры на разных языках программирования для автоматизации тестов пользовательского интерфейса для веб-приложений на любом HTTP-сайте. В наши дни он мало используется.

Data Selenium Data at Glance

  • Официальный веб-сайт: https://www.selenium.dev/
  • .
  • Авторы: 675
  • Звезды: 25,7K
  • Форк: 7,4K

.

  • Поддерживает несколько языков программирования, таких как Java, Javascript, C#, Python, Ruby и т. д.
  • Поддерживает все основные браузеры Chrome, Edge, Firefox и Safari
  • Поддерживает несколько операционных систем Windows, Mac и ОС на базе Linux
  • Сильная поддержка сообщества, поскольку Selenium используется многими тестировщиками по всему миру.
  • Простота в освоении и адаптации.
  • Поддерживает параллельное выполнение с Selenium Grid, сокращая время выполнения теста.
  • Selenium обширен, на рынке доступно множество плагинов и пакетов сообщества.
  • Платформа Selenium может быть расширена до мобильного тестирования.

    • Ограничения Selenium

    • Selenium предоставляет API высокого уровня; реализация зависит от пользователя. Это означает, что вам нужно настроить структуру, основанную на ваших потребностях. Если вы новичок в автоматизации тестирования, вы можете столкнуться с трудностями при настройке надежной среды.
    • Специальное соглашение об уровне обслуживания для технической поддержки недоступно; поскольку Selenium имеет открытый исходный код, вы должны полагаться на поддержку сообщества.
    • Selenium зависит от Webdriver, поскольку он работает с драйверами, специфичными для браузера (например, для запуска тестов в Chrome вам нужен драйвер Chrome). Это замедляет выполнение тестов и иногда затрудняет согласование версий браузера и драйвера.
    • Управление зависимостями, как упоминалось ранее, селен предоставляет только высокоуровневые API для управления действиями браузера. Для утверждений, конфигураций тестовой среды и отчетов вам необходимо полагаться на сторонние пакеты. Что, в свою очередь, увеличивает техническое обслуживание.
    • Проблема с современными платформами: Selenium может очень хорошо работать с приложением, созданным с использованием архитектуры старого стиля, когда речь идет о современных средах веб-разработки, таких как React, Angular, Vue и т. д., но может работать не очень хорошо.
    • Selenium не очень агрессивен в выпуске функций, в отличие от современной среды автоматизации тестирования, где он постоянно прислушивается к голосу пользователя и реализует новые функции и выпуски.

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

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

    2. Cypress

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

    Cypress предоставляет удобные для разработчиков функции, такие как простая настройка, установка, отладка, специальное окно Cypress для запуска тестов и т. д. .IO/

  • Лицензия: MIT
  • Данные GitHub
    • Пользователи: 699K
    • .0386 2.7K

    • Преимущества Cypress

    • Настройка среды автоматизации пользовательского интерфейса Cypress проста; как только вы установите, он готов.
    • Поддерживает различные типы тестирования; Cypress поддерживает Unit, Integration, Component, API Testing и End to end Testing.
    • Функция Cypress Time Travel обеспечивает моментальный снимок каждого шага теста.
    • Cypress записывает видео ваших тестов; вы можете настроить параметр скриншота.
    • Нет необходимости указывать ожидание явно. Cypress автоматически ждет, прежде чем выполнять какие-либо действия.
    • Тестирование Cypress надежнее и быстрее. В cypress нет концепции драйвера браузера. Cypress напрямую взаимодействует с браузером, поэтому тесты проходят быстрее и стабильнее.
    • Окно Interactive Test Runner в Cypress помогает ускорить разработку и отладку.
    • Отладка Cypress проста, поскольку предоставляет несколько вариантов отладки.
    • Поддерживает тесты Cypress Safari в WebKit.
    • Хорошо структурированная документация в Cypress облегчает изучение новых функций и концепций. Это помогает, особенно если вы только начали создавать среду автоматизации тестирования Cypress.
    • Сообщество Cypress растет, поэтому мы также можем ожидать хорошей поддержки сообщества в будущем.

    Ограничения Cypress

    • Ограничение перекрестного происхождения: Cypress официально задокументировал, что он поддерживает только URL-адреса одного и того же источника внутри теста. Например, если на вашем веб-сайте используется аутентификация Google, URL вашего веб-сайта будет равен 9.0385 www.xyz.com перенаправляет на signin.google.com . Поскольку google.com — это другой домен, Cypress не разрешает такое перенаправление. Предлагаемый обходной путь — этот вход должен обрабатываться программно. Это одна из основных причин, по которой многие организации все еще не решаются использовать Cypress.
    • Cypress поддерживает только язык программирования JavaScript/Typescript. Многие инженеры по автоматизации тестирования имеют опыт работы с Java или C#. Поскольку Cypress поддерживает только JavaScript, организация должна вкладывать средства в обновление своего набора навыков.
    • Cypress не поддерживает шаблоны объектов страниц, хотя модели объектов страниц могут быть реализованы в Cypress в некоторой степени, Cypress не рекомендует это делать.
    • Использование async/await в тесте Cypress может привести к неожиданному поведению теста.
    • Настройка параллельного тестирования в Cypress сложна и непроста.
    • Он не поддерживает несколько вкладок и окон, но Cypress упомянул об этом как о компромиссе.
    • Нет прямой поддержки инфраструктуры BDD, такой как Cucumber
    • в Cypress, вы обычно добавляете сторонние пакеты, что увеличивает обслуживание, и фреймворк постепенно становится нестабильным.

    Учитывая плюсы и минусы Cypress, он хорошо подходит для современных веб-приложений, таких как React, Vue, Angular и т. д. Нельзя отрицать тот факт, что это удобный инструмент для разработчиков. Cypress агрессивно предоставляет функции, но у него есть свои ограничения. Хотя, если вы знакомы с Javascript, вы можете пропустить async/await в Cypress.

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

    3. Драматург

    Playwright был запущен в 2020 году, и за несколько лет он повзрослел и привлек множество пользователей. Это связано с их агрессивной стратегией выпуска и хорошо документированным кодом.

    Драматург — это инструмент с открытым исходным кодом. Однако он привязан к бренду Microsoft. Это один из пионеров в безголовом тестировании браузера, что делает его популярным.

    Обзор драматургов

    • Лицензия: Apache-2.0
    • Официальный сайт: https://playwright.dev/
    • Данные GitHub
      • Пользователи: 22,5K
      • ВОЗМЕРЫ: 372
      • Звезды: 47,2K
      • : 47,2K
      • : 47,2K
      • . Преимущества Playwright

        • Поддержка нескольких языков программирования, таких как Javascript/Typescript, Python, Java, C# (.Net)
        • Поддержка нескольких браузеров, таких как Chromium, Firefox, Edge, Chrome и Safari (только выпуски Webkit)
        • Нет зависимости от веб-драйвера, поскольку Playwright напрямую выполняет команду в браузере. Таким образом, тесты сравнительно быстрее и стабильнее.
        • Протестируйте браузер Safari в Windows с помощью платформы автоматизации пользовательского интерфейса Playwright. Обычно браузеры Safari можно тестировать только с macOS, но Playwright предоставляет версию WebKit с исправлениями для Windows, которая больше похожа на Safari.
        • Поддерживает параллельное выполнение тестов в нескольких браузерах
        • Поддерживает все селекторы
        • Поддерживает современные фреймворки, такие как React, Angular и Vue.
        • Playwright codegen — программа для записи веб-тестов; Вы можете записывать тесты.
        • Playwright предлагает несколько способов отладки. Тесты можно отлаживать с помощью Playwright Inspector, Playwright Trace Viewer, инструментов разработчика браузера, отладчика кода Visual Studio, подробных журналов API однако вы можете настроить его с помощью Jest, Jasmine Mocha и т. д.
        • Драматург поощряет шаблоны проектирования Page Object Model.

        Ограничения Playwright

        • Хотя Playwright поддерживает Safari, это версия с открытым исходным кодом, которая представляет собой WebKit, а не фактический Safari
        • Он не поддерживает родные мобильные приложения.
        • Некоторые пользователи заметили, что некоторые языковые привязки нестабильны одновременно.
        • Вы можете расширить Playwright для Cucumber, но прямой поддержки нет. Это можно сделать с помощью сторонних плагинов или пакетов.

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

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

        4. WebDriverIO

        WebdriverIO не является новым фреймворком и существует уже давно. WebdriverIO чем-то похож на Selenium с JavaScript, так как внутри использует библиотеки Selenium.

        Это открытый исходный код и часть основы OpenJS.

         

         

        Краткий обзор данных WebdriverIO

        • Официальный сайт: https://webdriver.io/

        • 0 Лицензия1:

          1 Github Data

          • Users: 48.9k
          • Stars: 8k
          • Forks: 2.2k
          • Contributors: 471

        Advantages of WebdriverIO

        • WebdriverIO uses the Реализация Webdriver, поэтому он поддерживает все основные браузеры
        • Поддерживает почти 17 типов генераторов отчетов, WebdriverIO поддерживает несколько типов отчетов
        • WebdriverIO обладает широкими возможностями расширения, существует множество подключаемых модулей или пакетов на основе сообщества, которые можно легко интегрировать в инфраструктуру и расширить функции
        • WebdriverIO поддерживает шаблон объекта страницы.
        • WebdriverIO поддерживает несколько окон и вкладок
        • Нет ограничений для параллельного тестирования.
        • WebdriverIO может быть расширен для тестирования собственных мобильных приложений

        Ограничения WebdriverIO

        • WebdriverIO использует свои привязки протокола Webdriver, снова вводя еще один уровень. Хотя он поддерживает протокол Chrome DevTools для кросс-браузерного тестирования, вам нужно полагаться на Webdriver.
        • Новые выпуски нуждаются в миграции: Каждый раз, когда WebdriverIO выпускает новую версию, вы должны следовать руководству по миграции, чтобы изменить конфигурации.
        • Документация: Хотя вы можете найти документацию, она может показаться вам недостаточной, если вы новичок.
        • WebdriverIO поддерживает только языки javascript/typescript.

        WebdriverIO лучше всего подходит, если вы хорошо знаете Javascript; поскольку он расширяемый, вы можете создать надежную структуру с помощью webdriverIO. Однако, учитывая их документацию и поддержку сообщества, вы можете столкнуться с некоторыми трудностями при настройке фреймворка. Существуют плагины сообщества, которые вы можете подключить к своему фреймворку.

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

        5. TestCafe

        Многие могут не слышать название TestCafe, это еще один фреймворк на основе NodeJS, который поддерживает Javascript/Typescript из коробки. TestCafe — это инструмент автоматизации с нулевой конфигурацией.

        Это означает, что вы можете установить и запустить свой скрипт всего несколькими командами. TestCafe — это фреймворк с открытым исходным кодом.

        Данные TestCafe на Glance

        • Официальный веб -сайт: https://testcafe.io/
        • . 9,6K
        • Форки: 672
        • Авторы: 114

      . все необходимые функции установлены, и вы готовы начать тестирование.

    • TestCafe поставляется с набором необходимых функций; обычно нет необходимости устанавливать дополнительные пакеты зависимостей
    • Создание тестов в TestCafe легко и удобно для чтения
    • TestCafe выполняет команды в браузере, поэтому тесты становятся более стабильными и быстрыми
    • TestCafe поддерживает несколько вкладок или окон
    • TestCafe поддерживает параллельное тестирование
    • TestCafe поддерживает все основные браузеры.
    • Поддерживает шаблоны объектов страницы. Шаблон объекта страницы может быть разработан с помощью TestCafe.

    Ограничения TestCafe

    • Обучение: Вам необходимо изучить синтаксис TestCafe и вызовы API, чтобы использовать их
    • Синтаксис TestCafe отличается от других широко используемых фреймворков на основе JavaScript.
    • TestCafe поддерживает только языки программирования Typescript/Javascript
    • TestCafe имеет свои библиотеки утверждений, которые вам необходимо изучить. Настроить сторонние библиотеки утверждений с помощью TestCafe непросто.
    • TestCafe поддерживает только селекторы CSS.

    TestCafe хорош для начинающих, так как у него хорошая документация и все, что входит в его структуру. Однако он поддерживает только Javascript/Typescript. TestCafe не предоставляет столько настроек, сколько другие среды тестирования. Тем не менее, он все еще расширяем. При использовании TestCafe можно почувствовать разницу в синтаксисе, функциях и конфигурациях.

    6. NightwatchJS

    NightwatchJS — это платформа на основе NodeJS, созданная с помощью NodeJS, которая использует протокол Webdriver. BrowserStack поддерживает Nightwatch. Nightwatch можно использовать для комплексного тестирования, тестирования API, модульного тестирования и интеграционного тестирования с использованием комбинации сервисов NodeJS и API NightWatchJS.

    NightwatchJS Data at Glance

    • Official website: https://nightwatchjs. org/ 
    • License: MIT
    • Github Data
      • Users: 140K
      • Stars: 11.3K
      • Вилки: 1.1K
      • Участники: 110

    Преимущества NightwatchJS

  • 18 Простота установки и настройки0022
  • Тестовые сценарии NightwatchJS более читабельны
  • Его можно использовать для различных типов тестирования
  • Он поддерживает тестирование нескольких браузеров, таких как Chrome, Firefox, Edge и т. д.
  • Фреймворк NightwatchJS легко настроить или расширить
  • NightwatchJS поддерживает шаблон объекта страницы

    • Ограничения NightwatchJS

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

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

    7. Appium

    Appium — это среда автоматизации пользовательского интерфейса с открытым исходным кодом, которая поддерживает автоматизацию собственных мобильных приложений. С помощью Appium можно тестировать собственные мобильные приложения Android, iOS и Windows SDK. Appium поставляется с хорошим графическим интерфейсом, который помогает проверять и эффективно писать код.

    Data Appium на Glance

    • Официальный веб -сайт: http://appium.io/
    • Лицензия: Apache 2.0
    • Github Data
      • . 15,9K
      • Форки: 5,8K
      • Авторы: 324

    .

  • Кроссплатформенная поддержка Appium Обеспечивает кроссплатформенную поддержку Safari в IOS и Chrome, а также во встроенном браузере для Android, и тест безупречно работает на всех устройствах.
  • Appium поддерживает несколько языков программирования, таких как Java, Ruby, C#, PHP и Python
  • Платформа Appium может быть легко интегрирована с платформой Selenium.
  • Поддерживает реальные устройства, эмуляторы и симуляторы
  • Appium предоставляет инструмент записи, с помощью которого новички могут легко начать тестирование мобильных приложений.
  • Appium поддерживает облачное тестирование, такое как Browserstack и т. д.
  • Appium можно легко интегрировать с инструментами DevOps.

    • Недостатки Appium

    • Настройка среды Appium требует дополнительных усилий и опыта в программировании.
    • Интеграция отчетов затруднена по сравнению с другими платформами.
    • Appium поддерживает Android версии 4.3 и выше
    • Appium поддерживает гибридное приложение сложно; переход с браузера на нативное приложение требует написания сложного кода

    Appium — самый популярный фреймворк для мобильного тестирования. Однако установка требует опыта кодирования. Таким образом, новичок может чувствовать себя сложным. Appium можно интегрировать с Selenium; вы можете беспрепятственно заставить фреймворк работать на компьютере и мобильном устройстве с помощью настроенного фреймворка. Если у вас уже есть готовый фреймворк на основе Selenium и вы ищете инструмент для расширения фреймворка для мобильных приложений, то Appium — лучший выбор.

    8. Огурец

    Cucumber — это платформа с открытым исходным кодом для разработки и тестирования, управляемой поведением (BDD). Cucumber поставляется в различных вариантах, таких как Java, Javascript, SpecFlow для C# и т. д.

    Cucumber наиболее популярен из-за его интеграции с различными типами фреймворков. В настоящее время почти все основные фреймворки автоматизации поддерживают фреймворк Cucumber. Огуречные тесты написаны на языке Gherkin и называются файлами функций, а реализация написана в файле определения шага.

    Cucumber Data at Glance

    • Official website: https://cucumber.io/
    • License: MIT
    • Github Data
      • Users: 99.7K
      • Stars: 2.5K
      • Вилки: 2K
      • Вкладчики: 249

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

    • Недостатки Cucumber

    • Cucumber — это просто верхний слой вашей среды тестирования. Огурец сам по себе не может быть использован для построения фреймворка. Таким образом, тестировщики должны иметь навыки работы с TDD-фреймворком, таким как Selenium и Cypress
    • . Поддерживать фреймворк Cucumber сложно.

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

    Инструменты автоматизации бонусного тестирования

    9. Библиотеки автоматизации тестирования Puppeteer

    Puppeteer — это платформа с открытым исходным кодом, управляемая Google. Puppeteer построен на NodeJS и поддерживает языки программирования Javascript/Typescript. Puppeteer поставляется с лицензией Apache 2. 0. Puppeteer — лучший инструмент для скорости и стабильности, но главная проблема Puppeteer в том, что он официально поддерживает только браузеры на основе Chromium.

    Поддержка Firefox для Puppeteer все еще находится в экспериментальном состоянии. Puppeteer предоставляет обертку над протоколом Chrome DevTools, вам необходимо интегрировать библиотеки утверждений, такие как Jest Mocha и т. д. Для реализации Puppeteer требуется хорошее знание языка программирования Javascript.

    10. Инструмент автоматизации тестирования Katalon Studio

    Katalon Studio не является программой с открытым исходным кодом. Тем не менее, у него есть бесплатная версия; поскольку многие ручные тестировщики считают его полезным из-за функции записи и простой интеграции, мы упоминаем его здесь. Katalon Studio поддерживает системы на базе Windows, macOS и Linux. В бесплатной версии Katalon доступны ограниченные функции. Обратите внимание, что Katalon — это бесплатный инструмент, а не с открытым исходным кодом. В отличие от проекта с открытым исходным кодом, функции и ограничения контролируются Katalon. Он может измениться в любое время.

    11. Gauge Testing Framework

    Gauge — это платформа автоматизации тестирования с открытым исходным кодом, в основном используемая для приемочного тестирования. Калибровочные тесты содержат два файла: файл спецификации, который аналогичен файлу функций в Cucumber. Тем не менее, синтаксис будет другим, а другой файл — это файл реализации, который похож на файл определения в Cucumber. Gauge можно интегрировать с C#, Java, JavaScript ruby ​​и т. д. Его легко интегрировать с инструментом DevOps, а также он поддерживает выполнение параллельных тестов. Однако, поскольку пользовательская база меньше, поддержка Gauge сообществом значительно низка.

    Заключение

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

    Анализ и окончательная доработка платформы для вашей организации может занять некоторое время по сравнению со временем перехода на другую платформу через год. Переход на разные фреймворки с одного всегда рискован и требует времени. Не существует такой вещи, как «Лучший фреймворк для всего мира», но всегда найдется лучший фреймворк для вашей организации, так что выбирайте внимательно. Лучший способ начать процесс оценки — собрать требования, понять объем, выполнить меньший POC и завершить свою структуру.

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

      No related posts.