O que é teste de integração (tutorial com exemplo de teste de integração)

what is integration testing

O que é teste de integração: aprender com exemplos de teste de integração

O teste de integração é feito para testar os módulos / componentes quando integrados para verificar se eles funcionam conforme o esperado, ou seja, para testar os módulos que estão funcionando bem individualmente, não há problemas quando integrados.

Quando falamos em termos de teste de grande aplicação usando a técnica de teste de caixa preta, envolve a combinação de muitos módulos que estão fortemente acoplados uns aos outros. Podemos aplicar os conceitos da técnica de teste de integração para testar esses tipos de cenários.

Lista de tutoriais cobertos nesta série:

Tutorial nº 1: O que é teste de integração? (Este tutorial)
Tutorial # 2: O que é teste incremental
Tutorial nº 3: O que é teste de componentes
Tutorial nº 4: Integração contínua
Tutorial # 5 Diferença entre teste de unidade e integração
Tutorial # 6: Dez principais ferramentas de teste de integração

O que você aprenderá:

• O que é teste de integração?
• Por que teste de integração?
• Vantagens
• Desafios
• Tipos de teste de integração
  • Abordagem do Big Bang:
• Abordagens de integração de teste
  • Abordagem de baixo para cima:
  • Abordagem de cima para baixo
• Teste de integração de aplicativo GUI
  • Exemplo de teste de integração:
• Etapas para iniciar os testes de integração
• Critérios de entrada / saída para teste de integração
• Casos de teste de integração
• A integração é uma técnica de caixa branca ou caixa preta?
• Ferramentas de teste de integração
• Teste de integração do sistema
• Diferença entre teste de integração e teste de sistema
• Conclusão
• Leitura recomendada

O que é teste de integração?

O significado do teste de integração é bastante simples- Integre / combine o módulo testado da unidade um por um e teste o comportamento como uma unidade combinada.

A principal função ou objetivo deste teste é testar as interfaces entre as unidades / módulos.

Normalmente fazemos o teste de integração após o “Teste de unidade”. Uma vez que todas as unidades individuais são criadas e testadas, começamos a combinar esses módulos “Testados por Unidade” e começamos a fazer os testes integrados.

A principal função ou objetivo deste teste é testar as interfaces entre as unidades / módulos.

Os módulos individuais são primeiro testados isoladamente. Uma vez que os módulos são testados na unidade, eles são integrados um a um, até que todos os módulos sejam integrados, para verificar o comportamento combinacional e validar se os requisitos foram implementados corretamente ou não.

Aqui devemos entender que o teste de integração não acontece no final do ciclo, mas sim simultaneamente com o desenvolvimento. Então, na maioria das vezes, nem todos os módulos estão realmente disponíveis para teste e aqui está o desafio de testar algo que não existe!

Por que teste de integração?

Achamos que o teste de integração é complexo e requer algum desenvolvimento e habilidade lógica. Isso é verdade! Então, qual é o propósito de integrar este teste em nossa estratégia de teste?

Aqui estão alguns motivos:

1. No mundo real, quando os aplicativos são desenvolvidos, eles são divididos em módulos menores e os desenvolvedores individuais recebem 1 módulo. A lógica implementada por um desenvolvedor é bastante diferente de outro desenvolvedor, por isso é importante verificar se a lógica implementada por um desenvolvedor está de acordo com as expectativas e renderizando o valor correto de acordo com os padrões prescritos.
2. Muitas vezes, a face ou a estrutura dos dados muda quando eles passam de um módulo para outro. Alguns valores são anexados ou removidos, o que causa problemas nos módulos posteriores.
3. Os módulos também interagem com algumas ferramentas ou APIs de terceiros que também precisam ser testados para verificar se os dados aceitos por essa API / ferramenta estão corretos e se a resposta gerada também é a esperada.
4. Um problema muito comum em testes - Mudança frequente de requisitos! :) Muitas vezes, o desenvolvedor implanta as mudanças sem fazer um teste de unidade. O teste de integração torna-se importante nesse momento.

Vantagens

Existem várias vantagens neste teste e algumas delas estão listadas abaixo.

• Este teste garante que os módulos / componentes integrados funcionam corretamente.
• O teste de integração pode ser iniciado assim que os módulos a serem testados estiverem disponíveis. Não requer que o outro módulo seja concluído para que o teste seja feito, pois Stubs e Drivers podem ser usados ​​para o mesmo.
• Ele detecta os erros relacionados à interface.

Desafios

Listados abaixo estão alguns desafios envolvidos no teste de integração.

# 1) Teste de integração significa testar dois ou mais sistemas integrados para garantir que o sistema funcione corretamente. Não apenas os links de integração devem ser testados, mas um teste exaustivo considerando o ambiente deve ser feito para garantir que o sistema integrado funcione corretamente.

Pode haver diferentes caminhos e permutações que podem ser aplicados para testar o sistema integrado.

#dois) Gerenciar o teste de integração torna-se complexo devido a poucos fatores envolvidos nele, como banco de dados, plataforma, ambiente, etc.

# 3) Ao integrar qualquer novo sistema com o sistema legado, ele requer muitas mudanças e esforços de teste. O mesmo se aplica à integração de quaisquer dois sistemas legados.

# 4) Integrar dois sistemas diferentes desenvolvidos por duas empresas diferentes é um grande desafio, pois não é certo como um dos sistemas irá impactar o outro sistema se alguma mudança for feita em qualquer um dos sistemas.

Para minimizar o impacto durante o desenvolvimento de um sistema, algumas coisas devem ser levadas em consideração, como possível integração com outros sistemas, etc.

Tipos de teste de integração

Dada a seguir é um tipo de integração de teste, juntamente com suas vantagens e desvantagens.

Abordagem do Big Bang:

A abordagem do big bang integra todos os módulos de uma vez, ou seja, não é possível integrar os módulos um por um. Ele verifica se o sistema funciona conforme o esperado ou não depois de integrado. Se algum problema for detectado no módulo completamente integrado, será difícil descobrir qual módulo causou o problema.

A abordagem big bang é um processo demorado de encontrar um módulo que tem um defeito, pois isso demoraria e, uma vez que o defeito fosse detectado, consertar o mesmo teria um custo alto, pois o defeito é detectado em um estágio posterior.

Vantagens da abordagem do Big Bang:

• É uma boa abordagem para sistemas pequenos.

Desvantagens da abordagem do Big Bang:

• É difícil detectar o módulo que está causando o problema.
• A abordagem do Big Bang requer todos os módulos juntos para teste, o que, por sua vez, leva a menos tempo para teste, já que o projeto, o desenvolvimento e a integração levariam a maior parte do tempo.
• O teste ocorre de uma só vez, o que não deixa tempo para o teste de módulo crítico isoladamente.

Etapas do teste de integração:

1. Prepare a integração Plano de teste.
2. Prepare cenários de teste de integração e casos de teste.
3. Prepare scripts de automação de teste.
4. Execute casos de teste.
5. Relate os defeitos.
6. Rastreie e teste novamente os defeitos.
7. O novo teste e o teste continuam até que o teste de integração seja concluído.

Abordagens de integração de teste

Existem basicamente 2 abordagens para fazer a integração de teste:

1. Abordagem de baixo para cima
2. Abordagem de cima para baixo.

Vamos considerar a figura abaixo para testar as abordagens:

Abordagem de baixo para cima:

O teste ascendente, como o nome sugere, começa na unidade mais baixa ou mais interna do aplicativo e sobe gradualmente. O teste de integração começa no módulo mais baixo e progride gradualmente para os módulos superiores do aplicativo. Essa integração continua até que todos os módulos sejam integrados e todo o aplicativo seja testado como uma única unidade.

Neste caso, os módulos B1C1, B1C2 e B2C1, B2C2 são o módulo mais baixo cuja unidade é testada. Módulos B1 e B2 ainda não foram desenvolvidos. A funcionalidade do Módulo B1 e B2 é que ele chama os módulos B1C1, B1C2 e B2C1, B2C2. Visto que B1 e B2 ainda não foram desenvolvidos, precisaríamos de algum programa ou um “estimulador” que chamará os módulos B1C1, B1C2 e B2C1, B2C2. Esses programas de estimuladores são chamados DRIVERS .

Em palavras simples, DRIVERS são os programas fictícios usados ​​para chamar as funções do módulo inferior em um caso em que a função de chamada não existe. A técnica ascendente requer o driver do módulo para alimentar a entrada do caso de teste na interface do módulo sendo testado.

A vantagem dessa abordagem é que, se houver uma falha grave na unidade mais baixa do programa, é mais fácil detectá-la e medidas corretivas podem ser tomadas.

A desvantagem é que o programa principal realmente não existe até que o último módulo seja integrado e testado. Como resultado, as falhas de design de nível superior serão detectadas apenas no final.

Abordagem de cima para baixo

Essa técnica começa no módulo superior e gradualmente avança para os módulos inferiores. Apenas o módulo superior é testado isoladamente. Depois disso, os módulos inferiores são integrados um a um. O processo é repetido até que todos os módulos sejam integrados e testados.

servidor privado do world of warcraft vanilla

No contexto da nossa figura, o teste começa no Módulo A e os módulos inferiores B1 e B2 são integrados um por um. Agora, aqui os módulos inferiores B1 e B2 não estão realmente disponíveis para integração. Portanto, a fim de testar os módulos A mais avançados, desenvolvemos “ STUBS ”.

“Stubs” pode ser referido como código, um snippet que aceita as entradas / solicitações do módulo superior e retorna os resultados / resposta. Desta forma, apesar dos módulos inferiores não existirem, podemos testar o módulo superior.

Em cenários práticos, o comportamento dos stubs não é tão simples quanto parece. Nesta era de arquitetura e módulos complexos, o chamado módulo, na maioria das vezes envolve uma lógica de negócios complexa, como a conexão com um banco de dados. Como resultado, a criação de Stubs se torna tão complexa e demorada quanto o módulo real. Em alguns casos, o módulo Stub pode acabar sendo maior do que o módulo estimulado.

Ambos os Stubs e drivers são pedaços de código fictícios que são usados ​​para testar os módulos “não existentes”. Eles acionam as funções / método e retornam a resposta, que é comparada ao comportamento esperado

Vamos concluir algumas diferenças entre Stubs e driver :

A única mudança é constante neste mundo, então temos outra abordagem chamada “ Teste de sanduíche ”Que combina os recursos da abordagem de cima para baixo e de baixo para cima. Quando testamos programas enormes como sistemas operacionais, precisamos ter mais algumas técnicas que são eficientes e aumentam a confiança. O teste de sanduíche desempenha um papel muito importante aqui, onde os testes de cima para baixo e de baixo para cima são iniciados simultaneamente.

A integração começa com a camada intermediária e se move simultaneamente para cima e para baixo. No caso da nossa figura, nossos testes começarão em B1 e B2, onde um braço testará o módulo superior A e outro braço testará os módulos inferiores B1C1, B1C2 & B2C1, B2C2.

Uma vez que ambas as abordagens começam simultaneamente, esta técnica é um pouco complexa e requer mais pessoas com conjuntos de habilidades específicas e, portanto, aumenta o custo.

Teste de integração de aplicativo GUI

Agora vamos falar sobre como podemos implicar em testes de integração na técnica da caixa preta.

Todos nós entendemos que um aplicativo da web é um aplicativo multicamadas. Temos um front end que é visível para o usuário, temos uma camada intermediária que tem lógica de negócios, temos mais uma camada intermediária que faz algumas validações, integra algumas APIs de terceiros etc., então temos a camada posterior que é a base de dados.

Exemplo de teste de integração:

Vamos verificar o exemplo abaixo:

Sou proprietário de uma empresa de publicidade e posto anúncios em diversos sites. No final do mês, quero ver quantas pessoas viram meus anúncios e quantas pessoas clicaram neles. Preciso de um relatório para os meus anúncios exibidos e cobro de acordo com meus clientes.

Software GenNext desenvolveu este produto para mim e abaixo estava a arquitetura:

CEBOLA - Módulo de interface do usuário, que é visível para o usuário final, onde todas as entradas são fornecidas.
BL - É o módulo Business Logic, que contém todos os cálculos e métodos específicos do negócio.
VAL - É o módulo de Validação, que contém todas as validações da correção da entrada.
CNT - É o módulo de conteúdo que possui todos os conteúdos estáticos, específicos para as entradas inseridas pelo usuário. Esses conteúdos são exibidos nos relatórios.
NO - É o módulo Engine, este módulo lê todos os dados que vêm do módulo BL, VAL e CNT e extrai a consulta SQL e a dispara para o banco de dados.
Agendador - É um módulo que agenda todos os relatórios com base na seleção do usuário (mensal, trimestral, semestral e anual)
DB - É o banco de dados.

Agora, tendo visto a arquitetura de toda a aplicação web, como uma única unidade, o teste de integração, neste caso, terá como foco o fluxo de dados entre os módulos.

As perguntas aqui são:

1. Como o BL, VAL e o módulo CNT lerão e interpretarão os dados inseridos no módulo UI?
2. O módulo BL, VAL e CNT está recebendo os dados corretos da IU?
3. Em qual formato os dados de BL, VAL e CNT são transferidos para o módulo EQ?
4. Como o EQ lerá os dados e extrairá a consulta?
5. A consulta foi extraída corretamente?
6. O Scheduler está obtendo os dados corretos para relatórios?
7. O conjunto de resultados recebido pela EN, da base de dados está correto e conforme o esperado?
8. O EN consegue enviar a resposta de volta ao módulo BL, VAL e CNT?
9. O módulo de IU é capaz de ler os dados e exibi-los apropriadamente na interface?

No mundo real, a comunicação de dados é feita em formato XML. Portanto, quaisquer dados que o usuário inserir na IU, eles serão convertidos em um formato XML.

Em nosso cenário, os dados inseridos no módulo UI são convertidos em arquivo XML que é interpretado pelos 3 módulos BL, VAL e CNT. O módulo EN lê o arquivo XML resultante gerado pelos 3 módulos, extrai o SQL dele e consulta o banco de dados. O módulo EN também recebe o conjunto de resultados e o converte em um arquivo XML e o retorna para o módulo UI, que converte os resultados em formato legível pelo usuário e os exibe.

No meio temos o módulo planejador que recebe o conjunto de resultados do módulo EN, cria e agenda os relatórios.

Então, onde o teste de integração entra em cena?

Bem, testar se as informações / dados estão fluindo corretamente ou não será seu teste de integração, que neste caso seria validar os arquivos XML. Os arquivos XML são gerados corretamente? Eles têm os dados corretos? Os dados estão sendo transferidos corretamente de um módulo para outro? Todas essas coisas serão testadas como parte do teste de integração.

Tente gerar ou obter os arquivos XML e atualizar as tags e verificar o comportamento. Isso é algo muito diferente do teste usual que os testadores normalmente fazem, mas isso agregará valor ao conhecimento e compreensão do aplicativo dos testadores.

Algumas outras condições de teste de amostra podem ser as seguintes:

• As opções do menu estão gerando a janela correta?
• As janelas podem chamar a janela em teste?
• Para cada janela, identifique as chamadas de função para a janela que o aplicativo deve permitir.
• Identifica todas as chamadas da janela para outros recursos que o aplicativo deve permitir
• Identificar chamadas reversíveis: fechar uma janela chamada deve retornar à janela de chamada.
• Identifique chamadas irreversíveis: as janelas de chamada fecham antes que a janela chamada apareça.
• Teste as diferentes maneiras de executar chamadas para outra janela. - menus, botões, palavras-chave.

Etapas para iniciar os testes de integração

1. Compreenda a arquitetura do seu aplicativo.
2. Identifique os módulos
3. Entenda o que cada módulo faz
4. Entenda como os dados são transferidos de um módulo para outro.
5. Entenda como os dados são inseridos e recebidos no sistema (ponto de entrada e ponto de saída do aplicativo)
6. Separe o aplicativo para atender às suas necessidades de teste.
7. Identifique e crie as condições de teste
8. Pegue uma condição de cada vez e anote os casos de teste.

Critérios de entrada / saída para teste de integração

Critério de entrada:

• O documento do plano de teste de integração foi assinado e aprovado.
• Casos de teste de integração foram preparados.
• Os dados de teste foram criados.
• Teste de unidade de módulos / componentes desenvolvidos está completo.
• Todos os defeitos críticos e de alta prioridade são fechados.
• O ambiente de teste está configurado para integração.

Critério de saída:

• Todos os casos de teste de integração foram executados.
• Nenhum defeito crítico e de prioridade P1 e P2 é aberto.
• O relatório de teste foi preparado.

Casos de teste de integração

Os casos de teste de integração se concentram principalmente no interface entre os módulos, links integrados, transferência de dados entre os módulos como módulos / componentes que já são testados por unidade, ou seja, a funcionalidade e os outros aspectos de teste já foram cobertos.

Portanto, a ideia principal é testar se a integração de dois módulos funcionais funciona conforme o esperado quando integrados.

Por exemplo, casos de teste de integração para aplicativo Linkedin incluirão:

• Verificando o link da interface entre a página de login e a página inicial, ou seja, quando um usuário insere as credenciais e os registros, ele deve ser direcionado para a página inicial.
• A verificação do link de interface entre a página inicial e a página de perfil, ou seja, a página de perfil deve ser aberta.
• Verifique o link da interface entre a página de rede e suas páginas de conexão, ou seja, clicar no botão Aceitar em Convites da página de rede deve mostrar o convite aceito em sua página de conexão depois de clicado.
• Verifique o link da interface entre as páginas de notificação e diga o botão de parabéns, ou seja, clicar no botão de dizer parabéns deve direcionar para a nova janela de mensagem.

Muitos casos de teste de integração podem ser escritos para este site específico. Os quatro pontos acima são apenas um exemplo para entender quais casos de teste de integração estão incluídos no teste.

A integração é uma técnica de caixa branca ou caixa preta?

A técnica de teste de integração pode ser contada em caixas pretas, bem como técnica de caixa branca . Técnica de caixa preta é onde um testador não precisa ter nenhum conhecimento interno do sistema, ou seja, o conhecimento de codificação não é necessário, enquanto a técnica de caixa branca precisa de conhecimento interno do aplicativo.

Agora, ao realizar o teste de integração, pode incluir o teste de dois serviços da web integrados que buscarão os dados do banco de dados e fornecerão os dados conforme necessário, o que significa que pode ser testado usando a técnica de teste de caixa branca, enquanto a integração de um novo recurso no site pode ser testada usando a técnica da caixa preta.

Portanto, não é específico que o teste de integração seja uma técnica de caixa preta ou caixa branca.

Ferramentas de teste de integração

Existem várias ferramentas disponíveis para este teste.

Abaixo está uma lista de ferramentas:

• Rational Integration Tester
• Transferidor
• Vapor
• TESSY

Para obter mais detalhes sobre as ferramentas acima, verifique este tutorial:

Dez principais ferramentas de teste de integração para escrever testes de integração

Teste de integração do sistema

O teste de integração do sistema é feito para testar o sistema integrado completo .

Módulos ou componentes são testados individualmente em testes de unidade antes de integrar os componentes.

Depois que todos os módulos são testados, o teste de integração do sistema é feito integrando todos os módulos e o sistema como um todo é testado.

Diferença entre teste de integração e teste de sistema

O teste de integração é um teste no qual um ou dois módulos que são testados por unidade são integrados para testar e a verificação é feita para verificar se os módulos integrados funcionam conforme o esperado ou não.

O teste de sistema é um teste onde o sistema como um todo é testado, ou seja, todos os módulos / componentes são integrados em conjunto para verificar se o sistema funciona conforme o esperado e se nenhum problema ocorre por causa dos módulos integrados.

Conclusão

Trata-se de testes de integração e sua implementação nas técnicas de caixa branca e caixa preta. Espero que tenhamos explicado isso claramente com exemplos relevantes.

A integração de teste é uma parte importante do ciclo de teste, pois torna mais fácil encontrar o defeito quando dois ou mais módulos são integrados para integrar todos os módulos juntos na própria primeira etapa.

Ele ajuda a encontrar os defeitos em um estágio inicial, o que, por sua vez, economiza esforço e custo. Isso garante que os módulos integrados funcionem corretamente conforme o esperado.

Espero que este tutorial informativo sobre Teste de Integração tenha enriquecido seu conhecimento do conceito.

Leitura recomendada

• O que é teste de componente ou teste de módulo (aprender com exemplos)
• Melhores ferramentas de teste de software 2021 (QA Test Automation Tools)
• Spock para integração e testes funcionais com selênio
• As diferenças entre teste de unidade, teste de integração e teste funcional
• Integração de Selenium com JMeter
• Download do e-book do Testing Primer
• Teste Funcional Vs Teste Não Funcional
• Tutorial de Teste Pairwise ou Teste All-Pairs com ferramentas e exemplos