Главная страница Публикации Видео Доклад на Highload++ 2016

Доклад на Highload++ 2016

Доклад на Highload++ 2016: Автоматизация тестирования клиентской производительности

к.э.н. Лавлинский Н. Е., технический директор ООО «Метод Лаб»

Видео доклада:

Слайды:

Highload++ 2016: Автоматизация тестирования клиентской производительности (Лавлинский Николай) from Лавлинский Николай

Клиентская производительность – бесконечный процесс. Разрабатываются новые фичи, меняется дизайн, технологии, браузеры – контролировать скорость нужно постоянно.

Здесь есть два принципиальных направления: синтетические тесты в тестовом окружении и сбор метрик у реальных пользователей. Оба этих направления важны, но мы сконцентрируемся на синтетических тестах и будем использовать их для оценки влияния изменений в приложении на клиентскую производительность как часть процесса тестирования.

За счет использования изолированного окружения можно на раннем этапе ловить проблемы со скоростью, причем до релиза кода реальным пользователям.

Чем тестировать?

Нам нужно протестировать клиентскую часть веб-приложения. Конечно, можно пытаться создать некий программный эмулятор браузера, который будет парсить страницу, загружать ресурсы (картинки, шрифты, CSS, JS), возможно даже выполнять JS.

Но нас интересуют реальные браузеры, потому что сейчас в них зашито слишком много логики по оптимизации (приоритет запросов, предзагрузка и т. д.) и пытаться их эмулировать не представляется возможным.

Получается, нужен реальный браузер, желательно охватить основные виды браузеров реальной аудитории. Наиболее доступное решение: запуск браузеров на Windows. Мы получаем: Chrome, Firefox, IE.

Теперь встаёт вопрос: как автоматизировать запуск тестов и получение метрик для отчета? Нужно создавать обзязку для каждого браузера, придумать как сохранять метрики, обрабатывать их и отправлять обратно на платформу тестирования для анализа. Довольно сложная и дорогая задача.

WebPagetest Private Instance

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

Но мы можем запустить всё это у себя и получить полный доступ! Называется решение WebPagetest Private Instance, находится в open source (https://sites.google.com/a/webpagetest.org/docs/private-instances).

Архитектурно состоит из двух компонент: серверная часть (очередь задач и front-end) и тестовые агенты.

Тестовым агентом как правило выступает машина с Windows 7, часто это виртуальная машина. При этом настроить машину можно самостоятельно или использовать готовые образы в Amazon EC2. Мы выбираем самостоятельную установку, чтобы полностью управлять окружением и тестировать из нужной нам сети.

Для тестового агента уже разработана вся необходимая обвязка по автоматизации браузеров. Для ограничения скорости сети используется dummynet.

Один WebPagetest сервер может подключаться к нескольким тестовым агентам (как своим, так и публичным). На каждом агенте есть несколько браузеров.

Как только мы настроили тестовый агент и сервер, можно начинать тестирование через web-ui.

При этом мы сохраняем все стандартные возможности WPT:

  • Управление параметрами сети (up/down bandwidth, latency, packet loss).
  • Сбор всех возможных метрик производительности (включая кастомные).
  • Сбор скриншотов и видео загрузки.
  • Очистка кеша (включая SSL, DNS) перед тестами.

Но нам нужно автоматизировать процесс.

Тестирование на реальных мобильных устройствах

Данное решение позволяет подключать мобильные устройства в качестве тестовых агентов (Android, IOS). Однако, в этой области мало документации. Кроме того, мобильные устройства добавляют еще один фактор хрупкости в достаточно сложную систему. Также есть сложности с шейпингом трафика для мобильных.

Как вариант замены тестирования на мобильных можно использовать эмуляцию мобильного устройства в Chrome (получаем аналог Chrome Mobile). Для эмуляции мобильного CPU можно ограничить ресурсы виртуальной машине. Сетевые параметры доступны любые — здесь проблем нет.

Автоматизация WPT

Для целей автоматизации тестов в WPT PI есть несколько возможностей:

  • RESTful API
  • Batch библиотека (Python)
  • Batch CLI (wpt_batch.py)

Чтобы получить максимальную гибкость и настраивать процесс под себя, нужно использовать API. Так как оно реализовано в виде обычного HTTP-интерфейса, который на выходе даёт JSON или XML, то ограничений в языке программирования практически нет.

Что требуется для автоматизированного тестирования скорости.

  • Очередь заданий с сохранением статусов (внутренняя для нашей системы).
  • Сервер WPT PI (получает и запускает тесты, формирует результаты).
  • Обработчик результатов (получает результат от WPT и формирует результирующий отчет).

Запрос на тестирование

Чтобы отправить запрос на тест, требуется сделать POST-запрос на https://wptdomain/runtest.php.

Основные параметры:

  • url — что тестировать;
  • location — тестовый агент (включая браузер и параметры подключения);
  • runs — количество тестов;
  • fvonly – тестировать только FirstView;
  • video — захват скриншотов и видео;
  • f — формат данных (XML или JSON).

Результаты тетирования

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

Примеры полезных метрик, которые можно получить:

Здесь мы видим TTFB, начало рендеринга, время загрузки страницы, время полной загрузки, объёмы трафика на страницу, отдельно по типам (CSS, JS, Fonts). В конце есть оценки по степени оптимизации: заголовки кэширования, использование сжатия, оптимизация картинок, % соединений с keep-alive.

При желании можно получать отдельные данные по каждому запросу, или интегральные характеристики: PageSpeedIndex, затраты CPU на рендеринг страницы и т. д.

Проблемы данного решения

Основная сложность при использовании WPT PI это нестабильность результатов. Погрешность может достигать 50-100%. До конца победить эту проблему не получится, но есть набор мер по снижению негативного влияния:

  • увеличение количества прогонов;
  • использование медианного варианта теста;
  • оптимизация Windows тестового агента (отключение регулярных задач, использование аппаратной виртуализации);
  • расположение агента рядом с тестируемым приложением (в одной сети);
  • блокирование запросов на внешние сервисы (счетчики, виджеты и т. д.)

Второй недостаток: ресурсоёмкость для масштабирования тестов. Здесь можно увеличивать количество тестовых агентов и запускать ограниченные тесты часто (например, без сбора видео), а полные – реже.

Наконец, так как мы используем живые Windows машины, они требуют обслуживания и обеспечения безопасности. Нужно мониторить их состояние, перезагружать, ставить обновления (в том числе для агентов).

Область применения

Предложенное решение можно применять для таких задач:

  • внутренний мониторинг скорости (для исключения крупных провалов в скорости);
  • сравнение сервиса с конкурентами;
  • тестирование изменений и новых технологий;
  • оценка уровня оптимизации клиентской части и времени ответа сервера;
  • получение объективной картины о процессе рендеринга страниц.

Для чего этот инструмент неприменим:

  • Тестирование микроизменений (до 200 мс) – недостаточно точности.
  • Тестирование серверной производительности (лучше использовать специальные средства).
  • Нагрузочное тестирование.
  • Эмуляция действий реальных пользователей.

Выводы

В результате мы получаем рабочее решение с минимальными затратами на запуск и поддержку. Несмотря на указанные минусы, оно вполне справляется с большим кругом задач по автоматизации тестирования скорости. Мы получаем инструмент для ручного тестирования через web-ui, а также удобный доступ по API в одном флаконе.

За профессиональным ускорением сайтов обращайтесь к нам.

Лучшее ускорение сайтов в Рунете

Ускорение сайтов

Цена от 19 900 Р