Taurus é um framework open source para a automação de testes, especialmente de performance. É possível criar e reproduzir testes para diversas ferramentas open source de teste de performance e Selenium utilizando o Taurus.

Uma das razões para a criação do Taurus foi a vontade de superar questões existenciais do Jmeter que não podem ser solucionadas, como:

• Elevado custo computacional para exibir na GUI informações durante a execução de um teste
• Dificuldade em versionar o arquivo JMX, o conteúdo do arquivo é em formato XML
• Modo complicado para gerar relatórios

Porém, ele foi expandido para suportar outras ferramentas, como Gatling, Selenium, entre outras. Além disso, Taurus possui a intenção de ser uma ferramenta de fácil uso, principalmente para iniciantes na disciplina de teste de performance.

Para realizar o seu trabalho, Taurus consome um arquivo de configuração em YAML, um código fonte extremamente simples de leitura e entendimento.

Ainda melhor, o código fonte do arquivo de configuração também pode ser escrito em JSON – eu prefiro YAML. Observe um exemplo de teste de carga perfeitamente válido em YAML.

Código 1 – Arquivo de configuração quicktest.yaml

---
execution:
- concurrency: 10
  scenario: quick-test
  iterations: 30

scenarios:
  quick-test:
    requests:
      - http://blazedemo.com/

O Taurus possui seu próprio DSL (Domain-specific Language). A linguagem de configuração tem diversas seções chave. Neste exemplo quicktest.yaml, vemos duas seções da DSL do Taurus:

• Execution: trata da carga de trabalho (workload) que é uma característica comum de qualquer teste
• Scenarios: seção que define os cenários a serem rodados

Cada cenário tem sua lista de requisições a serem disparadas, característica elementar a qualquer teste. Neste caso havia somente um cenário: o quick-test.

O arquivo de configuração quicktest.yaml é um dos menores testes possíveis (uma requisição apenas). Vamos analisar esse teste.

Não há menção no teste para a ferramenta a ser utilizada – o teste será rodado com o Jmeter, pois é a ferramenta padrão do Taurus. A ação do teste será criar 10 usuários (concurrency), e rodar o cenário quick-test 30 vezes (iterations) para cada usuário.

O cenário quick-test se resume a submeter uma requisição à URL http://blazedemo.com. Nota-se que não foi definido o método HTTP a ser utilizado na requisição – o método padrão é o GET. Como veremos, muitas das configurações da DSL são padrão.

O teste de carga quicktest.yaml é um teste simples e débil, mas serve para ilustrar uma das características do Taurus, que é permitir ler e escrever testes de uma forma clara e simples. Essa característica auxilia a tarefa de manter e gerenciar o código fonte no sistema de controle de versão.

Algumas obrigações para escrever o código em YAML:

• Iniciar o conteúdo do arquivo com — (três traços)
• A indentação é responsável por representar a estrutura do documento
• Nunca utilize TAB para indentação, somente espaços
• Depois de hífen (-) e dois pontos (:) é necessário um espaço. O scenario quick-test é um nome composto, portanto, não precisa de espaço entre as palavras

YAML possui estruturas de dados comuns às linguagens de programação, como listas. A seção execution é uma lista de execuções – o exemplo acima possui apenas uma execução.

Outra estrutura em YAML é o dicionário, chave e valor. O elemento da lista execution, a execução em si, é um dicionário contendo três chaves (concurrency, scenario, iterations) e os valores correspondentes da execução.

A seção scenarios possui o cenário quick-test, que é um dicionário, embora neste exemplo não esteja claro para afirmar isso, nos próximos exemplo isso ficará claro.

O cenário quick-test possui uma lista de requisições chamada requests. Essa lista possui apenas uma requisição neste exemplo. Os tipos ordinários integer, string e float estão presentes em YAML.

Instalando o Taurus

Taurus é uma ferramenta de linha de comando. Existe um instalador para Windows e é possível instalar no Linux e Mac por linha de comando. Eu uso o Linux Mint – veja a documentação oficial para a instalação:

• http://gettaurus.org/install/Installation/

Uma vez instalado, para rodar o teste quicktest.yaml é preciso utilizar o comando bzt no console:

bzt quicktest.yaml

Por padrão, Taurus produz em tempo real as informações de percentis, e indicadores de performance chave (KPI) como hits, número de falhas, tempo de resposta das últimas requisições e acumulado.

Exibe também as informações sobre os recursos do computador que roda o Taurus no painel à direita, como memória utilizada pelo teste, bytes trafegados, consumo de CPU, entre outros.

Após a execução do teste Taurus, exibe o sumário da execução com as seguintes informações:

• Tempo de duração do teste
• Percentis
• Número total de hits e porcentagem de falhas
• Tempo médio de resposta, latência e tempo de conexão
• Código de saída demonstra o modo como Taurus foi finalizado. Código 0 significa que o teste foi executado sem problemas. Código 1 indica que houve um erro durante a execução, como um erro interno do Taurus. Código 2 significa que o Taurus recebeu uma ordem de interrupção (Control+C). Código 3 designa que o Taurus foi interrompido automaticamente através de um critério de parada que será explicado mais à frente.

Utilizando o Gatling

Vejamos outro exemplo de um teste mais aprimorado: o arquivo de configuração gatling.yaml. A versão Open Source do Gatling exibe uma interface texto pouco informativa durante a execução do teste. Com Taurus é possível superar essa fragilidade.

Código 2 – Arquivo de configuração gatling.yaml

---
execution:
- concurrency: 10
  scenario: other-test
  executor: gatling
  hold-for: 1m


scenarios:
  other-test:
    requests:
    - url: http://blazedemo.com/
      label: Home
      assert:
        - 'Welcome to the Simple Travel Agency!'
    - url: http://blazedemo.com/vacation.html
      label: 'Vacation'
      think-time: 3s
      assert:
        - 'Destination of the week: Hawaii !'

Neste exemplo, na seção execution vemos que a ferramenta a ser utilizada é o Gatling (executor), o número de usuários é 10 (concurrency), o cenário a ser executado é o other-test e o tempo total do teste é 1 minuto (hold-for).

Observe que não há um número de iterações estabelecidos – o teste realizará o máximo de iterações que puder dentro de um minuto.

Quanto ao cenário other-test, ele possui a lista requests, que contém dois elementos que representam as requisições. Os elementos da lista são dicionários com as configurações de cada requisição:

• Requisição à home do blazedemo.com: a requisição receberá um nome (label) Home que constará nos relatórios e há uma asserção no corpo da resposta, procurando pelo texto ‘Welcome to the Simple Travel Agency!’
• Requisição à página vacation.html do blazedemo.com: no relatório o nome da requisição será Vacation. Há três segundos de think-time e asserção no corpo de resposta buscando pelo texto ‘Destination of the week: Hawaii !’

Figura 3. Console de execução do teste gatling.yaml

Por trás do Taurus

Quando o Taurus consome o arquivo de configuração em YAML (ou JSON), acaba por gerar o arquivo de código fonte da ferramenta utilizada. No caso de um teste utilizando o Jmeter, o arquivo gerado é o requests.jmx.

A cada execução de teste é criado um diretório de artefatos no diretório corrente do prompt para colocar os arquivos consumidos e gerados pela execução. De uma forma abreviada, alguns dos comportamentos do Taurus, são:

• Procurar por uma versão atual de si próprio. Se houve atualização ele informa que uma nova versão está disponível
• Procurar a ferramenta a ser utilizada no diretório padrão do Taurus, que é o diretório .bzt (oculto) na home do usuário. No exemplo quicktest.yaml é o Jmeter. Se ele não encontrar a ferramenta escolhida, ele fará o download da última versão e a colocará no seu diretório padrão. Ele faz o mesmo procedimento para cada ferramenta escolhida (e suportada) no arquivo de configuração
• Gerar o arquivo de teste da ferramenta escolhida baseado no teste em YAML
• Todas as operações que o Taurus executa de escrita e leitura de arquivos ele registra no arquivo bzt.log

Existem diferenças entre os arquivos gerados por cada teste, dependendo da ferramenta escolhida. Por exemplo, no caso do Jmeter é gerado o arquivo JMX. No caso do Gatling, é gerado o arquivo Scala. Caso haja falhas (código de resposta inesperados) durante a execução, o Taurus registra a requisição no error.jtl (Jmeter).

Teste de performance com duas ferramentas de execução

O Taurus é extremamente versátil, pois pode rodar testes de diferentes ferramentas em uma mesma execução. Por exemplo, vamos rodar o teste quicktest.yaml e o gatling.yaml juntos.

bzt quicktest.yaml gatling.yaml

O poder do Taurus em unificar os testes é uma característica marcante. Existem muitos motivos para rodar testes de diferentes ferramentas, como utilizar scripts existentes e até mesmo aproveitar determinada característica de uma ferramenta.

O comportamento padrão do Taurus gera um arquivo chamado merged.yml com as configurações dos arquivos de entrada. Neste caso, são dois arquivos de configuração.

Código 4. Arquivo de configuração unificado merged.yml

---
execution:
- concurrency: 10
  iterations: 30
  scenario: quick-test
- concurrency: 10
  executor: gatling
  hold-for: 1m
  scenario: other-test
scenarios:
  other-test:
    requests:
    - assert:
      - Welcome to the Simple Travel Agency!
      label: Home
      url: http://blazedemo.com/
    - assert:
      - 'Destination of the week: Hawaii !'
      label: Vacation
      think-time: 3s
      url: http://blazedemo.com/vacation.html
  quick-test:
    requests:
    - http://blazedemo.com/

Neste teste, a seção execution é uma lista que possui dois elementos, as execuções presentes no arquivos de configuração de entrada. Cada elemento da lista é um dicionário contendo os pares de chaves e valores da execução.

A seção scenarios contém dois cenários: os dois dicionários quick-test e other-test que foram encontrados nos arquivos de configuração de entrada.

Um exemplo mais aprimorado: compra de uma passagem aérea

O exemplo travel.yaml é um teste de carga para o caso de compra de uma passagem aérea no site de exemplo http://blazedemo.com. Os passos para comprar a passagem seriam:

• 1. Visitar a home de blazedemo.com
• 2. Realizar um busca de voos, informando a cidade de partida Boston e a cidade de chegada Cairo
• 3. Escolher o primeiro voo da lista
• 4. Submeter os dados do formulário de dados pessoais para efetuar a compra

Código 5. Arquivo de configuração travel.yaml

---
execution:
- iterations: 10
  scenario: quick-test
  concurrency: 50
  ramp-up: 60s


scenarios:
  quick-test:
    retrieve-resources: true
    default-address: http://blazedemo.com
    headers:
      user-agent: 'Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/72.0.3626.110 Safari/537.36 Vivaldi/2.3.1440.48'
    requests:
    - url: /
      label: '01 - Home'
      think-time: 5s
      assert:
        - contains:
          - 'Welcome to the Simple Travel Agency!'
          subject: body
        - contains:
          - 200
          subject: http-code    
    - url: /reserve.php
      method: POST
      headers: 
        Content-Type: application/x-www-form-urlencoded
      think-time: 3s
      label: '02 - Reserva de Boston para Cairo'
      body:
        fromPort: Boston
        toPort: Cairo
      assert:
       - contains:
         - 'Flights from Boston to Cairo:'
    - url: '/purchase.php'
      method: POST
      headers:
        Content-Type: application/x-www-form-urlencoded
      think-time: 3s
      label: '03 - Compra de Boston para Cairo'
      body:
        airline: Virgin Airlines
        flight: 43
        fromPort: Boston
        price: 472.56
        toPort: Cairo
      assert:
        - contains:
          - 'Your flight from Boston to Cairo has been reserved.'
          - 'Airline: Virgin Airlines'
    - url: /confirmation.php
      label: '04 - Confirma compra'
      method: POST
      headers:
        Content-Type: application/x-www-form-urlenconded
      body:
        inputName: Name
        address: endereço
        cardType: Visa
        city: City
        state: State
        zipCode: 12345
        creditCardNumber: 00000
        creditCardMonth: 12
        creditCardYear: 2017
        nameOnCard: Name On Card
      assert:
        - contains:
          - 'Thank you for your purchase today!'
reporting:
- module: passfail
  criteria:
  - avg-rt of 01 - Home>150ms for 25s, continue as failed
  - avg-rt>300ms for 50s, stop as failed

Neste exemplo vemos novos elementos de configuração para submeter as requisições. O cenário quick-test possui a lista requests com quatro elementos – cada elemento da lista é um dicionário para definir as configurações da requisição.

Os elementos são bem conhecidos no mundo HTTP: body, headers e think-time. Há uma nova seção aparecendo reporting.

Esta seção habilita o módulo passfail que serve para estabelecer um estado para o teste baseado em um critério em tempo de execução. Neste exemplo, o critério é um lista chamada criteria, que possui dois critérios. Os critérios são os seguintes:

• Se a média do tempo de resposta para a requisição com label Home for maior que 150 milissegundos por 25 segundos, então continue a execução do teste e marque o teste como failed
• Se a média do tempo de resposta de todas as requisições for maior que 300 milissegundos por 50 segundos, então pare a execução do teste e marque como failed

Note que os critérios são bastante exigentes em relação ao tempo de resposta. Escolhi propositalmente esses valores tão baixos para que o teste falhe e o módulo passfail encerre o teste.

O código de saída é 3, indicando que o teste foi interrompido automaticamente. A possibilidade de construção de critérios é bastante expressiva – é possível criar critério sobre diferentes KPIs.

Disparando o teste através da nuvem

Na execução local do Taurus, as requisições são disparadas do próprio computador, o que não é indicado por uma questão de escalabilidade da carga do teste e de confiabilidade dos resultados obtidos.

Outra característica notável do Taurus é a opção de disparar o teste utilizando o BlazeMeter, um serviço em nuvem para execução de testes, especialmente de performance.

Para realizar o teste através do BlazeMeter é necessário ter um conta gratuita, e criar um API Key e API Secret no site do BlazeMeter.

Para isso, faça Log in no site do BlazeMeter , clique sobre o seu Workspace (nome), clique em Settings > API Keys e adicionar uma nova API Key. A conta gratuita possui uma limitação de 10 testes por mês, com um máximo de 50 usuários virtuais e duração máxima de 20 minutos por teste.

Para habilitar o teste na nuvem, basta incluir a seção provisioning no arquivo de configuração:

provisioning: cloud

E alterar o arquivo oculto .bzt-rc encontrado na home do usuário descomentando a seção modules. A configuração mínima da seção é incluir a API Key e API Secret em token separados por dois pontos.

Código 6. Trecho do arquivo oculto .bzt-rc responsável pela configuração da Cloud BlazeMeter

modules:
  blazemeter:
    token: API Key:API Secret

A partir dessas modificações às requisições de um teste, serão disparadas de alguma localização padrão da nuvem e ainda é possível escolher a localização exata na nuvem.

Experimente alterar o arquivo travel.yaml, ou qualquer outro arquivo de configuração para realizar o teste remotamente.

Existem muitas outras opções relativas à execução em nuvem. O resultado do teste estará disponível para visualização no site da BlazeMeter e será enviado um e-mail com o resultado do teste.

Por ser executado remotamente, o teste demora de 2 a 4 minutos para iniciar. Disparando o teste travel.yaml:

bzt travel.yaml

Além da visualização da execução do teste através do Taurus, o navegador é iniciado com a página da execução do teste através do site da BlazeMeter sendo atualizada periodicamente.

Muito além

Taurus provê configurações para customizar os mínimos detalhes de um teste e até mesmo monitoramento do servidor e é extremamente flexível, podendo receber as configurações por linha comando, o que é interessante para o teste contínuo em Jenkins. Muitas configurações e valores padrões são comuns à determinadas ferramentas, e outras são específicas.

Leia a documentação oficial para descobrir o capacidade total da ferramenta.

Referências

• http://gettaurus.org/learn/#/?_k=d7l6q8
• http://gettaurus.org/