Ранее мы уже писали о том, когда бывает нужна автоматизация тестирования и какие проверки при этом используют. Сегодня предлагаем обсудить использование инструментов на практике и оценить их производительность. С разрешения Giovanni Rago – автора серии полезных материалов о тестировании – мы перевели его статью «Puppeteer vs Selenium vs Playwright: сравнение скорости» (Puppeteer vs Selenium vs Playwright, a speed comparison). Статья будет интересна тем, кто задумывается о выборе подходящего инструмента автоматизации в своих проектах.
От автора:
Для разработки системы мониторинга и тестирования Checkly мы решили использовать Puppeteer. Это инструмент автоматизации тестирования с возможностью включения headless браузера и открытым исходным кодом, позже мы также внедрили Playwright. Checkly помогает узнать, работает ли тестируемый сайт так, как ожидается в определенный момент времени. В нашем случае основной интерес вызывала скорость работы инструмента.
Задача определения наиболее быстрого инструмента автоматизации не так проста. Поэтому мы решили провести свой бенчмарк – тест производительности, чтобы сравнить “новичков” Puppeteer и Playwright с “ветераном” WebDriverIO (в связке с Selenium и протоколом автоматизации DevTools).
В результате проведения тестов мы сделали неожиданные открытия: например, Puppeteer работает быстрее на небольших скриптах, а WebDriverIO показывает больший разброс на длинных сценариях. Далее подробнее расскажем о наших результатах и о том, как мы их получили.
Почему мы сравниваем эти инструменты автоматизации?
Рассматривать Puppeteer/Playwright и Selenium – это всё равно что сравнивать яблоки с апельсинами: инструменты имеют существенно разные возможности и применяются в разных областях автоматизации, и тот, кто их оценивает, должен учитывать это, прежде чем анализировать скорость.
До этого многие из нас долгое время работали с Selenium, и мы очень хотели понять, действительно ли новые инструменты работают быстрее.
Важно заметить, что WebDriverIO – это высокоуровневый фреймворк с множеством полезных функций, который может запускать автоматизацию в нескольких браузерах, используя различные встроенные инструменты.
Опыт показывает, что большинство пользователей Selenium, которые работают с JavaScript, используют WebDriverIO для запуска автоматизированных скриптов. Именно поэтому мы выбрали его. Также нам было интересно протестировать новый DevTools режим.
Другой важной задачей для нас было сравнить Playwright, для которого мы недавно добавили поддержку в Checkly, с нашим любимым Puppeteer.
Методология, или как мы запускали тесты
Можете смело пропустить этот раздел, если хотите сразу перейти к результатам. Но мы рекомендуем всё же ознакомиться с ним. Это поможет лучше понять результаты тестов.
Общие рекомендации
В тестировании производительности нет никакого смысла, если проверяемые инструменты находятся в разных условиях. Во избежание этого мы составили рекомендации и следовали им:
Равенство ресурсов: каждый тест запускался последовательно на одной и той же машине “в состоянии покоя”, то есть ни одна ресурсозатратная рабочая нагрузка не выполнялась в фоновом режиме во время бенчмарка, так как это могло бы исказить измерения.
Простое выполнение: скрипты запускались так, как это было показано в документации к каждому инструменту и с минимальными конфигурациями. Например, для Playwright – node script.js
Сопоставимые скрипты: мы стремились минимизировать разницу в скриптах, которые использовали для бенчмарка. Некоторые инструкции всё ещё нуждаются в добавлении, удалении, настройке, чтобы добиться стабильного выполнения.
Самые свежие версии: для тестирования всех инструментов мы использовали их последние версии.
Одинаковый браузер: все скрипты выполнялись в headless Chromium.
В следующем разделе представлена дополнительная информация по всем пунктам.
Техническая настройка
Для каждого теста на производительность мы собрали данные из 1000 успешных последовательных выполнений одного скрипта.
В случае Selenium наши скрипты работали на отдельном сервере, то есть мы не запускали новый сервер для каждого прогона (хотя всегда использовали чистую сессию), как делают некоторые фреймворки. Мы приняли такое решение с целью ограничения накладных расходов на время выполнения.
Все тесты мы проводили на MacBook Pro 16 последнего поколения под управлением macOS Catalina 10.15.7 (19H2) со следующими характеристиками:
Модель: MacBookPro16,1
Процессор: 6-Core Intel Core i7
Скорость процессора: 2,6 ГГц
Количество процессоров: 1
Количество ядер: 6
Кэш-память L2 (на ядро): 256 Кб
Кэш-память L3: 12Мб
Технология Hyper-Threading: включена
Память: 16 Гб
Мы использовали следующие зависимости:
bench-wdio@1.0.0 /Users/ragog/repositories/benchmarks/scripts/wdio-selenium
+-- @wdio/cli@6.9.1
+-- @wdio/local-runner@6.9.1
+-- @wdio/mocha-framework@6.8.0
+-- @wdio/spec-reporter@6.8.1
+-- @wdio/sync@6.10.0
+-- chromedriver@87.0.0
L-- selenium-standalone@6.22.1
scripts@1.0.0 /Users/ragog/repositories/benchmarks/scripts
+-- playwright@1.6.2
L-- puppeteer@5.5.0
Скрипты, которые мы использовали вместе с результатами их выполнения, вы можете найти в GitHub-репозитории.
Измерения
Мы получили следующие показатели, все рассчитано на основе 1000 прогонов:
* Среднее время выполнения (в секундах).
* Стандартное отклонение (в секундах): показатель разброса времени выполнения.
* Коэффициент вариации (CV): безразмерный коэффициент, который показывает отклонение результатов от среднего.
* P95 (изменение 95-го процентиля): наибольшее значение, оставшееся после отбрасывания верхних 5% отсортированного списка полученных данных. Интересно было бы узнать, как выглядит не экстремальное, но все еще высокое значение.
Что мы не измерили (пока)
* Надежность: ненадежные сценарии быстро становятся бесполезными, независимо от того, насколько быстро они выполняются.
* Эффективность распараллеливания: параллельный запуск очень важен в контексте инструментов автоматизации. Однако в этом случае мы в первую очередь хотели понять, с какой скоростью может выполняться один скрипт.
* Скорость в нелокальных средах: также, как и распараллеливание, облачное выполнение является обширной темой, которая выходит за рамки этой статьи.
* Использование ресурсов: необходимые объемы памяти и вычислительной мощности помогут определить, где и как вы можете запускать свои сценарии.
Результаты
Ниже вы видите совокупные результаты тестирования производительности. Полные наборы данных вы можете найти в репозитории GitHub.
Запуск на демосайте
Первый бенчмарк запускался на нашем демонстрационном сайте. Эта веб-страница, размещенная на Heroku, создана на основе Vue.js и использует бэкенд на Express. В большинстве случаев данные с бэкенда фактически не извлекаются. Вместо этого фронтенд хранит данные на стороне клиента.
В первом сценарии при выполнении процедуры быстрого входа мы ожидали, что время выполнения составит всего несколько секунд. Это отлично подходит для выявления потенциальных различий в скорости запуска между реальными инструментами.
Общие результаты выглядят следующим образом:
Первое, что обращает на себя внимание — это большая разница между средним временем выполнения для Playwright и Puppeteer, причем последний почти на 30% быстрее и демонстрирует меньший разброс в его производительности. Мы задумались, не связано ли это с более длительным запуском со стороны Playwright. Мы не стали рассматривать этот и аналогичный вопросы, во избежание увеличения объема работ для первого бенчмарка.
Вторым сюрпризом стал более низкий общий разброс при запуске WebDriverIO. Также интересно, насколько близки результаты: на диаграмме линии непрерывно пересекают друг друга, поскольку протокол автоматизации, похоже, не оказывает существенного влияния на время выполнения в этом сценарии.
Возможно, менее удивительным является то, что запуск Puppeteer без добавления какого-либо высокоуровневого фреймворка помогает нам значительно сократить время выполнения этого очень короткого скрипта.
Запуск на реальном веб-приложении
Предыдущий опыт научил нас, что разницу между демонстрационной средой и реальным миром почти всегда недооценивают. Поэтому мы очень хотели, чтобы тесты производительности выполнялись на рабочем приложении. В этом случае мы выбрали Checkly для запуска интерфейса Vue.js и бэкэнда, который в значительной степени использует AWS.
Запущенный нами скрипт очень похож на классический тест E2E: вход в Checkly, настроенная проверка API, сохранение и тут же удаление. Мы с нетерпением ждали этого сценария, но у каждого из нас были разные ожидания относительно того, как будут выглядеть цифры.
В этом случае разница во времени выполнения между Playwright и Puppeteer почти исчезла. Playwright теперь выходит на первое место и демонстрирует немного меньший разброс.
Разница между новыми инструментами и обеими разновидностями WebDriverIO тоже соответственно меньше. Стоит отметить, что последние два теперь дают больший разброс в результатах по сравнению с предыдущим сценарием, в то время как Puppeteer и Playwright показывают меньшие отклонения.
Интересно, что наш первоначальный тест для этого сценария включал внедрение файлов cookie в совершенно новый сеанс, чтобы иметь возможность полностью пропустить процедуру входа в систему. Позднее от этого подхода отказались, поскольку мы столкнулись с проблемами на стороне Selenium, когда сеанс переставал отвечать после загрузки определенного количества файлов cookie. WebDriverIO хорошо справился с этим, но этап внедрения файлов cookie резко увеличил разброс времени выполнения. Иногда казалось, что на этом этапе происходит зависание более 5 секунд.
Теперь мы отступим назад и сравним время выполнения в разных сценариях:
Сомневаетесь в результатах? Запустите свой собственный бенчмарк! Вы можете использовать наши сценарии тестирования, представленные выше. Не уверены в настройке? Не стесняйтесь сообщать об этом, чтобы сделать сравнение лучше.
Заключение
Прежде всего, давайте рассмотрим инструменты от самых быстрых к самым медленным для обоих сценариев тестирования:
Наше исследование производительности позволило сделать несколько интересных выводов:
Хотя Puppeteer и Playwright используют сходные API, похоже, что Puppeteer имеет значительное преимущество в скорости на более коротких скриптах (по нашим наблюдениям, выигрыш составляет около 30%).
Скрипты Puppeteer и Playwright показывают более быстрое время выполнения (около 20% в сценариях E2E) по сравнению с вариантами Selenium и DevTools WebDriverIO.
Протоколы автоматизации WebDriverIO, WebDriver и DevTools показали сопоставимое время выполнения.
Выводы
При запуске большого количества более быстрых сценариев, если нет необходимости в кросс-браузерности, возможно, стоит запустить Puppeteer, чтобы сэкономить время. В более длинных сценариях E2E разница сводится к минимуму.
Имеет смысл подумать, необходим ли вам запуск установки большего количества barebone-систем. Возможно, что удобство дополнительных инструментов WebDriverIO стоит того, чтобы потратить немного больше времени на ожидание результатов.
Колебания времени выполнения могут не иметь большого значения в бенчмарках, но в реальном мире они могут накапливаться и замедлять сборку. Помните об этом при выборе средства автоматизации.
Глядя на прогресс с обеих сторон, мы задаемся вопросом, выйдет ли в будущем DevTools на передний план или WebDriver будет продолжать играть центральную роль в автоматизации браузеров. Мы предлагаем обратить внимание на обе технологии.
К переводу этой статьи нас подтолкнуло то, что мы, как и автор, при автоматизации тестирования наших проектов чаще всего использовали возможности WebDriver. Оценивая результаты данного исследования, мы планируем опробовать новые инструменты, такие как Puppeteer и Playwright.
Спасибо за внимание! Надеемся, что перевод был вам полезен.