1.0.4 Vamos começar ¶

A maneira mais fácil de começar a usar o JMeter é primeiro baixar a versão de produção mais recente e instalá-la. A versão contém todos os arquivos necessários para construir e executar a maioria dos tipos de testes, por exemplo, Web (HTTP/HTTPS), FTP, JDBC, LDAP, Java, JUnit e muito mais.

Se você deseja realizar testes JDBC, é claro que precisará do driver JDBC apropriado de seu fornecedor. O JMeter não vem com nenhum driver JDBC.

O JMeter inclui o jar da API JMS, mas não inclui uma implementação do cliente JMS. Se desejar executar testes JMS, será necessário fazer download dos jars apropriados do provedor JMS.

Em seguida, inicie o JMeter e vá até a seção Construindo um Plano de Teste do Guia do Usuário para se familiarizar com os fundamentos do JMeter (por exemplo, adicionar e remover elementos).

Finalmente, passe pela seção apropriada sobre como construir um tipo específico de Plano de Teste. Por exemplo, se você estiver interessado em testar um aplicativo da Web, consulte a seção Construindo um Plano de Teste da Web . As outras seções específicas do Plano de Teste são:

• Plano de teste avançado da Web
• JDBC
• FTP
• JMS ponto a ponto
• Tópico JMS
• LDAP
• LDAP estendido
• WebServices (SOAP)

Quando estiver confortável com a construção e execução dos Planos de Teste JMeter, você poderá examinar os vários elementos de configuração (temporizadores, ouvintes, asserções e outros) que lhe dão mais controle sobre seus Planos de Teste.

1.1.1 Versão Java¶

Como o JMeter usa apenas APIs Java padrão, não envie relatórios de bugs se o JRE falhar ao executar o JMeter devido a problemas de implementação do JRE.

1.1.2 Sistemas Operacionais ¶

O JMeter é um aplicativo 100% Java e deve ser executado corretamente em qualquer sistema que tenha uma implementação Java compatível.

Os sistemas operacionais testados com o JMeter podem ser vistos nesta página no wiki do JMeter.

Mesmo que seu sistema operacional não esteja listado na página wiki, o JMeter deve ser executado nele, desde que a JVM seja compatível.

1.2.1 Compilador Java ¶

Se você quiser construir a fonte JMeter ou desenvolver plugins JMeter, precisará de um JDK 8 ou superior totalmente compatível.

1.2.2 Analisador XML SAX ¶

O JMeter vem com o analisador XML Xerces do Apache . Você tem a opção de dizer ao JMeter para usar um analisador XML diferente. Para fazer isso, inclua as classes para o analisador de terceiros no caminho de classe do JMeter e atualize o arquivo jmeter.properties com o nome de classe completo da implementação do analisador.

1.2.3 Suporte por e-mail ¶

O JMeter possui amplos recursos de e-mail. Ele pode enviar e-mails com base nos resultados dos testes e possui um amostrador POP3(S)/IMAP(S). Ele também possui um amostrador SMTP(S).

1.2.4 Criptografia SSL ¶

Para testar um servidor web usando criptografia SSL (HTTPS), o JMeter requer que uma implementação de SSL seja fornecida, como é o caso do Sun Java 1.4 e superior. Se sua versão do Java não inclui suporte a SSL, é possível adicionar uma implementação externa. Inclua os pacotes de criptografia necessários no classpath do JMeter . Além disso, atualize system.properties para registrar o Provedor SSL.

O padrão HTTP do JMeter é TLS de nível de protocolo. Isso pode ser alterado editando a propriedade do JMeter https.default.protocol em jmeter.properties ou user.properties .

Os amostradores HTTP JMeter são configurados para aceitar todos os certificados, confiáveis ​​ou não, independentemente dos períodos de validade, etc. Isso permite a máxima flexibilidade nos servidores de teste.

Se o servidor exigir um certificado de cliente, ele poderá ser fornecido.

Há também o SSL Manager , para maior controle dos certificados.

O amostrador SMTP pode, opcionalmente, usar um armazenamento confiável local ou confiar em todos os certificados.

1.2.5 Driver JDBC ¶

Você precisará adicionar o driver JDBC do seu fornecedor de banco de dados ao classpath se quiser fazer o teste JDBC. Verifique se o arquivo é um arquivo jar, não um zip.

1.2.6 Cliente JMS ¶

O JMeter agora inclui a API JMS do Apache Geronimo, portanto, você só precisa incluir o(s) jar(s) de implementação do Cliente JMS apropriado(s) do provedor JMS. Consulte a documentação deles para obter detalhes. Também pode haver algumas informações no JMeter Wiki .

1.2.7 Bibliotecas para ActiveMQ JMS ¶

Você precisará adicionar o jar activemq-all-XXXjar ao seu classpath, por exemplo, armazenando-o no diretório lib/ .

Consulte a página de configuração inicial do ActiveMQ para obter detalhes.

1.4.1 Classpath do JMeter ¶

O JMeter encontra automaticamente classes de jars nos seguintes diretórios:

JMETER_HOME/lib

usado para potes utilitários

JMETER_HOME/lib/ext

usado para componentes e plugins JMeter

Se você desenvolveu novos componentes do JMeter, então você deve criá-los e copiá-los no diretório lib/ext do JMeter . O JMeter encontrará automaticamente os componentes do JMeter em quaisquer jars encontrados aqui. Não use lib/ext para jars de utilitários ou jars de dependência usados ​​pelos plugins; destina-se apenas a componentes e plugins JMeter.

Se você não quiser colocar jars de plug-in JMeter no diretório lib/ext , defina a propriedade search_paths em jmeter.properties .

Jars utilitários e de dependência (bibliotecas etc) podem ser colocados no diretório lib .

Se você não quiser colocar esses jars no diretório lib , defina a propriedade user.classpath ou plugin_dependency_paths em jmeter.properties . Veja abaixo uma explicação das diferenças.

Outros jars (como JDBC, implementações JMS e quaisquer outras bibliotecas de suporte necessárias para o código JMeter) devem ser colocados no diretório lib - não no diretório lib/ext , ou adicionados ao user.classpath .

Você também pode instalar arquivos Jar do utilitário em $JAVA_HOME/jre/lib/ext , ou você pode definir a propriedade user.classpath em jmeter.properties

Observe que definir a variável de ambiente CLASSPATH não terá efeito. Isso ocorre porque o JMeter é iniciado com " java -jar ", e o comando java ignora silenciosamente a variável CLASSPATH e as opções -classpath / -cp quando -jar é usado.

1.4.2 Criar Plano de Teste a partir do Modelo ¶

Você tem a capacidade de criar um novo Plano de Teste a partir do modelo existente.

Para isso, use o menu Arquivo  →  Modelos… ou o ícone Modelos:

Um pop-up aparece, você pode escolher um modelo na lista:

Alguns modelos podem precisar de parâmetros de entrada do usuário. Para estas, após clicar no botão criar, uma nova janela aparecerá como segue:

Quando terminar com os parâmetros, clique no botão Validar e o modelo será criado.

Uma documentação para cada modelo explica o que fazer depois que o plano de teste é criado a partir do modelo.

1.4.3 Usando o JMeter atrás de um proxy ¶

Se você estiver testando por trás de um servidor de firewall/proxy, pode ser necessário fornecer ao JMeter o nome de host e o número da porta do servidor de firewall/proxy. Para fazer isso, execute o arquivo jmeter[.bat] a partir de uma linha de comando com os seguintes parâmetros:

-E

[esquema de proxy a ser usado - opcional - para não http]

-H

[nome do host do servidor proxy ou endereço IP]

-P

[porta do servidor proxy]

-N

[hosts não proxy] (por exemplo , *.apache.org|localhost )

-você

[nome de usuário para autenticação de proxy - se necessário]

-uma

[senha para autenticação de proxy - se necessário]

jmeter -E https -H my.proxy.server -P 8000 -u nome de usuário -a senha -N localhost

Você também pode usar --proxyScheme , --proxyHost , --proxyPort , --username e --password como nomes de parâmetros

Se o esquema de proxy for fornecido, o JMeter definirá as seguintes propriedades do sistema:

• http.proxyScheme

Se o host e a porta do proxy forem fornecidos, o JMeter configurará as seguintes propriedades do sistema:

• http.proxyHost
• http.proxyPort
• https.proxyHost
• https.proxyPort

O usuário e a senha usados ​​para um proxy podem ser fornecidos pelas propriedades do sistema http.proxyUser e http.proxyUser . Eles serão substituídos pelos argumentos ou valores acima definidos nos Amostradores HTTP.

Se uma lista de hosts não proxy for fornecida, o JMeter definirá as seguintes propriedades do sistema:

• http.nonProxyHosts
• https.nonProxyHosts

Portanto, se você não deseja definir os proxies http e https, pode definir as propriedades relevantes em system.properties em vez de usar os parâmetros de linha de comando.

As configurações de proxy também podem ser definidas em um plano de teste, usando a configuração HTTP Request Defaults ou os elementos amostradores de HTTP Request .

1.4.4 Modo CLI (o modo Linha de Comando era chamado de modo NON GUI) ¶

Para testes de carga, você deve executar o JMeter neste modo (sem a GUI) para obter os melhores resultados. Para fazer isso, use as seguintes opções de comando:

-n

Isso especifica que o JMeter deve ser executado no modo cli

-t

[nome do arquivo JMX que contém o Plano de Teste].

-eu

[nome do arquivo JTL para registrar os resultados da amostra].

-j

[nome do arquivo de log de execução do JMeter].

-r

Execute o teste nos servidores especificados pela propriedade JMeter " remote_hosts "

-R

[lista de servidores remotos] Execute o teste nos servidores remotos especificados

-g

[caminho para o arquivo CSV] gerar apenas o painel de relatórios

-e

gerar painel de relatório após teste de carga

-o

pasta de saída onde gerar o dashboard do relatório após o teste de carga. A pasta não deve existir ou estar vazia

O script também permite especificar as informações opcionais do servidor de firewall/proxy:

-H

[nome do host do servidor proxy ou endereço IP]

-P

[porta do servidor proxy]

jmeter -n -t meu_test.jmx -l log.jtl -H meu.proxy.server -P 8000

Se a propriedade jmeterengine.stopfail.system.exit estiver configurada para true (o padrão é false ), então o JMeter invocará System.exit(1) se não puder parar todos os encadeamentos. Normalmente isso não é necessário.

1.4.5 Modo Servidor ¶

Para testes distribuídos , execute o JMeter no modo de servidor no(s) nó(s) remoto(s) e, em seguida, controle o(s) servidor(es) a partir da GUI. Você também pode usar o modo CLI para executar testes remotos. Para iniciar o(s) servidor(es), execute jmeter-server[.bat] em cada host do servidor.

O script também permite especificar as informações opcionais do servidor de firewall/proxy:

-H

[nome do host do servidor proxy ou endereço IP]

-P

[porta do servidor proxy]

jmeter-server -H my.proxy.server -P 8000

Se desejar que o servidor saia após a execução de um único teste, defina a propriedade JMeter server.exitaftertest=true .

Para executar o teste do cliente no modo CLI, use o seguinte comando:

jmeter -n -t testplan.jmx -r [-Gprop=val] [-Gglobal.properties] [-X]

-G

é usado para definir as propriedades do JMeter a serem definidas nos servidores

-X

significa sair dos servidores no final do teste

-Rserver1,server2

pode ser usado em vez de -r para fornecer uma lista de servidores a serem iniciados. Substitui remote_hosts , mas não define a propriedade.

Se a propriedade jmeterengine.remote.system.exit for definida como true (o padrão é false ), o JMeter invocará System.exit(0) após interromper o RMI no final de um teste. Normalmente isso não é necessário.

1.4.6 Substituindo Propriedades Através da Linha de Comando ¶

As propriedades do sistema Java e as propriedades do JMeter podem ser substituídas diretamente na linha de comando (em vez de modificar jmeter.properties ). Para isso, use as seguintes opções:

-D[prop_name]=[valor]

define um valor de propriedade do sistema Java.

-J[prop_name]=[valor]

define uma propriedade JMeter local.

-G[prop_name]=[valor]

define uma propriedade JMeter a ser enviada a todos os servidores remotos.

-G[arquivo de propriedade]

define um arquivo contendo as propriedades do JMeter a ser enviado a todos os servidores remotos.

-L[categoria]=[prioridade]

substitui uma configuração de registro, definindo uma categoria específica para o nível de prioridade fornecido.

O sinalizador -L também pode ser usado sem o nome da categoria para definir o nível de log da raiz.

Exemplos :

jmeter -Duser.dir=/home/mstover/jmeter_stuff \
    -Jremote_hosts=127.0.0.1 -Ljmeter.engine=DEBUG

jmeter -LDEBUG

1.4.7 Log e mensagens de erro ¶

Aqui está um arquivo log4j2.xml de exemplo que define dois anexadores de log e registradores para cada categoria.

<Configuration status="WARN" packages="org.apache.jmeter.gui.logging">

  <Anexadores>

    <!-- O anexador do arquivo de log principal para jmeter.log no diretório a partir do qual o JMeter foi iniciado, por padrão. -->
    <Nome do arquivo="jmeter-log" fileName="${sys:jmeter.logfile:-jmeter.log}" append="false">
      <Padrão de Layout>
        <pattern>%d %p %c{1.}: %m%n</pattern>
      </PatternLayout>
    </Arquivo>

    <!-- Log appender para GUI Log Viewer. Veja abaixo. -->
    <GuiLogEvent name="gui-log-event">
      <Padrão de Layout>
        <pattern>%d %p %c{1.}: %m%n</pattern>
      </PatternLayout>
    </GuiLogEvent>

  </Appenders>

  <Registradores>

    <!-- Registrador raiz -->
    <Nível raiz="info">
      <AppenderRef ref="jmeter-log" />
      <AppenderRef ref="gui-log-event" />
    </Raiz>

    <!-- SNIP -->

    <!--
      # Exemplos de log Apache HttpClient
    -->
    <!-- # Ativar conexão de cabeçalho + registro de contexto - Melhor para depuração -->
    <!--
    <Nome do registrador="org.apache.http" level="debug" />
    <Nome do registrador="org.apache.http.wire" level="error" />
    -->

    <!-- SNIP -->

  </Registradores>

</Configuração>

Portanto, se você deseja alterar o nível de log da categoria org.apache.http para o nível de depuração, por exemplo, basta adicionar (ou descomentar) o seguinte elemento logger no arquivo log4j2.xml antes de iniciar o JMeter.

  <Registradores>
    <!-- SNIP -->
    <Nome do registrador="org.apache.http" level="debug" />
    <!-- SNIP -->
  </Registradores>

Para obter mais detalhes sobre como configurar o arquivo log4j2.xml , consulte a página de configuração do Apache Log4j 2 .

O nível de log para categorias específicas ou logger raiz também pode ser substituído diretamente na linha de comando (em vez de modificar log4j2.xml ). Para isso, use as seguintes opções:

-L[categoria]=[prioridade]

Substitui uma configuração de registro, definindo uma categoria específica para o nível de prioridade fornecido. Desde a versão 3.2, é recomendável usar um nome de categoria completo (por exemplo, org.apache.jmeter ou com.example.foo ), mas se o nome da categoria começar com jmeter ou jorphan , org.apache. será anexado internamente à entrada do nome da categoria para construir um nome de categoria completo (ou seja, org.apache.jmeter ou org.apache.jorphan ) para compatibilidade com versões anteriores.

Exemplos :

jmeter -Ljmeter.engine=DEBUG

jmeter -Lorg.apache.jmeter.engine=DEBUG

jmeter -Lcom.example.foo=DEBUG

jmeter -LDEBUG

Diferenças no Logging: Práticas Antigas e Novas :

Como o JMeter usa SLF4J como API de log e Apache Log4j 2 como uma estrutura de log desde 3.2, nem todos os níveis de log usados ​​antes de 3.2 podem corresponder exatamente a um dos novos níveis de log disponíveis fornecidos pelo SLF4J/Log4j2. Portanto, lembre-se das diferenças a seguir e das novas práticas sugeridas se precisar migrar qualquer configuração de registro e código de registro existentes.

LoggingManager.getLoggerFor(categoria de string);
LoggingManager.getLoggerForClass();

LoggerFactory.getLogger(categoria de string);
LoggerFactory.getLogger(Foo.class);

Se o JMeter detectar um erro durante um teste, uma mensagem será gravada no arquivo de log. O nome do arquivo de log é definido no arquivo log4j2.xml (ou usando a opção -j , veja abaixo). O padrão é jmeter.log e será encontrado no diretório a partir do qual o JMeter foi iniciado.

O menu Options  →  Log Viewer exibe o arquivo de log em um painel inferior na janela principal do JMeter.

No modo GUI, o número de mensagens de erro/fatais registradas no arquivo de log é exibido no canto superior direito.

A opção da linha de comandos -j jmeterlogfile permite processar após a leitura do arquivo de propriedades inicial e antes de quaisquer outras propriedades serem processadas. Portanto, permite que o padrão de jmeter.log seja substituído. Os scripts jmeter que usam um nome de plano de teste como parâmetro (por exemplo , jmeter-n.cmd ) foram atualizados para definir o arquivo de log usando o nome do plano de teste, por exemplo, para o plano de teste Test27.jmx o arquivo de log é definido como Test27. registro .

Ao executar no Windows, o arquivo pode aparecer apenas como jmeter , a menos que você tenha configurado o Windows para mostrar as extensões de arquivo. [O que você deve fazer de qualquer maneira, para facilitar a detecção de vírus e outras maldades que fingem ser arquivos de texto …]

Além de registrar erros, o arquivo jmeter.log registra algumas informações sobre a execução do teste. Por exemplo:

2017-03-01 12:19:20,314 INFO oajJMeter: Versão 3.2.20170301
2017-03-01 12:19:45,314 INFO oajgaLoad: Carregando arquivo: c:\mytestfiles\BSH.jmx
2017-03-01 12:19:52,328 INFO oajeStandardJMeterEngine: Executando o teste!
2017-03-01 12:19:52,384 INFO oajeStandardJMeterEngine: Iniciando 1 threads para o grupo BSH. Acelerar = 1.
2017-03-01 12:19:52,485 INFO oajeStandardJMeterEngine: Continuar no erro
2017-03-01 12:19:52,589 INFO oajtJMeterThread: Thread BSH1-1 iniciado
2017-03-01 12:19:52,590 INFO oajtJMeterThread: Thread BSH1-1 está concluído
2017-03-01 12:19:52,691 INFO oajeStandardJMeterEngine: Teste finalizado

O arquivo de log pode ser útil para determinar a causa de um erro, pois o JMeter não interrompe um teste para exibir um diálogo de erro.

1.4.8 Lista completa de opções de linha de comando ¶

Invocar JMeter como " jmeter -? " imprimirá uma lista de todas as opções de linha de comando. Estes são mostrados abaixo.

    --?
        imprimir opções de linha de comando e sair
    -h, --ajuda
        imprimir informações de uso e sair
    -v, --versão
        imprima as informações da versão e saia
    -p, --propfile <argumento>
        o arquivo de propriedades jmeter a ser usado
    -q, --addprop <argumento>
        arquivo(s) de propriedade JMeter adicionais
    -t, --testfile <argumento>
        o arquivo jmeter test(.jmx) a ser executado
    -l, --logfile <argumento>
        o arquivo para registrar amostras para
    -i, --jmeterlogconf <argumento>
        arquivo de configuração de log do jmeter (log4j2.xml)
    -j, --jmeterlogfile <argumento>
        arquivo de log de execução do jmeter (jmeter.log)
    -n, --nongui
        execute o JMeter no modo nongui
    -s, --servidor
        execute o servidor JMeter
    -H, --proxyHost <argumento>
        Definir um servidor proxy para o JMeter usar
    -P, --proxyPort <argumento>
        Defina a porta do servidor proxy para o JMeter usar
    -N, --nonProxyHosts <argumento>
        Definir lista de hosts não proxy (por exemplo, *.apache.org|localhost)
    -u, --username <argumento>
        Defina o nome de usuário para o servidor proxy que o JMeter deve usar
    -a, --password <argumento>
        Defina a senha para o servidor proxy que o JMeter deve usar
    -J, --jmeterproperty <argumento>=<valor>
        Definir propriedades adicionais do JMeter
    -G, --globalproperty <argumento>=<valor>
        Definir propriedades globais (enviadas aos servidores)
        por exemplo -Gport=123
         ou -Gglobal.properties
    -D, --systemproperty <argumento>=<valor>
        Definir propriedades adicionais do sistema
    -S, --systemPropertyFile <argumento>
        arquivo(s) adicional(is) de propriedade do sistema
    -f, --forceDeleteResultFile
        forçar a exclusão dos arquivos de resultados existentes e da pasta de relatórios da web, se houver, antes de iniciar o teste
    -L, --loglevel <argumento>=<valor>
        [category=]nível ex: jorphan=INFO, jmeter.util=DEBUG ou com.example.foo=WARN
    -r, --runremote
        Iniciar servidores remotos (conforme definido em remote_hosts)
    -R, --remotestart <argumento>
        Inicie esses servidores remotos (substitui remote_hosts)
    -d, --homedir <argumento>
        o diretório inicial do jmeter a ser usado
    -X, --remoteexit
        Saia dos servidores remotos no final do teste (modo CLI)
    -g, --reportonly <argumento>
        gerar painel de relatório apenas, a partir de um arquivo de resultados de teste
    -e, --reportatendofloadtests
        gerar painel de relatório após teste de carga
    -o, --reportoutputfolder <argumento>
        pasta de saída para o painel de relatórios

Nota: o nome do arquivo de log do JMeter é formatado como SimpleDateFormat (aplicado à data atual) se contiver aspas simples pareadas, .eg ' jmeter_'yyyyMMddHHmmss'.log '

Se o nome especial LAST for usado para os sinalizadores -t , -j ou -l , o JMeter entenderá que isso significa o último plano de teste executado no modo interativo.

1.4.9 Desligamento do modo CLI ¶

Antes da versão 2.5.1, o JMeter invocava System.exit() quando um teste de modo CLI era concluído. Isso causou problemas para aplicativos que invocam o JMeter diretamente, portanto, o JMeter não chama mais System.exit() para uma conclusão de teste normal. [Alguns erros fatais ainda podem invocar System.exit() ] O JMeter sairá de todas as threads não-daemon que iniciar, mas é possível que algumas threads não-daemon ainda permaneçam; isso impedirá a saída da JVM. Para detectar essa situação, o JMeter inicia um novo thread de daemon antes de sair. Este thread daemon espera um pouco; se ele retornar da espera, claramente a JVM não conseguiu sair e o encadeamento imprime uma mensagem para dizer o motivo.

A propriedade jmeter.exit.check.pause pode ser usada para substituir a pausa padrão de 2000ms (2s). Se definido como 0 , o JMeter não inicia o encadeamento do daemon.