Teste de carga:
HTTP vs Headless vs Navegador Real
O carregamento lento ou páginas da Web não responsivas têm um impacto na receita financeira porque os usuários frustrados provavelmente não retornarão quando o problema for resolvido. Portanto, os testes de desempenho tornaram-se uma parte fundamental da cadeia de desenvolvimento e a demanda ainda está crescendo.
As plataformas de teste de desempenho fornecem uma ampla gama de métodos de simulação de carga, como HTTP, headless e real browser-based. Neste artigo, delinearemos os principais aspectos daqueles seguidos por uma matriz de comparação, que você pode usar para escolher uma abordagem de simulação apropriada.
Nos primeiros dias da era digital, os testes baseados em HTTP eram muito populares. Com o surgimento da rica tecnologia de clientes web, as abordagens de simulação baseadas em HTTP tornaram-se cada vez mais ultrapassadas. Um típico driver de teste baseado em HTTP executa solicitações de serviço e analisa respostas. Os aplicativos modernos da Web 2.0 consistem em muitos scripts do lado do cliente, que são totalmente ignorados e não medidos neste tipo de execução de teste. Na pior das hipóteses, casos complexos de uso não podem ser simulados em nível de protocolo devido à escassez de ids gerados pelo lado do cliente.
Devido à sua solicitação e natureza baseada em resposta, a sobrecarga na máquina de injeção de carga é muito baixa. Um servidor de teste de carga típico pode simular até 800 sessões simultâneas. Casos complexos de uso baseados em protocolos podem ser difíceis de implementar. Um engenheiro de desempenho precisa lidar com cookies, IDs de sessão e outros parâmetros dinâmicos. Dependendo do tipo de sistema que está sendo testado, alguns nomes de formulários da Web muitas vezes mudam uma vez que uma nova versão foi implantada, o que fará com que o script baseado em HTTP falhe.
script de nível de protocolo de amostra
transação TMain
Var
hContext: número;
começar
WebPageUrl(“http://lab3/st/”, “Saudações”);
WebPageStoreContext(hContext);
WebPageLink(“Junte-se à experiência!”, ” – Novo Visitante”);
WebPageSubmit(“Continue”, CONTINUE001, “Menu principal”);
WebPageLink(“Produtos”, “ShopIt – Produtos”);
WebPageLink(NULL, “ShopIt – Produto”, 3);
WebPageSubmit(“Pesquisa”, SEARCH001, ” – Pesquisa”, 0, NULL, hContext);
fim TMain;
dclform
CONTINUE001:
“nome” := “jack”,
“New-Name-Button” := “Continuar”;
SEARCH001:
“pesquisar” := “boot”;
Afinal, os scripts de nível de protocolo são bons para testes de nível de componentes em ambientes de integração contínua e a configuração perfeita para testes de estresse devido à sua baixa pegada em máquinas de injeção de carga.
Com o surgimento das tecnologias web 2.0, o negócio de testes enfrentou sérios desafios. Aplicativos de navegador ricos não podiam mais ser testados ou simulados no nível do protocolo devido à lógica do lado do cliente ausente durante a repetição do script. Portanto, vários navegadores sem cabeça foram introduzidos, como HtmlUnit, PhantomJS ou SlimerJS. Eles são muitas vezes construídos em cima do WebKit, o motor por trás do Chrome e do Safari.
Navegadores sem cabeça são semelhantes aos navegadores reais sem a GUI. Muitas plataformas de teste de automação e teste de desempenho estão usando navegadores sem cabeça para simular tráfego.
Navegadores sem cabeça têm suas próprias armadilhas; à medida que os novos navegadores entram nos mercados, os kits de navegador sem cabeça precisam acompanhar todo o desempenho e os aprimoramentos dos navegadores reais.
A simulação da renderização do lado do cliente não é de graça. Um servidor típico de injeção de carga pode simular até 10-12 sessões simultâneas de navegador sem cabeça, contra 500 de sessões baseadas em HTTP.
A implementação e a personalização do script de teste não são muito difíceis. Se você tem habilidades básicas de codificação, você será capaz de criar scripts simples. Nem todos os navegadores sem cabeça fornecem recursos de replay visual e sem depuração de script de replay visual ou análise de erros pode se tornar muito complicado.
exemplo de script phantomjs
“usar rigoroso”;
página var = require (‘webpage’).create(),
servidor = ‘http://posttestserver.com/post.php?dump’,
dados = ‘universo=expansão&resposta=42’;
page.open (servidor, ‘post’, dados, função (status) {
se (status !== ‘sucesso’) {
console.log(‘Incapaz de postar!’);
} outra coisa {
console.log(page.content);
}
phantom.exit();
});
No script de exemplo visto aqui uma simples solicitação de postagem é executada. Você precisa de habilidades de programação Java para personalizar tais scripts de teste.
Os aplicativos Web2.0 estão cheios de JavaScript, Flash, Ajax e CSS. Sem um navegador completo, não é possível medir os tempos reais de resposta de ponta a ponta de toda a página da Web. Testes reais de desempenho baseados em navegador permitem verificar a funcionalidade e a velocidade do site conforme percebido pelo usuário final.
Uma solução típica de teste de desempenho do navegador real coleta tempos de carregamento de imagens, JavaScript, CSS e muito mais. Muitas vezes eles fornecem gráficos de cachoeira, que visualizam o tempo de carga desses componentes.
A pegada de um navegador real baseado em navegador é ligeiramente maior. Considerando o fato de que a simulação do navegador sem cabeça não oferece tempos de resposta 100% realistas, é justo dizer que a simulação real baseada no navegador deve ser preferida. Em cenários da vida real, os navegadores sem cabeça têm apenas 20% melhor do que os navegadores reais. Assim, se o injetor de carga única de tamanho médio pode executar 10-12 sessões de navegador sem cabeça, o mesmo injetor de carga pode executar 8-10 sessões reais do navegador.
A implementação e manutenção de scripts de teste é fácil porque as ações do usuário são diretamente refletidas e o replay visual facilita a depuração. No script de exemplo abaixo o navegador abre uma URL, insere usuário e senha e clica no botão de login.
exemplo de script real baseado em navegador
transação TMain
começar
BrowserStart (BROWSER_MODE_DEFAULT, 800, 600);
navegar para o site de login
BrowserNavigate (“http://demo.com/TestSite/LoginForm.html”);
definir a autenticação para o site seguro
BrowserSetText(“//INPUT[@name=’user’]”, “User1”);
BrowserSetPassword(“//INPUT[@name=’pwd’]”, “Password1”);
login
BrowserClick(“//INPUT[@value=’Login’]”, BUTTON_Left);
fim TMain;
Afinal, a simulação real do navegador é útil para testes realistas de carga de ponta a ponta, mas pode ficar caro para testar os altos volumes do usuário, porque a pegada no servidor de injeção de carga é muito alta.
Tipos de teste de desempenho
Testes de velocidade de componentes
Nos últimos anos, os métodos de desenvolvimento de software têm se movido na direção ágil. Sprints de liberação curta são essenciais. Desenvolvedores e engenheiros de teste automatizam suas verificações de qualidade e desempenho. Normalmente, eles implementam testes de desempenho baseados em serviços no nível de protocolo ou simulam verificações reais de desempenho baseadas no navegador para comparar tempos de resposta de ponta a ponta com limites de desempenho acordados.
Objectivos
+ Repetibilidade
+ Interface automatizada e verificações de desempenho de ponta a ponta
+ Compare os tempos de resposta com os limites acordados
Testes de carga
Por várias razões, os testes de carga são o método ideal de teste quando se trata de verificação de requisitos não funcionais. Uma delas é que os tempos de resposta podem ser verificados em condições reprodutíveis. Outra é que esses testes permitem a verificação dos limites de tempo de resposta. A medição do tempo de resposta realista é essencial em cenários de teste de carga. Portanto, os engenheiros de teste usam simulação de usuário baseada em navegador sem cabeça ou real para suas configurações de teste de carga.
Objectivos
+ Simulação de carga reprodutível
+ Verificação dos limites de tempo de resposta
+ Identificar gargalos em produção como condições de carga
+ Cenários realistas de teste de ponta a ponta
Teste de estresse
Se você tiver que testar a confiabilidade do seu aplicativo em condições de pico de carga, execute um teste de estresse. Neste tipo de teste você especifica principalmente o número máximo de usuários e o tempo sobre o qual o ramp up e a carga de estado constante devem estar em seu aplicativo. O objetivo é identificar os pontos de ruptura da sua aplicação em teste.
Objectivos
+ Escalabilidade e estabilidade de provas
+ Simule as condições de carga de pico
+ A reprodutibilidade exata não é importante
comparação
Obviamente, existem boas razões para o protocolo, simulação de usuário baseada em navegador sem cabeça ou real. A matriz abaixo fornece algumas orientações para escolher a abordagem apropriada.
Critérios
HTTP
Navegador sem cabeça
Navegador Real
Simulação do usuário
Sem
renderização do lado do cliente
Alguns elementos do lado do cliente são simulados
Simulação real do usuário
Implementação
e personalização do script
Difícil quando os sites são complexos
Habilidades de desenvolvedor necessárias para construir scripts robustos
Roteiros simples, fáceis de personalizar
S
cript replay
Análise de baixo nível necessária
Dependendo do motor usado, o replay visual é possível
Você vê o que você tem
Manutenção do script
Habilidades de programação necessárias
Erros em seções não renderizadas são complicados de resolver
Fácil porque você vê falhas durante o replay
Suporte multi navegador
Algumas ferramentas emulam navegadores da Web, mas isso não é comparável
Sim, mas alguns elementos muitas vezes estão faltando
Alguns suportam outras versões e navegadores diferentes
F
ootprint na máquina de injeção de carga
Baixo,
até 800 sessões por servidor
Médio,
até
10-12
sessões por servidor
Alta,
até 6 sessões por servidor
Recomendado
para
DevOps
Depende do cenário real de teste
Não, muitas vezes scripts complexos
Sim, figuras fáceis de usar e realistas
Recomendado para testes de carga
Não,
o processamento do lado do cliente é ignorado
Sim, melhor que simulação HTTP
Sim, simulação realista do usuário
Recomendado para testes de estresse
Sim, porque há uma sobrecarga baixa na máquina geradora de carga
Não, sobrecarga na máquina geradora de carga é muito alta
Não,
sobrecarga mais alta na máquina geradora de carga
Custos
baixo
alto
alto
Recomendado para testes de alto volume e baixo custo webserver testes de estresse (sempre que possível)
Não recomendado
Recomendado para simulações de aplicativos complexos da vida real.
Teste de estresse
Se você tiver que testar a confiabilidade do seu aplicativo em condições de pico de carga, execute um teste de estresse. Neste tipo de teste você especifica principalmente o número máximo de usuários e o tempo sobre o qual o ramp up e a carga de estado constante devem estar em seu aplicativo. O objetivo é identificar os pontos de ruptura da sua aplicação em teste.
Objectivos
+ Escalabilidade e estabilidade de provas
+ Simule as condições de carga de pico
+ A reprodutibilidade exata não é importante
comparação
Obviamente, existem boas razões para o protocolo, simulação de usuário baseada em navegador sem cabeça ou real. A matriz abaixo fornece algumas orientações para escolher a abordagem apropriada.
| Critérios | HTTP | Navegador sem cabeça | Navegador Real |
| Simulação do usuário | Sem renderização do lado do cliente | Alguns elementos do lado do cliente são simulados | Simulação real do usuário |
| Implementação e personalização do script | Difícil quando os sites são complexos | Habilidades de desenvolvedor necessárias para construir scripts robustos | Roteiros simples, fáceis de personalizar |
| Replay de script | Análise de baixo nível necessária | Dependendo do motor usado é possível reproduzir visual | Você vê o que você tem |
| Manutenção do script | Habilidades de programação necessárias | Erros em seções não renderizadas são complicados de resolver | Fácil porque você vê falhas durante o replay |
| Suporte multi navegador | Algumas ferramentas emulam navegador da Web, mas isso não é comparável | Sim, mas alguns elementos muitas vezes estão faltando | Alguns suportam outras versões e navegadores diferentes |
| Pegada na máquina de injeção de carga | Baixo, até 800 sessões por servidor | Médio, até 10-12 sessões por servidor | Alta, até 6 sessões por servidor |
| Recomendado para DevOps | Depende do cenário real de teste | Não, muitas vezes scripts complexos | Sim, figuras fáceis de usar e realistas |
| Recomendado para testes de carga | Não, o processamento do lado do cliente é ignorado | Sim, melhor que simulação HTTP | Sim, simulação realista do usuário |
| Recomendado para testes de estresse | Sim, porque há uma baixa sobrecarga na máquina geradora de carga | Não, sobrecarga na máquina geradora de carga é muito alta | Não, sobrecarga mais alta na máquina geradora de carga |
| Custos | baixo | alto | alto |
| Recomendado para testes de alto volume e baixo custo webserver testes de estresse (sempre que possível) | Não recomendado | Recomendado para simulações de aplicativos complexos da vida real.
|
- 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/
