Testes instáveis e falsos positivos: por que os testes falham em um aplicativo que funciona
Testes instáveis e falsos positivos explicados: por que testes end-to-end e visuais falham em um aplicativo que funciona, e como evitar isso sem deixar passar regressões reais.
12 min de leituraPela equipe do GUI Test Studio
Um build vermelho deveria significar uma única coisa: o aplicativo está com defeito.Com muita frequência significa outra coisa: um teste clicou cedo demais, uma fonte foi renderizada em um tom diferente, um indicador de carregamento ainda estava girando.Esses são os testes instáveis e os falsos positivos, e eles são um dos principais motivos pelos quais as equipes deixam de confiar nos seus testes de ponta a ponta.
Este guia explica de onde eles vêm nos testes programados e visuais, e como acabar com os falsos positivos sem deixar os bugs reais passarem.
O que são testes instáveis e falsos positivos?
Definição
Um falso positivo é um teste que falha enquanto o aplicativo funciona como deveria.
- Os testadores também o chamam de falha falsa ou alarme falso.
- O teste dá o alarme, alguém investiga, e não há nada de errado.
Definição
Um teste instável é um teste que é aprovado e falha com o mesmo código, sem nada alterado entre as execuções.
- Toda falha instável é um falso positivo.
Mas nem todo falso positivo é instável: um teste que falha toda vez porque a sua imagem esperada está desatualizada está errado, não instável.
O aplicativo funciona
O aplicativo está com defeito
O teste é aprovado
O teste falha
Quanto os falsos positivos custam a uma equipe
Um alarme falso custa uma investigação.Alguém abre os logs, executa o teste de novo e não encontra nada.
O custo real vem depois.
- Quando a maioria dos builds vermelhos é ruído, as pessoas deixam de lê-los: é a fadiga de alertas.
- Depois vêm os hábitos que escondem bugs: executar um teste de novo até ele ficar verde, aceitar sem olhar cada nova captura de tela como linha de base, desativar o teste que sempre falha.
Cada um desses hábitos transforma o falso positivo de hoje no falso negativo de amanhã.O bug para o qual o teste foi escrito passa, porque ninguém acredita mais no teste.
O que causa testes de ponta a ponta instáveis?
Os testes de ponta a ponta comandam um aplicativo inteiro pela sua interface, então encontram tudo o que um usuário real encontra: servidores lentos, animações, outras janelas.Os testes programados acrescentam causas próprias.
| Causa | O que acontece |
|---|---|
| Tempo e esperas | O teste clica antes de o botão ficar pronto, ou uma pausa fixa é curta demais em um dia movimentado. |
| Elementos obsoletos | A página foi redesenhada entre encontrar um elemento e clicar nele, então o teste segura um elemento que não existe mais. |
| Seletores que mudaram | Um desenvolvedor renomeou uma classe ou uma atualização do framework mudou a estrutura da página, e o localizador não encontra nada, ou encontra o elemento errado. |
| Dados de teste | Um teste anterior deixou um registro para trás, ou dois testes alteram a mesma conta ao mesmo tempo. |
| Ambiente | Outro tamanho de tela, outra versão do navegador, outro sistema operacional ou uma máquina sobrecarregada. |
| Animações | O elemento é encontrado enquanto ainda desliza ou aparece aos poucos. |
| Rede | Uma requisição lenta ou que falhou deixa a página carregada pela metade, ou um script de terceiros chega atrasado. |
Por que os testes de regressão visual geram falsos positivos
O teste de regressão visual compara uma imagem do aplicativo com uma imagem de linha de base aprovada.Ele pega o que as asserções programadas deixam passar: uma cor errada, um rótulo sobreposto, um ícone ausente.Ele também enxerga diferenças que nenhuma pessoa chamaria de mudança.
| Fonte de ruído | Por que os pixels diferem |
|---|---|
| Anti-aliasing | As bordas do texto e das formas são suavizadas com cores intermediárias, e a suavização varia de uma máquina para outra. |
| Renderização de fontes em subpixels | No Windows, o texto é desenhado com leves franjas coloridas que dependem da tela e das suas configurações. |
| Ruído de vídeo e de compressão | Uma imagem tirada de uma gravação, ou comprimida, perde detalhes finos de cor que a tela ao vivo mantém. |
| Placas de vídeo e drivers | Duas máquinas podem mesclar e redimensionar a mesma página de um jeito um pouco diferente. |
| Conteúdo dinâmico | Uma data, um contador, um anúncio ou um feed ao vivo muda a cada execução. |
| Ponteiros e cursores de texto | O ponteiro do mouse ou um cursor de texto piscando está em uma imagem e não na outra. |
| Estados de hover | O ponteiro ficou parado sobre um botão durante uma execução, então o botão está destacado em uma só das imagens. |
| Uma página ainda carregando | A imagem foi tirada antes que uma imagem, uma fonte ou uma transição terminasse. |
Como as equipes corrigem testes instáveis hoje
Nos testes programados
Playwright
O Playwright espera antes de cada ação até que o elemento esteja visível, estável, habilitado e não coberto por outro elemento, e falha com um tempo limite esgotado caso contrário.
Cypress
O Cypress tenta de novo as suas consultas e asserções até que passem, por até 4 segundos por padrão.Ele também pode tentar de novo um teste inteiro que falhou, o que vem desativado por padrão.
Selenium
O Selenium oferece esperas explícitas que consultam o aplicativo até uma condição se cumprir, e a sua documentação desaconselha misturá-las com esperas implícitas.
Nos testes visuais
Playwright
No Playwright, toHaveScreenshot aceita um limite de cor por pixel, 0.2 por padrão, e um maxDiffPixels absoluto ou um maxDiffPixelRatio.Ele pode mascarar áreas dinâmicas e, por padrão, congela as animações e oculta o cursor de texto.
BackstopJS
O BackstopJS permite uma porcentagem de pixels diferentes, 0.1 por padrão, e pode ocultar ou remover os elementos que você indicar antes de tirar as suas imagens.
Chromatic
O Chromatic ignora por padrão os pixels com anti-aliasing, e o seu diffThreshold, 0.063 por padrão, define quanta mudança ele tolera.
Argos
O Argos estabiliza cada captura de tela por padrão: ele espera as fontes e as imagens, oculta o cursor de texto e as barras de rolagem, e sinaliza as capturas que mudam de uma execução para outra.
Percy
O Percy congela as animações e outros elementos dinâmicos, e as mudanças são aprovadas por build, por grupo ou uma captura de cada vez.O seu Visual Review Agent destaca as mudanças que considera significativas.
Applitools Eyes
O Applitools Eyes compara com níveis de correspondência.Strict procura ignorar o que o olho humano não veria, Layout verifica só a disposição, e Dynamic aceita qualquer data, endereço de e-mail ou URL válidos.
Cada um deles ajuda.Cada um também pede que você escolha um número, uma máscara ou um nível, teste por teste, e que revise as novas imagens à mão.Para ver essas ferramentas lado a lado, leia o estudo comparativo.
Por que uma tolerância mais frouxa não é a resposta
Uma tolerância é uma promessa: essa quantidade de diferença é ruído.A pergunta é em que essa quantidade é medida.
Uma proporção cresce com a imagem.Em uma tela inteira de 1920 por 1080 pixels, 0.1% são cerca de 2000 pixels, mais do que uma palavra alterada.Em um botão de 100 por 40 pixels, são 4 pixels, menos do que uma borda renderizada de outro jeito.
Uma tela inteira, 1920 × 1080
0.1% são cerca de 2000 pixels: mais do que uma palavra alterada.
Um botão, 100 × 40
0.1% são 4 pixels: menos do que uma borda renderizada de outro jeito.
Uma contagem absoluta não cresce com a imagem, mas soma o ruído espalhado pela imagem inteira como se fosse uma única mudança.Uma máscara esconde o ruído, e também esconde qualquer bug dentro da máscara.
Como o GUI Test Studio acaba com os falsos positivos sem deixar passar bugs
O GUI Test Studio é um conjunto de automação de testes de ponta a ponta para aplicativos web, aplicativos de desktop do Windows, Android e jogos.Você grava um teste uma vez, ou o descreve em um prompt, edita-o em uma linha do tempo e o executa a cada build.As suas asserções seguem uma regra: um teste falha quando uma pessoa veria um problema, e só nesse caso.
Encontrar
Perguntar ao aplicativo, ou encontrar o elemento pela visão
Aguardar
A tela, nunca um cronômetro
Comparar
Contar o que claramente mudou, e onde
Decidir
Análise inteligente com IA, se você a ativar
Informar
O que mudou, com palavras simples
Os elementos são encontrados de duas maneiras, sem seletor para quebrar
O GTS Engine + AI primeiro pergunta ao aplicativo onde um elemento está, pelas suas informações de acessibilidade no Windows, ou pelos próprios elementos da página em um navegador.Quando o aplicativo não diz, ele encontra o elemento pela visão na tela.Não há localizador para escrever, então uma classe renomeada ou um novo framework não quebra um teste.Veja como o GUI Test Studio encontra cada elemento.
As asserções aguardam a tela, nunca um cronômetro
Cada asserção continua procurando até que o que ela espera esteja na tela, até o seu tempo limite de 5 segundos por padrão, e o teste segue no momento em que isso aparece.Uma asserção visual de ausência aguarda que um indicador de carregamento desapareça, então uma página lenta é aguardada, não adivinhada.
Quando uma asserção visual ou uma asserção textual não encontrou o seu elemento na área de busca depois de um segundo, ela procura também na tela inteira, então uma janela que se moveu não reprova o teste.Antes de uma execução começar, o GUI Test Runner-Recorder compara a sua tela com o primeiro momento da gravação e segura a execução quando o aplicativo está em outra página.Veja as configurações de uma asserção.
A Fase de verificação conta o que mudou, e onde
Depois que o elemento é encontrado, a Fase de verificação o compara com o que você espera.Ela conta os pixels que claramente mudaram na pequena região mais afetada do elemento: um número absoluto, nunca uma porcentagem da imagem.
O ruído é espalhado: uma borda mais suave aqui, um tom mais claro ali.Uma mudança real é concentrada em um lugar: uma letra, um dígito, um ícone.É por isso que a mesma regra funciona em um ícone pequeno e em uma caixa de diálogo inteira.
Ruído de renderização
É aprovadoFraco e espalhado: uma borda mais suave aqui, um tom mais claro ali.
Uma mudança real
É reprovadaConcentrada em um lugar: uma letra, um dígito, um ícone.
| Na tela | O que a Fase de verificação faz |
|---|---|
| Um pixel só levemente diferente | Nunca é contado sozinho, enquanto uma letra que mudou de maiúscula para minúscula continua reprovando a asserção |
| Bordas suavizadas | Toleradas por Ignorar pequenos artefatos de renderização, ativado por padrão, enquanto um ícone ausente continua reprovando a asserção |
| Detalhes de cor que só a tela ao vivo consegue manter | Não são contados, enquanto um botão ou um selo que mudou de cor continua reprovando a asserção |
| Um cursor de texto piscando sozinho | Não é contado, enquanto uma letra alterada ao lado dele continua reprovando a asserção |
| Um dígito ou uma palavra alterados | Reprova a asserção, no lugar onde aconteceu |
Cada asserção tem um Rigor da verificação: Exato, Rigoroso, Padrão ou Flexível.Padrão serve para botões, rótulos e ícones do dia a dia, e Flexível serve para áreas grandes e telas cheias de coisas.Veja asserções visuais.
O momento certo, com o ponteiro onde estava
Um elemento muitas vezes é encontrado enquanto a tela ainda está se acomodando: um menu aparecendo aos poucos, uma página ainda carregando.A Passagem de acurácia aprimorada olha os quadros que vêm depois da correspondência, fica com aquele em que o elemento aparece melhor e se detém onde começa a próxima etapa do teste.Veja a Passagem de acurácia aprimorada.
Em um teste gravado, a execução coloca o ponteiro do mouse de volta onde ele estava quando a imagem foi tirada.Assim, um botão fica destacado na execução exatamente quando ficou destacado na gravação.
Um teste que você acabou de gravar, e ainda não editou, recebe uma ajuda a mais.Quando um elemento não aparece como foi gravado, a execução ajusta o teste de forma inteligente para encontrá-lo, e nunca faz isso para esconder uma diferença real.
Diferente de propósito: perfis de linha de base
Algumas diferenças são reais e desejadas: o modo escuro, uma tela de notebook em vez de um monitor 4K, outra versão do Windows, o aplicativo em francês.Um perfil de linha de base guarda uma versão esperada de uma asserção por ambiente, de modo que um único teste serve a todos.Onde procurar, quanto tempo aguardar e quão rigorosa ser continuam comuns a todas as versões.Veja Perfis de linha de base.
A Análise inteligente com IA dá o veredito final
Quando uma asserção encontra pixels alterados, a Análise inteligente com IA pode dar uma segunda olhada e decidir, com um modelo na nuvem e a sua própria chave, ou com um modelo de IA local no seu próprio computador, um que nós fornecemos ou um que você traz.Ela fica desativada até você ativá-la.
O ponteiro do mouse e o cursor de texto piscando nunca contam como diferença, enquanto uma letra ou um ícone que mudou continua contando.Você também pode dar a uma asserção Instruções para a IA com as suas próprias palavras, como: a data no canto muda todo dia.Veja Análise inteligente com IA.
Um relatório que diz o que mudou
O Relatório de confiança mostra cada asserção visual em duas fases.A Fase de busca responde se o elemento foi encontrado, e a Fase de verificação responde se ele tem a aparência esperada.O Pulso destaca o que mudou na tela, e o veredito diz isso com palavras simples.
Os seus pontos fracos apontam as asserções aprovadas pela menor margem, as que têm mais chance de falhar em seguida.O histórico mostra quando uma asserção começou a falhar.Quando uma mudança é desejada, você aceita o novo visual no relatório, e nada é escrito até você salvar.Veja o Relatório de confiança.
Parar ou continuar: você decide o que uma falha significa
Cada asserção diz o que a sua falha faz: parar o teste ou continuar.
- Uma asserção da qual dependem os cliques seguintes para por padrão, porque clicar sem ela acertaria o lugar errado.
- Uma asserção que só confirma o que está na tela continua, de modo que uma única execução informa todos os problemas que encontra.
Em um pipeline, o gtr-cli pode executar de novo um teste reprovado com a sua opção de novas tentativas.Trate isso como último recurso: são as causas acima que precisam ser corrigidas.
Uma lista de verificação contra falsos positivos
Do
- Aguarde uma condição: um elemento, um texto, um indicador de carregamento que sumiu.
- Mantenha cada asserção visual pequena e característica.
- Dê a cada ambiente legítimo a sua própria linha de base.
- Leia por que uma asserção falhou antes de executá-la de novo.
- Fique de olho nas asserções aprovadas por uma margem estreita.
Avoid
- Pausas fixas.
- Aumentar uma tolerância até o build ficar verde.
- Aceitar novas linhas de base sem olhar para elas.
- Tentar de novo as falhas até que passem.
- Mascarar áreas inteiras da tela.
Quer ver isso no seu próprio aplicativo?Testes visuais com o GUI Test Studio mostra a ideia toda em uma página.
Perguntas
O que é um falso positivo em testes de software?
Um falso positivo é um teste que falha enquanto o aplicativo funciona como deveria.Os testadores também o chamam de falha falsa ou alarme falso.O oposto, um teste que é aprovado enquanto há um bug na tela, é um falso negativo.
Qual é a diferença entre um teste instável e um falso positivo?
Um teste instável é aprovado e falha com o mesmo código, sem nada alterado entre as execuções.Toda falha instável é um falso positivo, mas um teste também pode falhar toda vez por um motivo errado, como uma imagem esperada desatualizada.
O que causa testes de ponta a ponta instáveis?
Na maioria das vezes, o tempo: o teste age antes de o aplicativo estar pronto.Seletores alterados, elementos obsoletos, dados de teste compartilhados, animações, redes lentas e diferenças entre máquinas são as outras causas comuns.
Como reduzir os falsos positivos nos testes de regressão visual?
Aguarde a tela se acomodar, mantenha pequena cada área comparada, ignore o ruído de renderização como o anti-aliasing e mantenha uma linha de base por ambiente.O GUI Test Studio conta só os pixels que claramente mudaram em um lugar, então o ruído de renderização é aprovado enquanto uma letra, um dígito ou uma cor alterados continuam reprovando.
Deve-se tentar de novo os testes instáveis?
Uma nova tentativa deixa um build verde, mas não elimina a causa, e pode esconder um bug real que só acontece às vezes.Use as novas tentativas para identificar os testes instáveis, e depois corrija o tempo, os dados ou a comparação por trás deles.
A IA consegue distinguir um bug visual real de um ruído?
Sim, como uma segunda olhada depois da comparação dos pixels.No GUI Test Studio, a Análise inteligente com IA dá o veredito final de uma asserção reprovada: diferenças pequenas são aprovadas, enquanto uma palavra, um número ou um valor alterados, ou um ícone ausente, continuam reprovando.
Selenium, Playwright, Cypress, BackstopJS, Chromatic, Argos, Percy e Applitools Eyes 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.