Teste de carga em APIs utilizando Artillery

Independente do produto que você esteja criando, é sempre importante assegurar a qualidade do mesmo fazendo uma bateria de testes antes de colocar no mercado. Se tratando de desenvolvimento de software, existem algumas métricas que são essenciais para deixar claro para todos os envolvidos no projeto, incluindo seus usuários, o quanto determinado sistema/aplicativo é confiável para suportar o uso do público. Dentro da área de qualidade de software, existem diversos tipos de testes que visam atingir o objetivo citado acima, de mostrar a todos que o produto é estável e robusto, alguns deles: teste de integração, teste unitário, teste de penetração, teste de regressão e por aí vai.

por Ulysses Marins 06/03/2017 Comentários

Independente do produto que você esteja criando, é sempre importante assegurar a qualidade do mesmo fazendo uma bateria de testes antes de colocar no mercado. Se tratando de desenvolvimento de software, existem algumas métricas que são essenciais para deixar claro para todos os envolvidos no projeto, incluindo seus usuários, o quanto determinado sistema/aplicativo é confiável para suportar o uso do público.

Dentro da área de qualidade de software, existem diversos tipos de testes que visam atingir o objetivo citado acima, de mostrar a todos que o produto é estável e robusto, alguns deles: teste de integração, teste unitário, teste de penetração, teste de regressão e por aí vai.

Este post tem como objetivo falar um pouco sobre o teste de carga, que em sua essência foi criado para simular quantidades diferentes de tentativa de acesso a determinado sistema ou device, tendo como saída um relatório de como o software se comportou em determinado cenário.

Quando falamos de APIs e escalonamento de infra, é interessante saber o número exato de requisições que o servidor (ou servidores) consegue responder corretamente em um tempo aceitável para seus clientes.

Caso você já tenha tentado fazer algo do tipo, provavelmente se deparou com o JMeter, que é uma das ferramentas mais famosas e completas para esse tipo de trabalho. Porém, a curva de aprendizado com o JMeter é um pouco longa, pois existem muitas configurações/opções que o usuário acaba se perdendo no início, até encontrar o que realmente precisa para o seu caso.

Na tentativa de tornar esse processo de teste de carga um pouco mais amigável ao usuário, foi criado o Artillery, uma ferramenta que com poucos passos permite você simular diversos tipos de cenários para teste de serviços que estejam utilizando para comunicação http e/ou web sockets.

Basicamente você precisa ter o node e o npm instalado para poder começar a brincadeira.

Para instalar o Artillery:

$ npm install -g artillery

Para testar sua instalação:

$ artillery dino

Caso tenha aparecido um dinossauro em seu terminal, está tudo certo e você pode seguir adiante.

Para começar a rodar seus testes de carga, é necessário criar um arquivo de configuração. Você pode dar qualquer nome a ele, mas para esse artigo, criarei um chamado artillery.yml.

Neste cara que você colocará todas as informações referentes a sua API, como endpoint, rotas e cenários. Você pode tanto testar rotas/recursos isolados, quanto cenários mais complexos, como por exemplo um processo de compra em um ecommerce, que basicamente teria uma rota para buscar os produtos, outra pra fazer checkout e outra para pagamento.

Segue abaixo um exemplo desse arquivo:

config:
  target: 'http://localhost:3000'
  phases:
    - duration: 60
      arrivalRate: 20
scenarios:
  -
    name: 'Listagem de usuários'
    flow:
    - get:
        url: "/users"

No arquivo acima colocamos o endpoint da nossa API, o atributo duration representa a duração deste ciclo de teste em segundos e o arrivalRate o número de novos usuários por segundo.

Para rodar o teste, rode o seguinte comando:

$ artillery run artillery.yml

Após a execução, temos o seguinte resultado:

Output do Artillery

Todas as métricas de tempo são em milis, RPS (request per second), codes são os códigos HTTP e o número de respostas com o mesmo, no caso acima, tivemos 1200 (60×20, como configuramos) requisições em 60 segundos e todas retornaram 200. Scenarios launched são os ‘usuários virtuais’ criados e Scenarios completed são quantos deles conseguiram executar o cenário com sucesso.

Importante: Enquanto o teste estiver rodando, um preview do resultado vai sendo printado no terminal a cada 10 segundos, mas só no final você tem os números consolidados do teste completo.

Agora você pode ir alterando números de usuários concorrentes, quantidade de tempo do teste, novos cenários, simulando fluxos mais complexos e etc.

Vale a pena dar uma olhada na documentação que é super objetiva e simples de entender.