Разделы портала

Онлайн-тренинги

.
Тестирование производительности: последовательность тестов, измеряемые показатели, правила подачи нагрузки
01.12.2017 10:24

Тестирование производительности – обобщенное понятие, которым часто обозначают разные виды проверки ПО. В данной статье команда A1QA с опорой на реальные кейсы расскажет, в какой последовательности проводится тестирование и что измеряется на каждом из этапов.

Первым в череде тестов проводится стресс-тест (Stress Test), цель которого – установить предельный уровень производительности продукта. Стресс-тест позволяет проанализировать зависимость ключевых характеристик системы (времени отклика самых важных бизнес-транзакций, количества запросов в секунду, количества транзакций в секунду) от количества одновременно работающих пользователей.

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

На втором этапе проводится нагрузочный тест (Load Test), с помощью которого оценивается способность системы справляться с длительной нагрузкой (4-8 часов). Количество пользователей для нагрузочного теста определяется в количестве 80% от результата максимальной производительности, выявленной при стресс-тесте. Уровень нагрузки при тестировании банковской системы поддерживался на одном уровне в течение восьми часов и составил 1200 пользователей. Нагрузочный тест показал существенное ухудшение производительности системы с течением времени, а дополнительное профилирование ее компонентов позволило обнаружить дефекты, проявляющиеся только при длительной работе большого количества пользователей (например, утечки памяти).

Как правильно подавать нагрузку на систему?

При проведении нагрузочного тестирования важно аккуратно подойти к установке инструмента нагрузочного тестирования. Инструмент устанавливается на генератор нагрузки – виртуальную или физическую машину, ресурсы которой используются для создания нагрузки на систему. Генератор нагрузки должен располагаться максимально близко к тестовому окружению. Это необходимо для устранения искажений при подаче нагрузки, вызванных задержками сети, величина которых может варьироваться от нескольких миллисекунд до нескольких десятков секунд.

Поскольку задержки, возникающие в локальных сетях при передаче пакетов данных, существенно меньше, мы рекомендуем размещать генератор нагрузки в одной локальной сети с серверами тестируемого приложения.

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

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

Например, на одном из проектов мы проводили тестирование крупного новостного портала игровой вселенной, который посещают пользователи со всего мира. Для предоставления объективных результатов мы провели распределенное нагрузочное тестирование. Нагрузка была распределена между несколькими генераторами нагрузки, расположенными в разных географических регионах. В качестве генераторов нагрузки использовались виртуальные машины, арендуемые на платформах облачных сервисов. Результаты распределенного тестирования позволили сделать выводы о необходимости размещения дополнительных серверов в регионах с наихудшими показателями производительности.

По желанию заказчика возможно проведение дополнительных видов тестов.

Дополнительные виды тестов производительности

Задачей объемного теста (Volume Test) является оценка производительности системы при увеличении объемов данных, хранимых в базе данных приложения. Схема подачи нагрузки при данном виде теста такая же, как и при нагрузочном. Для проведения теста требуется база данных, заполненная необходимым объемом данных. Так, при тестировании биллинговой системы для оператора мобильной связи, объем данных был выбран исходя из ее прогнозируемого наполнения через два года после выхода обновленной версии системы в производство.

Тест на стабильность (Stability Test) позволяет оценить работоспособность системы при длительной ожидаемой нагрузке в режиме работы 24/7. К примеру, если веб-сайт посещают пользователи, находящиеся в разных часовых поясах, уровень нагрузки может сохраняться постоянным. Помимо возможных перезапусков серверов системы под продолжительной нагрузкой, при тесте на отказоустойчивость также изучается влияние редких событий на деградацию производительности системы, например, работа сборщиков мусора.

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

Тестирование клиентской части vs. тестирование производительности

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

Наилучшим решением проблем со стабильностью и сбоями в работе веб-серверов является обеспечение двухуровневой архитектуры приложения: клиентской, или Front- end, части и серверной, или Back-end, части.

Пользователь открывает браузер и отправляет запрос к странице сайта на Front-end сервер. Запрос принимается и запрашивается у исполнительной части веб-приложения – Back-end сервера, который хранит логику приложения, обеспечивает выполнение PHP-скриптов и генерирует HTML-страницы. Front-end принимает сформированную страницу от Back-end и в качестве ответа на запрос пользователя передает ее в браузер. Получив страницу, браузер пользователя начинает ее отображение, что сопровождается отправкой серии запросов на графический контент и CSS. Эти запросы принимает Front-end и обрабатывает без обращений к Back-end’у.

Оценка скорости работы клиентской и серверной частей веб-приложения осуществляется двумя разными видами тестирования: для Front-end применяется тестирование клиентской части, или Client-Side Testing, а для Back-end – тестирование производительности серверной части.

Основная цель тестирования клиентской части состоит в измерении времени, необходимого браузеру, для загрузки HTML-страницы. Наиболее важными показателями здесь являются количество загружаемых данных, их объем, а также количество выполненных запросов.

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

Помимо общего веса страницы, инструменты предоставляют детализированную информацию по каждому из компонентов. Изучив параметры запросов, можно обнаружить ряд проблем, приводящих к ухудшению скорости отображения страницы. К примеру, подгружается слишком большая картинка и Javascript, или отправляется значительное количество запросов.

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

Другая необходимая проверка направлена на анализ заголовков кэширования, поскольку корректность его выполнения при повторном посещении страницы позволяет повысить скорость загрузки страницы до 80%.

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

Тестирование производительности серверной части направлено на анализ выполнения запросов и получения соответствующего запроса от Back-end.

Цели данного вида тестирования:

  • Измерить время отклика самых важных бизнес-транзакций;
  • Определить предельный уровень допустимой нагрузки;
  • Выявить «узкие» места в производительности системы;
  • Составить рекомендации по улучшению производительности;
  • Найти возможные дефекты, проявляющиеся только при одновременной работе большого количества пользователей.

Заключение

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

Обсудить в форуме