Привет, Хабр!
Это приквел моей предыдущей публикации и в то же время ремейк статьи Автоматизированное тестирование сервисов, использующих протокол MQ с помощью JMeter.
На этот раз расскажу о своем опыте примирения JMeter и IBM MQ для счастливого тестирования приложений на IBM WAS. Сталкивался с такой задачей, легко она не поддавалась. Хочу помочь сэкономить время всем заинтересованным.

О проекте: шина данных, множество xml-сообщений, три области обмена (очереди, БД, файловая система), веб-сервисы со своей логикой обработки сообщений. По мере развития проекта тестировать вручную становилось всё сложнее. На помощь был призван Apache JMeter — мощный и опенсорсный, с большим сообществом пользователей и дружелюбным интерфейсом. Легкость кастомизации версии «из коробки» позволяет покрыть любые кейсы, а обещание ведущего разработчика помочь если что (таки помог) окончательно утвердило в выборе.
Для взаимодействия с менеджером очередей нужен начальный контекст. Он бывает нескольких типов, вот тут можно почитать подробнее.
Для его создания удобно использовать MQ Explorer:

Рисунок 1: Добавление начального контекста
Выбрать файловый тип контекста и директорию для хранения .bindings файла, который будет содержать описание JNDI-объектов:

Рисунок 2: Выбор типа начального контекста
После чего можно приступать к созданию этих объектов. И начать с фабрики соединений:

Рисунок 3: Создание фабрики соединений
Выбрать понятное имя…

Рисунок 4: Выбор имени фабрики соединений
… и тип Queue Connection Factory:

Рисунок 5: Выбор типа фабрики соединений
Протокол — MQ Client для возможности взаимодействия с MQ удаленно:

Рисунок 6: Выбор протокола фабрики соединений
На следующем шаге можно выбрать уже существующую фабрику и дальнейшие настройки скопировать с нее. Жмем Next, если таковой нет:

Рисунок 7: Выбор настроек существующей фабрики соединений
В окне выбора параметров достаточно задать три. На вкладке Connection указать имя менеджера очередей и ip стенда с его расположением (порт 1414 оставить):

Рисунок 8: Настройка параметров фабрики соединений
И на вкладке Channels — канал для соединения. Нажать Finish для завершения:

Рисунок 9: Завершение создания фабрики соединений
Теперь создадим подключение к очереди:

Рисунок 10: Создание целевого объекта
Выберем понятное имя (предпочитаю указывать реальное имя очереди) и тип Queue:

Рисунок 11: Выбор имени и типа целевого объекта
По аналогии с Рисунком 7 можно скопировать настройки с существующей очереди. Также жмем Next, если она первая:

Рисунок 12: Выбор настроек существующего целевого объекта
В окне настроек достаточно выбрать имя менеджера и нужную очередь, нажать Finish. После чего повторить необходимое число раз, пока все очереди, нужные для взаимодействия с JMeter, не будут созданы:

Рисунок 13: Завершение создания целевого объекта
Подготовка JMeter заключается в добавлении библиотек, необходимых для взаимодействия с MQ. Они располагаются в %wmq_home%/java/lib. Скопируйте их в %jmeter_home%/lib/ext перед запуском JMeter.
Альтернативный список, предложенный polarnik в комментарии с небольшим нюансом: javax.jms-api-2.0.jar вместо jms.jar.
С jms.jar возникает ошибка NoClassDEfFoundError, решение которой нашел тут.
Оба списка библиотек успешно работают с JMeter 5.0 и IBM MQ 8.0.0.4.
Необходимый и достаточный набор элементов JMeter выглядит так:

Рисунок 14: Тест-план
В примере тест-плана пять переменных. Несмотря на малое их количество, рекомендую заводить отдельные конфигурационные элементы под разные типы переменных. По мере разрастания тестов это существенно упростит навигацию. В данном случае получается два списка. Первый содержит параметры подключения к MQ (см. Рисунок 2 и Рисунок 4):

Рисунок 15: Параметры подключения к MQ
Второй — имена целевых объектов, ссылающихся на очереди:

Рисунок 16: Параметризованные имена очередей
Остается настроить JMS Publisher для загрузки тестового сообщения в исходящую очередь:

Рисунок 17: Настройка JMS Publisher
И JMS Subscriber для вычитывания сообщения из входящей очереди:

Рисунок 18: Настройка JMS Subscriber
Если всё сделано правильно, результат выполнения в листнере наполнится яркими и жизнерадостными зелёными красками.
Намеренно опустил вопросы маршрутизации и администрирования, это довольно интимные и обширные темы для отдельных публикаций.
Кроме того, есть солидная порция нюансов в работе с очередями, базами и файлами, о которых также хотелось бы поговорить отдельно и обстоятельно.
Берегите своё время. И спасибо за внимание.

Это приквел моей предыдущей публикации и в то же время ремейк статьи Автоматизированное тестирование сервисов, использующих протокол MQ с помощью JMeter.
На этот раз расскажу о своем опыте примирения JMeter и IBM MQ для счастливого тестирования приложений на IBM WAS. Сталкивался с такой задачей, легко она не поддавалась. Хочу помочь сэкономить время всем заинтересованным.

Введение
О проекте: шина данных, множество xml-сообщений, три области обмена (очереди, БД, файловая система), веб-сервисы со своей логикой обработки сообщений. По мере развития проекта тестировать вручную становилось всё сложнее. На помощь был призван Apache JMeter — мощный и опенсорсный, с большим сообществом пользователей и дружелюбным интерфейсом. Легкость кастомизации версии «из коробки» позволяет покрыть любые кейсы, а обещание ведущего разработчика помочь если что (таки помог) окончательно утвердило в выборе.
Приготовление начального контекста
Для взаимодействия с менеджером очередей нужен начальный контекст. Он бывает нескольких типов, вот тут можно почитать подробнее.
Для его создания удобно использовать MQ Explorer:

Рисунок 1: Добавление начального контекста
Выбрать файловый тип контекста и директорию для хранения .bindings файла, который будет содержать описание JNDI-объектов:

Рисунок 2: Выбор типа начального контекста
После чего можно приступать к созданию этих объектов. И начать с фабрики соединений:

Рисунок 3: Создание фабрики соединений
Выбрать понятное имя…

Рисунок 4: Выбор имени фабрики соединений
… и тип Queue Connection Factory:

Рисунок 5: Выбор типа фабрики соединений
Протокол — MQ Client для возможности взаимодействия с MQ удаленно:

Рисунок 6: Выбор протокола фабрики соединений
На следующем шаге можно выбрать уже существующую фабрику и дальнейшие настройки скопировать с нее. Жмем Next, если таковой нет:

Рисунок 7: Выбор настроек существующей фабрики соединений
В окне выбора параметров достаточно задать три. На вкладке Connection указать имя менеджера очередей и ip стенда с его расположением (порт 1414 оставить):

Рисунок 8: Настройка параметров фабрики соединений
И на вкладке Channels — канал для соединения. Нажать Finish для завершения:

Рисунок 9: Завершение создания фабрики соединений
Теперь создадим подключение к очереди:

Рисунок 10: Создание целевого объекта
Выберем понятное имя (предпочитаю указывать реальное имя очереди) и тип Queue:

Рисунок 11: Выбор имени и типа целевого объекта
По аналогии с Рисунком 7 можно скопировать настройки с существующей очереди. Также жмем Next, если она первая:

Рисунок 12: Выбор настроек существующего целевого объекта
В окне настроек достаточно выбрать имя менеджера и нужную очередь, нажать Finish. После чего повторить необходимое число раз, пока все очереди, нужные для взаимодействия с JMeter, не будут созданы:

Рисунок 13: Завершение создания целевого объекта
Подготовка JMeter
Подготовка JMeter заключается в добавлении библиотек, необходимых для взаимодействия с MQ. Они располагаются в %wmq_home%/java/lib. Скопируйте их в %jmeter_home%/lib/ext перед запуском JMeter.
- com.ibm.mq.commonservices.jar
- com.ibm.mq.headers.jar
- com.ibm.mq.jar
- com.ibm.mq.jmqi.jar
- com.ibm.mq.pcf.jar
- com.ibm.mqjms.jar
- dhbcore.jar
- fscontext.jar
- jms.jar
- jta.jar
- providerutil.jar
Альтернативный список, предложенный polarnik в комментарии с небольшим нюансом: javax.jms-api-2.0.jar вместо jms.jar.
С jms.jar возникает ошибка NoClassDEfFoundError, решение которой нашел тут.
- com.ibm.mq.allclient.jar
- fscontext.jar
- javax.jms-api-2.0.jar
- providerutil.jar
Оба списка библиотек успешно работают с JMeter 5.0 и IBM MQ 8.0.0.4.
Настройка тест-плана
Необходимый и достаточный набор элементов JMeter выглядит так:

Рисунок 14: Тест-план
В примере тест-плана пять переменных. Несмотря на малое их количество, рекомендую заводить отдельные конфигурационные элементы под разные типы переменных. По мере разрастания тестов это существенно упростит навигацию. В данном случае получается два списка. Первый содержит параметры подключения к MQ (см. Рисунок 2 и Рисунок 4):

Рисунок 15: Параметры подключения к MQ
Второй — имена целевых объектов, ссылающихся на очереди:

Рисунок 16: Параметризованные имена очередей
Остается настроить JMS Publisher для загрузки тестового сообщения в исходящую очередь:

Рисунок 17: Настройка JMS Publisher
И JMS Subscriber для вычитывания сообщения из входящей очереди:

Рисунок 18: Настройка JMS Subscriber
Если всё сделано правильно, результат выполнения в листнере наполнится яркими и жизнерадостными зелёными красками.
Заключение
Намеренно опустил вопросы маршрутизации и администрирования, это довольно интимные и обширные темы для отдельных публикаций.
Кроме того, есть солидная порция нюансов в работе с очередями, базами и файлами, о которых также хотелось бы поговорить отдельно и обстоятельно.
Берегите своё время. И спасибо за внимание.
