Teste de carga: HTTP vs Headless vs Real Browser

Um esboço dos principais aspectos dos métodos de simulação de carga, como HTTP, headless e real browser-based seguido de uma matriz de comparação, para ajudá-lo a escolher uma abordagem de simulação apropriada.
teste de desempenho

Teste de carga:

HTTP vs Headless vs Navegador Real

teste de desempenho
visão geral:

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.

Simulação de carga baseada em HTTP

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”;

O roteiro de exemplo visto aqui é uma vitrine para a natureza técnica desses roteiros. Se um atributo técnico do seu aplicativo mudar, então você terá que reescrever todo o script.

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.

Simulação de carga baseada no navegador sem cabeça

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.

Simulação de carga baseada em navegador real

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.

Share on facebook
Facebook
Share on twitter
Twitter
Share on linkedin
LinkedIn
Share on email
Email
Share on print
Print