Тестирование асинхронных web-сервисов через MQ-очереди

общие вопросы
,
#1

Добрый день!

У меня есть вопрос к бывалым специалистам. Есть проект на котором нужно тестировать функционал сервисов и желательно еще и создавать авто-тесты по функциональным сценариям. Сервисы работают через MQ-очереди. Из одной читают, в другую пишут ответ.

Читал, что многие делают через юнит-тесты, разворачивают в памяти БД и т.п. и тесты гоняются очень быстро. У нас ситуация немного другая. Тестировать надо на Бд близкой к боевой. Очень много логики заложено в справочники БД.

На своем проекте пришли к использованию SoapUI и изредка rfhutil и т.п. штуки для ручного проброса сообщений в очередь. Также на SoapUI делаю авто-тесты. Получается довольно удобно и наглядно. Но возник вопрос, есть ли еще какие инструменты для тестирования. Какие есть подходы. Какие есть плюсы/минусы и подводные камни.

Из того что уже увидел на SoapUI - принцип домино очень часто срабатывает. И еще на free версии сложно закладывать логику Data Driven, т.е. таблицы с данными.
Пока просто под каждый сервис создаем отдельный TestSuite и в нем под каждую проверку свой TestCase. Все параметры подключения и некоторые переменные глобального характера вынесены на уровень проекта в Custom Properties. Еще проблемы бывают с парсингом XML, т.к. в отличии от работы с WSDL в SoapUI при работе с MQ приходится использовать groovy для парсинга запроса/ответа. Не то чтобы это была большая проблема, но там обращение к элементам идет не по имени, а по индексу (не нашел как по имени искать элементы) и как итог конструкция может быть очень хрупкой к перемене тегов в ответе.

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

Какие вообще есть инструменты для тестирования веб-сервисов?
Вот тут смотрел презентацию Фреймворк автотестирования веб-сервисов своими силами в которой описывается самоделка. Какие преимущества делать отдельный фрейм-ворк? В принцие ничто не мешает отправлять запросы и из Eclipse, правда тесты будут менее понятны для обычных тестировщиков. В этом плане SoapUI куда как проще. В одном окне отправил XML, которую легко тут же отредактировать, а в другом получаешь ответ. Который можно и визуально сравнить с ожидаемым и накидать Assertions которые проверят его и по XSD-схеме и другие проверки сделают и в базу стрельнут запрос. А если чего нет, то можно подумать над jar-библиотекой, которая бы делала что нужно.

Еще прочитал про какую-то утилиту Cinimex Test Tool, но там нужно звонок обратный заказывать и скорее всего она платная. В отличии от SoapUI, который имеет бесплатную версию (по большей части нам уже хватает возможностей бесплатной версии). Еще есть какие-то решения от HP и IBM и может еще какие-то, но вроде бы там тоже звонки от менеджера и только за деньги.

Кто-то работал с другими инструментами? Какие впечатления, какой результат?
Еще смотрел в сторону бесплатного jmeter, но по удобству и наглядности он SoapUI чутка проигрывал и не стал тратить на него время. Может и зря.

P.S. в данном разделе уже прочел все схожие темы, но кроме SoapUI ничего особо не предлагали и еще все они были 2-3 годичной давности. Может что-то с тех пор поменялось? Отпишитесь кто с чем и как работал.

P.P.S. сервисы у меня асинхронные через MQ-очередь, поэтому даже с SoapUI приходится довольно много шаманить, чтобы оно работало и еще много всяких “странностей” в его работе часто всплывает…

#2

А какой MQ-брокер используется? И все же уточню, не стоит ли задача в тестировании самих сообщений (аля некое промежуточное звено, перехватывающее очередь, способное сгенерить / засетить / проанализировать нужные данные on-fly)?

#3

День добрый! Не очень понял вопрос про MQ-брокер. У нас используется IBM WebSphere MQ, но SoapUI работает с ним через Hermes JMS на более высоком уровне абстракции и там в Hermes можно любой другой брокер настроить и прицепить другую библиотеку (jar-ник), а в SoapUI ничего и не изменится. Вообще, не думал, что тип брокера может как-то повлиять на работу и тестирование. Есть какие-то ограничения? Нужно ли как-то это рассматривать в создаваемой тестовой модели?

У нас стоит задача проверки функционала системы. Есть некая система, назовем ее Б. Она делается на технологии Д, и должна эта система заменить систему А, которая давно стоит в проме и работает на технологии Г. При этом весьма желательно чтобы потребители данных сервисов ничего не заметили или имели минимальные доработки со своей стороны. Для этого необходимо проверить и убедиться, что система Б делает тоже или почти тоже что и система А. Документации по обеим системам понятно дело нет. Тестировать сам MQ-брокер не нужно. Нужно отправлять сообщения заданного формата в очередь In и забирать свой ответ из очереди Out. На этапе системного тестирования смотрится изолированное приложение + БД + брокер, остальное на заглушках, если таковые имеются и требуются. Часть вещей приходится смотреть вручную, особенно режимы нештатной работы или записи в журнале транзакций. Но такие вещи смотрятся не постоянно, т.к. требуют много времени. И они пока не в приоритете для автоматизации. Пока достаточно сформировать запрос XML заполнив ее некими данными из БД (написав нужный запрос) и отправить ее в очередь In, далее из очереди Out берется ответ на наш запрос и проверяется на то, что мы примерно ожидаем. А также пуляются запросы в БД, чтобы убедиться что в ней сделаны нужные нам изменения или получены именно те данные, что мы запрашивали.

На каждый такой сервис типа getClientInfo или setDateOpen или что-то там еще делается от нескольких штук до нескольких десятков сценариев с различными исходами в зависимости от заложенной логики проверки. Assert’ов при этом в каждом тесте от 10 до 30 штук, т.к. один запрос делает много вещей и желательно максимально убедиться, что сервис делает то что нужно.

#4

Про брокер спрашивал, т.к. когда-то был у нас на ревью проект, где требовалось тестирование корректности самих сообщений. Т.е. предлагалось встраивать слушатель сообщений в качестве прослойки между low и high уровнями приложения. В данном случае использовался RabbitMQ, под который уже написана спринговая оболочка. По сути, таким образом можно было наблюдать за системой, записывать данные, эмулировать различные кейсы с обеих сторон, генерить валидные и не очень сообщения, следить за реакцией, собирать статистику и т.п. Но это скорее доп. уровень тестирования аля middleware framework. У ваш же - более глобальная задача.