Q&A по QA: разбираем вопросы митапа по автоматизации тестирования
Привет, Хабр!
В октябре мы провели онлайн-митап по тестированию, в котором спикеры из Badoo, Skillbox, Почтатех и SuperJob поговорили о своем опыте перехода от ручного тестирования к автоматизации, рассказали о подходах к стабилизации тестов для мобильных приложений и многом другом. Встречу посетили более 600 участников, а QA Lead SuperJob Антон Шкредов получил столько интересных вопросов, что мы решили сделать отдельный пост в блоге. Итогами разбора делимся под катом.
Запись митапа доступна по ссылке, а если смотреть неудобно, то главные тезисы доклада Антона можно почитать на Хабре.
1. Удалосьли с помощью Playwright в связке с CodeceptJS добиться того, что большинство тестов пишется универсально на веб и мобильный веб (переиспользование кода)?
Если такая фича нужна, то ее можно сделать, конечно. Достаточно при запуске тестов передавать необходимый конфиг: web, либо mweb. Но мы так не делаем, у нас веб и мобильная версия — два разных приложения (не адаптив), из-за этого довольно много различий, но есть и сходства, как правило, в элементах. Мы делаем базовый пейдж, на который ссылаются пейджи десктоп и мобайл, по сути, наследуются.
То есть мы переиспользуем только локаторы и обновляем их, соответственно, в одном месте. А тесты уже пишем отдельно под каждую платформу. Получается, что около 20% тестов дублируется, но это жертва во имя понятности и отсутствия оверхеда из-за этой универсальности. Мне кажется, автотесты в первую очередь должны быть понятными, а не содержать какую-то дополнительную логику внутри себя.
2. Как вы запускаете тесты в 15 параллельных потоков и, если не секрет, проводите их на железе или в облаке?
Запускаем тесты в 10 потоков, пользуемся встроенной в CodeceptJS фичей. Автотесты у нас атомарные, все завелось очень просто.
Прогон выполняется на наших железках, под них выделили сервера помощнее (по 32 ядра) — с учетом того, что на каждом сервере по три агента, такое количество оптимально (10 воркеров). Также, и сам Playwright позволяет масштабироваться, он запускает браузер один раз, а вся параллелизация уже проходит в контекстах, что-то вроде атомарных вкладок. За счет этого он точно ест меньше ресурсов.
3. Какие инструменты используете для скриншотного тестирования?
Эта задача состоит из двух этапов: сделать эталонный скриншот и сравнить его с фактическим. Скриншоты делаем с помощью Playwright, а сравниваем с помощью утилиты. Правда, мы ее немного подтюнили под Playwright, Allure и обновление эталонов через TeamCity. Также недавно вышел релиз тестраннера от Playwright, который умеет сравнивать скрины из коробки.
4. Как вы решаете проблему несоответствия версий веб-браузера и веб-драйвера? Hard code, какие-то фреймворки? Или такого не случалось у вас?
В Playwright эта проблема решена на уровне архитектуры. Вы выбираете версию Playwright, которую хотите использовать, и она с собой притянет правильные браузеры. Если хотите обновить браузеры — просто обновляете версию библиотеки. Прослойки в виде веб-драйвера нет вообще, так как используется DevTools-протокол.
5. Скажите, а для чего вам CodeceptJS? Почему бы не использовать сам Playwright с их собственным раннером?
Когда выбирали инструмент, Playwright еще не существовал. А у CodeceptJS конкурентов практически не было, все другие фреймворки на JS скорее заточены под Unit-тестирование (Jest, Mocha, AVA и т.д.).
Но на новом проекте мы как раз использовали тестраннер от Playwright, он все задачи выполняет из коробки, вплоть до поддержки Allure. Текущие автотесты переписывать уже не будем, но в новых проектах планируем его использовать.
6. Сколько у вас один инстанс браузера потребляет CPU и RAM?
Сильно зависит от того, что там вертится: недавно, например, увидели один Хром, который использует до 140% одного CPU и порядка 400MB RAM. Количество воркеров лучше всего подтюнить по факту запуска, мы пробовали гонять в разное количество потоков. На нашем железе и проекте оптимально 10.
7. Запускаете в обычном режиме или в headless? Большая разница по CPU и RAM?
Здесь у нас простой подход: пишем тесты локально в headful-режиме, а в CI гоняем headless, там нам интерфейс ни к чему.
8. Стабильность тестов выросла после перехода с Selenium Webdriver на Playwright? Если да, то насколько?
Набора одинаковых тестов на двух инструментах у нас не было, поэтому не могу дать точных цифр. Однозначно повысилась стабильность за счет встроенных ожиданий самого Playwright. Также мы получили возможность добавить осознанности в наши автотесты благодаря доступу ко всем запросам. Например, мы часто ожидаем успешный ответ от бэкенда, прежде чем начинать следующий шаг — делать это очень просто.
Пользуясь этим подходом, мы также проверяем отправку веб-аналитики. Если интересно, то скоро расскажу об этом подробнее и проведу мастер-класс на конференции TestDriven Conf 2022.
9. Selenoid не поддерживает Playwright. Хватает ли вам параллельных потоков при прогоне тестов? Что будете делать при масштабировании? Ведь при запуске огромного количества тестов на одной виртуалке, из-за создания множества контекстов, наверняка, тесты могут быть флаки в моменты пиковой нагрузки на CPU.
Selenoid довольно сильно нас выручил, когда мы использовали Webdriver, сейчас необходимость в нем пропала. С ростом количества тестов действительно возникает такой вопрос, даже больше скажу — текущие 30 минут для нас тоже уже много. Скорее всего, сейчас двинемся в сторону импакт-анализа, для более «умной» выборки тестов. Уже есть пара прототипов: как топорный — в виде парсинга коммита и попытки угадать затронутый функционал, так и более дорогой — в виде самописных анализаторов кода.
10. Какими инструментами тестируете API?
Мы используем Behat для тестов на API и Swagger для документирования. Кстати, недавно прикрутили к Behat-тестам отчет Allure, но пока не выгружаем их в TMS. Одна из задачек на будущее — добавить возможность запуска тестов через Allure TestOps по любой выборке (например, по конкретному эндпоинту) для всех слоев автотестов (в том числе, и UI-тестов на мобилках).
На этом все, надеемся было полезно. Присоединяйтесь к нашему уютному QA-чату в Телеграме, чтобы почитать больше вопросов и ответов, а также не пропустить анонсы новых митапов.
