Автоматизация системного интеграционного тестирования

Привет, читатели!

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

Как же происходит тестирование интеграции? Самый короткий ответ — никак, хотя у нас больше сотни систем, которые взаимодействуют через интеграционную шину Oracle Service Bus ^[1](OSB). У этого продукта есть инструмент OSB Console, который позволяет послать тестовый запрос и отображает полученный ответ. После того как разработчик реализует на шине новый сервис, сервис вручную проверяется через OSB Console. Если проверка успешна, то сервис объявляется работающим и меняется, только если на него начинают жаловаться разработчики внешних систем.

Поддержка используемой нами OSB подходила к концу, и возникла необходимость перехода на новую версию. Хотя сама миграция больших проблем не вызывала, встал вопрос, а как проверить работоспособность смигрированного решения? И тут наша команда в очередной раз задумалась о внедрении автоматического тестирования.

Как мы себе это представляли

Картинка получилась простая и сразу всем понравилась.

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

Виртуализация сервисов (mocks, stubs)

Возник вопрос, а что использовать в нашем окружении в качестве back-end систем? Очевидно, что настоящая back-end система не годится по нескольким причинам:

• Для тестов нам нужно, чтобы система работала над определенным набором данных. Предположим, что мы проверяем, как работает сервис, возвращающий остаток на счете. Для такого теста счет с данным номером должен существовать, и сервис должен возращать определенное значение. Поддержка тестовых данных на живой системе может быть трудоемким процессом.
• Система может быть вообще не доступна в тестовом окружении. Или на момент интеграции сервис может еще находиться в разработке.
• Для проверки исключительных ситуаций система должна возвращать ошибку.

Стало ясно, что нам потребуется симулятор сервисов, и логичным решением было посмотреть готовые продукты.

Оказалось, что смотреть особо некуда, потому что таких продуктов на рынке всего 5:

• Parasoft SoaTest ^[2]
• CA Lisa Service Virtualization ^[3]
• IBM Rational Service Tester ^[4]
• HP Service Virtualization ^[5]
• Soap UI ^[6]

Первые три продукта посмотреть не удалось, просто потому что их нельзя скачать и посмотреть. Нужно было заполнять длинные формы, оставлять телефоны, по которым с нами бы связались продажники, вобщем, все это могло тянуться месяцами. HP Service Virtualization в принципе тоже попадает в эту группу, но оказалось, что этот продукт у нас уже куплен. Однако, после недели мучений выяснилось, что использовать его не получится. Открытого API у этого продукта нет, а создать тысячи сервисов через визуальный редактор было нереально. Представитель HP сказал, что сервисы могут быть накликаны только вручную, а об автоматизации они не задумывались.

Большие надежды возлагались на Soap UI, который умеет запускать mock-сервисы, как web-приложение. Но, оказалось, что SOAP UI уж очень «UI». Во-первых, он не thread-safe, а во-вторых, использует очень много памяти и работает нестабильно.

В процессе исследований выяснилось, что в нашем банке уже есть аж четыре(!) самописных симулятора web-сервисов. Один из них оказался очень даже ничего, был взят за основу и по мере надобности дописан. Так в тестовом окружении у нас появился симулятор — web-приложение, которое по определенным HTTP-запросам возвращает определенные HTTP-ответы.

Каждый виртуальный сервис — это maven проект. В конфигурации проекта (service-descriptor.xml, response-selector.xml) написано как на основании HTTP-запроса определить, какой вызван сервис, какая нужна операция и по какому правилу вернуть HTTP-ответ.

После изменений исходников проект автоматически собирается на Jenkins и при помощи maven wagon деплоится в работающее приложения симулятора.

А теперь пишем тест

Следующим шагом нам нужно написать тест, который фактически будет симулятором front-end системы. То есть нам нужно написать web-service клиент.

Наш тест является maven проектом. Внутри проекта находятся пары файлов (запрос, ответ), которые собственно и являются исходниками. Билд проекта состоит в том, что наш самописный maven plugin вызывает web-сервис передает ему тестовый запрос, получает ответ и сравнивает его с тестовым ответом.

Тесты запускаются автоматически каждую ночь на Jenkins.

Создание тестовых данных

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

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

Что получилось

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

• Не все back-end системы работают через web-сервисы, нужны адаптеры для других протоколов.
• Есть требования тестировать не один сервис, а целый бизнес-процесс. В этом случае надо хранить согласованные наборы данных для нескольких сервисов.
• Написать симулятор, который поддерживает все, что умеет back-end — довольно большая работа. Мы не успели сделать поддержку REST-сервисов, асинхронные сообщения, а также разные методы аутентификации.

Самое главное, что реализованные тесты, обнаружили ошибки, которые бы произошли при миграции. А также обнаружили некоторые сервисы, которые в принципе не работали и не использовались. Так что наш опыт определенно положительный!

Планы на будущее

Нам понравилось, и мы будем продолжать. В ближайшем будущем планируется добавить симуляторы для JMS, поддержку бизнес-процессов и придумать, как проводить тесты производительности.

А вы тестируете интеграцию? Поделитесь, своим опытом!

Автор: kohus

Источник ^[7]