Проверка сводного отчета по тесту производительности - PullRequest
0 голосов
/ 06 марта 2019

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

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

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

, но в целом тесты параллелизма пользователей должны быть спроектированы таким образом, чтобы нагрузка изменялась, как схема перехода, как показано на рисунке ниже. enter image description here

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

Спасибо

1 Ответ

1 голос
/ 06 марта 2019

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

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

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

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...