Teste de capturas de tela pixel perfect: por que ele falha e o que pega os bugs visuais reais
O teste de capturas de tela pixel perfect falha duas vezes: o ruído de renderização gera alarmes falsos e um limite em porcentagem esconde bugs reais.Veja o que funciona.
O teste de capturas de tela pixel perfect compara cada pixel de uma captura com uma imagem de referência.Ele falha duas vezes: um ruído de renderização inofensivo gera alarmes falsos, e um limite em porcentagem flexível o bastante para calá-los deixa passar um dígito errado ou um ícone ausente.
O que é o teste de capturas de tela pixel perfect?
Definição
O teste de capturas de tela pixel perfect é uma verificação visual que compara uma nova captura com uma captura de referência, pixel a pixel.
- Qualquer pixel cuja cor difere conta como uma diferença.
- Um teste falha quando há diferenças, ou mais do que um limite permite.
É a forma mais simples de teste de regressão visual, e aquela com que a maioria das equipes começa.
A ideia é boa: uma pessoa julga uma tela olhando para ela, então um teste também deveria olhar.O problema é a medida.Uma tela não é desenhada com os mesmos pixels em todas as máquinas, e os bugs que importam muitas vezes têm só alguns pixels.
Nada está errado
Algo está errado
Por que a comparação pixel a pixel gera falsos positivos
Um falso positivo é um teste que falha enquanto a aplicação está correta.Em uma comparação pixel a pixel, ele vem de tudo o que muda pixels sem mudar o que uma pessoa vê.
| 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 essa suavização varia de uma máquina para outra. |
| Suavização de fontes | No Windows, o ClearType desenha o texto com leves franjas coloridas que dependem da tela e das suas configurações. |
| A placa de vídeo e o seu driver | Degradês, sombras e cantos arredondados podem sair um tom diferente em outra placa. |
| Gravação e compressão | Uma imagem de referência tirada de um vídeo guarda menos detalhe de cor do que a tela real mostra. |
| Um deslocamento de 1 pixel | Uma janela ou um layout que se moveu um pixel muda todas as bordas da imagem. |
| Um cursor de texto piscando | O cursor está aceso em uma captura e apagado na outra. |
| Um estado de passagem do mouse ou de foco | O ponteiro repousa sobre um botão em uma execução e não na outra, então o botão fica destacado em uma só imagem. |
| Conteúdo dinâmico | Uma data, um relógio, um contador ou um selo de notificação muda todos os dias. |
| Outra escala de tela | Um notebook a 150 % e um monitor a 100 % desenham o mesmo botão com outros pixels. |
Testes instáveis também têm outras causas, como esperas e tempo.Elas são tratadas em testes instáveis e falsos positivos.
Por que um limite no teste de regressão visual esconde bugs reais
A resposta habitual ao ruído é um limite: deixar a comparação passar enquanto menos de uma fração da imagem difere, muitas vezes 1 ou 2 %.Os alarmes falsos param.Os bugs reais começam a passar.
Bugs reais podem ser muito pequenos na tela.
- Um dígito errado em um preço ou em um total muda algumas dezenas de pixels.
- Uma maiúscula que virou minúscula muda mais algumas dezenas.
- Um pequeno ícone ausente muda algumas centenas.
- Em um painel ou em uma tela inteira, cada um fica muito abaixo de 1 %.
Os bugs que mais custam costumam ser os menores na tela: um dígito de uma fatura, uma palavra de um aviso legal.
Uma fração da imagem é a medida errada
Ruído e bugs se parecem quando você os conta na imagem inteira.Para uma pessoa, eles não se parecem.
- Ruído é o que ninguém vê: uma borda mais suave, um tom mais claro, um cursor que piscou.
- Uma mudança real é o que uma pessoa lê ou reconhece: uma letra, um dígito, um ícone, uma cor.
Esperado
$12,480
Esta execução
$12,430
Medido como fração da imagem
Um dígito é uma fração mínima do painel, muito abaixo de um limite de 2 %.
Passa: o bug escapa
Visto com os olhos de uma pessoa
Uma pessoa que lê o total vê na hora o dígito errado, e o GUI Test Studio também.
Falha: o bug é pego
Então a pergunta certa não é quanto da imagem mudou.É a pergunta que uma pessoa faz: alguém olhando esta tela veria uma diferença?A resposta não depende do tamanho da imagem, então vale para um ícone pequeno e para uma caixa de diálogo inteira.
As soluções habituais para testes de capturas instáveis, e quanto custam
| Solução | Quanto custa |
|---|---|
| Subir o limite | O ruído passa, e os pequenos bugs também. |
| Mascarar as partes que mudam | Cada data, relógio e selo é mascarado à mão, e um bug sob uma máscara nunca é visto. |
| Repetir um teste que falhou | Uma falha real ganha uma segunda chance de passar por sorte, e cada execução demora mais. |
| Manter uma imagem de referência por máquina | Cada navegador, sistema e escala precisa das próprias imagens, e cada uma precisa ser tirada de novo após cada mudança. |
| Congelar o ambiente | Uma única imagem de máquina executa todos os testes, e um teste que passa ali não diz nada das telas dos seus usuários. |
Em um framework com código como o Playwright, toHaveScreenshot recebe um limite de cor por pixel e um número ou uma fração máxima de pixels diferentes para a imagem inteira.Você escolhe esses números, escreve as máscaras e mantém uma imagem de referência por navegador e plataforma, em código que você mantém.
Como o GUI Test Studio compara capturas de tela
O GUI Test Studio cria testes de ponta a ponta de aplicações web, aplicações de desktop Windows, celulares Android e jogos a partir de uma gravação, sem código.Cada elemento em que você clica ou digita recebe uma asserção visual, uma asserção que guarda uma pequena imagem do elemento, o seu alvo visual.Veja asserções visuais.
Encontrar
A Fase de busca
Comparar
A Fase de verificação
Segundo olhar
Análise inteligente com IA
Relatório
O Relatório de confiança
Primeiro, encontrar o elemento
A Fase de busca encontra o elemento na tela real, onde quer que ele esteja agora.O GTS Engine + AI pergunta primeiro à aplicação, pelas suas informações de acessibilidade ou pelos próprios elementos da página, e encontra o elemento pela visão quando a aplicação não diz.Veja como o GUI Test Studio encontra cada elemento.
A comparação acontece então onde o elemento está.Uma janela que se moveu, ou um botão deslocado um pixel, não é diferença nenhuma.
Depois, compará-lo como uma pessoa o olha
A Fase de verificação compara o elemento com o seu alvo visual de forma perceptiva, como o olho humano faz.Ela nota o que uma pessoa notaria e ignora o que ninguém vê.
| Na tela | O que a Fase de verificação faz |
|---|---|
| Bordas suavizadas e suavização de fontes | Ignorados: eles mudam de uma máquina para outra, e ninguém os vê. |
| Gravação e compressão | Ignorados: uma imagem tirada de um vídeo guarda um pouco menos de detalhe de cor do que a tela ao vivo, e uma pessoa vê a mesma tela. |
| Um deslocamento de 1 pixel | Ignorado: o elemento é comparado onde está agora. |
| Um cursor de texto piscando | Ignorado, enquanto uma letra alterada ao lado é pega. |
| Um dígito errado | Pego: é o que uma pessoa lê primeiro. |
| Uma maiúscula que virou minúscula | Pego: uma pessoa vê na hora. |
| Uma cor alterada | Pego, assim que uma pessoa perceberia: um ícone vermelho que virou laranja falha. |
| Um ícone ausente | Pego: uma pessoa vê o espaço vazio. |
Passagem do mouse e datas
Em um teste gravado, a execução coloca o ponteiro do mouse de volta onde ele estava quando a imagem foi tirada.Um botão fica destacado na execução exatamente quando estava destacado na gravação.
Um valor que muda todos os dias não pertence a um alvo visual.Mantenha o alvo no próprio elemento, e verifique uma data, um total ou um contador com uma asserção textual dinâmica, que verifica o seu formato seja qual for o seu valor.Veja asserções de texto.
E quando uma tela fica diferente com razão no modo escuro, em outro idioma ou em outra tela, mantenha uma versão esperada por ambiente com um perfil de linha de base: veja testar o modo escuro, outros idiomas, outras telas.
Comparação de pixels contra o GUI Test Studio, caso a caso
| A diferença | Uma comparação de pixels com um limite em porcentagem | GUI Test Studio |
|---|---|---|
| Bordas suavizadas em outra máquina | Falha se rigorosa, passa se flexível | Passa: ninguém vê |
| Franjas coloridas da suavização de fontes | Falha se rigorosa | Passa: ninguém vê |
| O elemento se moveu 1 pixel | Falha: cada borda difere | Passa: o elemento é comparado onde está |
| Um cursor de texto piscando | Falha se rigorosa | Passa: um cursor piscando é ignorado |
| Um destaque de passagem do mouse | Falha | Passa: o ponteiro fica onde estava na gravação |
| A data de hoje | Falha todos os dias | Não comparada: uma asserção textual dinâmica verifica o seu formato |
| Um dígito errado | Passa em um limite de 1 ou 2 % | Falha: uma pessoa vê o dígito errado |
| Uma maiúscula que virou minúscula | Passa em um limite de 1 ou 2 % | Falha: uma pessoa vê a minúscula |
| Um pequeno ícone ausente | Passa em uma imagem grande | Falha: uma pessoa vê que o ícone sumiu |
Como escolher a tolerância de uma comparação de imagens
No GUI Test Studio, a tolerância de uma asserção visual é o seu Rigor da verificação, escolhido em palavras simples: mais rigoroso para detalhes finos, mais tolerante para telas carregadas.Não há nenhuma porcentagem para adivinhar.
| Rigor da verificação | Use para |
|---|---|
| Exato | Imagens que precisam ficar exatamente como estão. |
| Rigoroso | Texto pequeno e detalhes finos em que qualquer mudança importa. |
| Padrão | Os botões, rótulos e ícones do dia a dia.O valor padrão. |
| Flexível | Áreas grandes e telas carregadas, como uma página inteira ou uma cena de jogo. |
- 1
Selecione a asserção visual
Abra o teste no GUI Test Studio e clique na asserção visual na linha do tempo.As configurações dela aparecem no painel Propriedades.
- 2
Escolha um Rigor da verificação
Mantenha Padrão para os botões, rótulos e ícones do dia a dia.Escolha um nível mais rigoroso para texto pequeno e detalhes finos, um mais tolerante para áreas grandes e telas carregadas, e Exato só para uma imagem que precisa ficar exatamente como está.
- 3
Deixe Ignorar pequenos artefatos de renderização ativado
Ele vem ativado por padrão, então as bordas suavizadas que diferem entre máquinas são ignoradas.Desative-o só quando essas bordas forem o que você testa.
- 4
Execute o teste e leia o relatório
Clique em Executar teste.O Relatório de confiança destaca o que mudou e diz em uma frase por que a asserção foi reprovada.
- 5
Adicione Instruções para a IA se uma diferença for esperada
Em Avançado, escreva algumas palavras como: ignore o tamanho da fonte.A Análise inteligente com IA as segue ao julgar essa asserção.
A maioria dos testes nunca precisa de mais do que isso.As configurações exatas de cada nível, e as avançadas para a rara asserção que precisa delas, estão em asserções visuais e as configurações de uma asserção.
Teste visual com IA: um segundo olhar em palavras simples
Uma comparação visual diz que algo mudou e onde.Uma segunda opinião em palavras ajuda você a decidir o que fazer.Esse é o trabalho da Análise inteligente com IA, que fica desativada até você ativá-la.
O ponteiro do mouse e o cursor de texto piscando nunca contam como diferença para a IA.Uma asserção aprovada nunca é enviada a ela.
Ela funciona 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.Algumas diferenças são esperadas, e só você sabe quais: dê Instruções para a IA a uma asserção, como "ignore o tamanho da fonte" ou "o ícone pode ter qualquer cor".Veja Análise inteligente com IA.
Como ler uma falha visual
Depois de uma execução, o Relatório de confiança mostra cada asserção reprovada com a imagem esperada, a imagem encontrada e o que mudou destacado na tela.O veredito diz em uma frase o que mudou e onde.
Quando a mudança é intencional, aceite a nova aparência no relatório, e o teste passa a esperá-la.
Quais bugs visuais uma verificação com código não vê de jeito nenhum é o assunto de os bugs visuais que os testes automatizados não pegam.
Pontos principais
- 1O teste de capturas de tela pixel perfect falha duas vezes: o ruído de renderização reprova telas corretas, e um limite em porcentagem deixa passar bugs reais.
- 2Ruído é o que ninguém vê, uma mudança real é o que uma pessoa percebe: um dígito, uma letra, um ícone, uma cor.
- 3Uma fração da imagem é a medida errada. Pergunte, em vez disso, o que uma pessoa olhando a tela veria.
- 4O GUI Test Studio encontra primeiro o elemento e depois o compara como o olho humano faz, então suavização, compressão e um cursor piscando nunca reprovam um teste.
- 5A Análise inteligente com IA acrescenta um segundo olhar em palavras simples, e a resposta dela é o veredito final quando você a ativa.
Perguntas
O que é o teste pixel perfect?
O teste pixel perfect compara uma captura de tela de uma aplicação com uma captura de referência, pixel a pixel, e falha quando elas diferem.Ele vê cada mudança, inclusive as que ninguém consegue ver.Por isso gera alarmes falsos em telas corretas.
Por que os testes de comparação de capturas falham quando nada mudou?
Porque a mesma tela não é desenhada com os mesmos pixels em todo lugar.Bordas suavizadas, suavização de fontes, a placa de vídeo, a escala da tela, um cursor de texto piscando ou um destaque de passagem do mouse mudam alguns pixels sem mudar nada que uma pessoa notaria.Uma comparação pixel a pixel conta todos eles.
Qual é um bom limite para o teste de regressão visual?
Nenhuma porcentagem serve para todas as imagens.Uma fração pequena o bastante para pegar um dígito errado em um painel grande falha com um ruído inofensivo, e uma flexível o bastante para ignorar o ruído deixa esse dígito passar.Faça em vez disso a pergunta que uma pessoa faz: alguém olhando a tela veria uma diferença?É assim que o GUI Test Studio compara.
O anti-aliasing causa falsos positivos em testes visuais?
Sim, é uma das causas mais comuns.As bordas do texto e das formas são suavizadas com cores intermediárias, e essa suavização difere entre máquinas, placas de vídeo e configurações.O GUI Test Studio compara como uma pessoa olha uma tela, então a suavização que ninguém vê é ignorada.
Um limite de diferença de pixels pode esconder um bug real?
Sim.Um dígito errado, uma maiúscula que virou minúscula ou um pequeno ícone ausente muda de algumas dezenas a algumas centenas de pixels, uma fração mínima de uma imagem grande.Um limite de 1 ou 2 % deixa todos passarem.
Como o GUI Test Studio compara capturas de tela?
Em duas fases.A Fase de busca encontra o elemento na tela, para onde quer que ele tenha se movido.A Fase de verificação o compara então com o que você espera, como o olho humano faz: pega um dígito errado, uma palavra alterada, um ícone ausente ou outra cor, e ignora o ruído de renderização que ninguém vê.
O teste visual com IA é melhor que a comparação de pixels?
Eles funcionam melhor juntos.Uma comparação visual cuidadosa é rápida e repetível, e decide sozinha a maioria das asserções.No GUI Test Studio, a Análise inteligente com IA dá um segundo olhar só a uma asserção reprovada, diz em palavras simples o que mudou e dá o veredito final quando você a ativa.
Como lidar com datas e contadores em testes visuais?
Deixe-os fora da imagem que uma asserção visual compara, e verifique-os com uma asserção de texto.Uma asserção textual dinâmica verifica se um valor tem o formato certo, como uma data ou um valor em dinheiro, seja qual for o valor dele hoje.
Playwright, ClearType e Windows são marcas comerciais da Microsoft Corporation.
Continue lendo
Todos os artigos
Testes visuais
Teste de modo escuro, outros idiomas, outras telas: um único teste para todas as variações
10 min de leitura
Testes visuais
Bugs visuais que os seus testes automatizados deixam passar: como testar o que os usuários veem
10 min de leitura
Automação de testes
Teste manual vs. teste automatizado: por que o teste manual fica aquém nos testes de ponta a ponta
15 min de leitura