Virtualização de serviço - Service virtualization
| Desenvolvimento de software |
|---|
Na engenharia de software , a virtualização de serviço ou virtualização de serviço é um método para emular o comportamento de componentes específicos em aplicativos baseados em componentes heterogêneos, como aplicativos baseados em API , aplicativos baseados em nuvem e arquiteturas orientadas a serviços . É usado para fornecer às equipes de desenvolvimento de software e QA / teste acesso a componentes de sistema dependentes que são necessários para executar um aplicativo em teste (AUT), mas não estão disponíveis ou são de difícil acesso para fins de desenvolvimento e teste. Com o comportamento dos componentes dependentes "virtualizados", o teste e o desenvolvimento podem prosseguir sem acessar os componentes reais reais. A virtualização de serviço é reconhecida por fornecedores, analistas do setor e publicações do setor como sendo diferente da simulação. Veja aqui uma comparação de ferramentas de simulação de API .
Visão geral
A virtualização de serviço emula o comportamento dos componentes de software para remover as restrições de dependência nas equipes de desenvolvimento e teste. Essas restrições ocorrem em ambientes complexos e interdependentes quando um componente conectado ao aplicativo em teste é:
- Ainda não foi completo
- Ainda evoluindo
- Controlado por um terceiro ou parceiro
- Disponível para teste apenas em capacidade limitada ou em momentos inconvenientes
- Difícil de provisionar ou configurar em um ambiente de teste
- Necessário para acesso simultâneo por equipes diferentes com configuração variada de dados de teste e outros requisitos
- Restrito ou caro para usar para testes de carga e desempenho
Embora o termo "virtualização de serviço" reflita o foco inicial da técnica na virtualização de serviços da web , a virtualização de serviço se estende a todos os aspectos de aplicativos compostos: serviços, bancos de dados , mainframes , ESBs e outros componentes que se comunicam usando protocolos de mensagens comuns. Outras ferramentas similares são chamados de API simuladores, ferramentas API zombando, ao longo dos fios duplos de teste .
A virtualização de serviço emula apenas o comportamento dos componentes dependentes específicos que os desenvolvedores ou testadores precisam exercer para concluir suas transações de ponta a ponta. Em vez de virtualizar sistemas inteiros, ele virtualiza apenas fatias específicas de comportamento dependente, essenciais para a execução de tarefas de desenvolvimento e teste. Isso fornece lógica de aplicativo suficiente para que os desenvolvedores ou testadores obtenham o que precisam sem ter que esperar que o serviço real seja concluído e esteja prontamente disponível. Por exemplo, em vez de virtualizar um banco de dados inteiro (e executar todo o gerenciamento de dados de teste associado, bem como configurar o banco de dados para cada sessão de teste), você monitora como o aplicativo interage com o banco de dados e, em seguida, emula o comportamento do banco de dados relacionado (o SQL consultas que são passadas para o banco de dados, os conjuntos de resultados correspondentes que são retornados e assim por diante).
Aplicativo
A virtualização de serviço envolve a criação e implantação de um "ativo virtual" que simula o comportamento de um componente real que é necessário para exercer o aplicativo em teste, mas é difícil ou impossível de acessar para fins de desenvolvimento e teste.
Um ativo virtual representa um componente dependente, ouvindo as solicitações e retornando uma resposta apropriada - com o desempenho apropriado. Para um banco de dados, isso pode envolver ouvir uma instrução SQL e, em seguida, retornar as linhas da fonte de dados. Para um serviço da web, isso pode envolver a escuta de uma mensagem XML sobre HTTP , JMS ou MQ e , em seguida, o retorno de outra mensagem XML. A funcionalidade e o desempenho do ativo virtual podem refletir a funcionalidade / desempenho real do componente dependente ou pode simular condições excepcionais (como cargas extremas ou condições de erro) para determinar como o aplicativo em teste responde nessas circunstâncias.
Ativos virtuais são normalmente criados por:
- Gravação de comunicação ao vivo entre os componentes conforme o sistema é exercido a partir do aplicativo em teste (AUT)
- Fornecimento de registros que representam a comunicação histórica entre os componentes
- Analisando especificações de interface de serviço (como um WSDL )
- Definindo o comportamento manualmente com vários controles de interface e valores de fonte de dados
Eles são então configurados para representar dados, funcionalidades e tempos de resposta específicos.
Os ativos virtuais são implantados localmente ou na nuvem (pública ou privada). Com os ambientes de desenvolvimento / teste configurados para usar os ativos virtuais no lugar dos componentes dependentes, os desenvolvedores ou testadores podem exercitar o aplicativo no qual estão trabalhando sem ter que esperar que os componentes dependentes sejam concluídos ou estejam prontamente acessíveis.
Os analistas do setor relatam que a virtualização de serviço é mais adequada para "lojas de TI com experiência significativa em 'pular' testes de integração devido ao 'software dependente' e com um equipamento de teste razoavelmente sofisticado".
Relação com stubbing e zombaria
Uma abordagem alternativa para contornar as restrições de acesso do ambiente de teste descritas na introdução deste artigo é os membros da equipe desenvolverem stubs de método ou objetos fictícios que substituam os recursos dependentes. A deficiência dessa abordagem tornou-se aparente no início dos anos 2000 com o surgimento da arquitetura orientada a serviços . A proliferação de aplicativos compostos que dependem de vários serviços dependentes, além do aumento do desenvolvimento de software Agile após a publicação do Manifesto Agile em 2001, tornou cada vez mais difícil para desenvolvedores ou testadores desenvolver manualmente o número, escopo e complexidade de stubs ou simulações necessário para concluir as tarefas de desenvolvimento e teste para o desenvolvimento de aplicativos corporativos modernos.
A primeira etapa na evolução de stub para virtualização de serviço foi a tecnologia empacotada em ferramentas de teste SOA desde 2002. As primeiras implementações de virtualização de serviço foram projetadas para automatizar o processo de desenvolvimento de emulações simples semelhantes a stub para que os aplicativos compostos pudessem ser testados com mais eficiência . Como os sistemas corporativos continuaram a se tornar cada vez mais complexos e distribuídos, os fornecedores de ferramentas de software mudaram o foco do stub para a virtualização de serviço mais focada no ambiente. Embora o stubbing ainda possa ser concluído por meio de desenvolvimento manual e gerenciamento de stubs, o que se tornou conhecido como "virtualização de serviço" é concluído usando uma das tecnologias de virtualização de serviço comercial disponíveis (COTS) como uma plataforma para o desenvolvimento e implantação de seus "ativos de virtualização de serviço".
Agile e DevOps
A crescente popularidade do desenvolvimento de software Agile e DevOps criou uma demanda por um novo conjunto de ferramentas para fornecer virtualização de serviço para comunidades que trabalham dessa forma. Práticas como entrega contínua e mudança do desenvolvimento de mainframe e monolith para arquiteturas baseadas em microsserviço mais distribuídas se encaixam bem com os recursos de virtualização de serviço. As equipes Agile e DevOps preferem trabalhar com ferramentas leves que têm menos inchaço acumulado e nenhuma restrição de licenciamento incômoda.
