Автотесты на python с чего начать
Порараз бирацца: как мы учились писать автотесты на Python и что у нас получилось
Привет, Хабр! Меня зовут Артем Иванюта, в «Магните» я занимаюсь тестированием информационных систем закупок. В статье я расскажу, как наша команда запускала автотесты web-интерфейсов силами одного сотрудника, как мы вписали их в CI/CD-процесс и с чем столкнулись, решая задачу. Кстати, вы наверняка уже догадались, но все-таки скажу — да, я и есть тот самый «один сотрудник». Так что никакого кликбейта.
Одиннадцать друзей Иванюты
В нашей команде 11 человек, мы отвечаем за тестирование 15 информационных систем. Всего в «Магните» их больше 600. Мы занимаемся тестированием web-инструментов цепочки поставок розничной сети. Это, например:
система автоматизированных рабочих мест сотрудников;
SRM-система снабжения сырьем собственных производств и закупочной логистики;
электронный документооборот EDI;
информационная система графика поставок товара в магазины,
система управления ареалами AMS.
В масштабах «Магнита» это 25 000 пользователей — наших сотрудников, 4 500 — контрагентов и 16 000 торговых точек. Мы производим релизы ежедневно, а сам цикл в среднем составляет от 2 до 4 недель. По сути от нас зависит своевременная поставка товаров тысяч поставщиков на полки 16 тысяч магазинов (и много чего еще).
Восстание машин: срываем релизы
Мой путь в компании начался в 2014 году с отдела технического сопровождения торговых точек. Я занимался удаленной поддержкой и настройкой оборудования в гипермаркетах «Магнит». Это были кассы, системы эквайринга, серверы.
В 2018 году отдел тестирования запустил внутреннюю школу тестировщиков. За месяц я освоил базу и навыки, а затем перешел в команду тестирования web-интерфейсов. Пришел я как раз вовремя: поток входящих задач начал стремительно расти. Компания пошла по пути DevOps. Запускались новые системы, серьезно обновлялись основные.
К началу 2019 года объем тестирования увеличился вдвое. Так количество тикетов на каждого возросло в среднем с 30 до 70 в месяц, а горизонт планирования релизов сдвинулся на 2 месяца вперед.
При этом количество людей в команде оставалось прежним — все те же 11 друзей Иванюты:)
Когда графики релизов начали срываться на регулярной основе, а рутинные операции занимать больше 50% времени, мы поняли, что дальше так не потянем. Тогда и было принято решение часть сценариев покрыть автотестами.
Путь в питонисты
До 2019 года никто из нашей команды не занимался автотестами, 100% тестов обрабатывались вручную. Никто из нашей команды не умел кодить. И конечно мы не могли снижать темп основных задач. Поэтому всей командой уйти в обучение автоматизации тестирования тоже было нельзя. Решили, что в разведку пойдет кто-то один. Мне было интересно попробовать: я изучил опыт сообщества и остановился на python. Python считается универсальным языком, поскольку подходит под множество задач. К примеру, на Python написан Instagram, его используют в аналитике данных, запуске космических кораблей и. в автоматизации тестирования. Чтобы скорость работы команды не снижалась, приняли совместное решение — я иду обучаться, команда забирает 80% моих задач.
Какие цели мы поставили для внедрения автотестов:
Увеличение скорости тестирования.
Мы накопили довольно большую библиотеку регрессионных сценариев тестирования различных веб-интерфейсов. Релизы в команде проводятся каждый день, поэтому регресс востребован и выполняется тестировщиками регулярно вручную. Его выполнение занимало не меньше 8 часов, а автоматизированные тесты могли сократить время на обработку регресса до 95% и больше.
Повышение качества тестирования.
При частом прогоне рутинных проверок всегда есть риск пропустить ошибку. Машина же совершит её с меньшей вероятностью за счёт многократного прогона автотестов. Разработчик самостоятельно может запустить автотестирование после изменения кода без помощи тестировщика. То есть это время команды освобождается для других задач.
Разработанные автотесты нужно сопровождать и развивать. Мы решили сделать ставку на развитии своей команды и запустили «Школу автотестирования». Я на себе прочувствовал, как «заряжает» обучение на реальных задачах. В Магнит я прошел такой опыт дважды, получив и новую экспертизу, и развитие. Программу Школы выстроили по такому же принципу — много практики и реального опыта.
Поддержка DevOps-стратегии компании.
В 2018 году «Магнит» взял курс на развитие DevOps. Наши 15 систем не стали исключением. Их ждали обновление и переход на новые практики и инструменты. Автотесты — одна из обязательных стадий процесса CI/CD.
Вот так архитектурно он выстроен у нас:
Так мы договорились о целях и тактике. Следующая задача — понять, что именно покрывать автоматизацией.
Автоматизируем регресс
Мы обновляем информационные системы «Магнита» под условия бизнеса практически ежедневно:
Во-первых, мы следуем конкретному плану изменений и обновлений систем. Такой план формируем внутри ИТ ежемесячно для каждой системы.
Во-вторых, пользователи от бизнеса направляют запросы на новый функционал. В среднем на сотрудника приходится по 2–3 системы в день.
Получается, попытка автоматизировать все кейсы сразу была бы обречена на провал: сил могло хватить только на актуализацию тестовых сценариев.
После анализа всей базы тестовых случаев для автоматизации выбрали регрессионные сценарии.
Для нас регресс — один из самых трудоемких этапов тестирования, так как он направлен на проверку и выявление ошибок в статичном функционале. Такой функционал или не меняется, или меняется редко. Значит, каждый день мы выполняем именно типовые проверки.
В каждом регрессионном сценарии более 100 кейсов. Зачастую кейсы связаны между собой. Поэтому первое, что я сделал, — провел анализ тестовых случаев на предмет критичности и взаимосвязи функциональности.
В TMS системе TestRail создал 3 группы приоритета регрессионных сценариев для последующей автоматизации:
Критичный — например, кейсы направлены на проверку доступности всех вкладок, кнопок, фундаментальной логики приложения. Ошибки в этой группе тестов могут привести к полной блокировке работы инструмента;
Высокий — кейсы в большей степени направлены на проверку бизнес-логики и алгоритмов инструмента. Ошибки в этой группе тестов могут привести к некорректным данным, повлиять на работу самого приложения и связанных с ним систем;
Низкий — кейсы не влияют на бизнес-процессы, но должны выполняться при каждом регрессе. Например, поиск, фильтрация и другие.
Теперь расскажу про пошаговую настройку процесса и инструментов.
Запускаем змея на Pytest
Я использовал Python и его фреймворк Pytest. Оба инструмента широко используются в мире тестирования, по ним накоплена база знаний, есть много плагинов. Поэтому вместе с Selenium WebDriver такой набор удовлетворяет всем потребностям в тестировании web-интерфейсов.
Для работы с базой данных я использовал библиотеку SQLAlchemy. Это одна из самых популярных библиотек для работы с СУБД для Python.
При создании структуры проекта брал паттерн Page Object. Этот шаблон проектирования позволяет разделить код тестов и описание страниц. Так тесты приобретают читаемый вид, а методы работы со страницей мы можем переиспользовать. Результат: упрощаем поддержку кода и уменьшаем его количество.
Структура проекта выглядит так:
Configuration – для настройки подключения к БД, учетные данные для авторизации в приложении;
Locators – хранит локаторы для поиска элементов на странице;
Pages – содержит методы для работы со страницами. Для каждой вкладки приложения используется своя страница с методами работы с ней;
Tests – хранит сами тесты;
Tools – хранит инструменты для подключения к БД. Это создание самого подключения, методы работы с БД, запросы к БД.
conftest.py — хранение фикстур. Фикстуры в контексте pytest — это вспомогательные функции для наших тестов, которые не являются частью тестового сценария;
pytest.ini – для регистрации меток маркировки тестов;
requirements.txt – файл зависимостей приложения для автоматической установки пакетов python с помощью утилиты pip;
testrail.cfg – конфигурационный файл с настройками для TestRail.
Помещаем в base_page методы или локаторы, которые используются в кейсах для разных страниц:
Как в итоге выглядит тест? Лаконично 🙂
В pages мы расписываем сами методы. Клик на кнопку:
Для поиска элементов на странице я использовал язык запросов XPath. Часть элементов страницы имеют уникальные name или id, которые указали разработчики фронта, поэтому к ним легко обращаться:
А другая часть не имеет таких уникальных идентификаторов, поэтому здесь помогают возможности языка XPath:
Запуск и закрытие браузера вынесены в conftest.py.
Добавляем функцию, например так:
В самом тесте мы не расписываем авторизацию и переход на нужную вкладку, это все выносится в setup с помощью фикстуры:
Ключ на старт: запускаемся через Gitlab CI
Для каждого проекта есть свой job в Gitlab CI, который запускается при необходимости. Последняя версия проекта тянется с репозитория.
Прогон самих тестов происходит на Selenoid. С помощью графической оболочки можно увидеть информацию о запущенных браузерах, их версиях, разрешении.
Развернув интерфейс тестирования можно увидеть, что происходит в режиме реального времени:
Фреймворк Pytest позволяет выбрать часть кейсов или пропускать те, которые сейчас не нужны. Например, для кейсов по одной вкладке приложения ставим маркировку @pytest.mark и запускаем тестирование нужной вкладки приложения. Фикстуры позволяют запустить тестирование в нужной версии браузера.
Получаем отчет в TestRail
Так выглядит результат выполнения автотестов, переданный в TestRail:
В названии передаю id джобы и название интерфейса, который тестирую. Вижу полную информацию по тестам, которые прошли успешно:
и детальную информацию по ошибкам, если они есть:
Как интегрировать автотесты в CI-процесс
Переменная CI_PIPELINE_ID добавлена для идентификации сборки в TestRail.
После пуша в ветку запускается сборка по алгоритму. Описание храним в файле gitlab-ci.yml. Если стадия автотестов пройдёт успешно, то актуальная версия выкатит в продакшн.
Автотесты во спасение или Выход из штопора
План сработал, мы смогли запустить автоматизацию и разгрузить команду:
Среднее время выполнения регрессионного сценария сократилось на
95% и стало занимать 20 минут;
Сократилось время выпуска релизов (Time To Market), а их количество в месяц выросло с 4 до 6;
Добились отказоустойчивости программного продукта при поставках, исключили риски в регрессе;
Из 1000 тестовых кейсов повысили количество покрытых автотестами до 400.
Этот год стал челленджем для всей команды и для меня лично.
Мы сделали выбор в пользу TestRail из-за его интеграции с основным инструментом тестирования Pytest. Плюсом стало наличие готовых фреймворков. Gitlab CI используется в разработке информационных систем коммерции и полностью соответствует нашему запросу. Поэтому предпочли тому же Jenkins.
По хорошей традиции запустили школу «Автоматизации тестирования» на практике, наш опыт может быть полезным другим командам тестирования в «Магните». Первые студенты-тестеры завершили обучение. Так практические навыки распространяются в компании.
Наша команда покрыла автотестами регресс на web-приложениях, сейчас мы готовы автоматизировать функциональное тестирование. Впереди более сложные задачи, и конечно нам будет полезен ваш опыт:
С какими проблемами перехода на автоматизацию тестирования столкнулись вы?
Как решали сложные кейсы автоматизации функционального тестирования?
Автоматизированное тестирование с Pytest
Перевод статьи подготовлен специально для студентов курса «Python QA Engineer».
Мы живем в эпоху, когда программное обеспечение очень быстро отправляется на рынок. Из-за этого процесс разработки становится очень стрессовым. Высокие темпы внедрения ПО и быстрая доставка выглядят как хорошая составляющая бизнес-модели, однако здесь возникает вопрос о том, как поставлять программное обеспечение надлежащего качества.
Почему нужны автоматизированные тесты
У автоматизированного тестирования есть множество плюсов, вот три основных:
Переиспользование: Нет необходимости писать каждый раз новые скрипты, даже при выпуске новой версии операционной системы, если только в этом не появится острая необходимость.
Надежность: Люди склонны совершать ошибки, а машины совершают их с меньшей вероятностью. А еще они работают быстрее при выполнении повторяющихся шагов/тестов, которые необходимо выполнять постоянно.
Работа 24/7: Вы можете запустить тестирование в любое время суток даже удаленно. Если запустить тестирование ночью, то оно будет выполняться даже пока вы спите.
Развитый полнофункциональный инструмент тестирования pytest на Python
В настоящее время существует множество фреймворков и инструментов для тестирования. Встречаются разные разновидности фреймворков, например, управляемые данными, управляемые ключевыми словами, гибридные, BDD и т.д. Вы можете выбрать тот, который лучше всего будет отвечать вашим требованиям.
Должен сказать, что Python и pytest занимают огромную нишу в этом вопросе. Python и связанные с ним инструменты широко используются, вероятно потому, что они более доступны для людей, имеющих мало опыта программирования по сравнению с другими языками.
Фреймворк pytest позволяет легко писать небольшие тесты, но также масштабируется для поддержки сложного функционального тестирования приложений и библиотек.
Несколько ключевых особенностей pytest :
Автоматическое и конфигурируемое обнаружение тестов
Давайте посмотрим на очень простую тестовую функцию:
Шаблонный код? Не переживайте, фикстуры спешат на помощь!
Посмотрите на тестовые функции, которые тестируют базовые операции в программе Wallet:
В более контролируемой среде у вас может быть файл с тестовыми данными, например test-data.ini в вашем репозитории или оболочке, которая сможет его прочитать, при этом ваша тестовая функция может вызывать различные оболочки для чтения тестовых данных.
Но у меня есть тестовые случаи, которые я хочу выполнять на различных наборах данных!
Не беспокойтесь, у pytest есть классная функция для параметризации вашей фикстуры. Давайте посмотрим на примере.
Предположим, что у вашего продукта CLI – интерфейс, который управляется локально. Кроме того, у вашего продукта есть множество параметров по умолчанию, которые устанавливаются при запуске, и вы хотите проверить все значения этих самых параметров.
Вы могли подумать о написании отдельного тест-кейса для каждого из этих параметров, но с pytest все намного проще!
Круто, не правда ли? Вы только что написали 13 тест-кейсов (каждый устанавливает разное значение setting_value ), а в будущем, если вы добавите новый параметр в свой продукт, то все, что вам нужно будет сделать – это добавить еще один кортеж.
Как pytest интегрируется с тестированием пользовательского интерфейса с Selenium и тестами для API?
Что ж, у вашего продукта может быть несколько интерфейсов. CLI – как мы говорили выше. Аналогично GUI и API. Перед развертыванием вашего программного продукта важно протестировать их все. В корпоративном программном обеспечении, где несколько компонентов взаимосвязаны и зависят друг от друга, изменение в одной части может повлиять на все остальные.
Например, на высоком уровне это может быть проверка структуры репозитория.
Как вы видите на изображении выше, он дает хорошую возможность разделять компоненты:
apiobjects: хорошее место для создания оболочек для вызова конечных точек API. У вас может быть BaseAPIObject и производный класс, отвечающий вашим требованиям.
helpers: Можете добавить сюда свои вспомогательные методы.
pageobjects: шаблон архитектуры PageObjects можно использовать для создания классов различных страниц GUI. Мы используем Webium, который является библиотекой реализаций шаблонов Page Object для Python.
suites: вы можете написать свои наборы pylint-проверок для кода, они помогут получить большую уверенность в качестве вашего кода.
tests: вы можете каталогизировать тесты на основе ваших предпочтений. Это позволит легко управлять и обозревать ваши тесты.
Я привел это просто для справки, структура репозитория и зависимости могут быть организованы с учетом ваших личных потребностей.
У меня много тест-кейсов, и я хочу, чтобы они выполнялись параллельно
У вас может быть множество тест-кейсов в вашем наборе, и случается, что нужно запустить их параллельно и сократить общее время выполнения тестирования.
Давайте посмотрим, как он работает на примере.
У меня есть репозиторий автоматизированного тестирования CloudApp для моих GUI тестов на Selenium. Помимо этого, он постоянно растет и пополняется новыми тестами и теперь в нем лежит сотня тестов. То, что я хочу сделать – это запустить их параллельно и сократить общее время выполнения тестирования.
В терминале просто введите pytest в корневой папке проекта/папке с тестами. Это позволит выполнить все тесты.
pytest-xdist запустит все тесты параллельно!
Таким способом вы также сможете параллельно запустить несколько браузеров.
Отчеты
Pytest поставляется со встроенной поддержкой создания файлов с результатами тестирования, которые можно открыть с помощью Jenkins, Bamboo или других серверов непрерывной интеграции. Используйте следующее:
Это поможет сгенерировать отличный XML-файл, который можно открыть множеством парсеров.
Заключение
Автоматизация тестирования на Python. Шесть способов тестировать эффективно
Мы уже говорили об автоматизации тестирования, теперь пришло время познакомиться с шестью лучшими инструментами автоматизации тестирования на Python.
Есть хорошая новость – в стандартной библиотеке Python уже есть отличные инструменты для модульного тестирования. Вы можете очень долго строить надежную автоматизацию тестирования с помощью встроенных возможностей языка. Но добавить автоматизацию в стандартную базу кода Python очень просто, поскольку этот язык используется для различных задач, в том числе для создания самих инструментов автоматизации тестирования.
Вы можете настроить нужную степень и уровень автоматизации тестирования на Python, и создавать тесты в соответствии с растущей базой кода.
PyUnit и Nose2
PyUnit – это фреймворк юнит-тестирования на Python. Его добавили в стандартную библиотеку Python еще в версии 2.1, он совместим со всеми последующими версиями языка. PyUnit – это реализация JUnit на Python, стандартного фреймворка юнит-тестирования Java. Именно поэтому разработчики, которые переходят с Java на Python найдут его очень простым в использовании. Оба фреймворка обязаны своим существованием фреймворку для тестирования на Smalltalk от Кента Бека.
PyUnit содержит все необходимые инструменты для создания автоматизированных тестов.
Фикстуры, с помощью которых вы можете создавать и удалять объекты, необходимые для теста.
Методы для выполнения тестов.
Наборы для группировки классов тестов в логические юниты.
Раннеры для выполнения тестов.
Вот пример базового юнит-теста:
PyUnit – отличная вещь для начала настройки автоматизации тестирования на Python, но это лишь базовый набор инструментов. Вам еще понадобятся инструменты для автоматизации выполнения тестов и сбора результатов. Здесь в игру вступает Nose.
Nose2 – это следующий шаг после PyUnit. Он добавляет поддержку автоматического обнаружения тестов и плагины для выполнения тестов и создания документации. Система плагинов Nose2 добавляет дополнительный функционал в виде декораторов, параметризированных тестов и поиска тестов. Например, AllModules находит все тесты и собирает из них выходные данные.
Nose2 также содержит Such – DSL для написания функциональных тестов.
PyTest
PyTest (https://pytest.org/en/latest/) – нативная библиотека тестирования на Python, она содержит расширенный набор функций PyUnit. По сравнению с моделированием архитектуры JUnit, она определенно написана в стиле Python. Она активно использует декораторы и ассерты Python.
PyTest также поддерживает параметризированное тестирование (без плагинов по типу Nose), что упрощает переиспользование кода и его покрытие тестами.
Если вы перепишете под Pytest тот тест, который мы написали выше, он будет выглядеть более декларативным.
PyTest использует тестовые фикстуры для передачи Widget методу тестирования.
В дополнение к фикстурам, тестовым наборам и тест-раннерам, в PyTest есть собственная поддержка поиска тестов. Вы можете выбрать наборы тестов для запуска, основываясь на именах методов, пактов или декораторов, которые вы добавляете в код тестов. Еще PyTest умеет выполнять тесты параллельно. При использовании этих функций одновременно, вы облегчите себе управление большими базами кода по сравнению с PyUnit.
PyTest упрощает создание отчетов в виде обычного текста, XML или HTML. Также вы можете добавить информацию о покрытии кода в отчеты PyTest.
Несмотря на то, что PyTest можно использовать самостоятельно, вы можете интегрировать его с другими фреймворками тестирования и тест-раннерами, такими как PyUnit и Nose2. Благодаря такой совместимости PyTest станет отличным выбором для растущих проектов, которым нужно хорошее покрытие тестами. Для PyTest нужен Python 3.6 или более поздние версии.
Behave
PyUnit и PyTest – мощные традиционные фреймворки для юнит-тестирования, но что, если вам нужны behavior-driven тесты?
Behave – это behavior-driven (BDD) фреймворк для тестирования. Он критически отличается от PyUnit и PyTest. В нем вы пишете тесты на Gherkin вместо Python. Несмотря на то, что здесь не оригинальный Gherkin от Cucumber, в Behave есть полная поддержка Gherkin, поэтому он является одним из самых популярных BDD-фреймворков для Python.
Behave настолько распространен, что даже у Jetbrains есть для него плагин в PyCharm Professional Edition. Также существует множество онлайн-руководств и документации для работы с Behave.
Вы описываете тесты грамматикой естественного языка, и описываете функцию с точки зрения поведения и ожидаемых результатов тестирования. Затем вы пишете свои тесты с аннотациями, которые соответствуют поведению и условиям. Behave запускает тесты, собирает результаты и документирует их в виде файлов поведения.
Если вы интересуетесь или даже уже используете behavior-driven разработку (BDD), Behave – один из лучший вариантов для этого. Он поставляется с интеграциями как для Django, так и для Flask, так что вы можете использовать его в full-stack проектах.
Тест из предыдущих примеров можно реализовать на Behave, как представлено ниже.
Вот грамматика естественного языка:
А вот код на Python. У Given, When и Then есть соответствующие аннотации.
Lettuce
Lettuce – это behavior-driven инструмент автоматизации для Selenium и Python. Подобно Behave, он использует синтаксис Gherkin для описания тестовых сценариев, но у него не такая совместимость, как у Behave. Lettuce не так распространен, как Behave, однако он хорошо работает с небольшими проектами.
Его также легко интегрировать с другими фреймворками, такими как Selenium и Nose.
Тесты на Lettuce чем-то напоминают тесты на Behave. Вот как это выглядит на естественном языке:
А вот код. Вместо отдельной аннотации для каждого шага теста, Lettuce аннотирует сам step.
Когда вы интегрируете Lettuce с Selenium, у вас получается надежный фреймворк для тестирования приложений на Django. Так что, если вам не нравится синтаксис Jasmine с JavaScript, этот вариант может оказаться наилучшим.
Однако Lettuce не обновлялся с 2016 года. Вы все еще можете скачать его и использовать в коде, но больше он не поддерживается.
Jasmine для автоматизации тестирования на Python
BDD – не просто популярная парадигма разработки на Python, также она широко распространена в веб-разработке. Jasmine – популярный фреймворк для тестирования веб-приложений в стиле BDD. Скорее всего вы думаете о Jasmine, как об инструменте тестирования приложений на JavaScript, но вы вполне можете использовать его для автоматизации тестирования на Python.
Благодаря Jasmine-Py вы можете добавить Jasmine в свои проекты на Django. Так вы сможете запускать Jasmine из вашей среды Python и с вашего сервера CI/CD.
Тестирование веб-приложений на основе поведения, а не DOM, делает ваши тесты более устойчивыми к изменениям. Это становится огромным преимуществом в тот момент, когда вы тестируете как код на Django создает страницы. Вместо Gherkin вы будете писать тесты в грамматике Jasmine.
Результаты можно применить как к своему веб-сайту, так и к коду на Django.
Фреймворк Robot
Фреймворк Robot – это открытый фреймфорк автоматизации тестирования. Организации используют его для автоматизации приемочного тестирования. Вы пишете тесты в DSL фреймворка Robot, синтаксисе, который используется для создания приемочных тестов.
Вместо того, чтобы ориентироваться на поведение, как в Jasmine, Robot ориентируется на ключевые слова.
Ключевое слово – это любая функция или метод, которые вы можете вызвать в тесте. Ключевые слова определяются либо в Robot, либо в основной системе, либо в пользовательских библиотеках для тестирования. Также вы можете определять новые ключевые слова в терминах уже существующих ключевых слов.
Можно расширить возможности Robot с помощью библиотек для тестирования, написанных на Python или Java. Таким образом, в дополнение к использованию этого фреймворка для тестирования кода на Python, вы можете расширить Robot с помощью Python. Также у вас есть доступ к обширной библиотеке плагинов для Robot.
DSL фреймворка позволяет легко создавать сценарии для автоматизации тестирования. С помощью правильного набора плагинов вы можете автоматизировать почти любой аспект приемочного тестирования. Еще вы можете создавать новые ключевые слова более высокого уровня, используя уже существующие.
Вам определенно нужна автоматизация тестирования на Python
В последние десять лет популярность Python неуклонно росла. Ее рост вы можете увидеть в индексе TIOBE. Велика вероятность, что вы уже пишете на Python или планируете добавить его в свой инструментарий в ближайшее время.
Расширение области применения Python привело к распространению фреймворков, инструментов тестирования и других утилит. Вне зависимости от того, создаете ли вы REST-сервис на бэкенде или любое другое приложение, для вас найдется подходящий фреймворк для автоматизированного тестирования.
Какой из них будет лучше отвечать вашим потребностям? У Testim есть руководство, которое поможет вам принять взвешенное решение. Обратитесь к нему и начните тестировать на Python уже сегодня.
Перевод подготовлен в рамках курса «Python QA Engineer». Приглашаем всех желающих на день открытых дверей онлайн: на этой встрече узнаете больше о программе курса и формате обучения, познакомитесь с преподавателем. Регистрация здесь.