O que é teste SOA? Tutorial com exemplo

O que é teste SOA?

SOA (Orientado a Serviços Archi(textura) Testando É o teste do estilo arquitetônico SOA, no qual os componentes do aplicativo são projetados para se comunicar por meio de protocolos de comunicação, normalmente através de uma rede.

O que é SOA?

SOA é um método de integração de aplicativos e processos de negócios para atender às necessidades de negócios.

In Engenharia de SoftwareA Arquitetura Orientada a Serviços (SOA) proporciona agilidade e flexibilidade aos processos de negócios. Uma alteração em um processo ou aplicativo pode ser direcionada a um componente específico sem afetar todo o sistema.

Os desenvolvedores de software que trabalham em SOA desenvolvem ou compram partes de programas chamadas Serviços.

O que é Serviço?

O diagrama abaixo mostra um gateway de pagamento publicado como um serviço que vários sites de comércio eletrônico podem utilizar.

• Um serviço pode ser uma unidade funcional de uma aplicação ou processo de negócio, que pode ser reutilizada ou repetida por qualquer outra aplicação ou processo. (Por exemplo, na imagem acima, o Gateway de Pagamento é um serviço que pode ser reutilizado por qualquer site de comércio eletrônico. Sempre que um pagamento precisa ser feito, o site de comércio eletrônico chama ou solicita o serviço de Gateway de Pagamento. Após a conclusão do pagamento no gateway, uma resposta é enviada de volta para o site de comércio eletrônico.)
• Os serviços são fáceis de montar e reconfigurar componentes.
• Os serviços podem ser comparados a blocos de construção. Eles podem construir qualquer aplicação necessária, e adicioná-los ou removê-los da aplicação ou do processo de negócios é fácil.
• Os serviços são definidos mais pela função comercial que desempenham do que como blocos de código.

Serviços web

A maioria dos serviços SOA são expostos como serviços web, portanto, vale a pena definir a mecânica de uma chamada de serviço web antes das camadas de teste.

Serviços Web São componentes de aplicativos independentes que estão disponíveis na web.

Eles podem ser publicados, encontrados e usados ​​na web, e se comunicam pela internet. A sequência abaixo mostra como um provedor, um registro e um consumidor interagem.

• O Provedor de Serviços publica o serviço na Internet.
• O cliente pesquisa um serviço web específico no Registro de Serviços Web.
• A URL e wsdl Os dados para o serviço web necessário são retornados. Usando o WSDL e o URLA comunicação entre o provedor de serviços e o solicitante ocorre por meio de mensagens SOAP.
• Quando um consumidor acessa um serviço web, uma conexão HTTP é estabelecida com o provedor.
• Uma mensagem SOAP é criada para instruir o provedor a invocar a lógica de serviço web necessária.
• A resposta recebida do provedor é uma mensagem SOAP incorporada na resposta HTTP. Essa resposta HTTP é o formato de dados compreensível pela aplicação consumidora.

Exemplo

A captura de tela abaixo mostra uma previsão do tempo fornecida por um serviço externo e incorporada na página inicial de um mecanismo de busca.

A página inicial de um site e um mecanismo de busca exibem uma previsão do tempo diária. Em vez de programar a seção de previsão do tempo do zero, um serviço de previsão do tempo pode ser adquirido de um fornecedor e integrado às páginas.

Camadas de teste SOA

A SOA consiste em várias tecnologias, e os aplicativos construídos usando SOA possuem vários serviços que são fracamente acoplados. O diagrama abaixo mapeia as três camadas que um plano de teste deve abranger.

Os testes de SOA devem se concentrar em 3 camadas do sistema.

Camada de Serviços

Esta camada consiste nos serviços expostos por um sistema, derivados de funções de negócio.

Por exemplo, considere um site de bem-estar que consiste em:

• Peso Tracker
• Açúcar Sanguíneo Tracker
• Pressão arterial Tracker

TracOs servidores exibem os respectivos dados e a data em que foram inseridos. A camada de serviços consiste nos serviços que obtêm os respectivos dados do banco de dados:

• Peso Tracserviço ker
• Açúcar Sanguíneo Tracserviço ker
• Pressão arterial Tracserviço ker
• Serviço de login

Camada de Processo

A camada de processos consiste nos processos, o conjunto de serviços que fazem parte de uma única funcionalidade.

Os processos podem fazer parte de uma interface de usuário (por exemplo, um mecanismo de busca) ou de uma ferramenta ETL que extrai dados do banco de dados.

O foco principal nesta camada está nas interfaces e processos do usuário. A interface do usuário do peso. tracO foco principal é o ker e sua integração com o banco de dados.

As seguintes funções devem ser consideradas:

• Adicionando novos dados
• Editando dados existentes
• Criando um novo tracker
• Excluindo dados

Camada do Consumidor

Esta camada é composta principalmente por interfaces de usuário, como ilustra a tela abaixo.

Com base nessas camadas, o teste de uma aplicação SOA é distribuído em três níveis:

• Nível de serviço
• Nível de interface
• Nível de ponta a ponta

As duas abordagens diferem: uma abordagem de cima para baixo é usada para o projeto de testes, enquanto uma abordagem de baixo para cima é usada para a execução de testes.

Estratégia para testes SOA

Abordagem de planejamento de testes

• Os testadores de SOA devem compreender a arquitetura completa da aplicação.
• A aplicação precisa ser dividida em serviços independentes (um serviço que possui sua própria estrutura de requisição e resposta e não depende de nenhum outro serviço para formar uma resposta).
• A estrutura da aplicação precisa ser reorganizada em três componentes: dados, serviços e aplicações front-end.
• Todos os componentes precisam ser cuidadosamente analisados ​​e cenários de negócios devem ser elaborados.
• Os cenários de negócios devem ser classificados como cenários comuns e cenários específicos da aplicação.
• A TracMatriz de Habilidades devem ser preparados, e todos os casos de teste devem ser tracadaptado a cenários de negócios.

Abordagem de execução de teste

• Cada componente de serviço deve ser testado.
• Teste de integração dos componentes de serviço deve ser feito para validar o fluxo de dados através dos serviços e a integridade dos dados.
• Teste do sistema É necessário realizar uma simulação completa do modelo para validar o fluxo de dados entre a aplicação front-end e o banco de dados.
• Teste de Desempenho deve ser feito para ajuste fino e desempenho ideal.

Métodos de teste SOA

1) Testes baseados em dados e orientados por cenários de negócios

• Diversos aspectos comerciais relacionados ao sistema devem ser analisados.
• Os cenários devem ser desenvolvidos com base na integração dos diversos serviços web da aplicação, e dos serviços web com a aplicação.
• A configuração dos dados deve ser feita com base nos cenários acima.
• A configuração dos dados também deve abranger cenários de ponta a ponta.

2) Esboços

• Interfaces fictícias são criadas para testar serviços.
• Várias entradas podem ser fornecidas através dessas interfaces e as saídas podem ser validadas.
• Quando um aplicativo usa uma interface para um serviço externo que não está sendo testado (um serviço de terceiros), um stub pode ser criado durante o teste de integração.

3) Teste de regressão

• Teste de regressão A atualização do aplicativo deve ser feita quando houver várias versões, para garantir a estabilidade e a disponibilidade dos sistemas.
• Será criado um conjunto abrangente de testes de regressão cobrindo os serviços que constituem uma parte importante da aplicação.
• Este conjunto de testes pode ser reutilizado em várias versões do projeto.

4) Teste de nível de serviço

Os testes de nível de serviço incluem testar o componente quanto à funcionalidade, segurança, desempenho e interoperabilidade. Cada serviço precisa ser testado individualmente primeiro.

5) Teste Funcional

Teste funcional deve ser feito em cada serviço para:

• Garantir que o serviço forneça a resposta correta para cada solicitação.
• Garantir que os erros corretos sejam recebidos para solicitações com dados inválidos ou incorretos.
• Verificar cada solicitação e resposta para cada operação que o serviço precisa executar em tempo de execução.
• Valide as mensagens de falha quando ocorrer um erro no servidor, no cliente ou na rede.
• Valide se as respostas recebidas estão no formato correto.
• Verifique se os dados recebidos na resposta correspondem aos dados solicitados.

6) Teste de segurança

Os testes de segurança do serviço web são um aspecto importante durante os testes de nível de serviço da aplicação SOA, pois garantem a segurança da aplicação.

Os seguintes fatores precisam ser cobertos durante o teste:

• O serviço web deve seguir o padrão da indústria definido pelo WS-Security.
• As medidas de segurança devem funcionar perfeitamente.
• Criptografia de dados e assinaturas digitais nos documentos.
• Autenticação e autorização.
• Injeção de SQL, malware, XSS, CSRF e outras vulnerabilidades serão testadas no XML.
• Ataques de negação de serviço.

7) Teste de desempenho

É necessário realizar testes de desempenho do serviço, pois os serviços são reutilizáveis ​​e várias aplicações podem estar utilizando o mesmo serviço.

Os seguintes fatores são considerados durante o teste:

• O desempenho e a funcionalidade do serviço precisam ser testados sob carga pesada.
• O desempenho do serviço precisa ser comparado quando ele funciona individualmente e quando está integrado à aplicação.
• Teste de carga Testes de desempenho do serviço devem ser realizados para verificar o tempo de resposta, identificar gargalos, verificar a utilização da CPU e da memória e prever a escalabilidade.

8) Teste de nível de integração

• Os testes de nível de serviço garantem o funcionamento adequado dos serviços individualmente; não garantem o funcionamento dos componentes acoplados.
• Os testes de integração são realizados com foco principal em: interfaces de.
• Esta fase cobre todos os cenários de negócios possíveis.
• Nesta fase, devem ser realizados mais um teste não funcional da aplicação. Os testes de segurança, conformidade e desempenho garantem a disponibilidade e a estabilidade do sistema em todos os seus aspectos.
• Os protocolos de comunicação e de rede deverão ser testados para validar a consistência da comunicação de dados entre os serviços.

9) Teste de ponta a ponta

Esta fase garante que a aplicação esteja em conformidade com os requisitos de negócio, tanto funcionais quanto não funcionais.

Os itens abaixo serão testados durante o período de teste. teste de ponta a ponta:

• Todos os serviços funcionando conforme esperado após a integração
• Manipulação de exceção
• Interface do usuário do aplicativo
• Fluxo de dados adequado através de todos os componentes
• Processo de negócio

Desafios nos testes de SOA

Aplicar esses métodos raramente é simples, e as dificuldades descritas abaixo são recorrentes em quase todos os programas de SOA (Avaliação Orientada a Serviços).

• Falta de interfaces para serviços.
• O processo de teste abrange vários sistemas, o que cria necessidades complexas de dados.
• A aplicação é uma coleção de vários componentes que tendem a mudar, portanto a necessidade de testes de regressão é mais frequente.
• Devido à arquitetura multicamadas, é difícil isolar os defeitos.
• Como um serviço é utilizado por diferentes interfaces, a carga é difícil de prever, o que torna o planejamento de testes de desempenho complexo.
• A Arquitetura Orientada a Serviços (SOA) é um conjunto de tecnologias heterogêneas. Testar uma aplicação SOA exige pessoas com diferentes conjuntos de habilidades, o que, por sua vez, aumenta os custos de planejamento e execução.
• Como o aplicativo integra vários serviços, os testes de segurança apresentam seus próprios desafios. Validar a autenticação e a autorização é difícil.

Ferramentas de teste SOA

Existem muitas ferramentas de teste SOA disponíveis no mercado para auxiliar os testadores na avaliação de aplicações SOA. Aqui estão algumas das ferramentas de teste SOA mais populares.

1) SoapUI

SoapUI é uma ferramenta de teste funcional de código aberto para serviços e Teste de API.

• Aplicativo de desktop
• Suporta múltiplos protocolos — SOAP, REST, HTTP, JMS, AMF, JDBC
• Os serviços web podem ser desenvolvidos, inspecionados e invocados.
• Também pode ser usado para testes de carga. Teste de automaçãoe testes de segurança
• Stubs podem ser criados por MockServices
• As solicitações e os testes de serviços web podem ser gerados automaticamente por meio de seu cliente de serviço web.
• Possui ferramentas de relatório integradas
• Desenvolvido pela SmartBear, que envia ambos os produtos. de código aberto SoapUI distribuição e comercialização ReadyAPI edição

2) Virtualização de serviços da Broadcom (anteriormente iTKO LISA)

LISA é um conjunto de produtos que oferece uma solução de teste funcional para sistemas distribuídos, como SOA. O produto passou da iTKO para a CA Technologies e hoje é comercializado como Broadcom Service Virtualization.

• Também pode ser usado para testes de regressão, integração, carga e desempenho.
• Pode ser usado para projetar e executar testes.

3) UFT Um (anteriormente HP Service Test)

O Service Test é uma ferramenta de teste funcional que oferece suporte a testes de interface do usuário e de serviços compartilhados. Sua funcionalidade de teste de API foi incorporada ao Unified Functional Testing, agora comercializado pela [nome da empresa/organização]. OpenText as UFT Um.

• É possível realizar testes funcionais e de desempenho de serviços com um único script.
• Integrado ao Quality Center, agora vendido como OpenText ALM / Quality Center.
• É possível gerenciar uma quantidade enorme de serviços e dados.
• Suporta testes de interoperabilidade simulando ambientes de clientes JEE, AXIS e DotNet.

4) Teste SOA da Parasoft

O Parasoft SOAtest é um conjunto de ferramentas de teste e análise desenvolvido para testes de API e aplicações orientadas a API.

• Suporta serviços web, REST, JSON, MQ, JMS, TIBCO, HTTP e tecnologias XML.
• São possíveis testes funcionais, de unidade, de integração, de regressão, de segurança, de interoperabilidade, de conformidade e de desempenho.
• É possível criar stubs usando Virtualização Parasoft, que são mais capazes do que SoapUI Serviços simulados.

Casos de uso de teste SOA

O exemplo prático abaixo aplica a estratégia, os métodos e as ferramentas acima a um único site de comércio eletrônico, fase por fase.

Considere um site de comércio eletrônico que contenha as funções e subfunções abaixo.

processamento de pedido

O gráfico abaixo divide o processamento de pedidos nas subfunções que se tornam serviços.

FASE 1

Na primeira fase de testes de SOA, a fase de estratégia de testes, a aplicação é dividida em serviços e funções de negócio.

Vamos analisar os serviços listados abaixo no aplicativo.

• Criar pedido
• Verifique o status do cliente
• Alterar status do pedido
• Verificar o estado do pedido
• Verificar estoque

As funções comerciais são as mesmas que as funções do site.

Nota: O documento de estratégia de testes conterá a lista dos serviços e das funções que devem ser testadas.

FASE 2

Esta é a fase de planejamento do teste. Casos de teste são escritos para cada nível.

Nível de ponta a ponta. Os casos de teste são escritos para cada caso de uso e fluxo de negócio. Abaixo estão exemplos de casos de teste.

• Criar um pedido com um usuário ativo.
• Crie um pedido com um usuário inativo.
• Crie um pedido com um produto disponível, cuja quantidade seja inferior à quantidade disponível.
• Crie um pedido com um produto disponível, cuja quantidade seja maior que a quantidade disponível.
• Criar um pedido com vários itens.
• Cancele um pedido completamente.
• Cancelar um pedido parcialmente.

Nível de integração. Os casos de teste são elaborados para a integração do banco de dados e da interface do usuário. Abaixo estão exemplos de casos de teste.

• Crie um novo pedido com um único item. Verifique se o pedido foi criado no banco de dados.
• Crie um novo pedido com um único item. Verifique se o preço calculado para o pedido está correto.
• Crie um novo pedido com um único item. Verifique se a quantidade do produto disponível foi reduzida pelo valor do pedido.
• Verifique se o status do pedido exibido na interface do usuário é o mesmo que o registrado no banco de dados.
• Cancele o pedido e verifique se o status do pedido foi modificado no banco de dados.
• Para pagamentos realizados pela primeira vez, verifique se os dados de pagamento inseridos na interface do usuário foram salvos no banco de dados.
• Para devolver pagamentos, verifique se os detalhes do pagamento no banco de dados são exibidos na IU.

Nível de serviço. Cada serviço é testado para todas as condições de dados. Abaixo estão alguns exemplos.

Não.	Detalhes do pedido	Condição do pedido
1	Criar pedido. Nº de itens = 1	Quantidade no pedido < Quantidade no banco de dados
2	Criar pedido. Nº de itens > 1	Quantidade em pedido < Quantidade no banco de dados
3	Criar pedido. Nº de itens = 1	Quantidade no pedido > Quantidade no banco de dados
4	Verifique o status da ordem	Status no banco de dados = Ativo
5	Verifique o status da ordem	Status no banco de dados = Enviado
6	Verifique o status da ordem	Status no banco de dados = Cancelado
7	Verifique o status da ordem	ID do pedido = inválido
8	Verifique a disponibilidade do produto	Quantidade de produto >0
9	Verifique a disponibilidade do produto	Quantidade do produto =0
10	Verifique a disponibilidade do produto	ID do produto = inválido

FASE 3 — Execução de Testes

A execução dos testes utiliza uma abordagem de baixo para cima: primeiro são realizados os testes em nível de serviço, depois os testes em nível de integração e, por último, os testes de ponta a ponta.

1) Nível de serviço

Vamos considerar que o SoapUI A ferramenta é usada para testar a aplicação. O WSDL e URL são navegados para a janela de teste de SoapUIE a solicitação para cada serviço é exibida na janela de solicitações. Ao modificar os dados de acordo com os casos de teste de nível de serviço, as solicitações são criadas para cada caso de teste.

Caso de teste	SOLICITAÇÃO	Resposta esperada
Criar pedido. Número de itens = 1, Quantidade no pedido < Quantidade no banco de dados	x2 2	o3251 Bem-sucedido
Criar pedido. Número de itens > 1, Quantidade no pedido < Quantidade no banco de dados	y1 1 y2 3	o3251 Bem-sucedido
Criar pedido. Número de itens = 1, Quantidade no pedido > Quantidade no banco de dados	x23 200	nulo Mal sucedido
Verificar o status do pedido. Status no banco de dados = Ativo	o9876	Ativo Bem-sucedido
Verifique o status do pedido. Status no banco de dados = Enviado	o9656	Enviado Bem-sucedido
Verificar status do pedido. ID do pedido = Inválido	y5686	nulo Sem sucesso
Verificar disponibilidade do produto. Quantidade do produto >0	d34	34 sim Bem-sucedido
Verificar disponibilidade do produto. Quantidade do produto = 0	34	0 não Bem-sucedido
Verificar disponibilidade do produto. ID do produto = inválido	sder	Mal sucedido

2) Nível de integração

Os casos de teste de nível de integração são executados na interface do usuário e no banco de dados. Crie um pedido com um único item:

• Um usuário abre o site.
• O usuário vai fazer um pedido.
• O usuário seleciona um produto e uma quantidade válidos e salva o pedido.
• Deverá ser exibida uma mensagem informando que o pedido foi realizado com sucesso.
• O usuário acessa o banco de dados e verifica se os detalhes do pedido são os mesmos que os inseridos no site.

3) Nível de ponta a ponta

Os fluxos de negócios e casos de uso são executados na interface do usuário. Crie um pedido com vários itens:

• Um usuário abre o site.
• O usuário vai fazer um pedido.
• O usuário consulta sobre um produto e quantidade válidos e os adiciona ao carrinho.
• Outros produtos válidos são adicionados com as quantidades corretas e o pedido é salvo. O pagamento é feito através de um novo método de pagamento e o pedido é finalizado.
• Uma mensagem dizendo “Pedido realizado com sucesso” deverá ser exibida.
• O testador deve validar se todo o fluxo é concluído sem distorção dos dados.

Perguntas Frequentes