Simulação de carga e tipos de teste de desempenho

O carregamento lento ou páginas web não responsivas têm um impacto direto na receita financeira. Garantir que você configure seus testes de desempenho com a simulação de carga correta é fundamental. Se não for feito corretamente, pode ter efeitos desastrosos. Usuários frustrados provavelmente abandonarão o que quer que fosse que estavam fazendo e não retornem. Mesmo que você e sua equipe tenha resolvido esse problema, é provável que seja tarde demais. Eles provavelmente já encontraram uma solução alternativa. E uma vez que eles têm, é improvável que eles vão mudar de volta.

Não só você tem que se preocupar com a perda de receita, mas outros fatores, como a confiança do consumidor, a integridade da marca, etc., provavelmente são mais prejudiciais para o negócio. Quanto mais tempo a questão durar, mais difícil é recuperar a confiança do consumidor. Não só isso, o retorno dos investimentos que você fez em seu produto, equipes e organização vai levar mais tempo para perceber, se em tudo. Portanto, o teste (e monitoramento) de desempenho tornou-se uma parte fundamental e crítica da cadeia de desenvolvimento de software e aplicativos. A necessidade de uma solução que possa executar testes de desempenho de forma adequada e precisa de perto da experiência do usuário está em alta demanda.

As plataformas de teste de desempenho fornecem uma ampla gama de métodos de simulação de carga, como TESTES HTTP/S, sem cabeça e baseados em navegador real. Neste artigo, delinearemos os principais aspectos de cada um, seguidos de 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 nossa era digital, os testes baseados em HTTP eram muito populares. Com o surgimento da rica tecnologia de cliente web, essa abordagem tornou-se cada vez mais desatualizada (e os testes de desempenho com ferramentas como o JMeter também se tornaram um pouco desatualizados). 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. Devido à escassez de IDs de sessão gerados pelo cliente, casos complexos de uso não podem ser simulados no nível do protocolo.

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 da tecnologia do sistema que está sendo testado, alguns nomes de formulário da Web geralmente mudam depois que uma nova versão é implantada, o que fará com que o script baseado em HTTP falhe.

O roteiro da amostra abaixo mostra a própria natureza técnica desses roteiros. Se um atributo técnico do seu aplicativo mudar, você deve reescrever todo o script, o que é mais fácil de dizer do que fazer.


//sample protocol level script
transaction TMain
var
hContext: number;
begin
WebPageUrl("https://lab3/st/", "Greetings");
WebPageStoreContext(hContext);
WebPageLink("Join the experience!", " - New Visitor");
WebPageSubmit("Continue", CONTINUE001, "Main menu");
WebPageLink("Products", "ShopIt - Products");
WebPageLink(NULL, "ShopIt - Product", 3);
WebPageSubmit("Search", SEARCH001, " - Search", 0, NULL, hContext);
end TMain;

dclform
CONTINUE001:
“nome” := “jack”,
“New-Name-Button” := “Continuar”;

SEARCH001:
“pesquisar” := “boot”;

Afinal, scripts de nível de protocolo são bons para testes de nível de componente em ambientes de integração contínua e, devido ao seu baixo espaço ocupado em máquinas de injeção de carga, são o cenário perfeito para testes de estresse.

Simulação de carga baseada em 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 à falta de lógica do lado do cliente 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.

Os navegadores sem cabeça têm todas as vantagens dos navegadores reais e funcionam mais rápido sem a GUI pesada. Muitas plataformas de automação de teste e teste de desempenho estão usando navegadores sem cabeça, pois permitem simulação realista do usuário.

Alguns provedores construíram seus próprios motores de navegador sem cabeça, mas se desarmaram com armadilhas de manutenção porque devem acompanhar as novas versões do navegador. Nesta situação, é altamente recomendável usar qualquer kit de navegador sem cabeça disponível gratuitamente, porque há uma ampla comunidade que trabalha em melhorias.

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é oito sessões simultâneas de navegador sem cabeça.

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 desenvolvedor, você será capaz de criar scripts simples. Nem todos os navegadores sem cabeça fornecem recursos de replay visual e sem replay visual, depuração de script e análise de erros podem se tornar muito complicados.

No script de exemplo abaixo, uma simples solicitação de postagem é executada. Você precisa de habilidades de programação Java para personalizar esses scripts de teste.


//sample phantomjs script
"use strict";
var page = require('webpage').create(),
server = 'https://posttestserver.com/post.php?dump',
data = 'universe=expanding&answer=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();
});

Com essa consideração em mente, navegadores sem cabeça são o caminho a percorrer se você tem habilidades de programação e você está usando uma solução que permite replay de script visual.

 

Simulação de carga baseada em navegador real

Os aplicativos web 2.0 estão cheios de JavaScript, Flash, AJAX, CSS, etc. Sem um navegador completo, não é possível medir os tempos reais de resposta completa de todo o aplicativo ou página web. O teste de desempenho baseado em navegador real permite que você verifique a funcionalidade e a velocidade do site conforme percebido pelo usuário final, que, como discutimos acima, é onde realmente conta.

Uma solução típica de teste de desempenho do navegador 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. Como a simulação do navegador sem cabeça não oferece um tempo de resposta 100% realista, é justo dizer que a simulação real baseada no navegador deve ser o método preferido para testes.

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 a senha do usuário e clica no botão de login.


//sample real browser-based script
transaction TMain
begin
BrowserStart(BROWSER_MODE_DEFAULT, 800, 600);

navegar para o site de login
BrowserNavigate (“https://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. No entanto, não use-o para testes de estresse porque a pegada no servidor de injeção de carga é muito alta.

 

Diferentes tipos de testes de carga e 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ço (e às vezes testes de API) no nível do protocolo ou simulam verificações de desempenho reais baseadas em navegador para comparar tempos de resposta de ponta a ponta com limites de desempenho acordados.

Objetivos dos testes de velocidade de componentes:

  • Verifique e repita o comportamento de entrada/saída.
  • Interface automatizada e verificações de desempenho de ponta a ponta.
  • Comparando os tempos de resposta com os limites acordados.

Testes de carga

A carga testa a configuração ideal quando se trata de verificação de requisitos não funcionais. Uma das razões é 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.

Objetivos dos Testes de Carga:

  • Simulação de carga reprodutível.
  • Verificação dos limites de tempo de resposta.
  • Identificação de gargalos em condições de carga semelhantes à produção.
  • Criando cenários realistas de teste de ponta a ponta.

Teste de estresse

Se você precisar provar a confiabilidade de seu aplicativo em condições de pico de carga, execute um teste de estresse para determinar o ponto de interrupção do sistema.

Objetivos do Teste de Estresse:

  • Prove escalabilidade e estabilidade nas condições de pico de tráfego.
  • Observe como o sistema falha e volta a funcionar.
  • A reprodutibilidade não é importante.

 

comparação

Obviamente, existem boas razões e situações para simulações de usuários de protocolo, sem cabeça e reais baseadas em navegador. A matriz abaixo fornece algumas orientações sobre quando escolher a abordagem de teste apropriada.

Critérios HTTP Navegador sem cabeça Navegador Real
Simulação do usuário (1) Sem renderização do lado do cliente (2) Alguns elementos do lado do cliente são simulados (3) Simulação real do usuário
Implementação e personalização do script (1) Difícil quando os sites são complexos (2) Habilidades de desenvolvedor necessárias para construir scripts robustos (3) Scripts simples, fáceis de personalizar
Replay de script (1) Necessidade de análise de baixo nível (2) Dependendo do motor usado é possível reproduzir visual (3) Você vê o que você ganha
Manutenção do script (1) Habilidades de programação necessárias (2) Erros em seções não renderizadas são complicados de resolver (3) Fácil porque você vê falhas durante o replay
Suporte multi navegador (1) Algumas ferramentas emulam navegadores da Web, mas isso não é comparável (2) Sim, mas alguns elementos muitas vezes estão faltando (2) Alguns suportam outras versões e navegadores diferentes
Pegada na máquina de injeção de carga (3) Baixa, até 800 sessões por servidor (2) Médio, até 8 sessões por servidor (1) Alta, até 6 sessões por servidor
Recomendado para DevOps (2) Depende do cenário real do teste (1) Não, muitas vezes scripts complexos (3) Sim, figuras fáceis de usar e realistas
Recomendado para testes de carga (1) Não, o processamento do lado do cliente é ignorado (2) Sim, melhor que a simulação HTTP (3) Sim, simulação realista do usuário
Recomendado para testes de estresse (3) Sim, porque há uma sobrecarga baixa na máquina geradora de carga (2) Não, sobrecarga na máquina geradora de carga é muito alta (1) Não, sobrecarga mais alta na máquina geradora de carga
Custos (3) Baixa (2) Médio (1) Alto
Pontuação Total 17 19 24

Espero que este artigo sobre simulação de carga e tipos de teste de desempenho tenha lhe dado alguma visão adicional sobre seus testes de desempenho. Se você tiver alguma dúvida sobre a execução de testes de carga e estresse, ou a solução LoadView em geral, entre em contato com nossa equipe ou inscreva-se para uma demonstração com um de nossos engenheiros de desempenho.