O que é LoadRunner?
O LoadRunner é uma ferramenta de teste de desempenho que foi lançada pela Mercury em 1999. O LoadRunner foi posteriormente adquirido pela HPE em 2006. Em 2016, o LoadRunner foi adquirido pela MicroFocus.
O LoadRunner oferece suporte a várias ferramentas de desenvolvimento, tecnologias e protocolos de comunicação. Na verdade, esta é a única ferramenta no mercado que oferece suporte a um grande número de protocolos para realizar testes de desempenho. Os resultados do teste de desempenho produzidos pelo software LoadRunner são usados como referência em relação a outras ferramentas
Neste tutorial, você aprenderá-
- Por que LoadRunner?
- Por que você precisa de testes de desempenho?
- O que é a arquitetura LoadRunner?
- Roteiro de testes de desempenho: etapas detalhadas
- Perguntas frequentes
Por que LoadRunner?
O LoadRunner não é apenas uma ferramenta pioneira em Teste de Desempenho, mas ainda é um líder de mercado no paradigma de Teste de Desempenho. Em uma avaliação recente, o LoadRunner tem cerca de 85% de participação no mercado 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 Server, Citrix, RTE, Mail e, acima de tudo, Windows Socket. Não existe uma ferramenta concorrente no mercado que ofereça tamanha variedade de protocolos em uma única ferramenta.
O que é mais convincente para escolher o LoadRunner em testes de software é a credibilidade dessa ferramenta. A ferramenta LoadRunner há muito estabeleceu uma reputação, visto que frequentemente você encontrará clientes verificando seus benchmarks de desempenho usando o LoadRunner. Você encontrará alívio se já estiver usando o LoadRunner para suas necessidades de teste de desempenho.
O software LoadRunner é totalmente integrado a outras ferramentas da HP, como o Unified Functional Test (QTP) e ALM (Application Lifecycle Management), permitindo que você execute seus processos de teste de ponta a ponta.
O LoadRunner funciona com base na simulação de usuários virtuais no aplicativo em questão. Esses usuários virtuais também chamados de VUsers, replicam as solicitações do cliente e esperam uma resposta correspondente ao passar uma transação.
Por que você precisa de testes de desempenho?
Uma perda estimada de 4,4 bilhões em receita é registrada anualmente devido ao fraco desempenho da web.
Na era da Web 2.0 de hoje, os usuários clicam se um site não responde 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 de desempenho costumam ser mais devastadoras do que se imaginou. Temos exemplos como aqueles que chegaram recentemente ao Bank of America Online Banking, Amazon Web Services, Intuit ou Blackberry.
De acordo com Dunn & Bradstreet, 59% das empresas Fortune 500 passam por um período de inatividade estimado de 1,6 horas por semana. Considerando que a empresa Fortune 500 média com um mínimo de 10.000 funcionários está pagando $ 56 por hora, a parte de mão de obra dos custos de tempo de inatividade para tal organização seria de $ 896.000 por semana, traduzindo-se em mais de $ 46 milhões por ano.
Estima-se que o tempo de inatividade de apenas 5 minutos do Google.com (19 de agosto de 13) custe o gigante das buscas em US $ 545.000.
Estima-se que as empresas perderam vendas no valor de $ 1100 por segundo devido a uma interrupção recente do Amazon Web Service.
Quando um sistema de software é implantado por uma organização, ele pode encontrar muitos cenários que possivelmente resultam em latência de desempenho. Uma série de fatores causa 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 é a arquitetura LoadRunner?
Em termos gerais, a arquitetura do HP LoadRunner é complexa, mas fácil de entender.
Suponha que você seja designado para verificar o desempenho da Amazon.com para 5.000 usuários
Em uma situação da vida real, todos esses 5.000 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 Virtual User Generator é um IDE (Integrated Development Environment) ou um rico editor de codificação. VUGen é usado para replicar o comportamento do Sistema Sob Carga (SUL). O 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:
- Navegando na página de produtos da Amazon.com
- Confira
- Processo de pagamento
- Verificando a página Minha conta
Controlador
Uma vez que um script VUser é finalizado, o Controller é um dos principais componentes do LoadRunner que controla a simulação de carga gerenciando, por exemplo:
- Quantos VUsers devem ser simulados em relação a cada processo de negócios ou VUser Group
- Comportamento dos VUsers (aumento, redução, natureza simultânea ou concorrente etc.)
- Natureza do cenário de carga, por exemplo, vida real ou orientado para o objetivo ou verificação de SLA
- Quais injetores usar, quantos VUsers contra cada injetor
- Colete os resultados periodicamente
- Spoofing de IP
- Relatório de erros
- Relatórios de transações etc.
Fazendo uma analogia com o nosso controlador de exemplo, o seguinte parâmetro será adicionado ao Script VUGen
1) 3500 usuários estão navegando na página de produtos da Amazon.com
2) 750 usuários estão no checkout
3) 500 usuários estão realizando processamento de pagamento
4) 250 usuários estão verificando a página Minha conta SOMENTE após 500 usuários terem feito o processamento do pagamento
Cenários ainda mais complexos são possíveis
- Inicie 5 VUsers a cada 2 segundos até que uma carga de 3500 VUsers (navegando na página de produtos da Amazon) seja alcançada.
- Repita por 30 minutos
- Suspender iteração para 25 VUsers
- Reinicie 20 VUSers
- Inicie 2 usuários (no Checkout, Processamento de pagamento, página MyAccounts) a cada segundo.
- 2500 VUsers serão gerados na Máquina A
- 2500 VUsers serão gerados na Máquina B
Máquina de agentes / geradores de carga / injetores
O HP LoadRunner Controller é responsável por simular milhares de VUsers - esses VUsers consomem recursos de hardware, por exemplo, processador e memória - colocando um limite na máquina que os está simulando. Além disso, o controlador simula esses VUsers da mesma máquina (onde o controlador reside) e, portanto, os resultados podem não ser precisos. Para lidar com essa preocupação, todos os VUsers estão espalhados por várias máquinas, chamadas de Geradores de Carga 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 do VUser e das especificações da máquina, vários injetores de carga podem ser necessários para a 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.
Pegando a analogia de nosso exemplo da Amazon, a saída deste componente será
Análise:
Uma vez que os cenários de carga tenham sido executados, a função dos componentes de " Análise " do LoadRunner entra.
Durante a execução, o Controller cria um despejo de resultados na forma bruta e contém informações como, qual versão do LoadRunner criou esse despejo de resultados e quais foram as configurações.
Todos os erros e exceções são registrados em um banco de dados de acesso da Microsoft, denominado output.mdb. O componente "Análise" lê este arquivo de banco de dados para realizar vários tipos de análises e gerar gráficos.
Esses gráficos mostram várias tendências para entender o raciocínio por trás dos erros e falhas sob carga; assim, ajuda a descobrir se a otimização é necessária no SUL, Server (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 da Web tenha capacidade de 1 GBps, enquanto o tráfego de dados excede essa capacidade, causando danos aos usuários subsequentes. Para determinar se o sistema atende a essas necessidades, o engenheiro de desempenho precisa analisar o comportamento do aplicativo com uma carga anormal. Abaixo está um gráfico que o LoadRunner gera para obter a largura de banda.
Roteiro de testes de desempenho: etapas detalhadas
O roteiro de testes 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 (seguido por ajustes de sistema)
Agora que você instalou o LoadRunner, vamos entender as etapas envolvidas no processo, uma a uma.
Etapas envolvidas no processo de teste de desempenho
Planejando o Teste de Carga
O planejamento do Teste de Desempenho é diferente do planejamento de um SIT (Teste de Integração do Sistema) ou UAT (Teste de Aceitação do Usuário). O planejamento pode ser dividido em pequenos estágios, conforme descrito abaixo:
Reúna sua equipe
Ao iniciar o Teste do LoadRunner, é melhor documentar quem estará participando da atividade de cada equipe envolvida durante o processo.
Gestor de projeto:
Nomeie o gerente de projeto que será o proprietário dessa atividade e servirá como ponto de referência para o escalonamento.
Especialista em Função / 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
Arquiteto de sistema:
Fornece planta do SUL
Desenvolvedor da Web e PME:
- Mantém o site e fornece aspectos de monitoramento
- Desenvolve o site e corrige bugs
Administrador do sistema:
- Mantém servidores envolvidos ao longo de um projeto de teste
Descreva os aplicativos e os processos de negócios envolvidos:
O teste de carga bem-sucedido requer que você planeje realizar determinados processos de negócios. Um Processo de Negócios consiste em etapas claramente definidas em conformidade com as transações de negócios desejadas - de modo a cumprir seus objetivos de teste de carga.
Uma métrica de requisitos pode ser preparada para induzir a carga do usuário no sistema. Abaixo está um exemplo de sistema de atendimento em uma empresa:
No exemplo acima, os números referem-se ao número de usuários conectados ao aplicativo (SUL) em determinado horário. Podemos extrair o número máximo de usuários conectados a um processo de negócios a qualquer hora do dia, que é calculado nas colunas mais à direita.
Da mesma forma, podemos concluir o número total de usuários conectados ao aplicativo (SUL) a 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
Estatísticas e observações extraídas de testes de desempenho são muito influenciadas por vários fatores, conforme explicado anteriormente. É de importância crítica preparar os dados de teste para o teste de desempenho. Às vezes, um determinado processo de negócios 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'
Nessa situação, o usuário B precisa ter 200 contratos 'criados' no sistema. Além disso, o usuário C precisa de 150 contratos como "aprovados" para simular uma carga de 150 usuários.
Isso significa implicitamente que você deve criar pelo menos 200 + 150 = 350 contratos.
Depois disso, aprove 150 contratos para servir 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 contorno
Especule cada um dos fatores que podem afetar o desempenho de um sistema. Por exemplo, ter hardware reduzido terá um impacto potencial no desempenho do SUL (System Under Load).
Registre todos os fatores e configure monitores para que você possa medi-los. Aqui estão alguns exemplos:
- Processador (para servidor da Web, servidor de aplicativos, servidor de banco de dados e injetores)
- RAM (para servidor da Web, servidor de aplicativos, servidor de banco de dados e injetores)
- Servidor Web / App (por exemplo IIS, JBoss, Jaguar Server, Tomcat etc)
- Servidor de banco de dados (tamanho PGA e SGA no caso de Oracle e MSSQL Server, SPs etc.)
- Utilização da largura de banda da rede
- NIC interna e externa em caso de agrupamento
- Balanceador de carga (e que está distribuindo a carga uniformemente em todos os nós dos clusters)
- Fluxo de dados (calcule quantos dados se movem de e para o cliente e servidor - depois calcule se a capacidade do NIC é suficiente para simular o número X de usuários)
Crie scripts VUGen
A próxima etapa após o planejamento é criar scripts de VUser.
Criação de Cenário
A próxima etapa é criar seu cenário de carga
Execução de 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 uma 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 sobrecarregado 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.
Análise de resultados (seguido por ajustes de sistema)
Durante a execução do cenário, o LoadRunner registra o desempenho do aplicativo sob diferentes cargas. As estatísticas retiradas da execução do teste são salvas e a análise de detalhes é realizada. A ferramenta 'HP Analysis' gera vários gráficos que ajudam a identificar as causas raiz de um atraso no desempenho do sistema, bem como 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
- Recursos do Windows
- Estatísticas de erros
- Resumo transação
Perguntas frequentes
Quais aplicativos devemos testar de desempenho?
O Teste de Desempenho é sempre feito apenas para sistemas baseados em cliente-servidor. Isso significa que qualquer aplicativo que não seja uma arquitetura baseada em cliente-servidor não deve exigir o Teste de Desempenho.
Por exemplo, o Microsoft Calculator não é baseado em cliente-servidor nem executa vários usuários; portanto, não é um candidato para Teste de Desempenho.
Qual é a diferença entre Teste de Desempenho e Engenharia de Desempenho
É importante entender a diferença entre Teste de Desempenho e Engenharia de Desempenho. Um entendimento é compartilhado abaixo:
O Teste de Desempenho é uma disciplina preocupada em testar e relatar o desempenho atual de um aplicativo de software sob vários parâmetros.
Engenharia de desempenho é o processo pelo qual o software é testado e ajustado com a intenção de obter o desempenho necessário. Este processo visa otimizar o traço de desempenho do aplicativo mais importante, ou seja, a experiência do usuário.
Historicamente, teste e ajuste têm sido domínios distintamente separados e frequentemente concorrentes. Nos últimos anos, entretanto, vários grupos de testadores e desenvolvedores colaboraram de forma independente para criar equipes de ajuste. Como essas equipes tiveram um sucesso significativo, o conceito de combinar testes de desempenho com ajuste de desempenho se popularizou e agora chamamos isso de engenharia de desempenho.