Рекомендации по структуре подхода к плану испытаний JMeter

Im новый для Jmaeter и в настоящее время пытается получить лучшее использование из него для создания плана тестирования производительности API.

Рассмотрим следующий сценарий.

У нас есть APi, который возвращает такие данные, как доступность части и детали заказа для диапазона или частей.

Я хочу проанализировать время отклика api под различными шаблонами нагрузки.

Допустим, у нас 5 пользователей.
— Каждый пользователь отправляет серию повторных запросов в API.
— Запрос, сделанный каждым пользователем, уникален только для этого пользователя.
i.e
Пользователь 1 запрашивает части a,b, c.
Пользователь 2 запрашивает части d, e, f… и так далее

— Все пользователи шлифуют свои запросы одновременно.

Я подошел к этому так, чтобы создать 5 отдельных групп потоков для каждого пользователя.
В каждой группе потоков находится определенный http-запрос, который отправляется каждым пользователем.
Каждый запрос http управляется своим собственным контроллером цикла, где я установил количество раз для каждого запроса, который будет отправлен

Поскольку я хочу, чтобы все пользователи отправляли свои запросы сразу, я снял флажок
«последовательно запускать группы потоков» в основном плане тестирования. на первый взгляд план тестирования выглядит примерно так:
вид плана тестирования

Поскольку я новичок в использовании Jmeter и тестировании производительности, у меня есть несколько вопросов относительно моего подхода:

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

  2. При текущей настройке каждая группа потоков использует время нарастания по умолчанию, равное 1 секунде. Я решил, что это нормально, так как каждая группа потоков представляет только одного пользователя. Однако я думаю, что это может вызвать задержку при запуске каждого тестового запуска. Существуют ли какие-либо другие потенциально лучшие способы справиться с этим, такие как использование планировщика или увеличение времени нарастания для каждой группы потоков, чтобы они не начинались в одно и то же время?

Заранее спасибо за любые советы

2 ответа

  1. Ваш подход верен.

    Если вы хотите, чтобы запросы были параллельными, они должны быть в отдельных группах потоков. Каждая группа потоков должна моделировать прецедент. В вашем случае use-case-это определенный набор запросов.

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

    1. Прежде всего, ваш тест должен быть реалистичным, он должен представлять реальных пользователей (или группы пользователей) как можно ближе. Если тест это делает-это хороший тест и наоборот. Что-то вроде:

      • Если User1 и User2 представляют 2 разные группы пользователей (например, User1 аутентифицируется, а User2 не аутентифицируется или User1 является администратором, а User2-гостем), они должны перейти в разные группы потоков.

      • Лучше использовать итерации группы потоков вместо контроллеров цикла, поскольку некоторые тестовые элементы, такие как HTTP Cookie Manager, имеют настройки, такие какClear Cookies each Iteration, которые не уважают итерации, производимые циклом или в то время как контроллер, они рассматривают только итерации группы потоков

      • Единственный способ гарантировать отправку запросов одновременно-поместить их в одну группу потоков и использовать таймер синхронизации

    2. Когда дело доходит до реального нагрузочного теста, вы всегда должны постепенно добавлять нагрузку, чтобы вы могли коррелировать различные метрики, такие как время отклика, пропускная способность, частота ошибок с увеличенным числом виртуальных пользователей. Такой же подход должен быть применен для «ramping-down», вы не должны выключать нагрузку сразу, чтобы иметь возможность видеть, как ваше приложение восстанавливается после нагрузки. Вы можете использовать некоторые пользовательские группы потоков, доступные через проект JMeter Plugins, как:

      Они обеспечивают гибкий и удобный путь установить пожеланную картину нагрузки.