Home

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

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

Перед вами самые распространенные виды тестирования производительности.

1. Стресс-тестирование (Stress Test)

Этот тест проводится первым. Нагрузка постепенно увеличивается до тех пор, пока приложение не перестанет работать корректно. В конце теста фиксируется количество пользователей, которое приложение выдерживало, соответствуя требованиям производительности, и сколько выдержать не смогло. Первое значение и будет пределом производительности вашего приложения. Часто этот вид тестирования проводится, если заказчик предвидит резкое увеличение нагрузки на систему. Например, для e-commerce это могут быть дни распродаж.

2. Нагрузочный тест (Load Test)

Нагрузка на систему подается на протяжении 4-8 часов. В это время собираются метрики производительности: количество запросов в секунду, транзакций в секунду, время отклика от сервера, процент ошибок в ответах, утилизация аппаратных ресурсов и т д. Собранные метрики проходят проверку на соответствие заданным требованиям. В результате получаем ответ на вопрос: соответствует ли система требованиям производительности?

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

1. 3. Тестирование на больших объемах данных (Volume Test)

Данный вид тестирования помогает сделать прогноз относительно работоспособности приложения. Форма подаваемой нагрузки та же, что и при нагрузочном тестировании. Задача теста – узнать, какое влияние окажет увеличение объема данных на систему. Таким образом, можем найти ответ на вопрос: как изменится производительность приложения спустя X лет, если аудитория приложения вырастет в Y раз?

1. 4. Тестирование отказоустойчивости (Stability Test)

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

1. 5. Тестирование масштабируемости (Scalability Test)

Профиль нагрузки тот же, что и при нагрузочном тестировании. Что получаем в результате? Ответы на следующие вопросы:

• Увеличится ли производительность приложения, если добавить дополнительные аппаратные ресурсы?
• Увеличится ли производительность пропорционально количеству добавленных аппаратных средств?

О видах тестирования поговорили, теперь коснемся такого важного аспекта их проведения как нагрузка.

Подаваемая нагрузка

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

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

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

Например, нагрузка на окружение подается равной 1000 пользователей, а действительная нагрузка во время теста составляет только 200 пользователей. Разница обусловлена «узким местом» в сети между клиентами и сервером.

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

При правильном подходе мы тестируем производительность системы, а не сети. Для этого тестовое окружение и генератор должны быть расположены в одной локальной сети.

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

Какие же метрики собираются во время тестирования производительности?

Время отклика измеряется с момента отправки запроса к серверу до получения последнего байта от сервера.

Запросы в секунду. Клиентское приложение формирует HTTP-запрос и отправляет его на сервер. Серверное ПО данный запрос обрабатывает, формирует ответ и передает его обратно клиенту. Общее число запросов в секунду и есть интересующая нас метрика.

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

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

Процент ошибок рассчитывается как отношение невалидных ответов к валидным за промежуток времени.

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

Советы для тестировщиков и аналитиков по тестированию производительности

• Корреляция динамических параметров и построение скриптов должны быть основаны на реальном поведении пользователей. Иначе тестирование будет больше напоминать DDOS-атаку.
• Перед разработкой и запуском скриптов необходимо провести большую аналитическую работу, чтобы понять и подготовить детализированную методологию тестирования производительности.
• Важно принимать во внимание временные задержки между действиями пользователей и корректно размещает их в скриптах согласно поведению реальных пользователей.
• Функция кэширования должна воспроизводиться как для каждого виртуального пользователя, так и для реальных пользователей в промышленной эксплуатации системы.
• Виртуальные пользователи должны использовать заранее подготовленные тестовые данные и взаимодействовать с системой в поведенческой манере. Каждое действие должно иметь предварительно заданную вероятность и выполняться только определенным количеством пользователей.
• Чтобы найти функциональные дефекты, которые проявляются только при нагрузке, следует создавать скрипты с такими же наборами действий, как и у реальных пользователей. Это даст возможность проанализировать и воспроизвести запросы.

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

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