Главная
Блог разработчиков phpBB
 
+ 17 предустановленных модов
+ SEO-оптимизация форума
+ авторизация через соц. сети
+ защита от спама

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

Anna | 2.06.2014 | нет комментариев
Привет, Програвчане!

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

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

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

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

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

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

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

Появился вопрос, а что применять в нашем окружении в качестве 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.

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

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

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

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

Планы на грядущее

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

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

 Источник: programmingmaster.ru
Оставить комментарий
Форум phpBB, русская поддержка форума phpBB
Рейтинг@Mail.ru 2008 - 2017 © BB3x.ru - русская поддержка форума phpBB