Преодоление ограничений среды при интеграционном тестировании

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

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

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

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

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

Ограничения среды

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

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

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

Методы устранения узких мест

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

Планирование использования среды

Простейшая стратегия заключается в том, чтобы активно планировать использование среды и управлять ею. Обычно ответственность за это возлагается на менеджера выпуска. Интеграционные среды рассматриваются как ценные ресурсы и выделяются для тестирования выпуска в зависимости от его приоритета и сроков. Современные инструменты управления выпусками, такие как IBM UrbanCode Release, способны обеспечить формальное отслеживание среды, планирование и выявление конфликтов, но до сих пор в этих целях широко используются электронные таблицы.

Преимущества

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

Недостатки

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

Среда как услуга

Чрезвычайно полезна возможность запросить среду тестирования, оптимизированную для вашего приложения, и подготовить и настроить ее в течение нескольких минут. Для этого используются технологии облака (открытого или частного) в сочетании с механизмом модельных сред, таким как UrbanCode Deploy with Patterns, для создания сред, их настройки и ликвидации.

Преимущества

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

Недостатки

Низкие затраты на создание среды ведут к размножению сред. Это может привести к большим расходам на оборудование, особенно при наличии очень больших сред интеграции. Среды, построенные поверх относительно дешевых облачных ресурсов, помогают уменьшить затраты на установку. Так как среды легко создавать и ликвидировать, уменьшается склонность поддерживать редко используемые среды. Вместо этого можно освобождать ресурсы, когда они не используются, и при необходимости быстро восстановить среду.

Так как эта стратегия строится на облаке и виртуализации, многие "ценные" компоненты не вписываются в стратегию "среда как услуга". Их нужно либо распределять между несколькими планируемыми средами, либо виртуализировать.

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

Виртуализация услуг

При виртуализации услуг некоторые из компонентов системы заменяются "заглушками" или "фиктивными компонентами". Этот подход известен давно. Разработчики создают макет, который внешне функционирует как полноценная служба, и выполняют тестирование с этим макетом. Например, если услуги сторонней компании по предоставлению котировок акций оцениваются, исходя из числа транзакций, то для целей тестирования разработчик может создать службу-дублер с тем же API, которая всегда возвращает одни и те же значения. Инструменты виртуализации служб вроде тех, что присутствуют в IBM Rational Test Workbench, рационализируют процесс создания подобных заглушек и управления их использованием.

Преимущества

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

Заглушки также могут заменять компоненты, поставляемые другими группами. Этот подход имеет три основных преимущества:

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

Недостатки

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

Реалистичный сценарий, объединяющий разные методы

Вымышленный пример крупной системы Marketplace демонстрирует, как использовать разные инструменты вместе. Marketplace состоит из многих частей.

• 60 веб-сервисов, которые тесно связаны между собой. Каждая из четырех групп отвечает за 15 сервисов.
• До 20% транзакций выполняют компоненты мейнфрейма; эти компоненты редко меняются и принадлежат другой группе.
• Клиентский веб-сайт, витрина предоставляемых услуг, принадлежит группе .com.
• Данные поступают от двух сторонних организаций (через веб-сервис). Услуги одной из них оцениваются по числу транзакций, а другой - нет.

У группы выпуска Marketplace была одна большая среда интеграционного тестирования (INT) и среда тестирования производительности (PERF). Теперь каждая из шести групп располагает небольшой лабораторией тестирования, где можно проверять отдельные компоненты, но не комплексные сценарии. Интеграционное тестирование значится в графике выпуска, и руководство выпуском регулирует доступ к средам INT и PERF.

Интеграционные среды уровня группы

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

• Среда как услуга (EaaS): инструменты EaaS ускоряют работу экземпляра приложения с помощью внутреннего облака компании. Используется только набор виртуальных машин, необходимый для обслуживания данной группы разработки, и последняя рабочая копия пользовательского интерфейса.
• Виртуализация услуг: услуги других групп веб-сервисов и мейнфрейма виртуализируются. Виртуализируются только те услуги, которые оцениваются по числу транзакций, другие используются "живьем".
• Планирование среды: для наглядности используется система планирования на базе инструмента Release Management, которая "знает", в какой среде выполняется работа для того или иного выпуска. Однако поскольку недостатка в средах нет, плановое распределение сред на уровня группы не производится.

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

Среда интеграции уровня выпуска

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

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

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

Тестирование производительности

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

Окончательное интеграционное тестирование

Для окончательной проверки интеграции используется среда интеграционного тестирования. Так как она предусматривает доступ к ценным ресурсам, таким как реальная версия сдельно оплачиваемых услуг и компоненты мейнфрейма, она подлежит управлению и планированию. По-прежнему применяется система планирования использования среды для ее выделения предстоящим выпускам.

Модель

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