As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

Crie um cenário de teste

A criação de um cenário de teste envolve quatro etapas principais: definir configurações gerais, definir o cenário, moldar padrões de tráfego e revisar sua configuração.

Etapa 1: configurações gerais

Configure os parâmetros básicos para seu teste de carga, incluindo nome do teste, descrição e opções gerais de configuração.

Identificação do teste

Opções de agendamento

Configure quando o teste deve ser executado:

Fluxo de trabalho de agendamento

Quando você agenda um teste, ocorre o seguinte fluxo de trabalho:

Dados dinâmicos

Marque a caixa de seleção Incluir dados em tempo real para visualizar métricas em tempo real enquanto seu teste está sendo executado. Quando ativado, você pode monitorar:

O recurso de dados ao vivo fornece gráficos em tempo real com dados agregados em intervalos de um segundo. Para obter mais informações, consulte Monitoramento com dados em tempo real.

Etapa 2: Configuração do cenário

Defina o cenário de teste específico e selecione sua estrutura de teste preferida.

Seleção do tipo de teste

Escolha o tipo de teste de carga que você deseja realizar:

Modo de forma de tráfego

Escolha qual lado controla a carga que o teste gera. O modo selecionado altera os campos que o console mostra na Etapa 3: Forma do tráfego.

O Native exige um script carregado, portanto, você não pode selecioná-lo ao escolher o tipo de teste Simple HTTP Endpoint. Para obter as definições completas e orientações sobre qual modo escolher, consulte Modos de formato de tráfego.

Configuração de endpoint HTTP

Quando “Simple HTTP Endpoint” é selecionado, a solução gera um plano de teste do JMeter a partir da sua configuração e o executa com o binário Apache JMeter incluído. Defina estas configurações:

Scripts de estrutura de teste

Ao usar o JMeter, k6 ou Locust, carregue seu arquivo de script de teste ou um arquivo.zip contendo seu script de teste e arquivos de suporte.

Para o JMeter, você pode incluir plug-ins personalizados em uma /plugins pasta dentro do seu arquivo.zip.

Para o Locust, um script de teste dentro de um arquivo.zip deve ser nomeado. locustfile.py Para instalar pacotes Python de terceiros no contêiner em tempo de execução, inclua um requirements.txt arquivo no arquivo e, opcionalmente, um packages subdiretório de arquivos wheel para instalá-los sem acesso à Internet. Para obter mais informações, consulte Testes do Locust.

Duração da segurança (modo nativo)

Quando você seleciona o modo nativo, o console mostra um campo Duração de segurança ao lado do upload do script. O padrão é 4 horas e o máximo é 24 horas.

No modo nativo, a duração da segurança encerra um teste que é executado por mais tempo do que você pretendia, porque seu script decide quando a execução termina. É um guarda, não um cronograma. Se o teste ainda estiver em execução quando a duração terminar, a solução interromperá a estrutura de teste. Ele mantém os resultados da parte executada e registra a execução como concluída em vez de falhada. Defina-o acima da execução mais longa que você espera que o script precise.

Etapa 3: Forma do tráfego

Configure como o tráfego será distribuído durante o teste, incluindo suporte multirregional.

Modos de formato de tráfego

A solução oferece dois modos de formato de tráfego, Padrão e Nativo. Eles diferem em qual lado controla a carga: a solução ou o script que você carrega. Você seleciona o modo na Etapa 2: Configuração do cenário e ele determina quais dos campos abaixo se aplicam.

Padrão

O modo padrão coloca a solução no controle da carga. Você define o número de tarefas do Fargate por região, os usuários virtuais simultâneos por tarefa, um período de aceleração e uma duração de espera. A solução executa seu teste por meio da estrutura de automação Taurus, que traduz esses valores nos próprios controles de carga da estrutura subjacente. O Taurus tem precedência sobre qualquer carga declarada pelo script, portanto, um bloco de opções k6, um Locust LoadTestShape ou um grupo de threads do JMeter são reescritos ou ignorados. Os usuários virtuais de uma região são a contagem de tarefas multiplicada pela simultaneidade de cada tarefa, e a forma é a mesma, seja qual for a estrutura escolhida. É assim que todos os testes eram executados antes da versão 4.3.0, então os cenários criados anteriormente continuam se comportando exatamente como antes e não precisam de alterações.

Escolha Padrão quando a forma de carregamento estiver fora do script, definida pelo console, pela CLI ou por um agente. O Standard é o único modo que permite definir uma contagem exata de usuários virtuais e alterar a forma de aceleração e retenção sem tocar no script. Somente o Standard oferece suporte ao tipo Simple HTTP Endpoint, em que a solução gera o plano de teste para você. Usos típicos: uma verificação de capacidade de 500 a 5.000 usuários virtuais, uma regressão noturna com 1.000 usuários por dez minutos ou qualquer comparação que precise de uma rampa idêntica. Seu limite é a expressividade. Qualquer coisa que o Taurus não possa representar não está disponível aqui, incluindo vários cenários ponderados, limites por estágio e executores de taxa de chegada.

Nativo

O modo nativo coloca seu script no controle do carregamento. A solução executa o arquivo que você carregou na própria linha de comando da estrutura:jmeter -n -t,k6 run, oulocust --headless. Ele não passa por sinalizadores de carregamento, então seu script é a única autoridade sobre o tráfego que ele gera e a solução nunca o reescreve. Restam dois controles: quantas tarefas do Fargate iniciar por região e uma duração de segurança necessária de até 24 horas. A duração da segurança protege contra um script que nunca existe, não contra um cronograma. Se um teste ainda estiver em execução quando a duração terminar, a solução interrompe a estrutura, coleta os resultados da parte executada e registra a execução como concluída em vez de falhada. Cada tarefa é executada como um processo de estrutura independente, sem coordenação entre as tarefas, portanto, uma região gera uma cópia completa da carga declarada do seu script para cada tarefa. Por exemplo, um script k6 que contém 200 usuários virtuais, executado em cinco tarefas, coloca 1.000 usuários virtuais no alvo. A contagem de tarefas é, portanto, o único controle de carga que o Native oferece, e ela se move em múltiplos inteiros de tudo o que o script declara. Alterar a rampa, o tempo de espera ou a contagem de usuários virtuais em si significa editar o script.

Escolha Nativo quando quiser executar um script exatamente como ele foi escrito. Um script que já é executado localmente ou em CI é executado inalterado na solução, o que é o principal motivo para procurar o Native. O Native preserva tudo o que a estrutura pode expressar: cenários, estágios e limites do K6; LoadTestShape classes Locust e conjuntos de tarefas ponderadas; temporizadores do JMeter e grupos de threads. Escolha-o quando o formato da carga fizer parte do significado do teste, e reproduzi-lo fielmente importa mais do que dirigi-lo de fora. Usos típicos: reutilizar um script k6 de um pipeline sem reescrevê-lo, um perfil de pico e depois recuperação ou cenários ponderados que um único número de simultaneidade não pode expressar. Duas restrições decorrem da execução da estrutura conforme criada. O Native requer um script carregado, portanto, o Simple HTTP Endpoint não está disponível. Os scripts do Locust não devem ser definidosprocesses, pois a solução conta as solicitações somente quando o Locust é executado como um único processo.

Escolher um modo

Multi-Region configuração de tráfego

Selecione uma ou mais regiões da AWS para distribuir geograficamente seu teste de carga. Para cada região selecionada, configure:

Determine o número de usuários

O número de usuários que um contêiner pode suportar para um teste pode ser determinado aumentando gradualmente o número de usuários e monitorando o desempenho na Amazon CloudWatch. Depois de observar que o desempenho da CPU e da memória está se aproximando de seus limites, você atingiu o número máximo de usuários que um contêiner pode suportar para esse teste em sua configuração padrão (2 vCPUs e 4 GB de memória).

Essa calibragem define o valor de simultaneidade, portanto, ela se aplica ao modo Padrão. Os limites de contêiner que ele estabelece também se aplicam ao modo nativo. Lá, você aumenta ou diminui a carga declarada pelo script, em vez de definir o campo Simultaneidade.

Processo de calibração

Você pode começar a determinar os limites de usuários simultâneos para seu teste usando o exemplo a seguir:

Repita as etapas 1 a 3 se o teste não tiver excedido os limites de recursos. Opcionalmente, você pode aumentar os recursos do contêiner para permitir um número maior de usuários simultâneos. No entanto, isso resulta em um custo maior. Para obter detalhes, consulte o Guia do desenvolvedor.

Para obter mais informações sobre como calibrar usuários por mecanismo, consulte Calibrando um teste Taurus na documentação. BlazeMeter

Tabela de tarefas disponíveis

A Tabela de Tarefas Disponíveis exibe a disponibilidade de recursos para cada região selecionada:

Para aumentar o número de tarefas disponíveis ou vCPUs por tarefa, consulte o Guia do desenvolvedor.

Duração do teste

Defina por quanto tempo seu teste de carga será executado. O console mostra essa seção somente no modo Padrão. No modo nativo, seu script determina por quanto tempo o teste é executado, limitado pela duração de segurança definida na Etapa 2: Configuração do cenário.

Etapa 4: revisar e criar

Analise todas as suas configurações antes de criar o cenário de teste. Verificar:

Depois de analisar, escolha Criar para salvar seu cenário de teste.

Gerenciando cenários de teste

Depois de criar um cenário de teste, você pode: