На Хабре уже была публикация, посвященная нагрузочному тестированию АС, взаимодействующих по JMS при помощи JMeter. В ней описано применение JMeter как источника нагрузки, внешней системы, инициирующей бизнес-процесс в нашей (тестируемой) системе. Но что делать, если процесс инициируется внутри нашей системы, она отправляет запросы во внешнюю систему и ожидает ответа (то есть нам необходима заглушка внешней системы)?
Найти ответ на этот вопрос нам пришлось во время одного из проектов по нагрузочному тестированию.
На тот момент мы видели два пути решения:
Первый путь сулил неопределенные трудозатраты (пусть и относительно небольшие) в связи с тем, что опыта создания JMS-приложений (даже простых) не было.
С учетом того, что некий опыт работы с JMeter был, благодаря элементам вроде Aggregate Report можно в реальном времени следить за работой будущей заглушки, было решено остановиться на втором варианте.
Первым делом был сформулированы требования к нашей заглушке:
Первоначальная настройка JMeter идентична описанной в публикации «Автоматизированное тестирование сервисов, использующих протокол MQ с помощью JMeter», за исключением того, что также были использованы JMeter Plugins (конкретно Dummy Sampler для отладки).
В качестве Thread Group в тест-плане было достаточно стандартной (особой регуляции количества тредов во время работы заглушки не требовалось).
Далее добавляем JMS Subscriber, отвечающий за чтение сообщения из очереди. На рисунке ниже приведены настройки Subscriber.
После считывания сообщения из очереди при помощи View Result Tree можно увидеть его свойства. Пример свойств считываемого из очереди сообщения приведены ниже:
Для извлечения JMSCorrelationID (одно из свойств сообщения, которое позволит менеджеру очередей и тестируемому приложению понять, на какой запрос посылаемое заглушкой сообщение является ответом) и бизнес-даты (в нашем случае — значение одного из полей XML запроса, которое позволит выбрать подходящий ответ) используем Regular Expression Extractor (пример использования на рисунке ниже):
В связи с тем, что по методике НТ задержка ответа от внешней системы была фиксированной, для ее эмуляции был использован Constant Timer (см. ниже), создающий фиксированную задержку между последовательными запросами. Если вам в ходе ваших тестов будет нужна изменяющаяся задержка, рекомендуем присмотреться к любому из Random Timer.
Теперь на основании считанного сообщения мы можем выбрать подходящий ответ. Для этого используем Switch controller:
Для отправки ответа на запрос внутрь Switch controller подкладываем сэмплеры JMS Publisher с именами, соответствующими возможным значениям переменной p_destination (которое было извлечено регулярным выражением из Subscriber).
Внутрь тела (область Text Message) сэмплеров JMS Publisher добавляем динамические данные при помощи переменных JMeter (например timestamp и т.п.).
В области JMS Properties сэмплеров JMS Publisher добавляем JMSCorrelationId со значением ID:${corrId}.
Для анализа статистики работы можно добавить Aggregate Report, который позволит анализировать статистику работы заглушки в части количества принятых и отправленных сообщений.
Подводя итог, еще раз остановимся на плюсах создания JMS-заглушки при помощи JMeter по сравнению с самостоятельной разработкой:
Найти ответ на этот вопрос нам пришлось во время одного из проектов по нагрузочному тестированию.
На тот момент мы видели два пути решения:
- Написание собственного JMS-приложения, реализующего простую логику, необходимую для проведения тестирования;
- Использование JMeter.
Первый путь сулил неопределенные трудозатраты (пусть и относительно небольшие) в связи с тем, что опыта создания JMS-приложений (даже простых) не было.
С учетом того, что некий опыт работы с JMeter был, благодаря элементам вроде Aggregate Report можно в реальном времени следить за работой будущей заглушки, было решено остановиться на втором варианте.
Первым делом был сформулированы требования к нашей заглушке:
- Считывать сообщение из очереди;
- Извлекать из него CorrelationId и бизнес-данные для выбора и отправки подходящего ответа;
- Ждать определенное время (для эмулиции задержки ответа от внешней системы);
- Отправлять подходящий ответ с некоторым количеством динамических данных.
Первоначальная настройка JMeter идентична описанной в публикации «Автоматизированное тестирование сервисов, использующих протокол MQ с помощью JMeter», за исключением того, что также были использованы JMeter Plugins (конкретно Dummy Sampler для отладки).
В качестве Thread Group в тест-плане было достаточно стандартной (особой регуляции количества тредов во время работы заглушки не требовалось).
Далее добавляем JMS Subscriber, отвечающий за чтение сообщения из очереди. На рисунке ниже приведены настройки Subscriber.
После считывания сообщения из очереди при помощи View Result Tree можно увидеть его свойства. Пример свойств считываемого из очереди сообщения приведены ниже:
Для извлечения JMSCorrelationID (одно из свойств сообщения, которое позволит менеджеру очередей и тестируемому приложению понять, на какой запрос посылаемое заглушкой сообщение является ответом) и бизнес-даты (в нашем случае — значение одного из полей XML запроса, которое позволит выбрать подходящий ответ) используем Regular Expression Extractor (пример использования на рисунке ниже):
В связи с тем, что по методике НТ задержка ответа от внешней системы была фиксированной, для ее эмуляции был использован Constant Timer (см. ниже), создающий фиксированную задержку между последовательными запросами. Если вам в ходе ваших тестов будет нужна изменяющаяся задержка, рекомендуем присмотреться к любому из Random Timer.
Теперь на основании считанного сообщения мы можем выбрать подходящий ответ. Для этого используем Switch controller:
Для отправки ответа на запрос внутрь Switch controller подкладываем сэмплеры JMS Publisher с именами, соответствующими возможным значениям переменной p_destination (которое было извлечено регулярным выражением из Subscriber).
Внутрь тела (область Text Message) сэмплеров JMS Publisher добавляем динамические данные при помощи переменных JMeter (например timestamp и т.п.).
В области JMS Properties сэмплеров JMS Publisher добавляем JMSCorrelationId со значением ID:${corrId}.
Для анализа статистики работы можно добавить Aggregate Report, который позволит анализировать статистику работы заглушки в части количества принятых и отправленных сообщений.
Подводя итог, еще раз остановимся на плюсах создания JMS-заглушки при помощи JMeter по сравнению с самостоятельной разработкой:
- Меньше возможностей выстрелить себе в ногу (количество кода, который нужно писать, сведено к минимуму, большая часть логики можно реализовать при помощи элементов JMeter);
- Имеется графический интерфейс и Listener для сбора статистики по работе заглушки, который нет необходимости прикручивать к заглушке самостоятельно;
- Нет необходимости устанавливать какое-либо дополнительное ПО для развертывания заглушки (Tomcat или Glassfish);
- Удобство запуска (запускается как обычный тест JMeter).