O que é teste de regressão? Testes de regressão end-to-end sem código
O que é teste de regressão, e por que os testes de regressão end-to-end detectam o que os testes unitários deixam passar: o que cobrir, quando executar e como automatizar sem código.
11 min de leituraPela equipe do GUI Test Studio
O que é teste de regressão?
Definição
O teste de regressão verifica se uma alteração em um aplicativo não quebrou algo que já funcionava.
- Um novo recurso, a correção de um bug, a atualização de uma biblioteca ou uma nova versão de navegador podem quebrar uma parte do aplicativo que ninguém tocou.
- Os mesmos testes são executados de novo após a alteração, e um teste que era aprovado antes e falha agora encontrou uma regressão.
A palavra vem de andar para trás: o aplicativo regrediu, ele funciona pior hoje do que ontem.É isso que torna uma regressão tão frustrante para os usuários.Algo em que eles confiavam simplesmente parou de funcionar.
As regressões acontecem porque as partes de um aplicativo dependem umas das outras de maneiras que ninguém tem em mente.Um estilo compartilhado, uma regra de arredondamento, um campo renomeado em uma API: uma pequena alteração em um lugar alcança telas bem longe dele.Quem fez a alteração verificou o que mudou, e estava certo.A quebra está em outro lugar.
Teste de regressão versus reteste
Os dois são muitas vezes confundidos, e respondem a perguntas diferentes.
| Pergunta | Reteste | Teste de regressão |
|---|---|---|
| O que ele verifica? | Que o bug que você corrigiu está realmente corrigido. | Que a correção, ou qualquer outra alteração, não quebrou mais nada. |
| Onde ele olha? | No lugar do bug. | Em todo o resto, principalmente no que os usuários usam. |
| Quais testes? | As etapas que mostraram o bug. | A mesma suíte, executada de novo após cada alteração. |
| Quando? | Uma vez, depois da correção. | Após cada alteração, durante toda a vida do aplicativo. |
Testes de regressão unitários, de integração e de ponta a ponta
Existem testes de regressão em todos os níveis de um aplicativo, e cada nível vê uma parte diferente dele.
Quanto do aplicativo cada teste vê
Testes unitários
Uma função, sozinha
Detecta: Um cálculo que devolve o valor errado
Testes de integração
Duas ou três partes juntas
Detecta: Um serviço que não responde mais do jeito que o seguinte espera
Testes de ponta a ponta
O aplicativo inteiro, pela tela
Detecta: Um total, um botão, uma página ou uma mensagem que o usuário vê quebrado
Os testes unitários e de integração são rápidos e precisos, e toda equipe deveria tê-los.Mas eles verificam o código como o desenvolvedor o imagina.Um usuário nunca chama uma função: ele clica em um botão, lê um total e espera que a página seguinte abra.
Algumas regressões só existem na tela, onde os testes unitários nunca olham.
- Uma mudança de estilo esconde o botão Pagar atrás de um banner.
- Um total é calculado corretamente e exibido com a moeda errada.
- Uma caixa de diálogo abre atrás da janela.
- Uma tradução é longa demais e o rótulo fica cortado.
É por isso que o teste de regressão de ponta a ponta é o que mais importa: um teste de ponta a ponta conduz o aplicativo inteiro pela sua interface, do jeito que um usuário o percorre, e verifica o que o usuário vê.Veja o que é teste de ponta a ponta para o quadro completo.
Os seus usuários não executam os seus testes unitários.Eles usam o seu aplicativo, tela após tela.
Teste de regressão funcional e não funcional
O teste funcional verifica o que o aplicativo faz: o pedido é feito, o relatório é exportado, a mensagem de erro aparece quando um campo está vazio.O teste não funcional verifica como ele faz isso: com que rapidez, com que aparência, como se comporta em outro dispositivo ou em uma rede lenta.
Regressão funcional
A finalização da compra ainda faz o pedido, e a confirmação ainda mostra o número do pedido.
Regressão visual
A tela ainda tem a mesma aparência: nenhum ícone faltando, nenhuma palavra cortada, nenhum botão na cor errada.
Regressão não funcional
A página ainda carrega a tempo, e o layout ainda se sustenta em um celular e em uma conexão lenta.
A maioria das suítes de regressão é funcional, e a maioria das quebras visuais e de layout passa por elas porque uma asserção funcional pergunta se um elemento existe, não se uma pessoa consegue vê-lo.Bugs visuais que os seus testes automatizados não pegam mostra por quê.
O que deve entrar em uma suíte de regressão de ponta a ponta?
Uma suíte de regressão que tenta cobrir tudo nunca fica pronta e nunca ganha confiança.Comece pequeno, com o que mais doeria se quebrasse.
- 1
Listar as jornadas sem as quais os usuários não vivem
Cadastro, login, busca, finalização da compra, o relatório que os seus clientes exportam toda segunda-feira.De cinco a dez jornadas, cada uma do primeiro clique até o resultado que o usuário espera.
- 2
Adicionar o que já quebrou antes
Todo bug que já chegou aos usuários merece um teste, para que nunca mais volte sem ser notado.É assim que uma suíte de regressão aprende.
- 3
Pesar pelo risco, não pelo número de telas
Uma tela usada por todos os clientes todos os dias importa mais do que dez páginas de configurações.Dinheiro, dados e login vêm primeiro.
- 4
Verificar resultados, não só cliques
Um teste que clica ao longo da finalização da compra e nunca verifica o total comprova pouco.Cada jornada termina naquilo que o usuário veio buscar, e o teste verifica isso: o total, a confirmação, o arquivo exportado.
- 5
Mantê-la rápida o bastante para ser executada a cada alteração
Marque um punhado de jornadas como a suíte de smoke test, as que são executadas em cada pull request em poucos minutos.O resto é executado toda noite.
Quando os testes de regressão devem ser executados?
Quanto antes uma regressão é encontrada, mais barata ela é: a alteração ainda está fresca na cabeça do desenvolvedor, e nada foi construído em cima dela ainda.
| Quando | O que é executado | Por quê |
|---|---|---|
| Cada pull request ou build | A suíte de smoke test: as jornadas críticas. | Uma quebra é pega antes do merge, enquanto a alteração é pequena. |
| Toda noite | A suíte inteira. | Tudo é verificado uma vez por dia, sem atrasar ninguém. |
| Antes de uma versão | A suíte inteira, em todos os navegadores e dispositivos que você suporta. | O que os usuários vão receber de fato é verificado onde eles vão receber. |
| Depois de uma atualização que você não controla | A suíte inteira. | Uma nova versão de navegador, de sistema operacional ou de biblioteca pode quebrar o aplicativo sem que uma linha do seu código mude. |
Jornada de finalização da compra, últimos oito builds
- #38
- #39
- #40
- #41
- #42
- Começou a falhar#43
- #44
- #45
#42 a última execução aprovada#43 a alteração a examinar primeiro#45 corrigido e verificado de novo
Por que as suítes de regressão automatizadas são abandonadas
A maioria das equipes concorda que o teste de regressão deveria ser automatizado.Muitas tentaram, e muitas suítes automatizadas acabam desligadas ou ignoradas.Os motivos são quase sempre os mesmos.
A suíte custa mais para manter do que economiza.
- Os testes em código encontram botões por seletores, e cada redesenho quebra dezenas deles de uma vez.
- Só os desenvolvedores conseguem consertá-los, e os desenvolvedores estão construindo recursos.
- Os testes falham por motivos inofensivos, um tom de cor ou um pixel de anti-aliasing, então as pessoas param de ler os resultados.
- A suíte completa leva horas, então é executada uma vez por semana, e as regressões esperam dias para ser encontradas.
Automatizar o teste de regressão de ponta a ponta sem código
O GUI Test Studio é feito para o teste de regressão de ponta a ponta de aplicativos web, aplicativos de desktop do Windows, celulares e jogos, pela interface deles, sem código de teste para escrever ou manter.
Gravar cada jornada uma vez
Clique em Gravar no GUI Test Runner-Recorder e percorra a jornada no seu aplicativo real, como um usuário faria.Os cliques, a digitação e as asserções do que apareceu se tornam um teste.Você também pode descrever a jornada em um prompt para o seu assistente de IA, e o teste é criado para você.
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.
- 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, então um redesenho do código por trás de um botão não quebra o teste.
Editar como um vídeo
Todo teste abre no GUI Test Studio em uma linha do tempo: as etapas como blocos, as asserções ao lado, a gravação em cima.Altere uma asserção, adicione uma espera, agrupe as etapas de uma jornada: sem código, e qualquer pessoa da equipe consegue fazer isso.Veja a linha do tempo.
Executar a cada build
O gtr-cli executa a suíte em uma máquina de build Windows e responde do jeito que um pipeline espera: um teste reprovado reprova o build, um arquivo JUnit preenche a aba de testes, e cada imagem do que falhou é guardada.
gtr-cli run tests\regression --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.
Uma regressão real, ou um ruído inofensivo?
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 tem a aparência que tinha quando foi gravado, com as imagens esperada e encontrada lado a lado e a diferença contornada.
O ruído é ignorado e as regressões são detectadas.
- Pequenas diferenças de renderização que nenhuma pessoa notaria não são contadas.
- Uma palavra alterada, um selo faltando ou um botão que ficou cinza 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.
Uma alteração intencional é aceita com um clique
Nem toda diferença é uma regressão: às vezes a nova tela é a certa.No Relatório de confiança, aceite o que a execução encontrou como a nova imagem esperada, e a próxima execução compara com ela.Para telas que diferem de propósito, um modo escuro ou outro idioma, as linhas de base guardam uma versão por ambiente.
Saber quando começou
Toda execução fica guardada no Histórico do teste.Quando uma jornada começa a falhar, o Histórico mostra a última execução aprovada e a primeira reprovada, e duas execuções podem ser comparadas asserção por asserção.
Todos os navegadores e dispositivos, e um bug no seu rastreador
Um teste web gravado uma vez é executado no Chrome, no Edge e no Firefox, em celulares e tablets, em outros idiomas e tamanhos de tela: veja teste entre navegadores.E uma execução reprovada pode virar sozinha um item do Jira, com as etapas para reproduzir e as imagens: veja testes reprovados como bugs no Jira.
Uma alteração é enviada
Um recurso, uma correção, uma atualização
O build é executado
O gtr-cli executa a suíte
Relatório de confiança
Regressão ou ruído, com imagens
Fazer o merge, ou corrigir primeiro
Uma falha bloqueia a alteração
Faça
- Uma pequena suíte de jornadas críticas a cada build
- Asserções do que o usuário vê no fim de cada jornada
- Um teste para cada bug que chegou aos usuários
- Todos os navegadores e dispositivos antes de uma versão
Evite
- Uma suíte tão grande que só é executada uma vez por semana
- Testes que clicam ao longo de uma jornada e não verificam nada
- Falhas que ninguém lê porque metade delas é ruído
- Testes que só os desenvolvedores conseguem alterar
Pontos principais
- 1O teste de regressão verifica se uma alteração não quebrou nada que funcionava. Os mesmos testes, executados de novo após cada alteração.
- 2O reteste comprova uma correção; o teste de regressão comprova que a correção não custou mais nada.
- 3Os testes de regressão de ponta a ponta pegam o que os usuários sentem: os totais, botões, páginas e mensagens que os testes unitários nunca veem.
- 4Comece pequeno: de cinco a dez jornadas críticas a cada build, a suíte completa toda noite, todos os navegadores e dispositivos antes de uma versão.
- 5Uma suíte precisa distinguir uma regressão de um ruído, e custar pouco para manter, ou será abandonada.
Perguntas
O que é teste de regressão?
O teste de regressão verifica se uma alteração em um aplicativo não quebrou algo que já funcionava.Depois de um novo recurso, da correção de um bug ou de uma atualização, os mesmos testes são executados de novo, e qualquer teste que era aprovado antes e falha agora aponta para uma regressão.
Qual é a diferença entre teste de regressão e reteste?
O reteste verifica se o bug que você corrigiu está realmente corrigido.O teste de regressão verifica se a correção, ou qualquer outra alteração, não quebrou o resto do aplicativo.O reteste olha para um lugar, o teste de regressão olha para todo o resto.
O que é teste de regressão de ponta a ponta?
O teste de regressão de ponta a ponta executa as jornadas importantes de um aplicativo pela interface dele, do jeito que um usuário as percorre, após cada alteração.Ele pega as quebras que só aparecem na tela: um total errado, um botão que não abre mais a sua caixa de diálogo, uma página que não carrega.
O teste de regressão é funcional ou não funcional?
Os dois.A maioria dos testes de regressão é funcional: eles verificam se os recursos ainda fazem o que devem.Uma regressão também pode ser não funcional, como uma página que ficou lenta ou um layout que quebrou em um celular, e essas merecem testes próprios.
Com que frequência executar testes de regressão?
Execute uma suíte curta de jornadas críticas a cada pull request ou build, a suíte completa toda noite, e a suíte completa em todos os navegadores e dispositivos antes de uma versão.Quanto antes uma regressão é pega, mais barato é corrigi-la.
É possível automatizar o teste de regressão sem escrever código?
Sim.Com o GUI Test Studio, você grava uma jornada uma vez usando o aplicativo, ou a descreve em um prompt, e o teste é criado para você.Ele é executado de novo a cada build com o gtr-cli, e ninguém precisa manter código de teste.
O que é teste de regressão visual?
O teste de regressão visual compara o que a tela mostra agora com o que mostrava antes, para pegar mudanças que um usuário veria: um ícone faltando, uma palavra cortada, um botão na cor errada.É um tipo de teste de regressão de ponta a ponta.
OpenAI, Anthropic, Jira, TeamCity, Jenkins, GitHub, GitLab, Azure DevOps, Chrome, Edge e Firefox são marcas comerciais dos seus 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.