O que é teste de “navegador real”?

Por que é diferente?

Existem duas maneiras de testar o software. A primeira e mais óbvia é simplesmente permitir que os usuários testem a funcionalidade usando o software conforme pretendido. Este é o método mais provável de produzir os resultados mais úteis e práticos. O outro método é automatizar os testes. Isso requer um segundo software projetado para fornecer dados de entrada e analisar a saída do aplicativo original. O teste automatizado é bastante útil em situações em que um grande volume de saída é necessário para determinar se o aplicativo está funcionando corretamente.


Para sites da Web, o processo de teste pode ser executado exatamente da mesma maneira. Os usuários podem operar e explorar o site para ver se ele faz o que deve fazer. Também é possível escrever software que pode fornecer entrada e analisar a saída do site automaticamente.

Big picture

A metáfora

A melhor maneira de visualizar a diferença entre o teste do "navegador real", onde um navegador real é usado para operar e testar um site, e o teste automatizado, onde várias solicitações de protocolo são enviadas para um site e a saída resultante é verificada para ver se inclui as combinações certas de dados e apresentação, é imaginar um test drive.


O método do "navegador real" para um carro seria colocar um robô no assento do motorista e fazê-lo operar fisicamente os controles para manobrar o veículo. O método automatizado seria operar o veículo por controle remoto. Após alguns momentos, deve ficar claro por que uma versão é mais eficaz do que a outra.

Teste de cliente

O principal problema dos navegadores virtuais é que eles não possuem um método de teste ou avaliação da funcionalidade do cliente. A única maneira pela qual eles podem se comunicar com um aplicativo ou site da web é testando o código que reside no servidor. Se eles tentarem automatizar o processo de execução e teste do código do lado do cliente, controles da interface do usuário e lógica de apresentação, então eles estão replicando funcionalidades já encontradas nos navegadores, o que coloca em questão a decisão de excluir o navegador em primeiro lugar .


O código do lado do cliente pode fazer uma grande diferença na funcionalidade adequada de um site ou aplicativo da web. Por exemplo, se um usuário não consegue encontrar um botão, ou interpreta erroneamente os controles da interface do usuário de forma que eles não podem executar a sequência adequada de cliques de botão, seleções ou opções de menu para executar uma determinada tarefa, essa falha não pode ser simulada no software . A menos que os programas de teste sejam deliberadamente escritos para ignorar certos elementos da interface do usuário, ou escritos para funcionar mal de propósito, eles não podem simular confusão ou erros.

Interface de automação

O que a maioria dos usuários da web não sabe é que a totalidade da world wide web não é apenas acessível por meio de navegadores, mas também por meio de uma interface de linha de comando. Todos os protocolos populares da Internet são baseados em texto, o que significa que com comandos digitados simples ou complexos, é possível “navegar” na web, e-mail, Usenet, FTP e vários outros protocolos. Não é prático, necessariamente, porque o software existe para colocar um front-end compreensível nessas operações, mas é possível.


Os comandos baseados em texto são projetados para serem coletados em sequências, o que significa que com um pouco de organização é possível operar um site apenas enviando comandos de texto. Como a saída resultante também é texto, ela pode ser analisada quanto à precisão. Esta é a base para algo chamado de navegador “virtual”.

Interface Prática

Embora seja possível automatizar o ato de operar uma interface gráfica, isso não pode ser feito sem usar um navegador ou escrever um software que imite a funcionalidade de um navegador. Esta é a principal falha na ideia de testar um aplicativo da Web por meio da automação. O software projetado para receber entrada e produzir saída pode ser totalmente automatizado, porque fornecer "entrada" é algo que o software pode fazer por conta própria. Na verdade, o conceito de “canais” no sistema operacional UNIX tira total proveito disso, transformando a saída de um programa na entrada de outro.


Mas quando se trata não apenas de fornecer informações, mas também de tomar decisões sobre como essas informações devem ser organizadas, torna-se muito mais difícil automatizar. Se o problema for evitado, é possível obter alguns dos benefícios, mas o teste excluirá tudo relacionado à interface de usuário do cliente.


minha conexao software automatizado definitivamente tem seu lugar e pode representar uma enorme economia de custos. Mas uma das métricas mais importantes em relação a aplicativos e sites da web é a facilidade de uso e a satisfação do usuário: duas coisas que só podem ser medidas trabalhando com usuários reais e navegadores reais.