Ferramenta de teste LoadRunner – Componentes e Archiarquitetura

O que é LoadRunner?

LoadRunner é uma ferramenta de teste de desempenho lançada por Mercury em 1999. O LoadRunner foi posteriormente adquirido pela HPE em 2006. Em 2016, o LoadRunner foi adquirido pela MicroFocus.

LoadRunner oferece suporte a várias ferramentas de desenvolvimento, tecnologias e protocolos de comunicação. Na verdade, esta é a única ferramenta no mercado que suporta um número tão grande de protocolos para conduzir Teste de Desempenho. Os resultados dos testes de desempenho produzidos pelo software LoadRunner são usados ​​como referência em relação a outras ferramentas

Vídeo do LoadRunner

Por que LoadRunner?

LoadRunner não é apenas uma ferramenta pioneira em Testes de Desempenho, mas ainda é líder de mercado no paradigma de Testes de Desempenho. Em uma avaliação recente, o LoadRunner possui cerca de 85% de participação de mercado na indústria de testes de desempenho.

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 Soquete. Não existe nenhuma ferramenta concorrente no mercado que possa oferecer uma variedade tão ampla de protocolos reunidos em uma única ferramenta.

O que é mais convincente em escolher o LoadRunner em testes de software é a credibilidade desta ferramenta. A ferramenta LoadRunner estabeleceu uma reputação há muito tempo, com a frequência que você encontrará clientes verificando seus benchmarks de desempenho usando LoadRunner. Você encontrará alívio se já estiver usando o LoadRunner para suas necessidades de testes de desempenho.

O software LoadRunner está totalmente integrado com outras ferramentas HP, como Unified Functional Test (QTP) e ALM (Application Lifecycle Management), que permitem que você execute seus processos de teste de ponta a ponta.

LoadRunner trabalha com o princípio de simular usuários virtuais no aplicativo em questão. Esses usuários virtuais, também denominados VUsers, replicam as solicitações do cliente e esperam uma resposta correspondente à passagem de uma transação.

Por que você precisa de testes de desempenho?

Estima-se que perda de 4.4 bilhões em receitas é registrado anualmente devido ao baixo desempenho da web.

Na era atual da Web 2.0, os usuários saem do site se um site não responder em 8 segundos. Imagine-se esperando 5 segundos ao pesquisar no Google ou fazer um pedido de amizade no Facebook. As repercussões do tempo de inatividade do desempenho são muitas vezes mais devastadoras do que se imaginava. Temos exemplos como os que chegaram recentemente ao Bank of America Online Banking, Amazon Serviços Web, Intuit ou Blackberry.

De acordo com Dunn & Bradstreet, 59% das empresas Fortune 500 passam por um período estimado de inatividade de 1.6 horas por semana. Considerando que uma empresa média da Fortune 500 com um mínimo de 10,000 funcionários paga US$ 56 por hora, a parte trabalhista dos custos de tempo de inatividade para tal organização seria de US$ 896,000 semanais, traduzindo-se em mais de US$ 46 milhões por ano.

Estima-se que apenas um tempo de inatividade de 5 minutos no Google.com (19 de agosto de 13) custe ao gigante das buscas até US$ 545,000.

Estima-se que as empresas perderam vendas no valor de US$ 1100 por segundo devido a um recente Amazon Interrupção do serviço da 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 ao mesmo tempo em comparação com o passado

O que é o LoadRunner? Archiarquitetura?

Em termos gerais, a arquitetura do HP LoadRunner é complexa, mas fácil de entender.

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

Numa situação da vida real, todos esses 5000 usuários não estarão na página inicial, mas em uma seção diferente dos sites. Como podemos simular de forma diferente.

VUGen

VUGen ou usuário virtual Generator é um IDE (Ambiente de Desenvolvimento Integrado) ou um editor de codificação rico. VUGen é usado para replicar o comportamento do sistema sob carga (SUL). VUGen fornece um recurso de “gravação” que registra a comunicação de e para o cliente e o servidor na forma de um script codificado – também chamado de script VUser.

Portanto, considerando o exemplo acima, o VUGen pode gravar para simular os seguintes processos de negócios:

1. Navegando na página de produtos de Amazon.com
2. Finalizar Compra
3. para qualquer empresa
4. Verificando a página Minha conta

Responsável pelo Tratamento

Uma vez finalizado um script VUser, o Controller é 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 nosso controlador de exemplo, adicionaremos o seguinte parâmetro ao script VUGen

1) 3500 usuários são Navegando na página de produtos de Amazon.com

2) 750 usuários estão em Finalizar Compra

3) 500 usuários são realizando processamento de pagamento

4) 250 usuários são Verificando a página Minha conta SOMENTE após 500 usuários terem feito o processamento de pagamento

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

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

Máquina/Carga de Agentes Generators/injetores

O controlador HP LoadRunner é responsável por simular milhares de VUsers – esses VUsers consomem recursos de hardware, por exemplo, processador e memória – colocando assim um limite na máquina que os está simulando. Além disso, o Controller simula esses VUsers da mesma máquina (onde o Controller reside) e, portanto, os resultados podem não ser precisos. Para resolver esta preocupação, todos os VUsers estão espalhados por várias máquinas, chamadas Ver 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 analogia do nosso Amazon Exemplo, a saída deste componente será

Análise

Depois que os cenários de carga forem executados, a função de “Análise” entram os componentes do LoadRunner.

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 banco de dados de acesso, nomeado, output.mdb. O componente “Análise” lê esse arquivo de banco de dados para realizar diversos tipos de análises e gera 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 está um exemplo em que a largura de banda pode estar criando um gargalo. Digamos que o servidor Web tenha capacidade de 1 GBps, enquanto o tráfego de dados excede essa capacidade, causando sofrimento aos usuários subsequentes. Para determinar se o sistema atende a essas necessidades, o Performance Engineer precisa analisar o comportamento do aplicativo com uma carga anormal. Abaixo está um gráfico que o LoadRunner gera para obter largura de banda.

Como fazer testes de desempenho

O Roteiro de Teste de Desempenho pode ser amplamente dividido em 5 etapas:

• Planejando o teste de carga
• Crie scripts VUGen
• Criação de cenário
• Execução de Cenário
• Análise de resultados (seguida de ajustes no sistema)

Agora que você instalou o LoadRunner, vamos entender as etapas envolvidas no processo, uma por uma.

Etapas envolvidas no processo de teste de desempenho

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 começar a usar o LoadRunner Testing, é melhor documentar quem participará da atividade de cada equipe envolvida durante o processo.

Gestor de projeto:

Nomeie o gerente de projeto que será o responsável por esta atividade e servirá como responsável pelo escalonamento.

Especialista/Analista de Negócios:

Fornece análise de uso do SUL e fornece experiência na funcionalidade de negócios do site/SUL

Especialista em testes de desempenho:

Cria os testes de desempenho automatizados e executa cenários de carga

System Archiproteger:

Fornece planta do SUL

Desenvolvedor Web e PME:

• Mantém o site e fornece aspectos de monitoramento
• Desenvolve site e corrige bugs

Administrador do sistema:

• Mantém os servidores envolvidos durante um projeto de teste

Descreva os aplicativos e processos de negócios 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 mencionam a quantidade de usuários conectados à aplicação (SUL) em determinado horário. Podemos extrair o número máximo de usuários conectados a um processo de negócio a 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 contrato financeiro e o envia para revisão.
• Outro usuário ‘B’ aprova 200 contratos por dia criados pelo usuário ‘A’
• Outro usuário ‘C’ paga cerca de 150 contratos por dia aprovados pelo usuário ‘B’

Nesta situação, o Usuário B precisa ter 200 contratos ‘criados’ no sistema. Além disso, o usuário C necessita de 150 contratos como “aprovados” para simular uma carga de 150 usuários.

Isto significa implicitamente que você deve criar pelo menos 200+150=350 contratos.

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

Monitores de esboço

Especule cada fator que possa afetar o desempenho de um sistema. Por exemplo, ter hardware reduzido terá um impacto potencial no desempenho do SUL (System Under Load).

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)
• Fluxo de dados (calcular quantos dados são transferidos de e para o cliente e o servidor – depois calcular se a capacidade da NIC é 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 de usuário V.

Etapa 3) Criação do Cenário

O próximo passo é criar seu cenário de carga

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 fazer com que o servidor fique sob estresse e se comporte de maneira anormal. Este é o propósito do teste de desempenho. Os resultados obtidos são então usados ​​para análise detalhada 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 da aplicação sob diferentes cargas. As estatísticas extraídas da execução do teste são salvas e a análise detalhada é realizada. A ferramenta 'HP Analysis' gera vários gráficos que ajudam a identificar as causas raízes do atraso no desempenho do sistema, bem como de uma falha 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