AVALIAÇÃO GRATUITA

Teste de carga: HTTP vs Headless vs Real Browser

Inicie uma avaliação gratuita
Veja nossa solução de monitoramento de desempenho

Visão Geral

Páginas da web lentas ou que não respondem afetam diretamente a receita financeira, pois usuários frustrados provavelmente não retornarão mesmo após a resolução do problema. Por isso, os testes de performance se tornaram uma parte fundamental da cadeia de desenvolvimento, com uma demanda crescente.

As plataformas de teste de performance oferecem uma ampla variedade de métodos de simulação de carga, como HTTP, navegadores headless e navegadores reais. Neste artigo, apresentamos os principais aspectos de cada abordagem, seguidos por uma matriz comparativa que pode ser usada para escolher a simulação mais adequada.

Simulação de Carga Baseada em HTTP

Nos primeiros dias da era digital, os testes baseados em HTTP eram muito populares. Com o surgimento de tecnologias web ricas no lado do cliente, os métodos de simulação baseados em HTTP se tornaram cada vez mais obsoletos. Um driver de teste HTTP típico executa solicitações de serviço e interpreta as respostas. Aplicações modernas Web 2.0 incluem muitos scripts no lado do cliente, que são completamente ignorados e não são medidos nesse tipo de teste. No pior cenário, casos de uso complexos não podem ser simulados no nível do protocolo devido à ausência de IDs gerados no cliente.

Devido à natureza baseada em requisição e resposta, a sobrecarga na máquina de injeção de carga é muito baixa. Um servidor típico pode simular até 800 sessões simultâneas. Casos de uso complexos baseados em protocolo podem ser difíceis de implementar. Um engenheiro de performance precisa lidar com cookies, IDs de sessão e outros parâmetros dinâmicos. Dependendo do sistema testado, nomes de formulários podem mudar com novas versões, o que pode fazer com que scripts HTTP falhem.

Simulação de Carga com Navegador Headless

Com o avanço das tecnologias Web 2.0, o setor de testes enfrentou sérios desafios. Aplicações web ricas não podiam mais ser testadas no nível de protocolo, devido à ausência da lógica do lado do cliente durante a execução dos scripts. Assim, surgiram navegadores headless como HtmlUnit, PhantomJS e SlimerJS. Eles são geralmente baseados no WebKit, o motor por trás do Chrome e do Safari.

Navegadores headless são semelhantes a navegadores reais, mas sem interface gráfica (GUI). Muitas plataformas de automação de testes e de performance utilizam esses navegadores para simular tráfego.

No entanto, navegadores headless têm suas limitações: à medida que novos navegadores surgem, os kits headless precisam acompanhar as atualizações de performance e recursos dos navegadores reais.

A simulação do renderização no lado do cliente tem seu custo. Um servidor típico de injeção de carga consegue simular apenas de 10 a 12 sessões headless simultâneas, contra 500 sessões baseadas em HTTP.

A criação e personalização de scripts de teste não é muito difícil. Com conhecimentos básicos de programação, é possível desenvolver scripts simples. Nem todos os navegadores headless oferecem recursos de reprodução visual, e sem esse recurso, a depuração e análise de erros pode ser bastante complicada.

Simulação de Carga com Navegador Real

Aplicações Web 2.0 estão repletas de JavaScript, Flash, Ajax e CSS. Sem um navegador completo, não é possível medir com precisão o tempo de resposta de ponta a ponta de uma página. Testes de performance com navegadores reais permitem validar a funcionalidade e velocidade do site conforme percebidas pelo usuário final.

Uma solução típica de teste com navegador real coleta o tempo de carregamento de imagens, JavaScript, CSS e outros elementos. Frequentemente, são fornecidos gráficos em cascata (waterfall) para visualizar esses tempos.

A pegada de uso do navegador real é ligeiramente maior. Considerando que a simulação com navegador headless não entrega tempos 100% realistas, é justo afirmar que a simulação com navegador real é preferível. Em cenários reais, navegadores headless têm apenas 20% de desempenho superior aos reais. Assim, se um injetor de carga consegue simular 10–12 sessões headless, pode simular também 8–10 sessões reais.

A implementação e manutenção de scripts é fácil, pois as ações do usuário são reproduzidas diretamente, e a reprodução visual facilita a depuração. No exemplo abaixo, o navegador abre uma URL, insere usuário e senha e clica no botão de login.

Tipos de Testes de Performance

Testes de Velocidade de Componentes

Nos últimos anos, os métodos de desenvolvimento de software passaram a adotar o modelo ágil. Ciclos curtos de lançamento são essenciais. Desenvolvedores e engenheiros de teste automatizam verificações de qualidade e desempenho. Em geral, eles implementam testes de performance baseados em serviços no nível de protocolo ou simulam testes com navegador real para comparar tempos de resposta ponta a ponta com os limites estabelecidos.

Objetivos

  • + Repetibilidade
  • + Verificações automatizadas de interface e desempenho fim a fim
  • + Comparação de tempos de resposta com os limites definidos

Testes de Carga

Por vários motivos, testes de carga são ideais para verificar requisitos não funcionais. Permitem validar tempos de resposta sob condições reproduzíveis, além de verificar limites definidos. A medição realista do tempo de resposta é essencial nesse contexto. Por isso, engenheiros de teste usam simulação de usuários com navegador headless ou real.

Objetivos

  • + Simulação de carga reproduzível
  • + Verificação dos limites de tempo de resposta
  • + Identificação de gargalos sob carga semelhante à produção
  • + Cenários de teste realistas e completos

Testes de Estresse

Se você precisa testar a confiabilidade da aplicação sob carga máxima, realize um teste de estresse. Esse tipo de teste define o número máximo de usuários e o tempo de crescimento e estabilização da carga. O objetivo é identificar o ponto de ruptura da aplicação.

Objetivos

  • + Comprovar escalabilidade e estabilidade
  • + Simular condições de pico de carga
  • + A reprodutibilidade exata não é prioridade

Comparativo

Obviamente, há boas razões para utilizar simulação via protocolo, headless ou navegador real. A tabela abaixo ajuda a escolher a abordagem mais apropriada.

Critério HTTP Navegador Headless Navegador Real
Simulação de usuário Sem renderização no lado cliente Alguns elementos do lado cliente são simulados Simulação real do usuário
Implementação e personalização de script Difícil em sites complexos Necessita de habilidades de desenvolvimento Scripts simples e fáceis de adaptar
Reprodução de script Requer análise em baixo nível Reprodução visual possível (depende do motor) Você vê exatamente o que ocorre
Manutenção de script Requer programação Erros em áreas não renderizadas são difíceis de depurar Fácil, pois falhas são visíveis na reprodução
Suporte a múltiplos navegadores Algumas ferramentas emulam, mas não são comparáveis Sim, mas alguns elementos podem faltar Algumas suportam várias versões e navegadores
Uso de recursos da máquina de injeção Baixo, até 800 sessões por servidor Médio, até 10–12 sessões Alto, até 6 sessões
Recomendado para DevOps Depende do cenário Não, scripts geralmente complexos Sim, fácil de usar e dados realistas
Recomendado para testes de carga Não, processamento do cliente é ignorado Sim, melhor que simulação HTTP Sim, simulação realista do usuário
Recomendado para testes de estresse Sim, devido à baixa sobrecarga na máquina Não, sobrecarga muito alta Não, maior sobrecarga entre os métodos
Custos Baixo Alto Alto
Recomendado para testes de alto volume e baixo custo (quando aplicável) Não recomendado Recomendado para simulações complexas em ambiente real

Fontes utilizadas neste artigo:

Artigos mais recentes sobre desempenho na Web

Comece o Dotcom-Monitor gratuitamente hoje

Não é necessário cartão de crédito

Comece grátis AGORA