Тестировать будем "тренировочный" апи.
host=reqres.in
path=/api/users
Собственно создание теста
Шаг 1: Установка Apache JMeter
Если у вас еще не установлен JMeter, скачайте его с официального сайта Apache JMeter и установите на вашем компьютере.
Шаг 2: Создание нового тестового плана
1. Запустите JMeter.
2. В левом верхнем углу выберите "File" -> "New", чтобы создать новый тестовый план.
Шаг 3: Добавление Thread Group (Группа потоков)
1. В дереве теста на левой панели кликните правой кнопкой мыши на тестовый план (Test Plan).
2. Выберите "Add" -> "Threads (Users)" -> "Thread Group".
3. В настройках Thread Group укажите следующие параметры:
Number of Threads (users): количество виртуальных пользователей, например, 100.
Ramp-Up Period (in seconds): время, за которое заданное количество пользователей подключится, например, 10 секунд.
Loop Count: количество циклов выполнения для каждого пользователя. Если хотите, чтобы запросы выполнялись один раз, укажите 1. Если хотите, чтобы они выполнялись многократно, укажите большее значение или выберите Forever.
Шаг 4: Добавление HTTP Request Sampler
1. Кликните правой кнопкой мыши на Thread Group.
2. Выберите "Add" -> "Sampler" -> "HTTP Request".
3. Настройте HTTP Request следующим образом:
Name: Назовите запрос, например, Get Users.
Server Name or IP: Введите reqres.in.
Path: Введите /api/users.
Method: Убедитесь, что выбрано GET.
Protocol: Оставьте значение https (так как API использует HTTPS).
Шаг 5: Добавление HTTP Header Manager (Менеджер заголовков)
1. Кликните правой кнопкой мыши на HTTP Request.
2. Выберите "Add" -> "Config Element" -> "HTTP Header Manager".
3. В HTTP Header Manager добавьте заголовок для указания типа контента:
Name: Content-Type
Value: application/json
Шаг 6: Добавление Response Assertion (Проверка ответа)
1. Кликните правой кнопкой мыши на HTTP Request.
2. Выберите "Add" -> "Assertions" -> "Response Assertion".
3. В Response Assertion:
Field to Test: выберите Response Code.
Pattern Matching Rules: выберите Equals.
Patterns to Test: введите 200.
Шаг 7: Добавление View Results in Table (Просмотр результатов в таблице)
1. Кликните правой кнопкой мыши на Thread Group.
2. Выберите "Add" -> "Listener" -> "View Results in Table".
3. Этот элемент позволит вам просматривать результаты выполнения теста в табличном формате.
Шаг 8: Запуск теста
1. Нажмите на кнопку "Start" (зеленый треугольник) в верхнем меню, чтобы запустить тест.
2. После завершения теста посмотрите результаты в View Results in Table.
Шаг 9: Анализ результатов
1. В View Results in Table посмотрите на столбец Response Code. Убедитесь, что все запросы вернули код 200.
2. Если нужны дополнительные метрики, такие как время отклика, количество ошибок и т.д., можно добавить другие Listener'ы, такие как "Summary Report" или "Aggregate Report".
Шаг 10: Настройка нагрузки
В зависимости от целей тестирования, вы можете изменить параметры в Thread Group, такие как количество потоков (пользователей), время нарастания нагрузки и количество повторений, чтобы смоделировать разные сценарии нагрузки.
Этот пример позволяет провести базовое нагрузочное тестирование API с помощью JMeter. Вы можете усложнять тесты, добавляя дополнительные элементы, такие как CSV Data Set Config для параметризации запросов, или Timers для управления задержками между запросами.
Рекомендованные параметры и как оценить результат
1. Рекомендованные параметры для Thread Group:
Количество потоков (Number of Threads / Users):
- Малый сайт или сервис: 10-50 пользователей.
- Средний сайт или сервис: 50-200 пользователей.
- Крупный сайт или сервис: 200-1000+ пользователей.
Выбор количества потоков зависит от реальной нагрузки на систему. Например, если ваш сайт обслуживает около 500 пользователей в пиковые моменты, то стоит протестировать на 500+ потоков.
Время нарастания нагрузки (Ramp-Up Period):
- Короткий период: 1-10 секунд.
- Средний период: 10-60 секунд.
- Длинный период: 60-300 секунд.
Время нарастания нагрузки позволяет постепенно увеличивать число пользователей, что помогает лучше понять поведение системы при увеличении нагрузки.
Количество циклов (Loop Count):
- Если вы хотите провести однократное тестирование, установите
Loop Count = 1.
- Для длительных стресс-тестов, которые симулируют постоянную нагрузку, используйте большое значение или установите опцию Forever, чтобы запросы отправлялись непрерывно до тех пор, пока тест не будет вручную остановлен.
2. Оценка результатов:
Основные метрики для оценки:
1. Время ответа (Response Time):
- Среднее время ответа (Average Response Time):
Среднее время, которое требуется серверу для обработки запроса. Приемлемое значение: зависит от типа сервиса, но обычно стараются, чтобы оно было менее 1-2 секунд.
- Максимальное время ответа (Max Response Time):
Наибольшее время отклика среди всех запросов.
- 95-й перцентиль (95th Percentile Response Time):
Время ответа, которое 95% запросов не превышают. Оценивает стабильность системы.
2. Количество ошибок (Error Rate):
- Процент ошибок (Error %):
Процент запросов, завершившихся с ошибкой (например, 4xx или 5xx статус-коды).
Приемлемое значение: Стремитесь к 0%, но часто допускается небольшой процент ошибок, например, 0.1-1%.
3. Пропускная способность (Throughput):
- Количество запросов в секунду (Requests per Second): Количество успешно обработанных запросов в секунду. (чем больше, тем лучше. Можно оценивать исходя из исторических данных (например если становится хуже, это не хорошо))
- Байты в секунду (Bytes per Second): Скорость передачи данных между клиентом и сервером. (чем больше, тем лучше)
4. Время на соединение (Connect Time):
Время, необходимое для установления соединения с сервером. (чем меньше, тем лучше)
Как интерпретировать результаты:
1. Время ответа:
- Если среднее время ответа значительно увеличивается по мере роста нагрузки (количества пользователей), это может указывать на проблемные места в производительности.
- Если максимальное время ответа значительно превышает среднее, это может свидетельствовать о нестабильности системы или отдельных узких местах.
2. Ошибки:
- Появление ошибок при увеличении нагрузки может указывать на то, что система не справляется с нагрузкой и требуется оптимизация.
- Если процент ошибок превышает допустимый (например, >1%), это может быть признаком проблем с серверами (например, нехватка ресурсов) или проблем в коде.
3. Пропускная способность:
- Важно следить за тем, чтобы пропускная способность оставалась стабильной при увеличении нагрузки.
- Резкое снижение пропускной способности может указывать на насыщение системы и необходимость масштабирования.
Заключение:
- Хороший результат: низкое время отклика, отсутствие ошибок даже при высоких нагрузках, стабильная пропускная способность.
- Плохой результат: высокое время отклика, большое количество ошибок при увеличении нагрузки, нестабильная пропускная способность.
3. Дополнительные рекомендации:
- Анализировать логи: Важные ошибки могут не отображаться в JMeter, поэтому полезно анализировать серверные логи.
- Проводить тесты в несколько этапов: Начните с малых нагрузок и постепенно увеличивайте их, чтобы выявить пределы системы.
- Использовать мониторинг: Важно использовать инструменты мониторинга (например, Grafana, Prometheus) для наблюдения за состоянием серверов во время тестирования.
Нагрузочное тестирование — это не только про «запустить тест и получить цифры», но и про глубокий анализ этих цифр и выявление узких мест в системе, которые могут быть улучшены.
Вместо оглавления. Что вы найдете на канале QA Helper - справочник тестировщика?
Не забудьте подписаться на канал, чтобы не пропустить полезную информацию: QA Helper - справочник тестировщика
Пишите в комментариях какой пункт было бы интересно рассмотреть более подробно.
Обязательно прочитайте: Что должен знать и уметь тестировщик
Также будет интересно почитать: Вопросы которые задают на собеседовании тестировщикам