українська версія сайтуenglish website versionрусская версия сайта Deutsche Website Version
    ДомашняяОбучениеПосещение курсовПолучение работы QAСтатьиО насКонтактыНовостиФорум
     


    Мастерство в Обеспечении Качества ПО
    Подписаться письмом
    Наиболее популярные курсы Центра
    Какие курсы Центра Вам наиболее интересны?

     
      тел.: +38(044)45-900-46
      e-mail: classes@tester-training.com.ua

    Тестирование СОА
    Все больше организаций принимают стратегическое решение о переходе на сервис-ориентированную архитектуру (СОА); однако тем, кто не сталкивался с СОА, не известно, как она изменяет процесс тестирования. Особенностям тестирования СОА и посвящена эта статья.

    Что такое СОА?

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

    Уровневая модель СОА 

    СОА является многоуровневой системой. На нижнем уровне сервисы имеют ограниченную область применения и высокую степень обобщенности (базовые сервисы). Средний уровень («координация сервисов») содержит сервисы с более широкой областью применения и наличием некоторой бизнес-логики. Верхний уровень состоит исключительно из обращений к сервисам более низких уровней. Такую организацию обычно называют «управляемым бизнес-процессом» (orchestrated business process).

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

    Последствия для тестирования

    Ряд особенностей СОА определяет необходимость подходов к тестированию, отличных от тестирования «обычных» приложений.

    Многократное использование

    В правильно разработанной СОА широко распространено многократное использование сервисов. Чем больше расширяется СОА, тем больше сервисов используется многократно. Успешность этого подхода зависит от качества отдельных сервисов, так как многократное использование накладывает ряд жестких требований, например:

    • процесс, обращающийся к сервису, может рассчитывать на то, что сервис продолжит работу при любых обстоятельствах
    • когда функциональность сервиса расширяется, старые функции продолжают работать так же, как и раньше (так называемая обратная совместимость)

    Этот подход требует всестороннего тестирования сервиса перед интеграцией его в систему. Частое многократное использование сервисов в среде СОА требует больших объемов регрессионного тестирования, которое должно выполняться часто и быстро. Качественно разработанные, легкие для повторения тесты становятся необходимостью с самого начала разработки, что повышает выгодность использования инструментов для автоматизированного тестирования.

    Пользовательский интерфейс

    Большинство сервисов не имеют пользовательского интерфейса – они оперируют данными «втихомолку», не информируя пользователя о каждом своем действии. Тестирование таких сервисов становится скорее технической задачей, требующей специальных инструментов.

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

    Следовательно, использование инструментов автоматизированного тестирования, подготовленных к работе в среде СОА, является обязательным – без таких инструментов тестировщик растрачивает время на однообразные кропотливые действия, такие, как формирование XML сообщений вручную, вызовы сервисов, и внимательную вычитку файлов отчета для проверки результатов тестирования.

    Доступность сервисов

    Многое может и должно быть протестировано в СОА задолго до того, как система будет полностью функциональна. Следовательно, нужна возможность тестирования отдельных компонентов вне их контекста. Для этого обычно требуются модули-«заглушки» или специальные драйвера.

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

    Особые критерии качества

    Определенные характеристики качества являются более критичными для СОА, чем для «традиционных» систем. Так, тестирование производительности в «традиционных» системах обычно выполняется на последних этапах разработки и тестирует более-менее сформированную систему; в СОА, тестирование производительности начинается с момента разработки сервиса. Защита доступа также требует особого внимания, поскольку сервисы, по определению, доступны намного большему количеству пользователей, следовательно, риск неправильного использования намного выше. Функциональная совместимость, степень способности компонентов взаимодействовать друг с другом по заданным стандартам, также становится важной с первых этапов разработки – если соответствие стандартам не контролируется жестко, проблемы на дальнейших этапах гарантированы.

    Технологии

    Работа в сфере сервис-ориентированных ИТ-проектов подразумевает знакомство с рядом специальных принципов и технологий, например, сервисная шина предприятия (ESB), XML, WSDL, протоколы WEB2.0 и SOAP, BPEL, и другие. Тестировщикам необходимо знание этих технологий для тестирования и проверки результатов, а также для определения потенциально ошибочных областей.

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

    В мире ИТ принято различать разработку новых приложений и поддержку существующих. Для СОА это различие стирается, поскольку новая функциональность создается путем комбинирования новых сервисов с существующими. Системы, разрабатываемые в среде СОА, не могут рассматриваться как длительные крупномасштабные проекты – они являются набором локальных изменений. Как следствие, проектирование системы, тестирование и разработка переходят из категории проектно-ориентированных задач в непрерывные.

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

    Среда тестирования также получает ряд условий. Совокупное тестирование законченного бизнес-процесса требует наличия всех задействованных сервисов в среде тестирования. Если, как это обычно делается, каждый проект имеет свою среду тестирования, подготовка к совокупному тестированию становится сложнейшей задачей: установить правильные версии всех компонентов, привести в соответствие тестовые данные, и т.д. Для СОА правильнее организовать постоянную среду тестирования, управляемую специальным отделом.

    Инструменты

    Мы неоднократно отметили, что тестирование СОА невозможно без подходящих инструментов. Не все «традиционные» инструменты тестирования подходят для СОА – они должны поддерживать технологии, используемые данной СОА, тестирование производительности и систем защиты, а также работу с XML и использование модулей-«заглушек».

    Среди существующих инструментов для тестирования СОА можно отметить Parasoft SOAtest, Lisa-WS, Green Hat и SOAP UI.

    Способности тестировщика

    СОА подчеркивает различие между техническим тестировщиком и бизнес-тестировщиком. Тестирование на уровне сервисов является технической задачей, по причине отсутствия пользовательского интерфейса и необходимости специальных инструментов; тестирование на уровне дирижируемого бизнес-процесса требует понимания бизнес-рисков и быстрого, гибкого, эффективного выполнения. Это предоставляет тестировщикам все возможности для дальнейшей специализации в соответствии с личными способностями и интересами.

     

    (по материалам STAR Tester и Atos Origin)
     
     вверх
    Копирайт © 2006 - 2007 CEQA.