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:
- https://developers.google.com/web/tools/chrome-devtools/device-mode/testing-other-browsers
- https://watirmelon.blog/2015/12/08/real-vs-headless-browsers-for-automated-acceptance-tests/
- http://news.softpedia.com/news/what-is-a-headless-browser-and-what-s-it-good-for-485162.shtml
- https://github.com/dhamaniasad/HeadlessBrowsers
- https://circleci.com/
