Нагрузочное тестирование (Load testing)
Нагрузочное тестирование (load testing): Вид тестирования производительности, проводимый с целью оценить поведение компонента или системы под увеличивающейся нагрузкой (число одновременно работающих пользователей и/или число транзакций) для определения максимально допустимого уровня нагрузки для исследуемого компонента или системы. (ISTQB)
Нагрузочное тестирование (load testing): Тип тестирования уровня производительности, проводимого для оценки поведения элемента тестирования при ожидаемых условиях переменной нагрузки, обычно для ожидаемых условий низкого, типичного и пикового использования. (ГОСТ 56920)
Нагрузочное тестирование - это тестирование, имитирующее работу определенного количества бизнес пользователей на каком-либо общем (разделяемом ими) ресурсе. Этот подвид тестирования производительности выполняется для диагностики поведения системы при увеличении рабочей нагрузки.
Пример. Предположим, что требование нашего клиента для страницы входа составляет 2-5 секунд, и эти 2-5 секунд должны быть всегда, пока нагрузка не достигнет 5000 пользователей, а также если количество пользователей постепенно увеличивается, то сколько ЦП, памяти будет потребляться, каково состояние сети, время отклика, пропускная способность и т.д.
Подход к нагрузочному тестированию:
Определите критерии приемки нагрузочного теста. Например:
Время отклика страницы входа не должно превышать 5 секунд даже в условиях максимальной нагрузки;
Загрузка ЦП не должна превышать 80%;
Пропускная способность системы должна составлять 100 транзакций в секунду;
Определите бизнес-сценарии, которые необходимо протестировать. Не тестируйте все потоки, постарайтесь понять основные business flows, которые, как ожидается, будут происходить в производственной среде. Если это уже существующее приложение, мы можем получить информацию из логов. Если это новое приложение, нам нужно работать с бизнес-группами, чтобы понять закономерности потока, использование приложения и т. д. Иногда команда проекта проводит семинары, чтобы дать обзор или подробности о каждом компоненте приложения;
Моделирование рабочей нагрузки. Получив подробную информацию о бизнес-потоках, шаблонах доступа пользователей и количестве пользователей, нам нужно спроектировать рабочую нагрузку таким образом, чтобы она имитировала фактическую навигацию пользователя в производственной среде или как она ожидается в будущем, когда приложение будет в производстве. Ключевые моменты, которые следует помнить при разработке модели рабочей нагрузки, - это увидеть, сколько времени потребуется для завершения конкретного бизнес-потока. Здесь нам нужно назначить время обдумывания (think time) таким образом, чтобы пользователь мог более реалистично перемещаться по приложению. Схема рабочей нагрузки обычно будет с нарастанием, спадом и устойчивым состоянием (Ramp up, Ramp down and a steady state).
Устойчивое состояние обычно представляет собой одночасовое испытание под нагрузкой с нарастанием 15 минут и замедлением 15 минут.
Пример модели рабочей нагрузки: Предположим, что это интернет-магазин, где пользователи войдут в приложение и получат широкий выбор платьев для покупок и могут перемещаться по каждому продукту. Чтобы просмотреть подробную информацию о каждом продукте, им нужно щелкнуть по продукту. Если им нравится цена и качество продукта, они могут добавить его в корзину и купить продукт, выполнив проверку и произведя оплату. Список сценариев:
Обзор - здесь пользователь запускает приложение, входит в приложение, просматривает различные категории и выходит из приложения;
Обзор, Просмотр продукта, Добавить в корзину - здесь пользователь входит в приложение, просматривает различные категории, просматривает сведения о продукте, добавляет продукт в корзину и выходит из системы;
Обзор, просмотр продукта, добавление в корзину и оформление заказа - в этом сценарии пользователь входит в приложение, просматривает различные категории, просматривает сведения о продукте, добавляет продукт в корзину, оформляет заказ и выходит из системы;
Обзор, Просмотр продукта, Добавить в корзину, Оформить заказ и произвести оплату - здесь пользователь входит в приложение, просматривает различные категории, просматривает сведения о продукте, добавляет продукт в корзину, оформляет заказ, производит оплату и выходит из системы.
| Business Flow | Количество транзакций | Виртуальная пользовательская нагрузка | Время отклика (сек) | % Допустимая частота отказов | Транзакций в час |
|---|---|---|---|---|---|
1 | 17 | 1600 | 3 | Менее 2% | 96000 |
2 | 17 | 200 | 3 | Менее 2% | 12000 |
3 | 18 | 120 | 3 | Менее 2% | 7200 |
4 | 20 | 80 | 3 | Менее 2% | 4800 |
Приведенные выше значения были получены на основе следующих расчетов: Транзакций в час = Количество пользователей * Транзакции, совершенные одним пользователем за один час. Количество пользователей = 1600. Общее количество транзакций в сценарии просмотра = 17. Время отклика для каждой транзакции = 3. Общее время, за которое один пользователь совершил 17 транзакций = 17 * 3 = 51, округленное до 60 секунд (1 мин). Транзакций в час = 1600 * 60 = 96000 Транзакций.
Дизайн / разработка нагрузочных тестов - Нагрузочный тест должен быть разработан с использованием данных, которые мы уже собрали, то есть бизнес-потоков, количества пользователей, пользовательских шаблонов, показателей, которые необходимо собрать и проанализировать. Более того, тесты должны быть максимально реалистичными.
Выполнение нагрузочного теста - перед тем, как мы выполним нагрузочный тест, убедитесь, что приложение запущено и работает. Среда нагрузочного тестирования готова. Приложение функционально протестировано и работает стабильно. Проверьте параметры конфигурации среды нагрузочного тестирования. Она должна быть такой же, как и в производственной среде. Убедитесь, что доступны все тестовые данные. Не забудьте добавить необходимые метрики для отслеживания производительности системы во время выполнения теста. Всегда начинайте с небольшой нагрузки и постепенно увеличивайте ее. Никогда не начинайте работу с полной нагрузкой.
Анализ результатов нагрузочного теста - имейте baseline test, чтобы всегда сравнивать его с другими тестами. Соберите метрики и журналы сервера после запуска теста, чтобы найти узкие места. Некоторые проекты используют инструменты мониторинга производительности приложений для мониторинга системы во время тестового запуска, эти инструменты APM (Application Performance Monitoring) помогают легче определить основную причину и сэкономить много времени.
Отчетность - после завершения тестового прогона соберите все показатели и отправьте сводный отчет теста соответствующей группе со своими наблюдениями и рекомендациями.
Источники:
Доп. материал:
Last updated
