Сравнение по скорости: Cypress, Selenium, Playwright, Puppeteer

В компании Checkly (специализация: e2e-тестирование и тестирование API) сравнили популярные тестовые фреймворки по скорости (производительности). Полученные результаты остаются релевантными: архитектура этих фреймворков не претерпела существенных изменений.

Ситуация с фреймворками 

Немного статистики; она, конечно, субъективная, как и любой опрос в интернете, но в какой-то мере показательная, т.к. количество опрошенных больше 30 тысяч. Аудитория по странам:

Популярность тестовых фреймворков - демография
Аудитория опроса о популярности QA фреймворков
Популярность тестовых фреймворков
Популярность тестовых фреймворков.
Удовлетворенность применяемым инструментом
«Ну, такое»
Узнаваемость
Знают о
Заинтересованность
Интересуются
Применение
Применяют на практике
Довольны использованием
Результатами доволен

В принципе, сравнивать Puppeteer/Playwright и Cypress/Selenium, как считают некоторые, это «сравнение теплого с мягким», поскольку у этих фреймворков свое предназначение. Все же, указанные инструменты самые популярные и активно применяются в веб-тестировании, следовательно есть необходимость знать их сравнительные характеристики по производительности.

Кроме того, существует запрос на замену неформального стандарта в индустрии (Selenium) инструментами более новыми, активно развивающимися, и возможно более совершенными (см. выше второй рисунок — Selenium самый ненавидимый инструмент).

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

О Cypress

В отличие от прочих «конкурсантов», Cypress не является инструментом «общего назначения», это в первую очередь, как утверждают его создатели, средство автоматизации сквозных тестов. Действительно, Cypress хороший инструмент сквозного тестирования, не будучи «классическим» фреймворком автоматизации или широкопрофильным инструментом приспособленным под тестирование бэкэнда. Cypress — инструмент, изначально заточенный под e2e-тесты веб-приложений, с отличными возможностями написания и дебага е2е-скриптов; но это трудно измерить цифрами, а мы дальше сосредоточимся на измеряемых вещах. Официальная документация говорит, что в Cypress можно тестировать в том числе live/production сайты, на практике тестируются в основном сайты в разработке. 

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

Методология

Собраны данные 1000 успешных последовательных запусков одного и того же теста. В сценариях не производилась запись скриншотов и видео.

Принципы

Общие принципы, на которых основывалось сравнение:

  • Паритет по ресурсам. Каждый тест запускался последовательно на компьютерах (рабочих ноутбуках) с одинаковой конфигурацией. При этом запуск тестов был основной задачей (в фоне не было других «тяжелых» задач, которые могли бы повлиять на результаты).
  • Сценарии готовились в максимально упрощенном виде и согласно указаниям официальной документации фреймворков, и при минимуме дополнительной настройки/конфигурации.
  • Сценарии в разных фреймворках были или идентичны, или очень близки к этому; некоторые мелкие элементы могли быть добавлены/изменены/настроены, это не должно было повлиять на результаты.
  • Применялись последние версии фреймворков (на то время)
  • Все тестовые сценарии выполнялись в headless Chromium.

Как упоминалось выше, собраны данные из 1000 запусков сценария. Cypress запускался командой cypress run. Что касается Selenium, скрипты запускались на standalone-сервере; то есть новый сервер не запускался для каждого запуска, (но всегда выполнялась очистка сессии).

Аппаратная конфигурация:

  • Компьютер: MacBook Pro 16,1
  • Процессор: 6-Core Intel Core i7
  • Тактовая частота: 2,6 GHz
  • Количество процессоров: 1
  • Процессорных ядер: 6
  • L2 кэш : 256 KB
  • L3 кэш : 12 MB
  • Hyper-Threading: Включен
  • Память: 16 GB

Операционная система: MacOS Catalina 10.15.7 (19H2).

Зависимости — стандартные, например для WDIO: CLI, local-runner, mocha, spec-reporter, sync

Тестовые скрипты (с объяснениями и комментариями) можно посмотреть на Гитхабе. Там же и дата-сеты.

Метрики:

  • Усредненное время выполнения, в секундах (Mean execution time в таблицах ниже)
  • Стандартное отклонение (девиация), показатель изменчивости (вариабельности) времени выполнения
  • Коэффициент вариации (CV), насколько полученный результат отклонялся от усредненного
  • P95 (95% процентиль), самое высокое значение, если самые экстремальные 5% значений не учитывать

Что НЕ измерялось:

  • Надежность (стабильность): ведь нестабильные сценарии бесполезны, хоть бы и были быстрыми
  • Эффективность параллелизации: параллельное выполнение сценариев важно в контексте автоматизации; но в нашем случае делали упор на скорости выполнения лишь одного сценария
  • Скорость в нелокальных тестовых окружениях: облачные операции уже часть стандартного процесса автоматизации, но здесь (для упрощения) не применяли
  • Утилизация ресурсов: утилизация памяти и процессорных ресурсов не учитывалась

Сценарии

Далее агрегированные результаты. 

Сценарий 1. Простой e2e-тест статического веб-сайта.

Первый бенчмарк проводился на демо-сайте. Его характеристики:

  • Сделан на Vue.js
  • Хостится на Heroku
  • Практически статичный — очень мало данных подтягивается из бэкэнда.

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

Выполнение сценария 1
Выполнение сценария 1

Этапы сценария:

  1. Переход к форме логина
  2. Заполнение юзернейма/почты
  3. Заполнение пароля
  4. Клик по кнопке

Например для Playwright код выглядит так:

const { chromium } = require('playwright')

;(async () => {

  const browser = await chromium.launch()

  const page = await browser.newPage()

  await page.goto('https://danube-web.shop/')

  await page.click('#login')

  await page.type('#n-email', process.env.USER_EMAIL)

  await page.type('#n-password2', process.env.USER_PASSWORD)

  await page.click('#goto-signin-btn')

  await page.waitForSelector('#login-message', { visible: true })

  await browser.close()

})()

Результаты оказались следующими:

Результаты по 1 сценарию
Результаты первого сценария

Итак, в первом бенчмарке между фреймворками нет большой разницы в скорости, если не считать Cypress, там сценарий запускался существенно дольше; при этом в самом Cypress время запуска отображалось как 3 с, но на практике ему понадобилось еще 7 секунд.

Результаты по этому сценарию:

Статический сайт - логин
Статический сайт — логин

В таких «экспресс-сценариях» разница по времени их выполнения должна была быть большой; Cypress получился в 3 раза медленнее чем WebDriverIO+Selenium, и в 4 раза медленнее чем Puppeteer.

Ситуация понятна, следующий сценарий — более комплексный, он будет более показательным.

Сценарий 2. Сквозной тест веб-приложения на продакшен-стадии 

Тестовое приложение — веб-приложение с такими характеристиками:

  • Фронтэнд на Vue.js
  • Хостится на Heroku
  • Бэкэнд на AWS
  • Большой поток данных между бэкэндом и фронтэндом, много анимации, есть сторонние зависимости, и много компонентов стандартных для веб-приложения в production-статусе.

Второй тестовый e2e-сценарий дольше и сложнее чем первый:

  1. Логин в приложение
  2. Создание API-Check (что это?)
  3. Удаление API-Check.
Выполнение сценария 2
Сценарий 2 — выполнение

Агрегированные результаты:

Результаты сценария 2
Результаты сценария 2

Как видим, Cypress продолжает уступать остальным в скорости, примерно на 7 секунд. Cypress получается примерно в 2 раза медленнее, чем лучший из фреймворков (Playwright); но уже не в 4 раза — так как сценарий более сложный, и заточенность Cypress на «большие тесты» начинает сказываться в позитивном ключе.

Сценарий 2
Сценарий посложнее

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

Сценарий 3. Тестовый набор и веб-приложение

В тест-свит входят предыдущие сценарии (включая “создание-проверку-удаление API-check”), и два новых e2e-скрипта; в обоих скриптах есть логин, создание данных (см. о alert channels и snippets на их сайте) и удаление.

В Puppeteer и Playwright тест-свиты выполнялись с помощью Jest. В других фреймворках использовались их встроенные функции.

3 сценарий
Сценарий 3

Агрегированные результаты:

3 сценарий - числовые результаты
Результаты по 3 сценарию

Как и предполагалось, разница между Cypress и остальными уже намного меньше; по результатам 1000 запусков среднее время оказалось лишь на 3% медленнее чем у связки WebDriverIO+Selenium (самый медленный инструмент в этом сценарии), и лишь на четверть медленнее чем в Playwright.

Тестовый набор - сравнение
Тестовый набор — результаты

Далее из сравнения были исключены результаты больше 50 секунд, что позволило лучше рассмотреть разницу между Cypress и WebDriverIO:

Разница уменьшается

Интересно, что с большим сложным тестовым набором WebDriverIO+DevTools более-менее постоянно показывал нестабильность времени выполнения, чего не наблюдалось с первым сценарием маленького короткого теста статического сайта. 

Результаты

Теперь все вместе:

Усредненная длительность выполнения сценариев
Усредненная длительность выполнения сценариев

Финальный рейтинг фреймворков:

Итоговое сравнение
Как-то не удивлен — Playwright лучший

Попарное сравнение фреймворков (в предыдущем материале Checkly, с почти теми же данными, но без 3 сценария):

Playwright vs Puppeteer - 1 сценарий
Playwright vs Puppeteer — 1 сценарий
Puppeteer vs WDIO-DevTools
Puppeteer vs WDIO-DevTools — 1 сценарий
WDIO-Selenium vs WDIO-WebTools
WDIO-Selenium vs WDIO-WebTools — 1 сценарий
Playwright vs Puppeteer - 2 сценарий
Playwright vs Puppeteer — 2 сценарий
Playwright vs Selenium - 2 сценарий
Playwright vs Selenium — 2 сценарий

Пришли к следующим выводам:

  • Cypress показывает стабильно большое время запуска теста (чем другие фреймворки), особенно в маленьких сценариях, но в больших (то есть стандартных) сценариях и тестовых наборах этот недостаток Cypress исчезает.
  • Cypress приблизительно равен Selenium по производительности в больших тест-свитах (то есть стандартных e2e). Чем больше количество тестов, тем лучше себя показывает Cypress.
  • Преимущество Puppeteer перед Playwright в коротких сценариях не распространяется на большие сценарии. 
  • Playwright, похоже, является лучшим фреймворком, что касается быстроты (производительности) «в целом», и в реальных сценариях.
  • Playwright и Puppeteer — самые производительные фреймворки, показывают самые лучшие результаты во всех 3 кейсах.
  • Playwright в real-world-сценариях демонстрирует стабильно лучшие результаты (с самой низкой их вариабельностью).

Советы

  • Cypress — хорошая вещь для локальных больших тестовых наборов e2e, в таких ситуациях его потенциал раскрывается полностью. Cypress неплох для live-сайтов, хоть и не самый лучший по скорости.
  • Сравнительно большое время запуска в Cypress может мешать его применению в распространенных синтетических сценариях мониторинга; но не существует большой разницы по производительности в случае классических больших e2e-наборов.
  • Для синтетического мониторинга live-сайтов и приложений Playwright видится лучшим вариантом.

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

***

Также по теме:

Playwright: полный гайд + FAQ (и таблицы сравнения с другими фреймворками / выбора под задачу)

Playwright: маленький быстрый гайд — экспресс-версия туториала для очень занятых мидлов

Кажется, Playwright уже лучше чем Cypress — субъективно, но правдоподобно

Puppeteer — большой гайд — туториал для Junior/Middle QA

Раздел по Автоматизации QA на сайте — другие QA-инструменты, раздел продолжает наполняться (пишите, чего не хватает)

Канал в Телеграме, посвященный только автоматизации

ТГ-канал для подготовки к собеседованиям

***

Какой была ваша первая зарплата в QA и как вы искали первую работу?

Мега обсуждение в нашем телеграм-канале о поиске первой работы. Обмен опытом и мнения.

1 КОММЕНТАРИЙ

Подписаться
Уведомить о
guest

1 Комментарий
Старые
Новые Популярные
Межтекстовые Отзывы
Посмотреть все комментарии
romale007
romale007
8 месяцев назад

Занимательная статья, спасибо! А шо там с работой с табами у Cypress?

Мы в Telegram

Наш официальный канал
Полезные материалы и тесты
Готовимся к собеседованию
Project- и Product-менеджмент

? Популярное

? Telegram-обсуждения

Наши подписчики обсуждают, как искали первую работу в QA. Некоторые ищут ее прямо сейчас.
Наши подписчики рассказывают о том, как не бояться задавать тупые вопросы и чувствовать себя уверенно в новой команде.
Обсуждаем, куда лучше податься - в менеджмент или по технической ветке?
Говорим о конфликтных ситуациях в команде и о том, как их избежать
$1100*
медианная зарплата в QA в июне 2023

*по результатам опроса QA-инженеров в нашем телеграм-канале

Собеседование

19%*
IT-специалистов переехало или приняло решение о переезде из России по состоянию на конец марта 2022

*по результатам опроса в нашем телеграм-канале

live

Обсуждают сейчас