Um script gravado pode simular um usuário virtual; no entanto, uma mera gravação pode não ser suficiente para replicar o “comportamento real do usuário”.
Quando um script é gravado, ele cobre o fluxo único e direto do aplicativo em questão. Considerando que, um usuário real pode realizar várias iterações de qualquer processo antes de fazer logout. O atraso entre os botões de clique (tempo de reflexão) varia de pessoa para pessoa. É provável que alguns usuários reais acessem seu aplicativo por DSL e alguns o acessem por dial-up. Portanto, para obter a sensação real do usuário final, precisamos aprimorar nossos scripts para que tenham uma correspondência exata ou, pelo menos, um comportamento muito semelhante ao dos usuários reais.
O acima é a consideração mais significativa ao conduzir “Teste de desempenho”, mas há mais para um Script VU. Como você vai medir a quantidade precisa de tempo gasto por um VUser quando o SUL está passando por um teste de desempenho? Como você saberia se o VUser passou ou falhou em determinado ponto? Qual é a causa por trás da falha, se algum processo de back-end falhou ou os recursos do servidor foram limitados?
Precisamos aprimorar nosso script para ajudar a responder a todas as perguntas acima.
- Usando transações
- Compreendendo o tempo de reflexão, pontos de encontro e comentários
- Inserir funções através do menu
- O que é parametrização?
- Configurações de tempo de execução e seu impacto na simulação VU
- Executar lógica
- Ritmo
- Registro
- Think Times
- Simulação de velocidade
- Emulação de navegador
- Proxy
Usando transações
As transações são mecânicas para medir o tempo de resposta do servidor para qualquer operação. Em palavras simples, o uso de “Transação” ajuda a medir o tempo que o sistema leva para uma determinada solicitação. Pode ser tão pequeno quanto um clique de um botão ou uma chamada AJAX ao perder o foco da caixa de texto.
Aplicar transações é simples. Basta escrever uma linha de código antes que a solicitação seja feita ao servidor e fechar a transação quando a solicitação terminar. O LoadRunner requer apenas uma string como nome da transação.
Para abrir uma transação, use esta linha de código:
lr_start_transaction (“Nome da transação”);
Para fechar a transação, use esta linha de código:
lr_end_transaction (“Nome da transação”,);
O
- LR_AUTO
- LR_PASS
- LR_FAIL
Exemplo:
lr_end_transaction (“My_Login”, LR_AUTO);
lr_end_transaction (“Business_Workflow_Transaction Name”, LR_FAIL);
Pontos a serem observados:
- Não se esqueça, você está trabalhando com “C” e esta é uma linguagem que diferencia maiúsculas de minúsculas.
- O caractere ponto (.) Não é permitido no nome da transação, embora você possa usar espaços e sublinhado.
- Se você tiver ramificado bem o seu código e adicionado pontos de verificação para verificar a resposta do servidor, poderá usar o tratamento de erros personalizado, como LR_PASS ou LR_FAIL. Caso contrário, você pode usar LR_AUTO e o LoadRunner tratará automaticamente o erro do servidor (HTTP 500, 400 etc.)
- Ao aplicar transações, certifique-se de que não haja nenhuma instrução think_time sendo imprensada ou, de outra forma, sua transação sempre incluirá esse período.
- Como o LoadRunner requer uma string constante como nome da transação, um problema comum ao aplicar a transação é a incompatibilidade da string. Se você der um nome diferente ao abrir e fechar uma transação, você cometerá pelo menos 2 erros. Como a transação que você abriu nunca foi fechada, o LoadRunner produzirá um erro. Além disso, a transação que você está tentando fechar nunca foi aberta, resultando em um erro.
- Você pode usar sua inteligência e responder a si mesmo qual dos erros acima será relatado primeiro? Para validar sua resposta, por que não cometer seu próprio erro? Se você respondeu certo, está no caminho certo. Se você respondeu errado, você precisa se concentrar.
- Como o LoadRunner cuida automaticamente da sincronização de solicitações e respostas, você não precisa se preocupar com a resposta ao aplicar as transações.
Compreendendo o tempo de reflexão, pontos de encontro e comentários
Pontos de Encontro
Pontos de encontro significa “pontos de encontro”. É apenas uma linha de instrução que diz ao LoadRunner para introduzir a simultaneidade. Você insere pontos de rendezvous em scripts VUser para emular a carga pesada do usuário no servidor.
Os pontos de encontro instruem o VUser a esperar durante a execução do teste para que vários VUser cheguem a um determinado ponto, de modo que possam realizar uma tarefa simultaneamente. Por exemplo, para emular carga de pico no servidor do banco, você pode inserir um ponto de encontro instruindo 100 VUser para depositar dinheiro em suas contas ao mesmo tempo. Isso pode ser feito facilmente usando rendezvous.
Se os pontos de encontro não forem colocados corretamente, o VUser estará acessando diferentes partes do aplicativo - até mesmo para o mesmo script. Isso ocorre porque cada VUser obtém tempos de resposta diferentes e, portanto, poucos usuários ficam para trás.
Sintaxe: lr_rendesvous (“Nome lógico”);
Melhores Práticas:
- Prefixe um ponto de encontro com “rdv_” para melhor legibilidade do código; por exemplo, “rdv_Login”
- Remova quaisquer declarações de tempo de reflexão imediatas
- Aplicação de pontos de encontro em uma visualização de script (após a gravação)
Comentários
Adicione comentários para descrever uma atividade, um trecho de código ou uma linha de código. Os comentários ajudam a tornar o código compreensível para qualquer pessoa que o consulte no futuro. Eles fornecem informações sobre a operação específica e separam duas seções para distinção.
Você pode adicionar comentários
- Durante a gravação (usando a ferramenta)
- Após a gravação (escrevendo diretamente no código)
Prática recomendada: marque qualquer comentário na parte superior de cada arquivo de script
Inserir funções através do menu
Embora você possa escrever linhas simples de código diretamente, pode precisar de uma pista para recuperar uma função. Você também pode usar a Caixa de ferramentas de etapas (conhecida como Inserir função anterior à versão 12) para localizar e inserir qualquer função diretamente em seu script.
Você pode encontrar a Barra de Ferramentas Etapas em Exibir à Caixa de Ferramentas Etapas.
Isso abrirá uma janela lateral, olhe para o instantâneo:
O que é parametrização?
Um parâmetro no VUGen é um contêiner que contém um valor registrado que é substituído por vários usuários.
Durante a execução do script (em VUGen ou Controller), o valor de uma fonte externa (como .txt, XML ou banco de dados) substitui o valor anterior do parâmetro.
A parametrização é útil no envio de valores dinâmicos (ou exclusivos) ao servidor, por exemplo; um processo de negócios é desejado para executar 10 iterações, mas escolhendo um nome de usuário exclusivo a cada vez.
Também ajuda a estimular o comportamento real do sistema sujeito. Dê uma olhada no exemplo abaixo:
Exemplos de problemas:
O processo de negócios funciona apenas para a data atual que vem do servidor, portanto, não pode ser passado como uma solicitação codificada permanentemente.
Às vezes, o aplicativo cliente passa um ID exclusivo para o servidor (por exemplo session_id) para que o processo continue (mesmo para um único usuário) - Nesse caso, a parametrização ajuda.
Freqüentemente, o aplicativo cliente mantém um cache de dados enviados de e para o servidor. Como resultado, o servidor não está recebendo um comportamento real do usuário (caso o servidor execute um algoritmo diferente, dependendo dos critérios de pesquisa). Embora o script VUser seja executado com êxito, as estatísticas de desempenho desenhadas não serão significativas. Usar dados diferentes por meio de parametrização ajuda a emular a atividade do lado do servidor (procedimentos, etc.) e exercita o sistema.
Uma data codificada no VUser durante a gravação pode não ser mais válida quando essa data tiver passado. A parametrização da data permite que a execução do VUser seja bem-sucedida, substituindo a data embutida no código. Esses campos ou solicitações são os candidatos certos para parametrização.
Clique aqui se o vídeo não estiver acessível
Configurações de tempo de execução e seu impacto na simulação VU
As configurações de tempo de execução são tão significativas quanto seu script VUGen. Com configurações variadas, você pode obter designs de teste diferentes. É por isso que você pode acabar em resultados não repetíveis se as configurações de tempo de execução não forem consistentes. Vamos discutir cada atributo um por um.
Executar lógica
Run Logic define o número de vezes que todas as ações serão executadas, exceto vuser_init e vuser_end.
Provavelmente, isso deixa mais claro porque o LoadRunner sugere manter todo o código de Login em vuser_init e a parte de Logout em vuser_end, ambos exclusivamente.
Se você criou várias ações, digamos, Entrar, Abrir Tela, Calcular Aluguel, Enviar Fundos, Verificar Saldo e sair, então, o cenário abaixo ocorrerá para cada VUser:
Todos os VUsers farão login, executarão Abrir Tela, Calcular Aluguel, Enviar Fundos, Verificar Saldo - então - novamente Abrir tela, Calcular Aluguel ... e assim por diante - iterando 10 vezes - seguido de logout (uma vez).
Esta é uma configuração poderosa que permite agir mais como um usuário real. Lembre-se, um usuário real não faz login e logout todas as vezes - ele, geralmente, repete os mesmos passos.
Quantas vezes você clica em “caixa de entrada” ao verificar seu e-mail antes de sair?
Ritmo
Isso é importante. Na maioria das vezes, as pessoas são incapazes de compreender a diferença entre o ritmo e o tempo de reflexão. A única diferença é que “o ritmo se refere ao atraso entre as iterações”, ao passo que o tempo de reflexão é o atraso entre quaisquer 2 etapas.
A configuração recomendada depende do design do teste. No entanto, se você deseja ter uma carga agressiva, considere a opção “Assim que a iteração anterior terminar”
Registro
Um log (como geralmente entendido) é um registro de todos os eventos enquanto você executa o LoadRunner. Você pode habilitar o log para saber o que está acontecendo entre seu aplicativo e seu servidor.
O LoadRunner oferece um poderoso mecanismo de registro que é robusto e escalonável por conta própria. Ele permite que você mantenha apenas o “Registro padrão” ou um registro estendido detalhado e configurável ou desative-o completamente.
Um registro padrão é informativo e facilmente compreensível. Ele contém a quantidade certa de conhecimento de que você geralmente precisará para solucionar os scripts do VUser.
No caso do Log estendido, todas as informações do log padrão são um subconjunto. Além disso, você pode ter substituição de parâmetro. Isso informa ao componente LoadRunner para incluir informações completas de todos os parâmetros (da parametrização), incluindo solicitações, bem como dados de resposta.
Se você incluir “Dados retornados pelo servidor”, seu registro será extenso. Isso incluirá todas as informações HTML, tags, recursos e não recursos incluídos diretamente no log. A opção é boa apenas se você precisar de uma solução de problemas séria. Normalmente, isso torna o arquivo de log muito grande e difícil de compreender.
Como você já deve ter adivinhado, se optar pelo “Rastreamento avançado”, seu arquivo de log será enorme. Você deve tentar. Você notará que a quantidade de tempo gasto pelo VUGen também aumentou significativamente, embora isso não tenha impacto no tempo de resposta da transação relatado pelo VUGen. No entanto, esta é uma informação muito avançada e pode ser útil se você entender o aplicativo em questão, a comunicação cliente-servidor entre seu aplicativo e o hardware, bem como detalhes de nível de protocolo. Normalmente, essa informação está morta por essência, pois requer esforços extremos para entender e solucionar problemas.
Pontas:
- Não importa quanto tempo o VUGen leva quando o log é habilitado, ele não tem impacto no tempo de resposta da transação. A HP chama esse fenômeno de “tecnologia de ponta”.
- Desative o log se não for necessário.
- Desative o log quando terminar de usar seus scripts. Incluir scripts com o registro habilitado fará com que o controlador execute mais lentamente e reporte mensagens irritantes.
- Desativar o log aumentará a capacidade do número máximo de usuários que você pode simular no LoadRunner.
- Considere o uso de “Enviar mensagem apenas quando ocorrer um erro” - isso silenciará as mensagens de informação desnecessárias e relatará apenas as mensagens relacionadas ao erro.
Think Times
O Think Time é simplesmente o atraso entre duas etapas.
O Think Time ajuda a replicar o comportamento do usuário, pois nenhum usuário real pode usar qualquer aplicativo como uma máquina (VUGen). O VUGen gera tempo de reflexão automaticamente. Você ainda tem controle total para remover, multiplicar ou flutuar a duração do tempo de reflexão.
Para entender mais, por exemplo, um usuário pode abrir uma tela (que é uma resposta seguida por uma solicitação) e fornecer seu nome de usuário e senha antes de pressionar Enter. A próxima interação da aplicação com o servidor acontecerá quando ele clicar em “Sign In”. O tempo que um usuário levou para digitar seu nome de usuário e senha é Think Time no LoadRunner.
Se você está procurando simular uma carga agressiva no aplicativo, considere desabilitar o tempo de reflexão completamente.
No entanto, para simular um comportamento semelhante ao real, você pode “User Random Think Time” e definir as porcentagens conforme desejado.
Considere usar Limit Think Time para um período legítimo. Normalmente, 30 segundos é bastante bom.
Simulação de velocidade
A simulação de velocidade simplesmente se refere à capacidade de largura de banda de cada máquina cliente.
Uma vez que estamos simulando milhares de VUser através do LoadRunner, é incrível como o LoadRunner é simples para controlar a simulação de largura de banda / velocidade de rede.
Se você é cliente e acessa seu aplicativo acima de 128 Kbps, pode controlá-lo aqui. Você poderá simular um “comportamento semelhante ao real”, o que deve ajudar a obter as estatísticas de desempenho corretas.
A melhor recomendação é definir como Usar largura de banda máxima. Isso ajudará a desconsiderar quaisquer gargalos de desempenho relacionados à rede e se concentrar em quaisquer problemas potenciais no aplicativo primeiro. Você sempre pode executar o teste várias vezes para ver o comportamento variável em diferentes circunstâncias.
Emulação de navegador
A experiência do usuário não depende do navegador que o usuário final está usando. Claramente, isso está além do escopo das medidas de desempenho. No entanto, você pode escolher qual navegador deseja emular.
Você pode responder a si mesmo quando exatamente será importante para você selecionar o navegador correto nesta configuração?
Você usará essa configuração se o aplicativo em questão for um aplicativo da web, retornando respostas diferentes para navegadores diferentes. Por exemplo, você consegue ver imagens e conteúdos diferentes para IE e Firefox, etc.
Outra configuração importante é Simular o cache do navegador. Se você deseja medir o tempo de resposta quando o cache está habilitado, marque esta caixa. Se você está procurando a pior situação possível, isso obviamente não é uma consideração.
Baixar recursos não HTML permitirá que o LoadRunner baixe qualquer CSS, JS e outras mídias ricas. Isso deve ser mantido verificado. No entanto, se você deseja eliminar isso do design do teste de desempenho, pode desmarcar isso.
Proxy
É melhor eliminar completamente o proxy de seu ambiente de teste - isso tornará os resultados do teste não confiáveis. No entanto, você pode enfrentar situações em que isso seja inevitável. Em tal situação, o LoadRunner facilita as configurações de proxy.
Você estará trabalhando (ou deveria estar trabalhando) com nenhuma configuração de proxy. Você pode obtê-lo em seu navegador padrão. No entanto, não se esqueça de verificar qual navegador está definido como padrão e qual é a configuração de proxy do navegador padrão.
Se você estiver usando um proxy e ele exigir autenticação (ou um script), poderá clicar no botão Autenticar, que abre uma nova janela. Consulte a captura de tela abaixo.
Use esta tela para fornecer nome de usuário e senha para autenticação no servidor proxy. Clique em OK para fechar a tela.
Parabéns. Você concluiu a configuração de seu script VUGen. Não se esqueça de configurá-lo para todos os seus scripts de VUser.