Часть серии статей о |
Разработка программного обеспечения |
---|
В программной инженерии виртуализация служб или виртуализация служб — это метод эмуляции поведения определенных компонентов в гетерогенных приложениях на основе компонентов, таких как приложения на основе API , облачные приложения и сервисно-ориентированные архитектуры . Он используется для предоставления командам по разработке программного обеспечения и контролю качества/тестированию доступа к зависимым системным компонентам, которые необходимы для проверки тестируемого приложения (AUT), но недоступны или труднодоступны для целей разработки и тестирования. Благодаря «виртуализации» поведения зависимых компонентов тестирование и разработка могут продолжаться без доступа к фактическим живым компонентам. Поставщики, отраслевые аналитики и отраслевые издания признают виртуализацию служб отличной от имитации. [1] [2] Сравнение инструментов моделирования API см. здесь .
Виртуализация сервисов эмулирует поведение компонентов программного обеспечения для устранения ограничений зависимости в командах разработки и тестирования. Такие ограничения возникают в сложных взаимозависимых средах, когда компонент, подключенный к тестируемому приложению:
Хотя термин «виртуализация сервисов» отражает первоначальную направленность метода на виртуализацию веб-сервисов , виртуализация сервисов распространяется на все аспекты составных приложений: сервисы, базы данных , мэйнфреймы , ESB и другие компоненты, которые взаимодействуют с использованием общих протоколов обмена сообщениями. [3] [4] [5] Другие подобные инструменты называются симуляторами API , инструментами имитации API, тестовыми двойниками по проводу .
Виртуализация сервисов эмулирует только поведение определенных зависимых компонентов, которые разработчикам или тестировщикам необходимо использовать для завершения своих сквозных транзакций. Вместо того, чтобы виртуализировать целые системы, она виртуализирует только определенные фрагменты зависимого поведения, критически важные для выполнения задач разработки и тестирования. Это обеспечивает ровно столько логики приложения, чтобы разработчики или тестировщики получали то, что им нужно, не дожидаясь завершения и готовности фактического сервиса. Например, вместо виртуализации всей базы данных (и выполнения всего связанного управления тестовыми данными, а также настройки базы данных для каждого сеанса тестирования) вы отслеживаете, как приложение взаимодействует с базой данных, затем эмулируете соответствующее поведение базы данных ( SQL- запросы, которые передаются в базу данных, соответствующие возвращаемые наборы результатов и т. д.). [6] [7]
Виртуализация услуг подразумевает создание и развертывание «виртуального актива», имитирующего поведение реального компонента, который необходим для проверки работоспособности тестируемого приложения, но к которому трудно или невозможно получить доступ для целей разработки и тестирования.
Виртуальный актив заменяет зависимый компонент, прослушивая запросы и возвращая соответствующий ответ — с соответствующей производительностью. Для базы данных это может включать прослушивание оператора SQL, а затем возврат строк источника данных. Для веб-службы это может включать прослушивание сообщения XML по HTTP , JMS или MQ , а затем возврат другого сообщения XML. Функциональность и производительность виртуального актива могут отражать фактическую функциональность/производительность зависимого компонента или могут имитировать исключительные условия (например, экстремальные нагрузки или состояния ошибок), чтобы определить, как тестируемое приложение реагирует в этих обстоятельствах.
Виртуальные активы обычно создаются:
Затем они дополнительно настраиваются для представления конкретных данных, функциональности и времени отклика.
Виртуальные активы развертываются локально или в облаке (публичном или частном). С помощью сред разработки/тестирования, настроенных на использование виртуальных активов вместо зависимых компонентов, разработчики или тестировщики могут затем использовать приложение, над которым они работают, не дожидаясь завершения или доступности зависимых компонентов. [3] [4] [7]
Аналитики отрасли сообщают, что виртуализация услуг лучше всего подходит для «ИТ-отделов, имеющих значительный опыт «пропуска» интеграционного тестирования из-за «зависимого программного обеспечения» и имеющих достаточно сложную систему тестирования». [8]
Альтернативный подход к обходу ограничений доступа к тестовой среде, изложенный во введении к этой статье, заключается в том, что члены команды разрабатывают заглушки методов или фиктивные объекты , которые заменяют зависимые ресурсы. Недостаток этого подхода стал очевиден в начале 2000-х годов с появлением сервисно-ориентированной архитектуры . [9] Распространение составных приложений , которые полагаются на многочисленные зависимые службы, а также рост гибкой разработки программного обеспечения после публикации Agile Manifesto в 2001 году, все больше усложняли для разработчиков или тестировщиков ручную разработку количества, объема и сложности заглушек или фиктивных объектов, необходимых для выполнения задач разработки и тестирования для современной разработки корпоративных приложений. [10]
Первым шагом в эволюции от заглушек к виртуализации услуг стала технология, упакованная в инструменты тестирования SOA с 2002 года. [11] Самые ранние реализации виртуализации услуг были разработаны для автоматизации процесса разработки простых эмуляций, подобных заглушкам, чтобы можно было более эффективно тестировать составные приложения. [12] Поскольку корпоративные системы продолжали становиться все более сложными и распределенными, поставщики программных инструментов переключили внимание с заглушек на виртуализацию услуг, более ориентированную на среду. [2] Хотя заглушки все еще можно выполнить путем ручной разработки и управления заглушками, то, что стало известно как «виртуализация услуг», выполняется с использованием одной из доступных коммерческих готовых (COTS) технологий виртуализации услуг в качестве платформы для разработки и развертывания их «активов виртуализации услуг». [10]
Растущая популярность [13] гибкой разработки программного обеспечения и DevOps создала спрос на новый набор инструментов для предоставления виртуализации сервисов сообществам, которые работают таким образом. [14] Такие практики, как непрерывная поставка и переход от разработки на мэйнфреймах и монолитах к более распределенным архитектурам на основе микросервисов, хорошо сочетаются с возможностями виртуализации сервисов. Команды Agile и DevOps предпочитают работать с легкими инструментами, которые имеют меньше накопленного раздувания и не имеют обременительных лицензионных ограничений. [15]