Обзор
Медленная загрузка или отсутствие отклика у веб-страниц негативно сказываются на финансовых показателях, поскольку разочарованные пользователи, скорее всего, не вернутся даже после устранения проблемы. Поэтому тестирование производительности стало неотъемлемой частью цепочки разработки, и спрос на него продолжает расти.
Платформы для тестирования производительности предлагают широкий спектр методов моделирования нагрузки, включая HTTP, headless-браузеры и реальные браузеры. В этой статье мы рассмотрим основные аспекты каждого подхода, а также предложим сравнительную таблицу, которая поможет выбрать наиболее подходящий вариант.
Моделирование нагрузки на основе HTTP
В начале цифровой эпохи тестирование на основе HTTP было очень популярным. Однако с развитием богатых веб-клиентских технологий такие подходы постепенно устарели. Типичный HTTP-драйвер теста выполняет сервисные запросы и анализирует ответы. Современные приложения Web 2.0 содержат множество клиентских скриптов, которые полностью игнорируются и не измеряются при таком типе тестирования. В худшем случае сложные сценарии невозможно смоделировать на уровне протокола из-за отсутствия сгенерированных на клиенте идентификаторов.
Благодаря архитектуре, основанной на запросах и ответах, нагрузка на машину генерации нагрузки минимальна. Типичный сервер нагрузочного тестирования способен обрабатывать до 800 одновременных сессий. Однако реализация сложных сценариев на уровне протокола может быть затруднена. Инженеру по производительности приходится работать с cookie, ID сессий и другими динамическими параметрами. В зависимости от системы, названия полей форм могут меняться при каждом обновлении, что приведёт к сбоям HTTP-скриптов.
Моделирование нагрузки на основе headless-браузеров
С развитием Web 2.0 технологий индустрия тестирования столкнулась с серьёзными трудностями. Богатые браузерные приложения стало невозможно тестировать на уровне протокола из-за отсутствия клиентской логики при воспроизведении скриптов. Поэтому были разработаны headless-браузеры, такие как HtmlUnit, PhantomJS и SlimerJS. Они часто основаны на движке WebKit, используемом в Chrome и Safari.
Headless-браузеры похожи на обычные браузеры, но без графического интерфейса. Многие платформы автоматизации тестирования и производительности используют их для симуляции пользовательского трафика.
Однако у headless-браузеров есть свои недостатки: по мере появления новых браузеров, наборы headless-браузеров должны догонять их по производительности и функциональности.
Симуляция клиентского рендеринга обходится недёшево. Один сервер нагрузочного тестирования обычно может одновременно обрабатывать лишь 10–12 сессий headless-браузеров, в то время как HTTP-сессий — до 500.
Реализация и настройка скриптов не слишком сложна. При наличии базовых навыков программирования можно создать простые сценарии. Однако не все headless-браузеры поддерживают визуальное воспроизведение, и без него отладка и анализ ошибок могут быть крайне затруднены.
Моделирование нагрузки на основе реального браузера
Web 2.0-приложения насыщены JavaScript, Flash, Ajax и CSS. Без полноценного браузера невозможно измерить реальное время отклика всей страницы от начала до конца. Тестирование производительности с использованием реального браузера позволяет оценить функциональность и скорость сайта с точки зрения конечного пользователя.
Типичное решение для тестирования с реальным браузером собирает данные о времени загрузки изображений, JavaScript, CSS и других компонентов. Часто такие решения предоставляют диаграммы водопада, визуализирующие загрузку ресурсов.
Нагрузка на систему при использовании реального браузера немного выше. Учитывая, что headless-браузеры не обеспечивают 100% реалистичных откликов, предпочтительнее использовать реальные браузеры. На практике headless-браузеры лишь на 20% производительнее. Таким образом, если один генератор нагрузки может обслуживать 10–12 сессий headless, то он сможет поддерживать 8–10 сессий реальных браузеров.
Создание и поддержка скриптов упрощаются, поскольку действия пользователя видны, а визуальное воспроизведение облегчает отладку. В приведённом примере браузер открывает URL, вводит логин и пароль и нажимает кнопку входа.
Типы тестов производительности
Тесты скорости компонентов
В последние годы методы разработки программного обеспечения стали более гибкими. Короткие релизные циклы стали нормой. Разработчики и тестировщики автоматизируют контроль качества и проверки производительности. Обычно они реализуют сервисные тесты на уровне протокола или симулируют работу реального браузера для сравнения времени отклика с заданными порогами.
Цели
- + Повторяемость
- + Автоматизированные проверки интерфейса и производительности
- + Сравнение времени отклика с допустимыми значениями
Нагрузочные тесты
Нагрузочное тестирование — идеальный метод для проверки нефункциональных требований. Оно позволяет фиксировать время отклика в воспроизводимых условиях и проверять соблюдение пороговых значений. Важным является реалистичное измерение времени отклика, поэтому для таких тестов часто используют headless- или реальный браузер.
Цели
- + Воспроизводимая симуляция нагрузки
- + Проверка соответствия времени отклика целевым значениям
- + Выявление узких мест при нагрузке, близкой к боевой
- + Реалистичные тесты от начала до конца
Стресс-тесты
Если требуется проверить надёжность приложения при пиковых нагрузках, выполняется стресс-тест. В нём задаётся максимальное число пользователей и продолжительность фаз разгона и стабильной нагрузки. Цель — выявить точки отказа приложения.
Цели
- + Проверка масштабируемости и устойчивости
- + Симуляция пиковых нагрузок
- + Точная воспроизводимость не является приоритетом
Сравнение
Существует множество причин использовать протокол, headless- или реальный браузер для симуляции пользователя. Ниже представлена таблица, которая поможет выбрать нужный подход.
| Критерий | HTTP | Headless-браузер | Реальный браузер |
|---|---|---|---|
| Симуляция пользователя | Нет рендеринга на клиенте | Некоторые элементы клиента симулируются | Полноценная симуляция пользователя |
| Реализация и настройка скриптов | Сложно при сложных сайтах | Требуются навыки разработчика | Простые скрипты, легко адаптируются |
| Воспроизведение скриптов | Требуется анализ на низком уровне | Возможна визуализация (зависит от движка) | Что видишь — то и получаешь |
| Поддержка скриптов | Нужны навыки программирования | Ошибки в невизуализированных блоках трудно отлаживать | Просто — видно ошибки во время воспроизведения |
| Мультибраузерная поддержка | Некоторые инструменты эмулируют браузеры, но неадекватно | Да, но часть элементов может отсутствовать | Некоторые поддерживают разные версии и браузеры |
| Нагрузка на генератор трафика | Низкая, до 800 сессий на сервер | Средняя, до 10–12 сессий | Высокая, до 6 сессий |
| Рекомендуется для DevOps | Зависит от сценария | Нет, скрипты слишком сложные | Да, просто в использовании и реалистично |
| Рекомендуется для нагрузочных тестов | Нет, игнорируется клиентская обработка | Да, лучше чем HTTP | Да, реалистичная симуляция пользователя |
| Рекомендуется для стресс-тестов | Да, минимальная нагрузка на генератор | Нет, слишком высокие затраты | Нет, максимальная нагрузка на систему |
| Стоимость | Низкая | Высокая | Высокая |
| Рекомендуется для стресс-тестов веб-серверов с большим трафиком и минимальными затратами (где применимо) | Не рекомендуется | Рекомендуется для реалистичного моделирования сложных приложений |
Веб-страницы, использованные для подготовки материала:
- https://developers.google.com/web/tools/chrome-devtools/device-mode/testing-other-browsers
- https://watirmelon.blog/2015/12/08/real-vs-headless-browsers-for-automated-acceptance-tests/
- http://news.softpedia.com/news/what-is-a-headless-browser-and-what-s-it-good-for-485162.shtml
- https://github.com/dhamaniasad/HeadlessBrowsers
- https://circleci.com/