Teste de desempenho baseado em metas

O teste de desempenho baseado em metas é uma estratégia empregada em testes de software, particularmente testes de desempenho, para garantir que os sistemas de software atendam a objetivos de desempenho específicos sob várias condições. No teste de desempenho baseado em metas, o processo de teste é conduzido por metas ou objetivos predefinidos, em vez de apenas testar por causa disso.

O teste baseado em metas funciona usando as seguintes etapas:

1. Definição de Metas de Desempenho: O primeiro passo envolve definir quais metas de desempenho são importantes para o sistema de software que está sendo testado. Essas metas podem incluir limites de tempo de resposta, requisitos de taxa de transferência, metas de utilização de recursos e benchmarks de escalabilidade.
2. Projetando cenários de teste: Os cenários de teste são projetados com base em suas metas de desempenho definidas. Esses cenários simulam diferentes comportamentos do usuário, cargas e configurações do sistema para avaliar o desempenho do software sob várias condições. Por exemplo, os cenários podem incluir períodos de pico de uso, cargas de transações pesadas ou picos repentinos na atividade do usuário.
3. Execução de Testes: Os cenários de teste são executados no sistema de software de acordo com os requisitos de teste. Durante essa fase, métricas de desempenho, como tempos de resposta, taxa de transferência, utilização de recursos e escalabilidade do sistema, são medidas e monitoradas.
4. Analisando Resultados e Melhorias: Os dados de desempenho coletados são analisados para avaliar se o sistema atende às metas predefinidas. Essa análise ajuda a identificar gargalos de desempenho, limitações de escalabilidade e áreas em que o sistema pode não atender aos requisitos de desempenho. Com base na análise dos resultados dos testes, faça as melhorias e otimizações necessárias no seu sistema de software.
5. Repetindo o processo: O teste de desempenho baseado em metas é um processo iterativo. Depois de fazer melhorias, o ciclo de testes é repetido para validar se as metas de desempenho foram alcançadas e identificar quaisquer novos problemas de desempenho que possam ter surgido.

Os testes de desempenho se concentram principalmente em verificar a velocidade e a confiabilidade de uma aplicação, divididos em testes de carga (que são orientados a objetivos) e testes de estresse. Com o surgimento de métodos de desenvolvimento ágil, tornou-se crucial garantir que os resultados dos testes de carga possam ser facilmente reproduzidos.

A Importância da Definição de Metas de Desempenho

A definição de metas de desempenho é a pedra angular dos testes de desempenho baseados em metas. Essas metas servem como parâmetro para medir o desempenho do software. Eles fornecem uma estrutura tangível para avaliar se o software atende aos seus requisitos de desempenho sob várias condições, incluindo uso normal, cargas de pico e cenários de estresse.

Principais razões para o teste de desempenho baseado em metas

• Alinhamento com as Expectativas dos Stakeholders: Ao definir metas de desempenho específicas, você garante que o desempenho do software esteja alinhado com as expectativas das partes interessadas, incluindo usuários finais, clientes e patrocinadores do projeto.
• Validando os requisitos de desempenho: O teste baseado em metas ajuda a validar se o software atende aos requisitos de desempenho, fornecendo métricas concretas para avaliar a adequação do desempenho.
• Otimizando a utilização de recursos: O teste baseado em metas ajuda a otimizar a utilização de recursos, identificando ineficiências ou superutilização dos recursos do sistema, levando a uma alocação de recursos mais eficiente e economia de custos.
• Escalabilidade: Ao medir o desempenho sob cargas crescentes ou simultaneidade de usuários, o teste baseado em metas avalia a escalabilidade do software, garantindo que ele possa lidar com bases de usuários e cargas de trabalho crescentes.
• Mitigação de Riscos: O teste proativo em relação a metas de desempenho predefinidas ajuda a identificar e mitigar riscos relacionados ao desempenho antes da implantação do software, reduzindo a probabilidade de tempo de inatividade, insatisfação do usuário ou perdas financeiras.

Caso de uso baseado em metas: problema

Suponha que 20 usuários simultâneos gerem 2.000 transações por hora em seu novo aplicativo CRM. Seu objetivo é elaborar um teste de desempenho garantindo um tempo de resposta de oito segundos para as próximas quatro versões. O teste de estresse pode não replicar com precisão a taxa de transferência esperada nessas próximas versões, pois os tempos de resposta podem variar da versão atual.

Caso de uso baseado em metas: solução

1. Integre o ThinkTimes em seus scripts para introduzir pausas entre as ações do usuário.
2. Determine a linha de base e meça o tempo de execução de scripts de usuário único para calcular o tempo de sessão.
3. Configure os parâmetros de carga de trabalho, incluindo o máximo de usuários, a taxa de transação baseada em metas e o tempo de transação baseado em metas.
4. Execute o teste de desempenho baseado em metas para simular a carga esperada no aplicativo.
5. Revise o relatório de teste para verificar se o aplicativo conseguiu lidar com a carga dentro dos limites de tempo de resposta predefinidos.
6. Repita a execução de teste nas quatro versões subsequentes para avaliar se o aplicativo mantém os limites de taxa de transferência e tempo de resposta ao longo do tempo.

Recomendações e dicas para configurar a ferramenta EveryStep do LoadView

ThinkTime (obrigatório):

• Crie novas palavras-chave no The EveryStep Web Recorder (ThinkTimes) ou reutilize palavras-chave existentes.
• Verifique se os valores permitidos são pontos flutuantes 0,0 – 999,99.
• Permitir que os usuários adicionem manualmente o ThinkTimes aos scripts.
• Lembre-se de que o ThinkTimes representa os tempos de espera e é adicionado automaticamente pelo EveryStep Web Recorder durante a gravação da ação do usuário.
• Vários ThinkTimes podem existir em um script.
• Os ThinkTimes são desconsiderados em execuções de teste de script único.
• O ThinkTimes será utilizado em Calibração/Get Baseline.
• Os ThinkTimes não contribuem para medições de tempo de resposta.
• Os ThinkTimes são ignorados nos testes de estresse.

Simultaneidade de usuário (opcional):

• Introduza uma nova palavra-chave “WaitFor (Número de usuários)” no EveryStep Web Recorder.
• Esse ponto de espera global bloqueia usuários simulados em uma seção de script específica até que o número esperado de usuários atinja essa parte do script.

Limites de Tempo de Resposta (opcional):

• Implemente a nova palavra-chave SetBoundary no EveryStep Web Recorder.
• Sintaxe: SetBoundary(Timername, Bound 1, Bound 2).

Linha de base/calibração (obrigatório):

• LoadView executa uma execução de teste de usuário único.
• O ThinkTimes será usado como script.
• LoadView calcula o tempo da sessão: Tempo da sessão = tempo de execução do script + ThinkTime.

Configurar Carga de Trabalho/Plano de Execução (obrigatório):

• Os clientes especificam o tempo de ramp-up.
• Os clientes definem sua taxa de transação de meta.
• Os clientes definem o tempo de sessão da meta.
• O sistema calcula o número de usuários.
• Os clientes decidem se calculam os tempos de resposta durante o ramp-up ou não.

Executar teste (obrigatório):

• O LoadView executa o teste de acordo com a carga de trabalho/plano de execução configurado.
• O LoadView coleta tempos de resposta de scripts ou transações simulados.
• O LoadView ajusta dinamicamente o ThinkTime para atingir a taxa de transferência esperada; se o aplicativo em teste ficar lento, os ThinkTimes serão reduzidos. Se o ThinkTimes for zero e o tempo de sessão exceder o tempo de sessão de meta, uma mensagem de erro será gerada indicando que a taxa de transferência esperada não pôde ser atingida.
• O LoadView calcula os tempos de resposta de transações reais e temporizadores sem o ThinkTimes.

Recomendações e dicas para integração com o Dotcom-Monitor

EveryStep Web Recorder

• Apresentando novas palavras-chave do ThinkTime.
• Ignore o ThinkTime durante execuções de teste de usuário único.
• Adicione o ThinkTime durante a gravação do script.
• Introduza a nova palavra-chave WaitFor(Number user).
• Introduza a nova palavra-chave SetBoundary(TimerName, B1, B2).
• A palavra-chave WaitFor deve ser adicionada manualmente aos scripts criados.
• Utilize a palavra-chave SetLimite.

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 Plano de execução pelo recurso Carga de trabalho.
• Crie uma caixa de diálogo Configuração de carga de trabalho para oferecer suporte a testes de estresse, metas de transação e outros tipos.
• Especifique o tempo de ramp-up.
• Marque a caixa para calcular os tempos de resposta durante o ramp-up (sim/não).

Opção 2:

• Use o recurso de configuração de plano de execução avançado.
• Selecione o tipo de teste (estresse, baseado em metas).
• Defina os detalhes da meta da transação.
• Especifique o tempo de ramp-up.
• Marque 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.
• Dispare um aviso se a taxa de transferência esperada não puder ser alcançada.

relatório

• Configure uma seção para tempo de resposta, limites reais versus limites por temporizador.
• Configure uma seção para taxa de transferência, real versus esperada.

Dicas para integração com o Dotcom-Monitor: perguntas frequentes

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 é Baseline?

Uma execução de usuário único do dispositivo ou script, incorporando o ThinkTimes. O tempo de execução do script é calculado e armazenado como tempo de sessão, juntamente com detalhes adicionais, como 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 simula cenários de usuário complexos, particularmente situações de simultaneidade, o que é útil para testar se determinada funcionalidade funciona corretamente com vários usuários acessando um recurso simultaneamente.

Qual é a palavra-chave SetBoundary?

Ajuda a verificar a velocidade real de uma determinada ação ou temporizador em relação aos limites de tempo de resposta do SLA especificados. Se o limite permitido for violado, uma mensagem de erro será exibida e registrada no relatório de teste, simplificando a verificação do SLA.

Quais devem ser seus objetivos para o teste de carga?

• Garanta testes de desempenho 100% comparáveis em diferentes versões/execuções.
• Inclua recursos para simular padrões de carga regulares ou de pico.
• Obtenha confiança de que o sistema em teste pode lidar com a carga esperada dentro dos limites acordados.
• Concentre a otimização do desempenho nas ações do usuário que violam os limites acordados.

Que tipo de relatórios você deve configurar?

• Crie relatórios semelhantes aos relatórios atuais.
• Inclua Avg, Min, Max, Stddev, Percentil de tempos de resposta.
• Rastrear transações ok, Transações com falha e Taxa de erro.
• Todos os tempos de resposta devem ser sem a inclusão do ThinkTimes.

Limitações

Tempos de sessão de meta altos podem levar a tempos limite de sessão e falsos positivos. É crucial considerar cenários em que os tempos limite da sessão da Web sejam baixos, garantindo que o ThinkTimes esteja adequadamente posicionado para evitar falhas devido a tempos limite de sessão.

O que acontecerá se não atingirmos a meta?

• Se o tempo de resposta de um aplicativo em teste de carga diminuir e o tempo de sessão exceder o tempo de sessão de meta, a taxa de transação esperada não poderá ser atingida.
• O LoadView monitora o tempo real da sessão durante a execução do teste e ajusta o ThinkTimes para tentar atingir a taxa de transação esperada com base em metas.
• LoadView exibe mensagens de erro na tela de monitoramento se o tempo da sessão exceder o tempo da sessão de meta.
• O LoadView continua a execução do teste se a taxa de transação de meta não puder ser atingida, marcando a execução do teste como falha e indicando os dispositivos afetados no relatório.

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

• 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