t.me/atinfo_chat Telegram группа по автоматизации тестирования

Руководство от практика по современному SOA тестированию


(Mykhailo Poliarush) #1

Введение

SOA обещает увеличение гибкости и жизненного цикла приложения, более тесную интеграцию и снижения затрат. Однако эти обещания трудно выполнить. Строительство сложных интеграционных систем – это не простая задача, которая  включает сочетание сложных инструментов, индивидуальные методики и множество творческих подходов, для того чтобы правильно реализовать, оттестировать и поставить SOA-системы.

SOA тестирование – это сочетание проверок сервисов, проверки процессов, TDM и автоматизации UI. Сюда входит также создание таких методов, как непрерывное интеграционное тестирование и виртуализация сервисов.  Команды тестеров должны проверить системы у поставщика услуг и со стороны клиента для обеспечения безошибочного исполнения систем. Тесты также должны быть сгруппированы правильно в регрессионный набор. Ключевым моментом регрессионного набора является обработка данных на основании workflow.

Начиная наше путешествие с проверки в реальных условиях

Многие из нас были ознакомлены с  SOA с помощью веб-семинаров, статей и книг, изданных поставщиками SOA. Обещания, данные  евангелистами SOA, кажется, легко достичь, и они являются мечтой каждого технического директора. Но на этапе внедрения всплывает  реальность. Каждое обещание SOA в реальности является огромной проблемой.

Давайте кратко посмотрим на некоторые из общих проблем, с которыми мы столкнулись в процессе внедрения SOA за последнее время:

SOA приносит некоторые проблемы для команды
тестирования тем, что они должны изучить новые технологии, процессы и новые
инструменты, которые используются. Многие команды тестирования часто проверяют,
смогут ли они продолжать использовать классические инструменты и процессы в
новой среде SOA. Но как только они начинают SOA тестирование, понимают, что не смогут продолжать. Давайте посмотрим на некоторые из причин, и вопросы,
которые приводят к реализации:

Современные требования к инструменту

  • SOA имеет уникальную архитектурную экологию. Могут ли классические инструменты тестировать не-UI компоненты? Могут ли эти инструменты справиться с подпиской на brokers? Могут ли они интерпретировать сообщения, которые идут через ESB?

  • SOA имеет свой собственный набор уникальных протоколов. Может ли существующие инструменты автоматизации обрабатывать такие протоколы, как SOAP, WS-Security и подобные протоколы?

  • Могут ли классические инструменты изолировать ошибку посредством вызовов компонент по Web? 

Методология изменений

  • Новая архитектура приносит необходимость нового подхода. Текущие процессы жизненные цикла тестирования черного ящика и инструментов не могут справиться с внезапной необходимостью  для серьезного тестирования  серого ящика. Например, мы должны проверить UI и компоненты, которые вызываются после него.

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

Непрерывная цепь тестирования бизнес-процессов

  • Могут ли обрабатывать текущие средства выступать единым целым из несколько инструментов, которые охватывают все технологии? Например: UI автоматизация, промежуточное тестирование, тестирование и обслуживание базы данных запросов.

  • Непрерывная цепь тестирования процесса тестирования может создавать некоторые сложные Test Data Management (TDM) запросы, которые не требуют SOA монолитных систем.

Ограничения доступа

  • SaaS системы могут увеличивать стоимость регрессионного тестирования.

  • Некоторые системы, такие как мейнфреймы, не могут быть легкодоступными или доступными для тестирования вообще.

SOA Roadmap

Каждый проект SOA можно разделить на четыре стадии

  1. управление требованиями, 
  2. анализ и проектирование, 
  3. разработку (и тестирование), 
  4. развертывание и управление производством. 

Большинство SOA поставщиков предоставляют репозитории и BPM / БАМ системы, которые поддерживают фазу развертывания и управления производством. Эти фазы управляются специальными командами SOA и не являются основным направлениями для тестеров. CIT (компонетное интеграционное тестирование) и SIT (системное интеграционное тестирование), которые возникает на этапе проектирования, разработки и тестирования, имеет значительно большой интерес для тестеров SOA.

 

Диаграмма ниже иллюстрирует различные этапы Core SOA Solution:

core soa solution

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

Первые шаги в процессе тестирования SOA

SOA тестирование фокусируется на трех уровнях системы:

  1. Уровень сервиса: Включает в себя услуги, предоставляемые системами, которые являются производными от бизнес-функций.

  2. Уровень процесса: Содержит аспекты осуществления бизнес-процессов. В основном они существуют в виде составных сервисов, хореографии и моделей процессов. Эти процессы также может быть встроены в пользовательские интерфейсы, ETL-инструменты или доменные модели. При тестировании внимание больше сосредоточено на процессах, которые реализуются в пользовательских интерфейсах и на уровне процесса.

  3. Потребители сервиса: Это могут быть и другие услуги или компоненты пользовательского интерфейса.

Первым шагом в процессе тестирования SOA является проверка сервисов по функциональных и нефункциональных требований.

Затем мы проверяем шаги, осуществляемые в рамках процесса (это является синонимом интеграционному тестированию). Это проверка сервисов и компонентов процесса в прослойке поставщика сервисов.

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

Этот процесс немного изменяет проверку системы. В таких случаях, процессы встроены на основании пользовательских интерфейсов и доменных моделей. Ключевым моментом в таких случаях является тестирование сервисов, а затем уже автоматизация тестирования процессов, и т.д. для проверки целостности системы в целом. Этот подход показан ниже:

SOA Testing-the four step approach

Проблемы в реализации процессов тестирования SOA

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

Другим подходящим примером является процесс для ускорения UI автоматизации. Многие процессы здесь имеют повторяющиеся шаги (например, login или logout), которые требуют много усилий. Когда вы повторяете эти действия по тест кейсу, изменение их в SOA среде может быть весьма сложной задачей. Еще одна проблема в этом процессе – это необходимость протестировать системы или сервисы, которые имеют per-use затраты (ограниченное использование) или недоступные системы.

Давайте посмотрим на некоторые аспекты поддержки нижеуказанных процессов:

  1. Предоставление рабочих данных на основе предоставления сервисов и обслуживания целостности данных, их стабильности, маскирование данных: - тут необходимо применять виртуализацию и системы управление данными.

  2. Ускорение UI автоматизации: выбор инструмента и разработка фреймворков, которые генерируют UI скрипты автоматизации и централизуют повторяющиеся действия.

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

  4. Непрерывное интеграционное тестирование: Используйте инструменты тестирования, которые способны мониторить изменения в репозитории и в системе. Они должны запускать регрессионные наборы, чтобы избежать критических ошибок, а также выполнять регрессионные наборы на всех релизах для эффективного тестового покрытия.

Ниже мы рассмотрим некоторые другие аспекты SOA тестирования:

  1. Безопасность: Используйте инструменты тестирования безопасности, который фокусируется на тестировании серого и черного ящиков. Не забывайте использовать penetration инструменты и искать общие уязвимости, такие как инъекции (скриптов) и отказ в обслуживании сервисов. В некоторых архитектурах, тестирование сервисов для обеспечения безопасности - жизненно важно, для того, чтобы проверить слабые звенья в цепи безопасности.

  2. Производительность: сервисы и модели процессов могут быть очень не быстрыми при исполнении. Иногда даже обновление версии ПО, может повлиять на производительность. Другие возможные препятствия для производительности включают в себя сервисы, которые преобразуют данные и сервисы, которые синхронно вызываются из многочисленных приложений (особенно там, где производительность является критически важной и должна быть  достаточной, чтобы обойти ESBs).

  3. Обеспечение управляемости: Управление включают в себя обеспечение соответствия политикам, таким как PCI-DSS (безопасность) или WS-I Basic Profile (совместимость). Лучшим вариантом является работа с инструментом который может валидировать такие схемы.

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

Польза от автоматизации тестирования дает хорошее ROI при тестировании SOA. Это верно, потому что регрессивное тестирование имеет решающее значение для сути Agile в постоянно меняющемся мире SOA. Ваш выбор инструментов будет зависеть от ваших потребностей. Эти потребности могут быть от простых с открытым исходным кодом до очень дорогих коммерческих инструментов. Ваш подход тем не менее почти всегда будет одинаков и показан на рисунке ниже:

a simplifield view of test automatoin for SOA

 

На рисунке показан упрощенный вариант автоматизации тестирования для SOA (кроме TDM, end to end тестирования, UI автоматизации и так далее) и указывает на тестирование обобщенной SOA-системы. Основными этапами здесь являются:

  1. Тестеры используют инструмент автоматизации для вызова служб или для публикации и подписки на broker. Сервис может быть REST / POX / JSON / SOAP  и передаваться  через такие транспортные протоколы, как HTTP, FTP, и JMS. Brokering предоставляется в основном ESB, например, IBM, TIBCO и другими.

  2. Тестеры используют  различные методы проверки. Контент может быть идентифицирован как с помощью регулярных выражений, так и с помощью XPath. Правила проверки могут варьироваться от простой арифметики (<.>. =), до сложных скриптов Java .

  3. У тестеров есть различные варианты для параметризации.

  4. Тест кейсы, собранны в регрессионные наборы тестов.

  5. Наборы могут быть выполнены в соответствии с графиком работ или вызываться по требованию в соответствии с изменением в репозитории.

  6. NFRs может играть важную роль, поскольку большинство инструментов тестирования позволяют делать тестирование производительности. Некоторые инструменты включают в себя также функции безопасности тестирования.

Заключение

Очевидно, что SOA тестирование привело к улучшению подходов тестирования и к новому поколению специализированных инструментов. SOA-тестеры должны знать более объемные процессы, инструменты и расширять свои навыки, чтобы охватить более широкий спектр методов. К ним относятся UI автоматизация, TDM, виртуализация, безопасность и производительность.

Успех в реализации SOA QA зависит от использования необходимых инструментов и вспомогательных процессов, которые смогут реализовать тестирование. Это гарантирует, что следующее поколение системы будет соответствовать ожиданиям бизнес пользователей.