Ferramenta de teste LoadRunner: ArchiDiagrama de textura e componentes

O que é LoadRunner?

LoadRunner é um Teste de Desempenho ferramenta que foi pioneira por Mercury A Interactive foi fundada em 1999. Posteriormente, a LoadRunner foi adquirida pela HP em 2006, e a divisão de software da HP fundiu-se com a Micro Focus em um acordo anunciado em 2016 e concluído em 2017.

Nota da marca: OpenText concluiu a aquisição da Micro Focus em janeiro de 2023.A ferramenta não é mais vendida como HP ou Micro Focus LoadRunnerO LoadRunner Professional agora está disponível. OpenText Engenharia de desempenho profissional, LoadRunner Enterprise é OpenText Engenharia de desempenho empresarial e LoadRunner Cloud é OpenText Engenharia de Desempenho Essencial. Os nomes dos componentes abaixo — VuGen, Controlador, geradores de carga e Análise — permanecem inalterados.

O LoadRunner suporta diversas ferramentas de desenvolvimento, tecnologias e protocolos de comunicação. Ele possui uma das bibliotecas de protocolos mais abrangentes do mercado para a realização de testes de desempenho. Os resultados dos testes de desempenho gerados pelo software LoadRunner são usados ​​como referência para comparação com outras ferramentas.

Vídeo do LoadRunner

Assista ao vídeo abaixo para uma breve introdução ao LoadRunner antes de explorar os componentes.

Por que LoadRunner?

O LoadRunner não é apenas uma ferramenta pioneira em testes de desempenho, mas continua sendo um dos líderes de mercado nesse paradigma e ainda é o ponto de referência para muitas empresas.

A abrangência do protocolo é o motivo mais evidente pelo qual as equipes o escolhem, como mostra o mapa de componentes abaixo.

Em termos gerais, a ferramenta LoadRunner suporta RIA (Rich Internet Applications), Web 2.0 (HTTP/HTML, Ajax, Flex e Silverlight etc.), Mobile, SAP, Oracle, MS SQL Servidor, Citrix, RTE, Mail e acima de tudo, Windows Socket. Poucas ferramentas concorrentes oferecem uma variedade tão ampla de protocolos reunidos em uma única ferramenta, como ilustra a lista de protocolos abaixo.

O que torna a escolha do LoadRunner para testes de software ainda mais convincente é a credibilidade da ferramenta. O LoadRunner construiu uma sólida reputação, sendo comum encontrar clientes que utilizam o LoadRunner para validar os benchmarks de desempenho. Se você já utiliza o LoadRunner para suas necessidades de teste de desempenho, certamente encontrará alívio.

O software LoadRunner está intimamente integrado com as ferramentas irmãs do mesmo pacote — Unified Functional Testing (o antigo LoadRunner). QTP, agora vendido como OpenText Testes Funcionais) e ALM (Gerenciamento do Ciclo de Vida de Aplicativos, agora OpenText ALM/Quality Center) — que permite que você execute seus processos de teste de ponta a ponta.

O LoadRunner funciona com base no princípio de simular usuários virtuais na aplicação em questão. Esses usuários virtuais, também chamados de VUsers, replicam as requisições do cliente e esperam uma resposta correspondente para concluir uma transação.

Por que você precisa de testes de desempenho?

As estimativas do setor abaixo são amplamente citadas e datam do início da década de 2010, mas o padrão que descrevem não mudou: páginas lentas custam dinheiro.

Estima-se que o baixo desempenho dos sites cause uma perda de receita de US$ 4.4 bilhões anualmente.

Na era atual da Web 2.0, os usuários abandonam um site se ele não responder em 8 segundos. Imagine ter que esperar 5 segundos ao fazer uma busca por... Google ou enviar um pedido de amizade no Facebook. As repercussões da indisponibilidade do serviço costumam ser mais devastadoras do que se imagina. Há exemplos notórios, como os que afetaram o serviço de internet banking do Bank of America, Amazon Serviços Web, Intuit e Blackberry.

Segundo a Dun & Bradstreet, 59% das empresas da lista Fortune 500 sofrem, em média, 1.6 horas de inatividade por semana. Considerando que uma empresa média da Fortune 500 com pelo menos 10,000 funcionários paga US$ 56 por hora, o custo da mão de obra decorrente da inatividade para essa organização seria de US$ 896,000 por semana, o que se traduz em mais de US$ 46 milhões por ano.

Apenas 5 minutos de inatividade de GoogleEstima-se que a descontinuação do domínio .com em agosto de 2013 tenha custado à gigante das buscas cerca de 545,000 mil dólares.

Estima-se que as empresas perderam vendas no valor de US$ 1,100 por segundo durante um período anterior. Amazon Interrupção dos serviços web.

Quando um sistema de software é implantado por uma organização, ela pode encontrar muitos cenários que possivelmente resultam em latência de desempenho. Vários fatores causam desaceleração do desempenho, alguns exemplos podem incluir:

• Aumento do número de registros presentes no banco de dados
• Aumento do número de solicitações simultâneas feitas ao sistema
• Um número maior de usuários acessando o sistema simultaneamente em comparação com o passado.

Nem toda candidatura é, contudo, uma candidata adequada. Teste de carga Como se destina a sistemas cliente-servidor com múltiplos usuários, não vale a pena testar o desempenho de um utilitário de desktop para um único usuário como o abaixo.

O que é o LoadRunner? Archiarquitetura?

De forma geral, a arquitetura do LoadRunner é complexa, porém fácil de entender. O diagrama de arquitetura do LoadRunner abaixo mostra como os quatro componentes interagem entre si.

Suponha que você seja designado para verificar o desempenho de Amazon.com para 5000 usuários.

Em uma situação real, esses 5000 usuários não ficarão restritos à página inicial — eles estarão distribuídos por diferentes seções do site. Então, como simulamos essa diferença?

VuGen

VuGen ou Usuário Virtual Generator O VuGen é um IDE (Ambiente de Desenvolvimento Integrado) ou um editor de código avançado. Ele é usado para replicar o comportamento do Sistema Sob Carga (SUL). O VuGen oferece um recurso de "gravação" que registra a comunicação entre o cliente e o servidor na forma de um script codificado – também chamado de script. Script VUser.

Considerando o exemplo acima, o VuGen pode gravar para simular os seguintes processos de negócios:

• Navegando na página de produtos de Amazon.com
• Finalizar Compra
• para qualquer empresa
• Verificando a página Minha conta

Após a execução correta do script, geralmente é necessário capturar os valores dinâmicos do servidor. correlação antes que possa ser ampliado.

Responsável pelo Tratamento

Assim que um script VUser for finalizado, o Responsável pelo Tratamento é um dos principais componentes do LoadRunner que controla a simulação de carga, gerenciando, por exemplo:

• Quantos VUsers simular em cada processo de negócios ou grupo de VUsers
• Comportamento dos VUsers (aumento, desaceleração, natureza simultânea ou concorrente, etc.)
• Cenário de natureza da carga, por exemplo, vida real ou orientado a metas ou verificação de SLA
• Quais injetores usar, quantos VUsers em cada injetor
• Agrupe os resultados periodicamente
• Falsificação de IP
• Relatório de erros
• Relatórios de transações, etc.

Fazendo uma analogia com o nosso exemplo, o Controlador adicionará os seguintes parâmetros ao script VuGen:

1. 3500 usuários estão navegando na página de produtos de Amazon.com
2. 750 usuários estão no checkout.
3. 500 usuários estão realizando processamento de pagamentos.
4. Somente 250 usuários acessam a página "Minha Conta" depois que 500 usuários já tiverem processado o pagamento.

Cenários ainda mais complexos são possíveis:

• Inicie 5 VUsers a cada 2 segundos até uma carga de 3500 VUsers (navegando Amazon página do produto) é alcançado.
• Iterar por 30 minutos
• Suspender iteração para 25 VUsers
• Reiniciar 20 usuários virtuais
• Inicie 2 usuários (em Checkout, Processamento de Pagamento, Página Minhas Contas) a cada segundo.
• 2500 VUsers serão gerados na Máquina A
• 2500 VUsers serão gerados na Máquina B

Máquina/Carga de Agentes Generators/injetores

O LoadRunner Controller é responsável por simular milhares de VUsers – esses VUsers consomem recursos de hardware, como processador e memória – o que impõe um limite à máquina que os simula. Além disso, o Controller simula esses VUsers na mesma máquina (onde reside), e, portanto, os resultados podem não ser precisos. Para solucionar esse problema, todos os VUsers são distribuídos por várias máquinas, chamadas de Load Machines. Generators ou injetores de carga.

Como prática geral, o Controlador reside em uma máquina diferente e a carga é simulada de outras máquinas. Dependendo do protocolo dos scripts VUser e das especificações da máquina, vários injetores de carga podem ser necessários para uma simulação completa. Por exemplo, VUsers para um script HTTP exigirão de 2 a 4 MB por VUser para simulação, portanto, 4 máquinas com 4 GB de RAM cada serão necessárias para simular uma carga de 10,000 VUsers.

Tomando como exemplo a nossa própria analogia Amazon Por exemplo, a saída deste componente são 5000 VUsers divididos em dois injetores: 2500 VUsers gerados na Máquina A e 2500 na Máquina B.

Análise

Após a execução dos cenários de carga, a função do Análise Um componente do LoadRunner entra em ação.

Durante a execução, o Controller cria um dump de resultados em formato bruto e contém informações como qual versão do LoadRunner criou esse dump de resultados e quais foram as configurações.

Todos os erros e exceções são registrados em um Microsoft Acesse o banco de dados chamado output.mdb. O componente de Análise lê esse arquivo de banco de dados para realizar vários tipos de análise e gerar gráficos.

Esses gráficos mostram diversas tendências para entender o raciocínio por trás dos erros e falhas sob carga; ajudando assim a descobrir se a otimização é necessária no SUL, Servidor (por exemplo, JBoss, Oracle) ou infraestrutura.

Abaixo, um exemplo de como a largura de banda pode estar criando um gargalo. Digamos que o servidor web tenha capacidade de 1 Gbps, mas o tráfego de dados exceda essa capacidade, causando problemas para os usuários subsequentes. Para determinar se o sistema atende a essas necessidades, o Engenheiro de Desempenho precisa analisar o comportamento da aplicação sob carga anormal. Abaixo, um gráfico gerado pelo LoadRunner para obter informações sobre a largura de banda.

Como fazer testes de desempenho

O roteiro de testes de desempenho pode ser dividido em cinco etapas principais, resumidas no mapa abaixo:

1. Planejando o teste de carga
2. Criar scripts VuGen
3. Criação de cenário
4. Execução de Cenário
5. Análise de resultados (seguida de ajustes no sistema)

Com o LoadRunner instalado, vamos entender os passos envolvidos no processo um por um.

Etapa 1) Planejando o teste de carga

Planejar testes de desempenho é diferente de planejar um SIT (teste de integração de sistema) or UAT (teste de aceitação do usuário). O planejamento pode ser dividido em pequenas etapas, conforme descrito abaixo:

Monte sua equipe

Ao iniciar os testes com o LoadRunner, é recomendável documentar quem participará da atividade em cada equipe envolvida no processo, conforme demonstrado no organograma abaixo.

• Gestor de projeto: Nomeie o gerente de projeto que será o responsável por esta atividade e servirá como responsável pelo escalonamento.
• Especialista Funcional / Analista de Negócios: Fornece análise de uso do SUL e conhecimento especializado sobre a funcionalidade comercial do site ou SUL.
• Especialista em testes de desempenho: Cria testes de desempenho automatizados e executa cenários de carga.
• System Archiproteger: Fornece o projeto do SUL.
• Desenvolvedor Web e PME: Responsável pela manutenção do site, monitoramento, desenvolvimento e correção de erros.
• Administrador do sistema: Responsável pela manutenção dos servidores envolvidos durante todo o projeto de testes.

Descreva as aplicações e os processos de negócio envolvidos.

Bem sucedido Teste de carga requer que você planeje executar determinado processo de negócios. Um Processo de Negócios consiste em etapas claramente definidas em conformidade com as transações comerciais desejadas – de modo a atingir seus objetivos de teste de carga.

Uma métrica de requisitos pode ser preparada para obter a carga do usuário no sistema. Abaixo está um exemplo de sistema de atendimento em uma empresa:

No exemplo acima, os números indicam a quantidade de usuários conectados ao aplicativo (SUL) em um determinado horário. Podemos extracO número máximo de usuários conectados a um processo de negócios em qualquer hora do dia é calculado nas colunas mais à direita.

Da mesma forma, podemos concluir o número total de usuários conectados à aplicação (SUL) em qualquer hora do dia. Isso é calculado na última linha.

Os 2 fatos acima combinados nos dão o número total de usuários com os quais precisamos testar o desempenho do sistema.

Definir procedimentos de gerenciamento de dados de teste

As estatísticas e observações extraídas dos testes de desempenho são muito influenciadas por vários fatores, conforme informado anteriormente. É de importância crítica preparar dados de teste para testes de desempenho. Às vezes, um processo de negócios específico consome um conjunto de dados e produz um conjunto de dados diferente. Veja o exemplo abaixo:

• Um usuário 'A' cria um golpe financeirotrace o submete para revisão.
• Outro usuário, 'B', aprova 200 contracÉ um dia criado pelo usuário 'A'
• Outro usuário, 'C', paga cerca de 150 contracÉ um dia aprovado pelo usuário 'B'

Nessa situação, o Usuário B precisa ter 200 contracts 'criado' no sistema. Além disso, o usuário C precisa de 150 contracts como “aprovado” para simular uma carga de 150 usuários.

Isso significa implicitamente que você deve criar pelo menos 200 + 150 = 350 unidades.tracts.

Depois disso, aprove 150 contracts para servir como dados de teste para o Usuário C – os 200 restantes contracOs dados servirão como dados de teste para o usuário B.

Monitores de esboço

Considere todos os fatores que possam afetar o desempenho de um sistema. Por exemplo, a redução dos recursos de hardware pode impactar o desempenho do sistema sob carga (SUL).

Liste todos os fatores e configure monitores para poder avaliá-los. Aqui estão alguns exemplos:

• Processador (para servidor Web, servidor de aplicativos, servidor de banco de dados e injetores)
• RAM (para servidor Web, servidor de aplicativos, servidor de banco de dados e injetores)
• Servidor Web/aplicativos (por exemplo IIS, JBoss, Servidor Jaguar, Tomcat etc.)
• Servidor DB (tamanho PGA e SGA em caso de Oracle e MSSQL Server, SPs etc.)
• Utilização da largura de banda da rede
• NIC interna e externa em caso de cluster
• Load Balancer (e que está distribuindo carga uniformemente em todos os nós dos clusters)
• Dados flux (Calcule a quantidade de dados que trafegam entre o cliente e o servidor e, em seguida, calcule se a capacidade da placa de rede é suficiente para simular um número X de usuários.)

Etapa 2) Criar scripts VuGen

O próximo passo após o planejamento é criar scripts VUser, adicionando Parametrização, transações e configurações de tempo de execução à medida que o roteiro amadurece.

Etapa 3) Criação do Cenário

O próximo passo é criar seu Cenário de Carga no Controlador, escolhendo entre um cenário manual e um cenário orientado a objetivos.

Etapa 4) Execução do Cenário

A execução do cenário é onde você emula a carga do usuário no servidor, instruindo vários VUsers a executar tarefas simultaneamente.

Você pode definir o nível de carga aumentando e diminuindo o número de VUsers que executam tarefas ao mesmo tempo.

Essa execução pode resultar na queda do servidor. estresse e apresentando comportamentos anormais. Esse é justamente o propósito dos testes de desempenho. Os resultados obtidos são então utilizados para análises detalhadas e identificação da causa raiz.

Etapa 5) Análise de resultados (seguida de ajustes no sistema)

Durante a execução do cenário, o LoadRunner registra o desempenho do aplicativo sob diferentes cargas. As estatísticas obtidas durante a execução dos testes são salvas e uma análise detalhada é realizada. A ferramenta de análise (denominada 'HP Analysis' nas versões para as quais este guia foi escrito) gera vários gráficos que ajudam a identificar as causas principais da lentidão do sistema, bem como falhas do sistema.

Alguns dos gráficos obtidos incluem:

• Tempo para o primeiro buffer
• Tempo de resposta da transação
• Tempo médio de resposta da transação
• Acessos por segundo
• Windows Recursos
• Estatísticas de erros
• Resumo transação

Perguntas Frequentes