Проверка сводного отчета по тестированию производительности

#web-applications #jmeter #performance-testing

#веб-приложения #jmeter #тестирование производительности

Вопрос:

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

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

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

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

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

Спасибо

Ответ №1:

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

Для других типов тестирования, таких как стресс-тестирование или пиковое тестирование, придерживаться Закона Литтла не имеет большого смысла, поскольку рабочая нагрузка различается.

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

  1. Способна ли система обрабатывать ожидаемую нагрузку (нагрузочное тестирование)
  2. Какое максимальное количество одновременных пользователей может поддерживать система, обеспечивая приемлемое время отклика без ошибок (стресс-тестирование).
  3. Восстанавливается ли система, когда загрузка возвращается к нормальному состоянию
  4. Как система обрабатывает внезапные одновременные запросы (тестирование с повышением производительности)
  5. Способна ли система обрабатывать нагрузку в течение длительного периода времени (непрерывное тестирование)

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