Teste de Performance Baseado em Objetivos

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 específicos de desempenho sob várias condições. No teste de desempenho baseado em metas, o processo de teste é guiado por metas ou objetivos predefinidos em vez de simplesmente testar por testar.

O teste baseado em metas funciona usando os seguintes passos:

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. Desenho de Cenários de Teste: Os cenários de teste são desenhados com base nas metas de desempenho definidas. Esses cenários simulam diferentes comportamentos de usuários, cargas e configurações de sistema para avaliar como o software se comporta sob várias condições. Por exemplo, cenários podem incluir períodos de uso máximo, cargas pesadas de transações ou picos súbitos na atividade dos usuários.
3. Execução dos Testes: Os cenários de teste são executados contra o sistema de software sob os requisitos de teste. Durante esta 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. Análise dos Resultados e Melhoria: Os dados coletados sobre desempenho 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 onde o sistema pode falhar em atender aos requisitos de desempenho. Com base na análise dos resultados do teste, faça as melhorias e otimizações necessárias no seu sistema de software.
5. Repetição do Processo: O teste de desempenho baseado em metas é um processo iterativo. Após fazer melhorias, o ciclo de teste é repetido para validar se as metas de desempenho foram alcançadas e para identificar quaisquer novos problemas de desempenho que possam ter surgido.

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

A Importância de Definir Metas de Desempenho

Definir metas de desempenho é a pedra fundamental do teste de desempenho baseado em metas. Essas metas servem como a referência contra a qual o desempenho do software é medido. Elas proporcionam um quadro tangível para avaliar se o software atende aos seus requisitos de desempenho sob diversas condições, incluindo uso normal, cargas máximas e cenários de estresse.

Principais Razões para Teste de Desempenho Baseado em Metas

• Alinhamento com as Expectativas dos Interessados: Ao definir metas específicas de desempenho, você garante que o desempenho do seu software esteja alinhado com as expectativas dos interessados, incluindo usuários finais, clientes e patrocinadores do projeto.
• Validação dos Requisitos de Desempenho: O teste baseado em metas ajuda a validar se seu software atende aos seus requisitos de desempenho, fornecendo métricas concretas para avaliar a adequação do desempenho.
• Otimização da Utilização de Recursos: O teste baseado em metas ajuda a otimizar a utilização de recursos identificando ineficiências ou sobreutilização dos recursos do sistema, levando a uma alocação mais eficiente e redução de custos.
• Escalabilidade: Medindo o desempenho sob cargas crescentes ou concorrência de usuários, o teste baseado em metas avalia a escalabilidade do seu software, garantindo que ele possa suportar bases de usuários e cargas de trabalho crescentes.
• Mitigação de Riscos: Testar proativamente contra metas de desempenho predefinidas ajuda a identificar e mitigar riscos relacionados ao desempenho antes do software ser implantado, reduzindo a probabilidade de tempo de inatividade, insatisfação dos usuários ou perdas financeiras.

Exemplo de Caso de Uso Baseado em Metas: Problema

Suponha que 20 usuários concorrentes gerem 2.000 transações por hora em sua nova aplicação CRM. Seu objetivo é elaborar um teste de desempenho garantindo um tempo de resposta de oito segundos para as próximas quatro versões. Testes de estresse podem não replicar precisamente a taxa de transferência esperada nessas próximas versões, já que os tempos de resposta podem variar da versão atual.

Exemplo de Caso de Uso Baseado em Metas: Solução

1. Integre ThinkTimes em seus scripts para introduzir pausas entre ações de usuários.
2. Determine a linha de base e meça o tempo de execução dos scripts de um único usuário para calcular o tempo da sessão.
3. Configure os parâmetros da carga de trabalho, incluindo número máximo de usuários, taxa de transações 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 na aplicação.
5. Revise o relatório do teste para verificar se a aplicação conseguiu manejar a carga dentro dos limites predefinidos de tempo de resposta.
6. Repita a execução do teste nas próximas quatro versões para avaliar se a aplicação 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 EveryStep Web Recorder (ThinkTimes) ou reutilize palavras-chave existentes.
• Garanta que os valores permitidos sejam pontos flutuantes entre 0,0 e 999,99.
• Permita que os usuários adicionem manualmente ThinkTimes aos scripts.
• Lembre-se que ThinkTimes representa tempos de espera e é adicionado automaticamente pelo EveryStep Web Recorder durante a gravação de ações do usuário.
• Podem existir múltiplos ThinkTimes em um único script.
• ThinkTimes são desconsiderados em execuções de teste com script único.
• ThinkTimes serão utilizados na Calibração/Obtenção da Linha de Base.
• ThinkTimes não contribuem para as medições de tempo de resposta.
• ThinkTimes são ignorados em testes de estresse.

Concorrência de Usuários (opcional):

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

Limites de Tempo de Resposta (opcional):

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

Linha de Base/Calibração (obrigatório):

• LoadView executa uma execução de teste com um único usuário.
• ThinkTimes serão usados conforme script.
• LoadView calcula o tempo da sessão: Tempo da Sessão = tempo de execução do script + ThinkTime.

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

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

Executar Teste (obrigatório):

• LoadView executa o teste conforme a carga de trabalho/plano de execução configurado.
• LoadView coleta os tempos de resposta dos scripts ou transações simuladas.
• LoadView ajusta dinamicamente o ThinkTime para alcançar a taxa de transferência esperada; se a aplicação sob teste desacelerar, os ThinkTimes são reduzidos. Se os ThinkTimes forem zero e o tempo da sessão exceder o tempo da sessão objetivo, uma mensagem de erro é exibida indicando que a taxa de transferência esperada não pôde ser alcançada.
• LoadView calcula os tempos de resposta das transações e timers reais sem ThinkTimes.

Recomendações e Dicas para Integração com Dotcom-Monitor

EveryStep Web Recorder

• Introdução de novas palavras-chave ThinkTime.
• Ignorar ThinkTime durante execuções de teste com usuário único.
• Adicionar ThinkTime durante a gravação de scripts.
• Introdução da nova palavra-chave WaitFor(Número de usuários).
• Introdução da nova palavra-chave SetBoundary(NomeDoTimer, L1, L2).
• A palavra-chave WaitFor deve ser adicionada manualmente aos scripts criados.
• Utilizar a palavra-chave SetBoundary.

Calibração/Obtenção da Linha de Base

• Calcular o tempo da sessão durante a calibração.

Plano de Execução/Carga de Trabalho

Opção 1:

• Adicionar uma nova funcionalidade de configuração de carga de trabalho.
• Substituir o plano de execução pela funcionalidade de carga de trabalho.
• Criar um diálogo de configuração de carga de trabalho para suportar testes de estresse, metas de transação e outros tipos.
• Especificar o tempo de ramp-up.
• Marcar a caixa para calcular tempos de resposta durante o ramp-up (sim/não).

Opção 2:

• Usar a funcionalidade aprimorada de configuração do plano de execução.
• Selecionar o tipo de teste (estresse, baseado em metas).
• Configurar os detalhes da meta de transação.
• Especificar o tempo de ramp-up.
• Marcar a caixa para calcular tempos de resposta durante o ramp-up (sim/não).

Executar Teste

• Calcular o tempo real de execução do script/tempo da sessão.
• Ajustar dinamicamente os ThinkTimes com base no tempo real da sessão.
• Exibir um alerta se a taxa de transferência esperada não puder ser alcançada.

Relatório

• Configurar uma seção para tempo de resposta, real vs. limites por timer.
• Configurar uma seção para taxa de transferência, real vs. esperada.

Dicas para Integração com Dotcom-Monitor: FAQ

Quais são as Entradas do Usuário?

• ThinkTimes (ponto flutuante, >0)
• Transações Objetivo por hora (inteiro)
• Número máximo de usuários (inteiro)
• Tempo de ramp-up (minutos)
• Calcular tempo de resposta durante o ramp-up (Sim / Não)

O que é Linha de Base?

Uma execução de usuário único do dispositivo ou script, incorporando ThinkTimes. O tempo de execução do script é calculado e armazenado como tempo de sessão, junto com detalhes adicionais como recursos necessários para execução.

Como ajustar dinamicamente o teste de carga se a velocidade da transação mudar no sistema alvo?

• Calcular o tempo da sessão durante a calibração
• Usar ThinkTimes para alcançar o tempo de sessão objetivo solicitado
• Recalcular o tempo real da sessão durante a execução do teste
• Ajustar dinamicamente os ThinkTimes dependendo do tempo real da sessão
• Registrar mensagem de erro se o tempo de execução do script for > tempo da sessão objetivo
• Especificar o número máximo de usuários no cálculo da carga

O que é a palavra-chave WaitFor?

Ela simula cenários complexos de usuário, particularmente situações de concorrência, o que é útil para testar se certa funcionalidade funciona corretamente com vários usuários acessando simultaneamente um recurso.

O que é a palavra-chave SetBoundary?

Ajuda a verificar a velocidade real de uma determinada ação ou timer contra limites de tempo de resposta SLA especificados. Se o limite permitido for violado, uma mensagem de erro aparece e é registrada no relatório de teste, simplificando a verificação do SLA.

Quais devem ser suas metas para seu teste de carga?

• Garantir testes de desempenho 100% comparáveis entre diferentes versões/execuções.
• Incluir funcionalidades para simular padrões regulares ou picos de carga.
• Alcançar confiança de que o sistema sob teste pode lidar com a carga esperada dentro dos limites acordados.
• Focar otimização de desempenho nas ações do usuário que violam os limites acordados.

Que tipo de relatórios você deve configurar?

• Criar relatórios semelhantes aos atuais.
• Incluir tempos de resposta médio, mínimo, máximo, desvio padrão, percentil.
• Rastrear Transações ok, Transações falhadas e Taxa de erro.
• Todos os tempos de resposta devem ser sem a inclusão dos ThinkTimes.

Limitações

Tempos elevados de sessão objetivo podem levar a timeout de sessão e falsos positivos. É crucial considerar cenários onde os timeouts de sessão web são baixos, garantindo que ThinkTimes estejam corretamente posicionados para evitar falhas devido a timeouts de sessão.

O que acontece se não atingirmos a meta?

• Se o tempo de resposta de uma aplicação sob teste de carga desacelerar e o tempo da sessão exceder o tempo da sessão objetivo, a taxa de transação esperada não poderá ser alcançada.
• LoadView monitora o tempo real da sessão durante a execução do teste e ajusta os ThinkTimes para tentar atingir a taxa de transação baseada em metas esperada.
• LoadView exibe mensagens de erro na tela de monitoramento se o tempo da sessão exceder o tempo da sessão objetivo.
• LoadView continua a execução do teste se a taxa de transação objetivo não puder ser alcançada, marcando a execução do teste como falhada e indicando os dispositivos afetados no relatório.

Como é uma carga de trabalho baseada em metas típica?

• Tempo de ramp-up: 15 minutos
• Medir tempos de resposta durante o ramp-up: Sim / Não
  ST: Tempo da Sessão
• GST: Tempo da Sessão Objetivo
• TPH: Transações por hora
• Usuário: Calculado pelo LoadView (3600 / TPH) * GST = 72