Testes end-to-end vs testes de integração: o que cada um detecta (com exemplos)
Testes end-to-end vs testes de integração: o que cada um vê, o bug no checkout que só um teste da tela detecta, a pirâmide de testes, e de quantos testes end-to-end você precisa.
10 min de leituraPor Ait Nohaila, Representante de desenvolvimento de negócios
Testes de ponta a ponta vs testes de integração: a diferença em uma linha
Definição
O teste de integração verifica se duas ou mais partes de um aplicativo funcionam juntas na junção, por código ou por uma API, enquanto o teste de ponta a ponta verifica o aplicativo inteiro pela tela, do jeito que um usuário o percorre.
- Um teste de integração faz uma pergunta ao código: o serviço do carrinho retornou o total que o checkout espera?
- Um teste de ponta a ponta faz uma pergunta à tela: o usuário vê o total certo onde espera vê-lo?
- Os dois são necessários, e nenhum deles consegue responder à pergunta do outro.
Os dois são confundidos porque ambos testam mais de uma peça ao mesmo tempo.A diferença está em onde o teste se posiciona.Um teste de integração fica na junção entre duas partes e observa o que passa por ela.Um teste de ponta a ponta fica onde o usuário fica, diante da tela, e observa o resultado de tudo o que está por trás dela.
Os testes de integração verificam a junção.Um teste de ponta a ponta verifica o que é exibido.
Testes E2E e testes de integração lado a lado
Veja como os dois se comparam nas perguntas que uma equipe faz quando decide o que automatizar.
| Pergunta | Teste de integração | Teste de ponta a ponta |
|---|---|---|
| Escopo | Duas ou mais partes do aplicativo, juntas: um serviço e o banco de dados dele, a API e o módulo que a chama. | O aplicativo inteiro como o usuário o encontra, com todas as partes de que ele depende: a tela, os serviços por trás dela, muitas vezes outros sistemas, como um provedor de pagamentos. |
| Ponto de entrada | Código ou uma API: o teste chama uma função ou envia uma requisição e lê a resposta. | A tela: o teste clica, digita e lê o que é exibido, como uma pessoa faria. |
| O que ele encontra | Uma parte que não responde mais como a parte seguinte espera: um campo renomeado, um status errado, um registro ausente. | Uma jornada que não dá mais ao usuário o resultado certo: um total errado na tela, um botão que não faz nada, uma página que não abre. |
| Velocidade | De milissegundos a segundos por teste.Centenas podem ser executados a cada commit. | De segundos a minutos por jornada.Uma suíte de algumas dezenas é executada a cada build ou toda noite. |
| Custo | Barato de escrever para o desenvolvedor que conhece a junção, e barato de executar. | Caro quando é código: cada mudança de design quebra os seletores.Barato quando é gravado a partir da tela e mantido sem código. |
| Quem escreve | Os desenvolvedores, à medida que constroem cada junção. | Testadores, engenheiros de QA e product owners que sabem o que o usuário espera; os desenvolvedores também. |
| Quando é executado | A cada commit, no build, antes de qualquer merge. | A cada build ou pull request para algumas jornadas críticas, toda noite para a suíte inteira, em todos os navegadores e dispositivos antes de um lançamento. |
O bug que um teste de integração não consegue ver
Pense em um checkout.O serviço do carrinho soma os itens, o serviço de preços aplica o valor do frete, e a página de checkout exibe o resultado em três linhas: Subtotal, Frete e Total.Um dia, um desenvolvedor dá uma arrumada no template do checkout.Uma linha muda de lugar.O código por trás dela fica intacto.
O teste de integração pede à API o total do carrinho e o compara com o número esperado.Recebe 48.90, exatamente certo, e é aprovado.Cada serviço fez a sua parte, e a junção entre eles está íntegra.
O teste de ponta a ponta faz o que um cliente faz: adiciona dois itens, abre o checkout e lê o total antes de pagar.Na tela, a linha Total está vazia, e 48.90 agora aparece ao lado de Frete.Um cliente lê que o frete custa 48.90 e que não há nada a pagar.É um bug que ninguém discutiria, e nenhum teste de integração consegue vê-lo, porque um teste de integração nunca olha para a página.
O mesmo tipo de falha esconde muitos dos bugs que chegam aos usuários.
- Um total calculado em dólares e exibido com o símbolo do euro.
- Um botão Pagar empurrado para baixo da área visível por um novo banner.
- Uma mensagem de confirmação que aparece atrás da janela.
- Um rótulo longo demais para o campo depois de uma tradução.
- Em todos os casos, os dados estão certos e a tela está errada.
É a mesma lacuna que o artigo bugs visuais que os seus testes automatizados deixam passar descreve pelo outro lado: uma asserção que pergunta se um elemento existe não consegue dizer se uma pessoa pode vê-lo, lê-lo ou clicar nele.
A pirâmide de testes: onde cada camada conquista o seu lugar
A pirâmide de testes é a imagem habitual de como uma suíte deve ser dimensionada.O formato dela tem a ver com custo, não com importância: um teste unitário é executado em um milissegundo e pode ser escrito para cada caso, um teste de ponta a ponta inicia o aplicativo real e segue uma jornada, por isso eles são menos numerosos.
A pirâmide de testes: quantos testes, e o que cada camada vê
Testes unitários
Um teste unitário conquista o seu lugar ao detectar um cálculo errado no momento em que é escrito, na função que o fez.
Testes de integração
Um teste de integração conquista o seu lugar ao detectar uma junção que quebrou: um campo renomeado em um serviço e ainda esperado por outro.
Testes de ponta a ponta
Um teste de ponta a ponta conquista o seu lugar ao detectar o que só a tela mostra: o número certo no campo errado, o botão em que não dá para clicar, a página que nunca abre.
O teste de sistema fica perto do topo da pirâmide, e muitas equipes usam os dois nomes para a mesma coisa.A distinção útil: o teste de sistema verifica o aplicativo montado em relação aos requisitos, o teste de ponta a ponta segue a jornada de um usuário por tudo o que essa jornada toca.O que é teste end-to-end mostra o panorama completo.
Testes de integração vs testes de ponta a ponta: quando usar cada um
A escolha raramente é entre um e outro.Cada camada é a mais barata para um tipo diferente de pergunta, e uma equipe que sabe qual pergunta está fazendo coloca o teste no lugar certo.
Use um teste de integração quando a pergunta é sobre uma junção.
- A API ainda responde no formato que o módulo espera?
- O pedido chega ao banco de dados com todos os campos?
- A recusa do provedor de pagamentos volta como o erro que o código trata?
- São muitos casos pequenos, que é melhor verificar rápido, a cada commit, pelo desenvolvedor que construiu a junção.
Use um teste de ponta a ponta quando a pergunta é sobre o resultado do usuário.
- Um cliente consegue entrar, encontrar um produto, pagar e ver a confirmação com o número de pedido certo?
- O relatório que a equipe financeira exporta toda segunda-feira ainda abre com as colunas certas?
- São algumas jornadas inteiras, verificadas onde o usuário as verificaria, a cada build.
Use os dois quando há dinheiro, dados ou login envolvidos.
- O checkout acima precisa dos testes de integração, para que um total errado seja detectado na junção que o produziu, e do teste de ponta a ponta, para que um total certo exibido no lugar errado também seja detectado.
- Nenhum dos dois poderia ter substituído o outro naquele dia.
As duas camadas são testes de regressão: são executadas de novo depois de cada mudança para provar que nada do que funcionava quebrou.O que é teste de regressão explica quando executar cada uma e por que as suítes são abandonadas quando custam mais do que detectam.
De quantos testes de ponta a ponta você precisa?
Menos do que você imagina, e mais bem escolhidos.O topo da pirâmide não é lugar para listar todas as telas.É o lugar das jornadas que mais doeriam se quebrassem, cada uma seguida do primeiro clique até o resultado que o usuário veio buscar, e cada uma verificando esse resultado.
A maioria dos aplicativos é coberta por uma lista curta.
- 1Cadastro e login, incluindo o erro quando a senha está errada.
- 2A tarefa principal para a qual o aplicativo existe: fazer um pedido, reservar um horário, criar um cliente, enviar uma solicitação.
- 3O pagamento, até a confirmação e o número do pedido.
- 4A busca ou a lista de onde um usuário parte todos os dias.
- 5A exportação ou o relatório de que um cliente depende.
- 6Toda jornada que já quebrou uma vez e chegou aos usuários.
De cinco a quinze jornadas como essas, executadas a cada build, detectam a maior parte do que uma suíte de integração deixa passar.Cada uma termina em uma asserção do que a tela mostra: o total, a confirmação, o arquivo exportado.Um teste que clica por uma jornada inteira e não verifica nada prova pouco.
O que verificar em cada etapa é uma escolha que vale a pena fazer de propósito: uma imagem do elemento, as palavras dele, ou o que apareceu na tela.Escolher o que um teste verifica mostra como fazer.
Automatizar a camada de ponta a ponta sem código
A camada de ponta a ponta é a que a maioria das equipes deixa magra, porque tem sido a mais cara de manter: os testes em código encontram os elementos por seletores, e cada mudança de design os quebra.O GUI Test Studio tira o código dessa camada.Ele testa aplicativos web, aplicativos de desktop do Windows, celulares Android e jogos pela tela, do jeito que um usuário faz.
Grave, ou descreva
Clique em Gravar e percorra a jornada no seu aplicativo real: adicione os itens, abra o checkout, leia o total.Os cliques, a digitação e as asserções do que apareceu viram um teste, sem nenhum código para escrever.Você também pode descrever a jornada em um prompt para o seu assistente de IA, e o teste é criado para você.O seu primeiro teste, passo a passo leva cerca de dez minutos.
O teste verifica o que a tela mostra, não o código por trás dela.
- Uma asserção visual compara a imagem de um elemento, uma asserção textual lê as palavras dele, e uma asserção do que apareceu detecta a caixa de diálogo ou a mensagem que a etapa abriu.
- O GTS Engine + AI encontra cada elemento primeiro pelas informações de acessibilidade do aplicativo, e pela visão quando o aplicativo não diz.
Executar a cada build
O gtr-cli executa a suíte de ponta a ponta em uma máquina de build Windows e responde como um pipeline espera: uma jornada que falha faz o build falhar, um arquivo JUnit preenche a aba de testes, e cada imagem do que falhou fica guardada ao lado dos resultados de integração.
gtr-cli run tests\journeys --countdown 0 --junit results\junit.xml --artifacts results\artifactsFunciona no TeamCity, no Jenkins, no GitHub Actions, no GitLab e no Azure DevOps: veja Executar testes no seu pipeline.
O Relatório de confiança diz o que mudou
Toda execução termina em um Relatório de confiança.Para cada asserção, ele diz se o elemento foi encontrado e se ainda está como foi gravado, com as imagens esperada e encontrada lado a lado e a diferença destacada.Para o checkout acima, ele mostra a linha Total vazia e 48.90 uma linha acima: exatamente o que um testador teria escrito no relatório de bug.
O ruído é ignorado e as regressões são detectadas.
- Pequenas diferenças de renderização que nenhuma pessoa perceberia não são contadas, enquanto uma palavra alterada, um selo ausente ou um número na linha errada reprova a asserção.
- Quando uma imagem difere, a Análise inteligente com IA pode dar uma segunda olhada e dizer o que mudou em palavras simples, na nuvem com a sua própria chave ou no seu próprio computador com um modelo de IA local, um que fornecemos ou o seu.
Uma mudança é enviada
O template do checkout é arrumado
O build é executado
Testes de integração, depois o gtr-cli
Relatório de confiança
O total está na linha errada
Corrigido antes do merge
O usuário nunca chegou a ver
Pontos principais
- 1Os testes de integração verificam a junção entre as partes; um teste de ponta a ponta verifica o que é exibido para o usuário.
- 2O mesmo bug pode estar verde e vermelho ao mesmo tempo: a API retorna o total certo, a tela o mostra no campo errado.
- 3O formato da pirâmide tem a ver com custo, não com importância: muitos testes rápidos embaixo, algumas jornadas inteiras no topo, cada camada detectando o que as outras não conseguem.
- 4Use os dois quando há dinheiro, dados ou login envolvidos, e escolha a camada por quem escreveria o relatório de bug: um usuário ou um desenvolvedor.
- 5De cinco a quinze jornadas, cada uma verificando o seu resultado, cobrem a maior parte do que a suíte de integração deixa passar, e elas podem ser gravadas sem código.
Perguntas
Qual é a diferença entre teste de ponta a ponta e teste de integração?
O teste de integração verifica se duas ou mais partes de um aplicativo funcionam juntas na junção, geralmente por código ou por uma API.O teste de ponta a ponta verifica o aplicativo inteiro pela tela, do jeito que um usuário o percorre.Um teste de integração pode ser aprovado enquanto a tela mostra a coisa errada.
O teste de ponta a ponta é o mesmo que o teste de sistema?
Eles se sobrepõem, e muitas equipes usam as duas palavras para a mesma coisa.O teste de sistema verifica o aplicativo completo, montado, em relação aos requisitos.O teste de ponta a ponta segue a jornada de um usuário do primeiro clique até o resultado, por todas as partes que a jornada toca, outros sistemas incluídos.
Os testes de integração podem substituir os testes de ponta a ponta?
Não.Os testes de integração provam que as partes estão de acordo entre si, não que o usuário obtém o resultado certo na tela.Um total pode ser calculado certo por todos os serviços e ainda assim ser exibido no campo errado ou ficar escondido atrás de um banner, e só um teste que olha para a tela vê isso.
O que escrever primeiro: testes de integração ou testes de ponta a ponta?
Os desenvolvedores escrevem os testes de integração à medida que constroem cada junção, então eles costumam vir primeiro.Os primeiros testes de ponta a ponta são das jornadas que mais doeriam se quebrassem, como o login e o checkout, e podem ser gravados assim que essas jornadas funcionarem.
Quantos testes de ponta a ponta um projeto deve ter?
Menos do que você imagina, e mais bem escolhidos.De cinco a quinze jornadas cobrem o que a maioria dos aplicativos não pode se dar ao luxo de quebrar: o cadastro, o login, a tarefa principal, o pagamento, a exportação de que os clientes dependem.Cada um segue uma jornada até o resultado que o usuário veio buscar, e verifica esse resultado.
Por que os testes de ponta a ponta são mais lentos que os testes de integração?
Um teste de ponta a ponta inicia o aplicativo real, conduz as telas dele e espera cada uma responder, então uma jornada leva de segundos a minutos onde um teste de integração leva milissegundos.É por isso que os testes de ponta a ponta cobrem algumas jornadas importantes, e os testes de integração cobrem muitos casos.
O que é a pirâmide de testes?
A pirâmide de testes é uma forma de dimensionar uma suíte de testes: muitos testes unitários rápidos na base, menos testes de integração no meio, e um número pequeno de testes de ponta a ponta no topo.Cada camada detecta o que as camadas de baixo não conseguem, e a camada do topo é a única que vê o que o usuário vê.
Quem escreve os testes de ponta a ponta?
Qualquer pessoa que saiba o que o usuário espera, quando a ferramenta não exige código.Com o GUI Test Studio, um testador ou um product owner grava uma jornada usando o aplicativo, ou a descreve em um prompt, e o teste é executado a cada build com o gtr-cli.
TeamCity, Jenkins, GitHub, GitLab e Azure DevOps são marcas comerciais dos respectivos proprietários.
Pronto para gravar o seu primeiro teste?
Todos os recursos, por 15 dias.
Prefere ver no tipo de aplicativo que você testa?Agende uma chamada gratuita de 30 minutos com a nossa equipe.