Use capturas de tela para aparência em tela inteira, OCR para texto visível e correspondência de imagem para um alvo visual conhecido. Os testes visuais mais fortes do Android combinam uma afirmação focada com tempo estável e evidências de falha.
A resposta curta: teste o que deve permanecer verdadeiro
Use o teste de captura de tela quando toda a tela, componente, espaçamento, cor ou tipografia precisar permanecer visualmente consistente. Use o OCR quando o requisito for sobre palavras que uma pessoa pode ver, especialmente texto localizado ou renderizado dinamicamente. Use a correspondência de imagens quando um ícone, botão, emblema ou ilustração conhecido precisar aparecer mesmo quando não tiver um identificador de UI confiável.
Comece com um seletor de UI ou estado de acessibilidade quando o requisito for semântico: um controle existe, está habilitado, está selecionado ou expõe um rótulo estável. Adicione a detecção de objetos somente quando o alvo pertencer a uma classe visual e puder alterar muito o tamanho ou a posição de um modelo. Esses métodos são camadas, não estruturas de teste concorrentes.
- Pergunte quais evidências convenceriam um revisor de que o requisito foi aprovado.
- Escolha o sinal confiável mais estreito em vez de comparar cada pixel por padrão.
- Estabilize a tela antes de observá-la e salve um artefato quando a afirmação falhar.
Métodos de teste visual do Android comparados
| Método | Melhor para | Principal fraqueza | Evidência útil |
|---|---|---|---|
| UI ou estado de acessibilidade | Controles, rótulos, estado ativado, seleção, estrutura de navegação | Elementos renderizados personalizados ou inacessíveis podem ficar invisíveis para a árvore da IU | Hierarquia da UI, propriedades selecionadas, captura de tela |
| Captura de tela ou imagem dourada | Layout, espaçamento, cores, tipografia, aparência dos componentes | Dados dinâmicos, animação, diferenças de dispositivos e alterações de renderização podem criar diferenças barulhentas | Imagem atual, linha de base aprovada, diferença visual |
| OCR | Texto visível, localização, recibos, mensagens de status, valores renderizados como pixels | A qualidade do reconhecimento depende do corte, escala, contraste, dados de idioma, rotação e segmentação | Corte de origem, texto reconhecido, confiança ou lista de resultados |
| Correspondência de modelos | Um ícone, botão, emblema, miniatura ou pequena região estável conhecida | Tema, escala, compactação e redesenho podem invalidar o modelo | Modelo, região de pesquisa, melhor correspondência, pontuação, captura de tela |
| Detecção de objetos | Um objeto visual cuja classe permanece significativa enquanto a posição ou tamanho varia | Requer um modelo compatível, classes rotuladas, limites e validação de modelo | Versão do modelo, classe, caixa, pontuação, captura de tela |
A orientação oficial de teste de captura de tela do Android descreve a comparação da renderização atual com uma imagem de referência aprovada. O plugin de imagem do Appium expõe correspondência de recursos, correspondência de modelos e comparação de similaridade. O OpenCV documenta a mecânica de deslizar um modelo sobre uma imagem, enquanto o Tesseract documenta por que o pré-processamento de OCR e a segmentação de páginas são importantes. As ferramentas são diferentes, mas a questão do design do teste permanece a mesma: que observação comprova esse requisito?
Escolha a afirmação certa com quatro perguntas
1. O requisito é semântico ou visual?
Se o teste disser “o botão Enviar está ativado”, inspecione primeiro o estado da IU. Se disser “o botão Enviar não foi cortado após a alteração da fonte”, use uma captura de tela ou uma verificação visual focada. Uma consulta semântica geralmente é mais fácil de manter, mas não pode provar a aparência.
2. O texto exato é importante?
Use OCR quando a string voltada para o usuário for o requisito e o texto não for exposto de forma confiável por meio da árvore da UI. Restrinja o reconhecimento à menor região significativa, selecione o idioma correto e compare um resultado normalizado. Mantenha uma captura de tela porque uma sequência de OCR correta por si só não pode mostrar truncamento, sobreposição ou contraste insuficiente.
3. Existe um alvo visual estável?
Use a correspondência de modelos para um ícone conhecido ou um pequeno controle. Corte o modelo com precisão, pesquise dentro de uma região de interesse e defina o limite de amostras reais positivas e negativas. Um limite universal raramente é defensável em temas, resoluções e fluxos remotos compactados.
4. Toda a composição deve permanecer consistente?
Use a comparação de capturas de tela quando o relacionamento entre muitos elementos for importante. Controle fontes, localidade, configuração do dispositivo, barras do sistema, hora, dados de rede, animações e conteúdo propagado. Se essas entradas não puderem ser controladas, mascare ou corte as regiões dinâmicas em vez de aceitar um teste com ruído permanente.
Crie um teste visual que falhe de forma útil
- Coloque o aplicativo em um estado inicial nomeado em um dispositivo ou emulador autorizado.
- Aguarde uma condição estável, não apenas um atraso fixo. O UI Automator fornece espera de estabilidade e um sinal de prontidão específico do aplicativo é ainda melhor.
- Capture a menor região de origem que contém as evidências necessárias.
- Execute uma declaração primária: estado da interface do usuário, OCR, modelo, detecção ou comparação de captura de tela.
- Salve a imagem de origem e o resultado estruturado antes de realizar a próxima ação.
- Em caso de falha, pare ou siga um caminho de recuperação revisado. Não toque em um sósia próximo simplesmente para manter o teste em andamento.
Uma verificação visual torna-se mais segura quando autoriza uma transição. Observe o estado atual, faça a afirmação, execute a ação permitida somente após sucesso e verifique a pós-condição. Este é o mesmo princípio de design descrito no guia de clique automático de reconhecimento de imagem: o reconhecimento não é prova de que o fluxo de trabalho foi concluído.
Para trabalho em dispositivos reais, oEspelhamento de tela do Android para testes de aplicativos móveisoferece ao revisor uma visualização ao vivo enquanto o teste está sendo projetado. O guia de teste de fumaça de controle de qualidade de automação Androidexplica como manter verificações repetidas restritas e reproduzíveis.
Três cenários práticos de testes visuais do Android
Controle de qualidade de localização em uma tela de checkout
Use o estado da UI para navegar até a tela de checkout, OCR para confirmar o total localizado e o rótulo da ação e uma captura de tela focada para mostrar que as strings não estão cortadas ou sobrepostas. Execute cada localidade com dados de teste controlados. Uma comparação de pixels em tela inteira por si só será muito sensível ao comprimento da string traduzida, enquanto o OCR por si só não detectará danos ao layout.
Verificando um ícone da barra de ferramentas redesenhado
Use um modelo para o ícone aceito em uma pequena região da barra de ferramentas. Mantenha modelos separados quando temas claros e escuros forem suportados. Quando a correspondência falhar, anexe o corte da barra de ferramentas e a pontuação do melhor candidato. Se o ícone for redesenhado intencionalmente, revise e substitua o modelo em vez de diminuir o limite até que qualquer forma seja aprovada.
Um teste de fumaça em telefone real após a implantação
Comece com uma conta e um estado de aplicativo conhecidos, aguarde a tela inicial, afirme sua identidade, execute uma ação permitida e verifique o próximo estado nomeado. Capture uma captura de tela de cada falha. A densidade do dispositivo, as caixas de diálogo de permissão, os teclados, as notificações e as atualizações do sistema fazem parte do ambiente real do telefone, portanto, o teste deve reportá-los em vez de ocultá-los.
Falhas falsas comuns e como evitá-las
| Sintoma | Causa provável | Melhor resposta |
|---|---|---|
| A diferença da captura de tela muda a cada execução | Relógio, animação, anúncios, dados propagados, teclado, barra do sistema ou conteúdo de rede | Congelar entradas, aguardar estabilidade, cortar ou mascarar apenas a região dinâmica |
| OCR retorna texto plausível, mas errado | Idioma errado, baixo contraste, corte pequeno, rotação, ruído ou segmentação inadequada | Salve o recorte, melhore a escala e o contraste, escolha o idioma e a segmentação deliberadamente |
| A correspondência de modelos funciona apenas em um telefone | Densidade, tema, escala, proporção ou compactação diferentes | Use uma região de interesse e modelos validados para variantes visuais compatíveis |
| A imagem correta é encontrada, mas o toque falha | As coordenadas da correspondência não foram transformadas na tela atual ou uma sobreposição bloqueia a entrada | Separe o reconhecimento da ação e verifique o próximo estado |
| O teste continua na tela errada | Sem pós-condição ou borda de falha | Nomeie os estados esperados e pare quando a tela atual estiver fora do caminho revisado |
| Detector de objetos encontra a classe errada | O modelo ou os rótulos não cabem no domínio do aplicativo, o limite não é validado | Use um modelo compatível, registre versão e pontuação, teste amostras negativas |
As discussões da comunidade sobre testes de regressão do Android geralmente retornam aos mesmos custos de manutenção: matrizes de dispositivos, tempo instável, revisão de linha de base e telas cujo conteúdo muda. Essas não são razões para abandonar os testes visuais. Eles são motivos para tornar explícitos o ambiente de teste, a variação aceita e os artefatos de falha.
Como LaiCai Flow se encaixa nos testes visuais
LaiCai Flowé um recurso de automação dentro do LaiCai Screen Mirroring. Um fluxo pode combinar captura de tela, verificações de UI, OCR, correspondência de modelos, detecção de objetos, condições, ações e transições explícitas de sucesso ou falha. Isso permite que um testador modele a tela como um estado, em vez de tratar o reconhecimento como um truque isolado.
ComLaiCai Flow Inside, um perfil compatível pode ser executado por meio de LaiCai Android Agent no telefone após a implantação. A compatibilidade ainda depende de cada nó e ativo usado por esse perfil. OCR local usa Tesseract; a correspondência de modelo usa um recurso de imagem selecionado e uma pontuação configurável; a detecção local compatível usa um modelo compatível. Um nó de rede ou modelo remoto ainda precisa de sua própria dependência de rede.
Isso não torna todos os testes visuais automaticamente confiáveis. As equipes ainda precisam de linhas de base representativas, modelos, regiões de OCR, modelos, limites, casos negativos e pós-condições. A vantagem é que essas decisões e transições podem ser revisadas em um único fluxo de trabalho. O guia de automação AndroidAIfornece uma visão mais ampla da criação e execução em dispositivos reais.
O pacote mínimo de evidências para um teste visual com falha
- Nome do teste, compilação do aplicativo, modelo do dispositivo, versão do Android, localidade, tema e orientação.
- A captura de tela de origem ou região recortada usada pela afirmação.
- A linha de base, modelo, texto, classe ou propriedade de UI esperada.
- A diferença observada, resultado de OCR, caixa delimitadora, pontuação de correspondência ou valor de UI.
- O estado nomeado anterior, a tentativa de ação, o próximo estado esperado e o motivo da parada.
- Versão do ativo, modelo ou linha de base para que um revisor possa reproduzir a decisão.
Um rótulo de aprovação/reprovação sem esse contexto força a próxima pessoa a reproduzir toda a execução. Um pacote compacto de evidências transforma a falha em uma decisão revisável: consertar o produto, estabilizar o teste, atualizar um ativo visual aprovado ou rejeitar uma configuração de dispositivo não compatível.
Perguntas frequentes sobre testes visuais do Android
Todo teste de UI do Android deve incluir uma captura de tela?
Não. Use capturas de tela quando a aparência for importante ou quando um artefato com falha ajudar um revisor. As asserções semânticas geralmente são melhores para o comportamento que a árvore da UI expõe de maneira confiável.
O OCR é melhor do que a correspondência de imagens?
OCR responde a perguntas sobre texto visível. A correspondência de imagens responde a perguntas sobre um padrão visual conhecido. Se o requisito incluir o rótulo e sua aparência, use OCR mais uma captura de tela focada ou verificação de modelo.
Os testes de captura de tela podem ser executados em telefones Android reais?
Sim, mas dispositivos reais apresentam mais variações do que um renderizador ou emulador controlado no lado do host. Registre a configuração do dispositivo, estabilize a interface do usuário e os dados do sistema e defina as expectativas para a matriz de dispositivos que você realmente suporta.
Quando devo usar a detecção de objetos?
Use-o quando uma classe de objeto significativa se mover ou for dimensionada além da tolerância de um modelo estável e somente quando um modelo compatível tiver sido validado nas imagens reais do aplicativo. Não adicione um detector só porque parece mais avançado.
Escolha evidências antes de escolher tecnologia
O teste visual confiável do Android começa com uma frase: o que um revisor deve ser capaz de provar? Escolha o estado da UI para semântica, capturas de tela para composição, OCR para texto, correspondência de modelo para um alvo visual conhecido e detecção de objeto para uma classe validada com geometria variável.
Em seguida, torne a observação parte de uma transição de estado: estabilize, capture, afirme, aja somente após o sucesso, verifique a pós-condição e preserve as evidências de falha. Esse design é mais fácil de entender do que uma coleção de chamadas de visão desconectadas – e muito mais fácil de manter quando o aplicativo ou dispositivo muda.
- Desenvolvedores Android: teste de captura de tela
- Desenvolvedores Android: teste de captura de tela de visualização do Compose
- Desenvolvedores Android: UI Automator
- Appium: plugin de imagens e modos de comparação
- OpenCV: correspondência de modelo
- Tesseract: Melhorando a qualidade do OCR
- Discussão de desenvolvedores Android: teste de captura de tela