Когда проводить тестирование производительности с использованием Jmeter в CI Дженкинса?

Question

Я создаю CI-конвейер для микросервисов с использованием Jenkins. Теперь, я запутался с тестированием производительности, я имею в виду, где я должен добавить этап для тестирования производительности, после развертывания моего микросервиса на сервере или локального запуска микросервиса, а затем провести тестирование производительности?

Answer 1

Короткий быстрый ответ заключается в том, что это зависит от того, чего вы хотите достичь с помощью тестирования производительности.

Я говорю так из-за того, что называется спектр тестирования :

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

Подробнее об этом и тестировании вы можете прочитать в:

• Микросервисное тестирование: новый рассвет

• Тестирование микросервисов, разумный путь

Основным моментом спектра тестирования, однако, являются две установленные классификации:

• Предпроизводственные испытания
• Испытания в производстве - с тремя этапами: развертывание , выпуск , после выпуска

В вашем случае, если вы хотите использовать тестирование производительности для защиты от регрессии с новыми выпусками в автоматическом режиме, то вы должны добавить его как deploy фазовый тест в вашем трубопроводе. Или даже pu sh до релиза или после релиза фаз, подкрепленных мониторингом.

Но вы должны иметь в виду стоимость такого теста в автоматическом конвейере.

Если вы хотите запускать тесты производительности по требованию, выбрасывайте, тогда вам не обязательно заботиться об автоматизации. Затем ваши тесты производительности могут быть исключены из конвейера как предварительные тесты, которые выполняются по требованию в локальной (или промежуточной) среде.

Так что это действительно зависит.

Answer 2

Это зависит от того, какой подтип тестирования производительности вы выполняете.

Обычно я не рекомендовал бы, чтобы тестируемая система (в вашем случае микросервис) и генератор нагрузки (в вашем случае JMeter) работали на одной машине, потому что вы можете столкнуться с ситуацией, когда и микросервис, и JMeter борются за системные ресурсы, поэтому ваши результаты не будут надежными, как:

• , когда речь идет о высоких нагрузках, JMeter может быть очень ресурсоемким
• таким же относится к тестируемому приложению

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

Теоретически вы можете использовать локальные среды для регрессионного тестирования целей в случае, когда вы уже обнаружили все узких мест и обнаружили все проблемы и просто хотите убедиться, что новые функции и / или исправления ошибок не приводят к снижению производительности, но обязательно следите за системными ресурсами, чтобы исключить взаимные помехи JMeter и микросервиса, это можно сделать с помощью, например, JMeter PerfMon Plugin

В противном случае вы должны скорее ориентироваться на производство или производственную среду. Есть некоторые формы тестов производительности, которые вы можете проводить в уменьшенной среде , но вы не сможете полностью полагаться на результаты, если вы получили их в локальной системе, в которой нет рабочей машины ( s) технические характеристики оборудования.