3. Elementos de um Plano de Teste

3.0 Plano de Teste ¶

O objeto Plano de Testes possui uma caixa de seleção chamada " Teste Funcional ". Se selecionado, fará com que o JMeter registre os dados retornados do servidor para cada amostra. Se você selecionou um arquivo em seus ouvintes de teste, esses dados serão gravados no arquivo. Isso pode ser útil se você estiver fazendo uma pequena execução para garantir que o JMeter esteja configurado corretamente e que seu servidor esteja retornando os resultados esperados. A consequência é que o arquivo ficará enorme rapidamente e o desempenho do JMeter será prejudicado. Esta opção deve estar desativada se você estiver fazendo testes de estresse (ela está desativada por padrão).

Se você não estiver gravando os dados em um arquivo, esta opção não fará diferença.

Você também pode usar o botão Configuração em um ouvinte para decidir quais campos salvar.

3.1 Grupo de Threads ¶

Os elementos do grupo de threads são os pontos iniciais de qualquer plano de teste. Todos os controladores e amostradores devem estar em um grupo de threads. Outros elementos, por exemplo, Listeners, podem ser colocados diretamente sob o plano de teste, caso em que serão aplicados a todos os grupos de threads. Como o nome indica, o elemento do grupo de threads controla o número de threads que o JMeter usará para executar seu teste. Os controles para um grupo de threads permitem que você:

• Defina o número de threads
• Defina o período de aceleração
• Defina o número de vezes para executar o teste

Cada thread executará o plano de teste em sua totalidade e de forma totalmente independente de outros threads de teste. Vários encadeamentos são usados ​​para simular conexões simultâneas com seu aplicativo de servidor.

O período de aceleração informa ao JMeter quanto tempo levará para "acelerar" o número total de threads escolhidos. Se 10 threads forem usados ​​e o período de aceleração for de 100 segundos, o JMeter levará 100 segundos para colocar todos os 10 threads em execução. Cada encadeamento iniciará 10 (100/10) segundos após o início do encadeamento anterior. Se houver 30 encadeamentos e um período de aceleração de 120 segundos, cada encadeamento sucessivo será atrasado em 4 segundos.

A aceleração precisa ser longa o suficiente para evitar uma carga de trabalho muito grande no início de um teste e curta o suficiente para que os últimos threads comecem a ser executados antes que os primeiros terminem (a menos que alguém queira que isso aconteça).

Comece com Ramp-up = número de threads e ajuste para cima ou para baixo conforme necessário.

Por padrão, o grupo de threads é configurado para fazer um loop por seus elementos.

Thread Group também permite especificar o tempo de vida do Thread . Clique na caixa de seleção na parte inferior do painel Thread Group para ativar/desativar campos extras nos quais você pode inserir a duração do teste e o atraso na inicialização Você pode configurar a Duração (segundos) e o Atraso na inicialização (segundos) para controlar a duração de cada thread grupo e depois de quantos segundos ele inicia. Quando o teste for iniciado, o JMeter aguardará o Atraso de Inicialização (segundos) antes de iniciar os Threads do Grupo de Threads e executará pelo tempo de Duração (segundos) configurado .

3.2 Controladores ¶

O JMeter possui dois tipos de Controladores: Samplers e Controladores Lógicos. Estes conduzem o processamento de um teste.

Os samplers dizem ao JMeter para enviar solicitações para um servidor. Por exemplo, inclua um HTTP Request Sampler se desejar que o JMeter envie um pedido HTTP. Você também pode personalizar uma solicitação adicionando um ou mais elementos de configuração a um amostrador. Para obter mais informações, consulte Amostradores .

Os Controladores Lógicos permitem que você personalize a lógica que o JMeter usa para decidir quando enviar solicitações. Por exemplo, você pode adicionar um Interleave Logic Controller para alternar entre dois HTTP Request Samplers. Para obter mais informações, consulte Controladores lógicos .

3.2.1 Amostradores ¶

Os samplers dizem ao JMeter para enviar solicitações a um servidor e aguardar uma resposta. Eles são processados ​​na ordem em que aparecem na árvore. Os controladores podem ser usados ​​para modificar o número de repetições de um amostrador.

Os amostradores JMeter incluem:

• Solicitação de FTP
• Solicitação HTTP (pode ser usado para SOAP ou REST Webservice também)
• Solicitação JDBC
• solicitação de objeto Java
• Solicitação JMS
• Solicitação de teste JUnit
• Solicitação LDAP
• Solicitação de e-mail
• Solicitação de processo do SO
• solicitação TCP

Se você for enviar várias solicitações do mesmo tipo (por exemplo, solicitação HTTP) para o mesmo servidor, considere usar um elemento de configuração padrão. Cada controlador tem um ou mais elementos Defaults (veja abaixo).

Lembre-se de adicionar um Listener ao seu plano de teste para visualizar e/ou armazenar os resultados de suas solicitações em disco.

Se você estiver interessado em que o JMeter execute uma validação básica na resposta de sua solicitação, adicione uma Asserção ao amostrador. Por exemplo, no teste de estresse de um aplicativo da Web, o servidor pode retornar um código de "Resposta HTTP" bem-sucedido, mas a página pode conter erros ou ter seções ausentes. Você pode adicionar asserções para verificar determinadas tags HTML, strings de erro comuns e assim por diante. O JMeter permite criar essas asserções usando expressões regulares.

Amostradores integrados do JMeter

3.2.2 Controladores Lógicos ¶

Os controladores lógicos permitem personalizar a lógica que o JMeter usa para decidir quando enviar solicitações. Os controladores lógicos podem alterar a ordem das solicitações provenientes de seus elementos filhos. Eles podem modificar os próprios pedidos, fazer com que o JMeter repita os pedidos, etc.

Para entender o efeito dos controladores lógicos em um plano de teste, considere a seguinte árvore de teste:

• Plano de teste
• Grupo de tópicos
• Uma vez apenas controlador
• Solicitação de login (uma solicitação HTTP )
• Carregar página de pesquisa (amostrador HTTP)
• Controlador de intercalação
• Pesquisar "A" (Amostrador HTTP)
• Pesquisar "B" (Amostrador HTTP)
• Solicitação padrão HTTP (elemento de configuração)
• Solicitação padrão HTTP (elemento de configuração)
• Gerenciador de cookies (elemento de configuração)

A primeira coisa sobre este teste é que a solicitação de login será executada apenas na primeira vez. As iterações subsequentes irão ignorá-lo. Isso se deve aos efeitos do Once Only Controller .

Após o login, o próximo Sampler carrega a página de pesquisa (imagine um aplicativo da web onde o usuário efetua login e depois vai para uma página de pesquisa para fazer uma pesquisa). Esta é apenas uma solicitação simples, não filtrada por nenhum Controlador Lógico.

Depois de carregar a página de pesquisa, queremos fazer uma pesquisa. Na verdade, queremos fazer duas pesquisas diferentes. No entanto, queremos recarregar a própria página de pesquisa entre cada pesquisa. Poderíamos fazer isso com 4 elementos de solicitação HTTP simples (pesquisa de carregamento, pesquisa "A", pesquisa de carregamento, pesquisa "B"). Em vez disso, usamos o Interleave Controller que transmite uma solicitação filho a cada vez através do teste. Ele mantém a ordenação (ou seja, não passa um aleatoriamente, mas "lembra" seu lugar) de seus elementos filhos. Intercalar 2 solicitações filho pode ser um exagero, mas poderia facilmente ter havido 8 ou 20 solicitações filho.

Observe os padrões de solicitação HTTPque pertence ao Controlador Interleave. Imagine que "Pesquisa A" e "Pesquisa B" compartilham as mesmas informações de PATH (uma especificação de solicitação HTTP inclui domínio, porta, método, protocolo, caminho e argumentos, além de outros itens opcionais). Isso faz sentido - ambos são solicitações de pesquisa, atingindo o mesmo mecanismo de pesquisa de back-end (um servlet ou script cgi, digamos). Em vez de configurar ambos os amostradores HTTP com as mesmas informações em seu campo PATH, podemos abstrair essas informações para um único elemento de configuração. Quando o Interleave Controller "transmitir" solicitações de "Pesquisa A" ou "Pesquisa B", ele preencherá os espaços em branco com valores do Elemento de configuração de solicitação padrão HTTP. Então, deixamos o campo PATH em branco para essas solicitações, e coloque essas informações no elemento de configuração. Nesse caso, esse é um benefício menor, na melhor das hipóteses, mas demonstra o recurso.

O próximo elemento na árvore é outra solicitação padrão HTTP, desta vez adicionada ao próprio Grupo de Threads. O Grupo de Threads possui um Controlador Lógico integrado e, portanto, utiliza este Elemento de Configuração exatamente como descrito acima. Ele preenche os espaços em branco de qualquer solicitação que passar. É extremamente útil em testes da Web deixar o campo DOMAIN em branco em todos os elementos do HTTP Sampler e, em vez disso, colocar essas informações em um elemento de solicitação padrão HTTP, adicionado ao Grupo de threads. Ao fazer isso, você pode testar seu aplicativo em um servidor diferente simplesmente alterando um campo em seu Plano de Teste. Caso contrário, você teria que editar cada Sampler.

O último elemento é um gerenciador de cookies HTTP . Um gerenciador de cookies deve ser adicionado a todos os testes da web - caso contrário, o JMeter ignorará os cookies. Ao adicioná-lo no nível do Thread Group, garantimos que todas as solicitações HTTP compartilharão os mesmos cookies.

Os controladores lógicos podem ser combinados para obter vários resultados. Consulte a lista de controladores lógicos integrados .

3.2.3 Fragmentos de Teste ¶

O elemento Fragmento de Teste é um tipo especial de controlador que existe na árvore do Plano de Teste no mesmo nível do elemento Grupo de Encadeamento. Ele se distingue de um Thread Group por não ser executado a menos que seja referenciado por um Module Controller ou um Include_Controller .

Este elemento é puramente para reutilização de código nos Planos de Teste

3.3 Ouvintes ¶

Os ouvintes fornecem acesso às informações que o JMeter reúne sobre os casos de teste enquanto o JMeter é executado. O ouvinte Graph Results traça os tempos de resposta em um gráfico. O Ouvinte "Exibir Árvore de Resultados" mostra detalhes de solicitações e respostas do amostrador e pode exibir representações HTML e XML básicas da resposta. Outros ouvintes fornecem informações de resumo ou agregação.

Além disso, os ouvintes podem direcionar os dados para um arquivo para uso posterior. Cada ouvinte no JMeter fornece um campo para indicar o arquivo para armazenar os dados. Há também um botão de configuração que pode ser usado para escolher quais campos salvar e se usar o formato CSV ou XML.

Os ouvintes podem ser adicionados em qualquer lugar do teste, inclusive diretamente no plano de teste. Eles coletarão dados apenas de elementos em seu nível ou abaixo dele.

Existem vários ouvintes que vêm com o JMeter.

3.4 Temporizadores ¶

Por padrão, um thread JMeter executa amostradores em sequência sem pausa. Recomendamos que você especifique um atraso adicionando um dos temporizadores disponíveis ao seu grupo de threads. Se você não adicionar um atraso, o JMeter pode sobrecarregar seu servidor fazendo muitas solicitações em um período de tempo muito curto.

Um temporizador fará com que o JMeter atrase uma certa quantidade de tempo antes de cada amostrador que está em seu escopo .

Se você optar por adicionar mais de um cronômetro a um Grupo de Threads, o JMeter obtém a soma dos cronômetros e pausa por esse período de tempo antes de executar os amostradores aos quais os cronômetros se aplicam. Os temporizadores podem ser adicionados como filhos de amostradores ou controladores para restringir os amostradores aos quais são aplicados.

Para fornecer uma pausa em um único local em um plano de teste, pode-se usar o Flow Control Action Sampler.

3.5 Asserções ¶

Asserções permitem afirmar fatos sobre as respostas recebidas do servidor que está sendo testado. Usando uma asserção, você pode essencialmente "testar" se seu aplicativo está retornando os resultados esperados.

Por exemplo, você pode afirmar que a resposta a uma consulta conterá algum texto específico. O texto especificado pode ser uma expressão regular no estilo Perl e você pode indicar que a resposta deve conter o texto ou que deve corresponder à resposta inteira.

Você pode adicionar uma declaração a qualquer Sampler. Por exemplo, você pode adicionar uma declaração a uma solicitação HTTP que verifica o texto " </HTML> ". O JMeter então verificará se o texto está presente na resposta HTTP. Se o JMeter não encontrar o texto, ele marcará isso como uma solicitação com falha.

Para visualizar os resultados da asserção, adicione um Ouvinte de Asserção ao Grupo de Encadeamento. Asserções com falha também serão exibidas na visualização em árvore e nos ouvintes de tabela e contarão para o erro %age, por exemplo, nos relatórios Agregado e Resumo.

3.6 Elementos de Configuração ¶

Um elemento de configuração funciona de perto com um Sampler. Embora não envie solicitações (exceto para HTTP(S) Test Script Recorder ), ele pode adicionar ou modificar solicitações.

Um elemento de configuração é acessível apenas de dentro da ramificação da árvore onde você coloca o elemento. Por exemplo, se você colocar um HTTP Cookie Manager dentro de um Simple Logic Controller, o Cookie Manager só estará acessível aos HTTP Request Controllers que você colocar dentro do Simple Logic Controller (veja a figura 1). O Cookie Manager é acessível às solicitações HTTP "Página da Web 1" e "Página da Web 2", mas não "Página da Web 3".

Além disso, um elemento de configuração dentro de uma ramificação de árvore tem maior precedência do que o mesmo elemento em uma ramificação "pai". Por exemplo, definimos dois elementos HTTP Request Defaults, "Web Defaults 1" e "Web Defaults 2". Como colocamos "Web Defaults 1" dentro de um Loop Controller, apenas "Web Page 2" pode acessá-lo. As outras requisições HTTP usarão "Web Defaults 2", já que o colocamos no Thread Group (o "pai" de todas as outras ramificações).

3.7 Elementos do Pré-Processador ¶

Um pré-processador executa alguma ação antes de uma solicitação de amostrador ser feita. Se um pré-processador estiver conectado a um elemento do amostrador, ele será executado imediatamente antes da execução desse elemento do amostrador. Um pré-processador é usado com mais frequência para modificar as configurações de uma solicitação de amostra logo antes de ser executada ou para atualizar variáveis ​​que não são extraídas do texto de resposta. Consulte as regras de escopo para obter mais detalhes sobre quando os pré-processadores são executados.

3.8 Elementos de Pós-Processador ¶

Um pós-processador executa alguma ação após a solicitação do amostrador. Se um pós-processador estiver conectado a um elemento de amostrador, ele será executado logo após a execução desse elemento de amostrador. Um pós-processador é mais frequentemente usado para processar os dados de resposta, geralmente para extrair valores deles. Consulte as regras de escopo para obter mais detalhes sobre quando os pós-processadores são executados.

3.9 Ordem de execução ¶

0. Elementos de configuração
1. Pré-processadores
2. Temporizadores
3. Amostrador
4. Pós-processadores (a menos que SampleResult seja null )
5. Asserções (a menos que SampleResult seja null )
6. Ouvintes (a menos que SampleResult seja null )

Por exemplo, no seguinte plano de teste:

• Controlador
• Pós-processador 1
• Amostrador 1
• Amostrador 2
• Temporizador 1
• Asserção 1
• Pré-processador 1
• Temporizador 2
• Pós-processador 2

Pré-processador 1
Temporizador 1
Temporizador 2
Amostrador 1
Pós-processador 1
Pós-processador 2
Asserção 1

Pré-processador 1
Temporizador 1
Temporizador 2
Amostrador 2
Pós-processador 1
Pós-processador 2
Asserção 1

3.10 Regras de Escopo ¶

A árvore de teste JMeter contém elementos que são hierárquicos e ordenados. Alguns elementos nas árvores de teste são estritamente hierárquicos (ouvintes, elementos de configuração, pós-processadores, pré-processadores, asserções, temporizadores) e alguns são ordenados principalmente (controladores, amostradores). Ao criar seu plano de teste, você criará uma lista ordenada de solicitações de amostra (via Samplers) que representam um conjunto de etapas a serem executadas. Essas solicitações geralmente são organizadas em controladores que também são solicitados. Dada a seguinte árvore de teste:

A ordem dos pedidos será: Um, Dois, Três, Quatro.

Alguns controladores afetam a ordem de seus subelementos, e você pode ler sobre esses controladores específicos na referência do componente .

Outros elementos são hierárquicos. Uma Asserção, por exemplo, é hierárquica na árvore de teste. Se seu pai for uma solicitação, ele será aplicado a essa solicitação. Se seu pai for um Controlador, isso afetará todas as solicitações descendentes desse Controlador. Na seguinte árvore de teste:

A Asserção nº 1 é aplicada apenas à Solicitação Um, enquanto a Asserção nº 2 é aplicada às Solicitações Dois e Três.

Outro exemplo, desta vez usando Timers:

Neste exemplo, as solicitações são nomeadas para refletir a ordem em que serão executadas. O temporizador nº 1 será aplicado às solicitações dois, três e quatro (observe como a ordem é irrelevante para elementos hierárquicos). A Asserção nº 1 se aplicará apenas à Solicitação Três. O temporizador #2 afetará todas as solicitações.

Espero que esses exemplos deixem claro como os elementos de configuração (hierárquicos) são aplicados. Se você imaginar cada Request sendo passado pelas ramificações da árvore, para seu pai, então para o pai de seu pai, etc., e cada vez coletando todos os elementos de configuração desse pai, então você verá como ele funciona.

3.11 Propriedades e Variáveis ​​¶

As propriedades do JMeter são definidas em jmeter.properties (consulte Introdução - Configurando o JMeter para obter mais detalhes).
As propriedades são globais para o jmeter e são usadas principalmente para definir alguns dos padrões que o JMeter usa. Por exemplo, a propriedade remote_hosts define os servidores que o JMeter tentará executar remotamente. As propriedades podem ser referenciadas em planos de teste - consulte Funções - leia uma propriedade - mas não podem ser usadas para valores específicos de thread.

As variáveis ​​JMeter são locais para cada encadeamento. Os valores podem ser os mesmos para cada thread ou podem ser diferentes.
Se uma variável for atualizada por um encadeamento, somente a cópia do encadeamento da variável será alterada. Por exemplo, o Pós-Processador Extrator de Expressão Regular definirá suas variáveis ​​de acordo com a amostra que seu encadeamento leu, e estas podem ser usadas posteriormente pelo mesmo encadeamento. Para obter detalhes sobre como fazer referência a variáveis ​​e funções, consulte Funções e variáveis

Observe que os valores definidos pelo Plano de Teste e pelo elemento de configuração Variáveis ​​Definidas pelo Usuário são disponibilizados para todo o plano de teste na inicialização. Se a mesma variável for definida por vários elementos UDV, o último terá efeito. Uma vez que um encadeamento é iniciado, o conjunto inicial de variáveis ​​é copiado para cada encadeamento. Outros elementos como o Pré-Processador de Parâmetros do Usuário ou o Pós-Processador Extrator de Expressões Regulares podem ser usados ​​para redefinir as mesmas variáveis ​​(ou criar novas). Essas redefinições se aplicam apenas ao segmento atual.

A função setProperty pode ser usada para definir uma propriedade JMeter. Eles são globais para o plano de teste, portanto, podem ser usados ​​para passar informações entre threads - caso seja necessário.

3.12 Usando Variáveis ​​para parametrizar testes ¶

As variáveis ​​não precisam variar - elas podem ser definidas uma vez e, se deixadas sozinhas, não mudarão de valor. Assim, você pode usá-los como abreviação de expressões que aparecem com frequência em um plano de teste. Ou para itens que são constantes durante uma corrida, mas que podem variar entre as corridas. Por exemplo, o nome de um host ou o número de encadeamentos em um grupo de encadeamentos.

Ao decidir como estruturar um Plano de Teste, anote quais itens são constantes para a execução, mas quais podem ser alterados entre as execuções. Decida sobre alguns nomes de variáveis ​​para elas - talvez use uma convenção de nomenclatura, como prefixá-las com C_ ou K_ ou usar letras maiúsculas apenas para distingui-las das variáveis ​​que precisam ser alteradas durante o teste. Considere também quais itens precisam ser locais para um encadeamento - por exemplo, contadores ou valores extraídos com o pós-processador de expressão regular. Você pode querer usar uma convenção de nomenclatura diferente para eles.

Por exemplo, você pode definir o seguinte no Plano de Teste:

HOSPEDAGEM www.example.com
FIOS 10
LAÇOS 20

HOST ${__P(host,www.example.com)}
TÓPICOS ${__P(tópicos,10)}
LOOPS ${__P(loops,20)}

jmeter … -Jhost=www3.example.org -Jloops=13