Привет, Хабравчане!
Хочу поделиться с вами личным опытом в системном интеграционном тестировании. Наша команда занимается разработкой интеграционного слоя, через который связаны все системы в банке. Задач у нас много, времени не хватает, и вопрос тестирования интеграции всегда откладывался.
Как же происходит тестирование интеграции? Самый короткий ответ — никак, хотя у нас больше сотни систем, которые взаимодействуют через интеграционную шину Oracle Service Bus(OSB). У этого продукта есть инструмент OSB Console, который позволяет послать тестовый запрос и отображает полученный ответ. После того как разработчик реализует на шине новый сервис, сервис вручную проверяется через OSB Console. Если проверка успешна, то сервис объявляется работающим и меняется, только если на него начинают жаловаться разработчики внешних систем.
Поддержка используемой нами OSB подходила к концу, и возникла необходимость перехода на новую версию. Хотя сама миграция больших проблем не вызывала, встал вопрос, а как проверить работоспособность смигрированного решения? И тут наша команда в очередной раз задумалась о внедрении автоматического тестирования.
Картинка получилась простая и сразу всем понравилась.
В самом деле, нам нужно просто автоматизировать то, что мы делаем руками. Так давайте создадим тест, который будет хранить пары сообщений (запрос, ответ). После запуска наш тест пошлет запрос, получит ответ и сравнит его с хранящимся у него ответом. Если ответы совпали, то тест прошел успешно.
Возник вопрос, а что использовать в нашем окружении в качестве back-end систем? Очевидно, что настоящая back-end система не годится по нескольким причинам:
Стало ясно, что нам потребуется симулятор сервисов, и логичным решением было посмотреть готовые продукты.
Оказалось, что смотреть особо некуда, потому что таких продуктов на рынке всего 5:
Первые три продукта посмотреть не удалось, просто потому что их нельзя скачать и посмотреть. Нужно было заполнять длинные формы, оставлять телефоны, по которым с нами бы связались продажники, вобщем, все это могло тянуться месяцами. 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.
Конечно, полностью покрыть тестами интеграционный слой, который создавался более десяти лет, нам не удалось.
Самое главное, что реализованные тесты, обнаружили ошибки, которые бы произошли при миграции. А также обнаружили некоторые сервисы, которые в принципе не работали и не использовались. Так что наш опыт определенно положительный!
Нам понравилось, и мы будем продолжать. В ближайшем будущем планируется добавить симуляторы для JMS, поддержку бизнес-процессов и придумать, как проводить тесты производительности.
А вы тестируете интеграцию? Поделитесь, своим опытом!
Хочу поделиться с вами личным опытом в системном интеграционном тестировании. Наша команда занимается разработкой интеграционного слоя, через который связаны все системы в банке. Задач у нас много, времени не хватает, и вопрос тестирования интеграции всегда откладывался.
Как же происходит тестирование интеграции? Самый короткий ответ — никак, хотя у нас больше сотни систем, которые взаимодействуют через интеграционную шину Oracle Service Bus(OSB). У этого продукта есть инструмент OSB Console, который позволяет послать тестовый запрос и отображает полученный ответ. После того как разработчик реализует на шине новый сервис, сервис вручную проверяется через OSB Console. Если проверка успешна, то сервис объявляется работающим и меняется, только если на него начинают жаловаться разработчики внешних систем.
Поддержка используемой нами OSB подходила к концу, и возникла необходимость перехода на новую версию. Хотя сама миграция больших проблем не вызывала, встал вопрос, а как проверить работоспособность смигрированного решения? И тут наша команда в очередной раз задумалась о внедрении автоматического тестирования.
Как мы себе это представляли
Картинка получилась простая и сразу всем понравилась.
В самом деле, нам нужно просто автоматизировать то, что мы делаем руками. Так давайте создадим тест, который будет хранить пары сообщений (запрос, ответ). После запуска наш тест пошлет запрос, получит ответ и сравнит его с хранящимся у него ответом. Если ответы совпали, то тест прошел успешно.
Виртуализация сервисов (mocks, stubs)
Возник вопрос, а что использовать в нашем окружении в качестве back-end систем? Очевидно, что настоящая back-end система не годится по нескольким причинам:
- Для тестов нам нужно, чтобы система работала над определенным набором данных. Предположим, что мы проверяем, как работает сервис, возвращающий остаток на счете. Для такого теста счет с данным номером должен существовать, и сервис должен возращать определенное значение. Поддержка тестовых данных на живой системе может быть трудоемким процессом.
- Система может быть вообще не доступна в тестовом окружении. Или на момент интеграции сервис может еще находиться в разработке.
- Для проверки исключительных ситуаций система должна возвращать ошибку.
Стало ясно, что нам потребуется симулятор сервисов, и логичным решением было посмотреть готовые продукты.
Оказалось, что смотреть особо некуда, потому что таких продуктов на рынке всего 5:
- Parasoft SoaTest
- CA Lisa Service Virtualization
- IBM Rational Service Tester
- HP Service Virtualization
- Soap UI
Первые три продукта посмотреть не удалось, просто потому что их нельзя скачать и посмотреть. Нужно было заполнять длинные формы, оставлять телефоны, по которым с нами бы связались продажники, вобщем, все это могло тянуться месяцами. 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, поддержку бизнес-процессов и придумать, как проводить тесты производительности.
А вы тестируете интеграцию? Поделитесь, своим опытом!