Teste de desempenho baseado em metas com o LoadView

Os testes de desempenho verificam principalmente a velocidade e a confiabilidade de um aplicativo e são divididos em testes de carga (baseados em metas) e testes de estresse. Desde o surgimento de métodos ágeis de desenvolvimento, ser capaz de reproduzir resultados de testes de carga tornou-se uma prioridade máxima.

Quais são as razões para o teste de estresse?

A maneira mais fácil de configurar testes de desempenho é permitindo que vários usuários executem iterativamente scripts de teste. Esse tipo de teste é chamado de teste de estresse e é frequentemente usado para identificar pontos de ruptura em aplicações comerciais. A desvantagem é que o tempo real de resposta do seu aplicativo é o principal responsável pela carga simulada e você não pode controlar o throughput real. Em testes de escalabilidade, isso não é um problema, mas para uma comparação de desempenho entre diferentes lançamentos pode ser problemático.

Quais são as razões para testes de desempenho baseados em metas?

O maior benefício deste tipo de teste é que ele permite medições de velocidade sob condições realistas, reprodutíveis e limites de throughput. Testes de desempenho baseados em metas são frequentemente usados para validar contratos de nível de serviço em ambientes semelhantes à produção.

Considere a seguinte situação:

Vamos supor que 20 usuários simultâneos criarão 2.000 transações em seu novo aplicativo de CRM por hora. Você tem a tarefa de criar um teste de desempenho que verifica que o tempo de resposta de oito segundos para este aplicativo pode ser alcançado nas próximas quatro versões. Um teste de estresse provavelmente não permitirá a simulação exata do throughput esperado em seus quatro testes de desempenho de versão, porque você não pode assumir que o tempo de resposta permanecerá o mesmo que em sua versão real.

solução:

  1. Adicione ThinkTimes aos seus scripts
  2. Encontre a linha de base e o tempo de execução do script único para obter o tempo de sessão
  3. Configure a carga de trabalho, incluindo usuários máximos, taxa de transação baseada em metas e tempo de transação baseado em metas
  4. Execute o teste de desempenho baseado em metas para simular a carga esperada
  5. Revise o relatório do teste e verifique se o aplicativo em teste foi capaz de lidar com a carga dentro dos limites de tempo de resposta acordados
  6. Repita este teste executado em suas próximas quatro versões e verifique se seu aplicativo foi capaz de manter limites de throughput e tempo de resposta

Dicas para configurar a ferramenta EveryStep

ThinkTime (obrigatório)

Crie novas palavras-chave no EveryStep Web Recorder (ThinkTimes) ou reumem palavras-chave existentes

Certifique-se de que os valores permitidos são pontos flutuantes 0.0 – 999.99

Certifique-se de que os usuários podem adicionar ThinkTimes manualmente aos scripts

Lembre-se que o ThinkTimes são tempos de espera e adicionados pelo EveryStep Web Recorder automaticamente durante a gravação das ações do usuário.

Pode haver N ThinkTimes em um script

ThinkTimes são ignorados em testes de script único

ThinkTimes será usado em Calibração / Obter linha de base

ThinkTimes não fazem parte de medições de tempo de resposta

ThinkTimes são ignorados em testes de estresse

Concorrência do usuário (opcional)

Nova palavra-chave “WaitFor (Número de usuários)” no EveryStep Web Recorder

Este é um ponto de espera global que bloqueia usuários simulados em um determinado ponto dos scripts até que o número esperado de usuários tenha atingido esta seção do script

Limites de tempo de resposta (opcional)

Nova palavra-chave SetBoundary no EveryStep Web Recorder

Sintaxe: SetBoundary (Timername, Bound 1, Bound 2)

Linha de base/Calibração (necessária)

LoadView executa um único teste de usuário

ThinkTimes será usado como roteirizado

LoadView calculará o tempo de sessão

Tempo de sessão = tempo de execução do script + ThinkTime

Configure carga de trabalho/plano de execução (necessário)

Cliente define tempo de aumento

Cliente define taxa de transação de metas

Cliente define tempo de sessão de metas

Sistema calcula número de usuários

O cliente decide se deve calcular os tempos de resposta durante o ramp-up ou não

Teste de execução (necessário)

LoadView executa o teste de acordo com o plano de execução/carga de trabalho configurada

LoadView coleta tempos de resposta de scripts ou transações simuladas

LoadView ajusta dinamicamente o ThinkTime para alcançar o throughput esperado, se o aplicativo sob teste diminuir a velocidade do ThinkTimes. Se o ThinkTimes for zero e o tempo de sessão receber > o tempo de sessão, uma mensagem de erro será levantada, o que indica que o throughput esperado não poderia ser alcançado.

O LoadView calcula os tempos de resposta de transações reais e temporizadores sem o ThinkTimes.

Dicas para integração com o Dotcom-Monitor

EveryStep Web Recorder

Introduza novas palavras-chave thinkTime

Ignore o ThinkTime durante testes de um único usuário

Adicione ThinkTime durante a gravação do script

Introduza a nova palavra-chave WaitFor (Número do usuário)

Introduzir nova palavra-chave SetBoundary (TimerName, B1, B2)

A palavra-chave WaitFor deve ser adicionada manualmente aos scripts criados

Use a palavra-chave SetBoundary

Calibração/Obter linha de base

Calcule o tempo da sessão durante a calibração

Plano de Execução/Carga de Trabalho

Opção 1:

Adicione um novo recurso de configuração de carga de trabalho

Substitua o plano de execução pelo recurso de carga de trabalho

Crie a caixa de diálogo de configuração de carga de trabalho para suportar o teste de estresse, a meta de transação e outros tipos

Especifique o tempo de ramp-up

Verifique a caixa para calcular os tempos de resposta durante o ramp-up (sim/não)

Opção 2:

Use o recurso de configuração aprimorado do plano de execução

Selecione o tipo de teste (estresse, baseado em metas)

Defina os detalhes da meta da transação

Especifique o tempo de ramp-up

Verifique a caixa para calcular os tempos de resposta durante o ramp-up (sim/não)

Teste de execução

Calcule o tempo real de execução do script/tempo de sessão

Ajuste dinamicamente o ThinkTimes com base no tempo real da sessão

Levantar o aviso se o throughput esperado não poderia ser alcançado

relatório

Configure uma seção para tempo de resposta, limites reais vs por temporizador

Configure uma seção para throughput, real vs. esperado

Quais são as Entradas do Usuário?

ThinkTimes (Ponto flutuante, > 0)

Transações de metas por hora (Inteiro)

Número máximo de usuários (Inteiro)

Tempo de aumento (minutos)

Calcule o tempo de resposta durante o ramp-up (Sim / Não)

O que é “Linha de Base”?

Uma única execução do usuário do dispositivo ou script. Pense que os tempos são usados no parâmetro. O tempo de execução do script é calculado e armazenado como tempo de sessão. Detalhes adicionais também são calculados, como os recursos de execução necessários.

Como você pode ajustar dinamicamente o teste de carga se a velocidade de transação mudar no sistema de destino?

Calcule o tempo da sessão durante a calibração

Use thinktimes para alcançar o tempo de sessão de metas solicitado

Recalcular o tempo real da sessão durante a execução do teste

Ajuste dinamicamente do ThinkTimes dependendo do tempo real da sessão

Registre a mensagem de erro se o tempo de execução do script for > tempo de sessão de gol

Especifique o número de usuários máximos no cálculo da carga de trabalho

O que é a palavra-chave WaitFor?

Isso ajuda a simular cenários complexos de usuários, como situações de concorrência. É muito útil se você tiver que testar se determinada funcionalidade funciona corretamente se x número de usuários estiver acessando um recurso ao mesmo tempo.

Qual é a palavra-chave SetBoundary?

Os SLAs especificam limites de tempo de resposta para ações do usuário, como a busca por um cliente. A palavra-chave SetBoundary ajuda você a verificar a velocidade real de uma determinada ação ou temporizador. Se o limite permitido for violado, uma mensagem de erro será exibida e estará logado no relatório de teste. A verificação do SLA é muito mais fácil com esta nova palavra-chave SetBoundary

Quais devem ser seus objetivos para o teste de carga?

  • Testes de desempenho 100% comparáveis em diferentes versões/execuções
  • Recurso para simulação de padrões de carga regulares ou de pico
  • Confiança de que o sistema que está sendo testado pode lidar com a carga esperada dentro dos limites acordados
  • Focando a otimização de desempenho em ações de usuários que violaram o limite acordado

Que tipo de relatórios você deve configurar?

  • Crie relatórios semelhantes aos seus relatórios atuais
  • Avg, Min, Max, Stddev, Percentile response times
  • Transações ok, Transações falharam
  • Taxa de erro
  • Todos os tempos de resposta devem ser sem o ThinkTimes

Limitações

Os tempos de sessão de alta meta podem levar a intervalos de sessão e falsos positivos. Considere situações em que o tempo limite da sessão web é muito baixo, como 10 minutos. Se você executar um teste de desempenho baseado em metas com um script simples que executa um login e uma pesquisa do cliente, você deve colocar o ThinkTime entre login e pesquisa. Nesta situação hipotética, o tempo de sessão deve ser de 10 segundos o tempo de sessão de gol 700 segundos. Neste cenário, o ThinkTime será maior do que o tempo limite de sessão do seu aplicativo em teste. Todas as transações simuladas falharão porque seu script será executado no intervalo da sessão web e não será capaz de realizar a pesquisa do cliente.

O que acontecerá se não alcançarmos o objetivo?

Se o tempo de resposta de um aplicativo sob teste de carga diminuir e o tempo de sessão ficar maior do que o tempo de sessão de metas, a taxa de transação esperada não pode ser alcançada.

O LoadView observa o tempo real da sessão durante a execução do teste e ajusta o ThinkTimes para atingir a taxa de transação baseada em metas esperada.

O LoadView também exibe mensagem de erro na tela de monitoramento se o tempo de sessão for maior do que o tempo de sessão de gol.

O LoadView também continua com a execução do teste se a taxa de transação de meta não puder ser alcançada. Nesta situação, o teste será marcado com o estado falido. O relatório do teste mostraria claramente que o throughput esperado não poderia ser alcançado devido à desaceleração nos tempos de resposta e indicaria quais dispositivos são afetados.

Como é uma carga de trabalho baseada em metas de amostra?

Script / Dispositivo ST (seg)

Não editável

GST (seg)

Entrada do usuário

Tph

Entrada do usuário

utilizador

Não editável

Search_User 25 10 500 72
Inser_User 25 60 1000 216

Tempo de aumento: 15 minutos

Medir os tempos de resposta durante o Ramp up: Sim / Não
ST: Hora da sessão

GST: Tempo de sessão de gols

TPH: Transações por hora

Usuário: Calculado por LoadView (3600 / TPH ) * GST = 72