DEV Community

Cover image for Utilizando Stackspot na criação de testes de performance com K6🏋️‍♂️
Marlo Henrique
Marlo Henrique

Posted on

Utilizando Stackspot na criação de testes de performance com K6🏋️‍♂️

#testing #k6 #performance #stackspot

Um dos principais pontos que destaco no curso de testes de performance com K6 é a simplicidade com que podemos criar testes do zero. O K6 segue um ciclo de vida padronizado, no qual todas as fases necessárias para executar um teste de performance precisam ser definidas.

Logo, podemos utilizar de recursos que possibilitem a definição dessas fases do ciclo de vida em um script, acelerando o processo de criação e replicação para novos testes.

Neste artigo, abordaremos como criar scripts de testes de performance de forma automatizada com a ajuda de um plugin da StackSpot.

Entendendo o ciclo de vida do K6📚

Ao contrário de outras ferramentas de teste de performance, como o JMeter, o K6 segue um ciclo de vida bem definido. Isso significa que, independentemente da quantidade de vezes que o script de testes de performance seja executado, ele sempre passará pelas mesmas fases, na mesma ordem, sendo as fases de:

  • Inicialização
  • Configuração
  • Execução
  • Desmontagem

Inicialização

Durante a fase de inicialização do ciclo de vida do K6, ocorre o carregamento de arquivos locais e a importação de módulos nativos ou remotos. É importante ressaltar que essa chamada é feita apenas uma vez por VU.

Um dos principais módulos nativos utilizados na criação de um script é o modulo http:

import http from 'k6/http';
Enter fullscreen mode Exit fullscreen mode

Configuração

Durante a fase de configuração, são definidos os dados que serão compartilhados entre todas as VUs. Esses dados incluem informações cruciais, como a quantidade de VUs, duração, limites de validação e outras definições importantes para a execução do teste de performance. É importante destacar que essa fase é realizada apenas uma única vez durante todo o ciclo de vida.

export const options = {
  vus: 1,
  duration: '1m',
};
Enter fullscreen mode Exit fullscreen mode

Execução

Durante a etapa de execução, a função de teste é executada repetidamente com base nas configurações definidas anteriormente. Nesta fase, as VUs realizam solicitações HTTP, emitem métricas e executam validações e verificações definidas na fase de configuração.

A principal característica que diferencia essa etapa das outras funções que podem ser definidas na fase de configuração, é que a função de execução é a definida como default. Isso significa que, mesmo que nenhuma outra função seja definida na fase de configuração, a função de execução será executada automaticamente com base nas configurações.

export default function () {
  http.get('https://test.k6.io');
}
Enter fullscreen mode Exit fullscreen mode

Desmontagem

Essa é uma etapa opcional, na qual podemos processar os resultados obtidos durante as fases de configuração e execução. É bastante útil quando queremos enviar resultados por webhook para uma plataforma externa, notificar determinados serviços, ou montar relatórios personalizados, pois recebe como parâmetro os resultados obtidos na fase de execução. Essa etapa é executada uma única vez durante todo o ciclo de vida do teste.

export function teardown(data) {
  console.log(JSON.stringify(data));
}
Enter fullscreen mode Exit fullscreen mode

Mão na massa👩‍💻

Pré-requisito📑

Importando nossa stack 🔨

Para fins didáticos, utilizaremos a stack qa-api-stack, que já foi abordada em outros posts sobre o assunto Stackspot.

Para realizar a instalação, basta utilizar o seguinte comando na sua CLI:

stk import stack https://github.com/marlo2222/qa-api-stack
Enter fullscreen mode Exit fullscreen mode

Importante: Essa é uma stack para fins didáticos e que seu principal objetivo, que é a configuração de testes de API, ainda está em desenvolvimento.

Podemos verificar a disponibilidade do plugin k6-script-plugin, executando o comando stk list plugin:

+------------------+-----------------------------------------------------------------+-----------------+
| name             | description                                                     | version(latest) |
+------------------+-----------------------------------------------------------------+-----------------+
| k6-script-plugin | Plugin para criação de scripts de testes de performance com k6. | Sem release     |
|                  |                                                                 |                 |
| pitest-java      | Plugin para a configuração de testes de mutação com a           | Sem release     |
|                  | ferramenta pitest em projetos java.                             |                 |
+------------------+-----------------------------------------------------------------+-----------------+
Enter fullscreen mode Exit fullscreen mode

Utilizando o plugin🔌

Antes de iniciarmos a criação dos nossos scripts de teste de performance, vamos criar um diretório chamado "testes-performance" com o comando mkdir testes-performance. Em seguida, entraremos no diretório recém-criado com o comando cd testes-performance.

Estando no diretório, podemos utilizar nosso plugin para criação de testes de performance com o seguinte comando:

stk apply plugin -s qa-api-stack/k6-script-plugin
Enter fullscreen mode Exit fullscreen mode

o argumento -s basicamente ignora a checagem de aplicativos que não foram criados utilizando Stackspot.

A Stackspot solicitara algumas informações para criação do script, sendo o primeiro ponto o nome do script, nesse exemplo informaremos teste-get:

? Informe o nome do script: teste-get
Enter fullscreen mode Exit fullscreen mode

A seguir, precisamos configurar a quantidade de VUs que será utilizado no teste de performance. Neste caso, definiremos o valor de 50 VUs:

Informe a quantidade de VUs: 50
Enter fullscreen mode Exit fullscreen mode

As VUs (Virtual Users) representam a quantidade de usuários que simularemos acessar a nossa aplicação durante os testes de performance.

Outra informação que precisamos configurar é a duração dos testes, que é expressa em segundos. Neste caso, definiremos a duração de 15 segundos.

Informe a duração em seg: 15
Enter fullscreen mode Exit fullscreen mode

Um dos pontos mais importantes na configuração do nosso script de teste de performance é definir a URL que será utilizada para realização das requisições. Neste exemplo, usaremos uma API pública do K6, que retorna uma lista dos crocodilos atualmente cadastrados na plataforma.

Informe a url para teste: https://test-api.k6.io/public/crocodiles/
Enter fullscreen mode Exit fullscreen mode

Assim como a URL para testes, precisamos informar o método HTTP que será utilizado para as requisições. O plugin está configurado para exibir uma lista com os principais métodos: GET, POST, PUT, DELETE. Nesse exemplo, selecionaremos a opção GET:

? Selecione o método de teste 
 » 1) get
   2) post
   3) put
   4) delete
Enter fullscreen mode Exit fullscreen mode

A seguir, é necessário informar qual status code esperamos que as requisições retornem. Por padrão, o script utiliza o status code 200. No entanto, é possível fornecer qualquer código de status valido.

? informe o status code esperado: 200
Enter fullscreen mode Exit fullscreen mode

A próxima pergunta definira se você deseja adicionar alguns limites para validação do seu teste. Caso opte pela opção "Y", a Stackspot seguirá com algumas solicitações para definir esses limites. Neste exemplo, escolheremos a opção "Y".

Gostaria de definir thresholds/limites ao teste? (y/N) Yes
Enter fullscreen mode Exit fullscreen mode

Primeiro, precisaremos definir um percentil de confiança para o limite que avalia a duração das requisições, vamos selecionar a opção 95%:

? Selecione o percentil de confiança para duração da requisição 
   1) 90
 » 2) 95
Enter fullscreen mode Exit fullscreen mode

Após definimos o intervalo de confiança para o indicador de duração das requisições, precisamos informar um tempo esperado em milissegundos(ms). Informaremos um tempo aproximado de 400 ms:

? Informe a duração esperada da requisição em ms: 400
Enter fullscreen mode Exit fullscreen mode

Ao definir o percentil de 95%, esperamos que 95% das nossas requisições tenham um tempo de resposta igual ou inferior a 400 ms. Se o intervalo de confiança não for atingido, o teste falhará.

O segundo critério que será avaliado será a taxa de requisições com sucesso. Também utilizaremos percentis para esse indicador. Nesse exemplo selecionaremos a opção de 99%:

? Selecione a taxa de sucesso para as requisições em %
   1) 90
   2) 95
 » 3) 99
Enter fullscreen mode Exit fullscreen mode

Para o nosso segundo indicador, esperamos que 99% das requisições retornem o código de status 200. Se o intervalo de confiança não for atingido, o teste falhará.

Podemos observar que a Stackspot nos informa que o plugin foi aplicado com sucesso:

Plugin qa-api-stack/k6-script-plugin aplicado.
Enter fullscreen mode Exit fullscreen mode

Ao executar o comando ls, podemos verificar que o nosso script foi criado com sucesso.

$ ls
teste-get.js
Enter fullscreen mode Exit fullscreen mode

Analisando o script gerado🧐

Utilizando o comando cat test-get.js podemos observar a estrutura do script gerado pela Stackspot:

import http from 'k6/http';
import {sleep, check} from 'k6';

export const options = {
    vus: 50,
    duration: '15s',
    thresholds: {
        checks: ['rate > 0.99'],
        http_req_duration: ['p(95) < 400']
    }
}

export default function(){

    const params = {
        headers: {
            'Content-Type': 'application/json'
        }
    }

    const res = http.get('https://test-api.k6.io/public/crocodiles/', params);

    check(res,{
        'status 200': (r) => r.status === 200
    });

    sleep(1);
}
Enter fullscreen mode Exit fullscreen mode

Podemos perceber que o nosso teste de performance foi dividido em três fases distintas:

  • Inicialização: com a importação dos módulos necessários para o teste.
  • Configuração: com a configuração de quantidade de vus, duração e limites no escopo da constante options.
  • Execução: com o escopo da função default que realiza a execução do nosso teste de performance.

É importante destacar que a fase de desmontagem é opcional e, por isso, optamos por não defini-la. No entanto, é possível parametrizar essa fase utilizando a Stackspot, caso necessário.

Executando nosso teste🏆

Agora chegamos à fase mais esperada deste tutorial, a execução do nosso teste de performance. Podemos utilizar o seguinte comando:

 k6 run teste-get.js
Enter fullscreen mode Exit fullscreen mode

E obteremos como resultado a seguinte saída:

          /\      |‾‾| /‾‾/   /‾‾/
     /\  /  \     |  |/  /   /  /
    /  \/    \    |     (   /   ‾‾\
   /          \   |  |\  \ |  (‾)  |
  / __________ \  |__| \__\ \_____/ .io

  execution: local
     script: teste-get.js
     output: -

  scenarios: (100.00%) 1 scenario, 50 max VUs, 45s max duration (incl. graceful stop):
           * default: 50 looping VUs for 15s (gracefulStop: 30s)


     ✓ status 200

   ✓ checks.........................: 100.00% ✓ 668       ✗ 0
     data_received..................: 831 kB  52 kB/s
     data_sent......................: 119 kB  7.4 kB/s
     http_req_blocked...............: avg=23.06ms  min=0s      med=0s       max=310.93ms p(90)=0s       p(95)=306.61ms
     http_req_connecting............: avg=6.99ms   min=0s      med=0s       max=98.96ms  p(90)=0s       p(95)=92.33ms
   ✓ http_req_duration..............: avg=138.29ms min=84.38ms med=101.89ms max=871.45ms p(90)=179.46ms p(95)=330.96ms
       { expected_response:true }...: avg=138.29ms min=84.38ms med=101.89ms max=871.45ms p(90)=179.46ms p(95)=330.96ms
     http_req_failed................: 0.00%   ✓ 0         ✗ 668
     http_req_receiving.............: avg=448.18µs min=0s      med=0s       max=15.44ms  p(90)=471.4µs  p(95)=2.73ms
     http_req_sending...............: avg=5.07µs   min=0s      med=0s       max=510.4µs  p(90)=0s       p(95)=0s
     http_req_tls_handshaking.......: avg=9.07ms   min=0s      med=0s       max=125.65ms p(90)=0s       p(95)=120.03ms
     http_req_waiting...............: avg=137.84ms min=84.21ms med=101.82ms max=870.49ms p(90)=179.46ms p(95)=330.06ms
     http_reqs......................: 668     41.461698/s
     iteration_duration.............: avg=1.16s    min=1.08s   med=1.11s    max=2.18s    p(90)=1.2s     p(95)=1.64s
     iterations.....................: 668     41.461698/s
     vus............................: 7       min=7       max=50
     vus_max........................: 50      min=50      max=50
Enter fullscreen mode Exit fullscreen mode

Podemos notar que os limites que definimos para a http_req_duration e o status code das solicitação foram validados com sucesso. É importante destacar que o indicador iterations aponta para uma taxa de transferência de 41,46 solicitações por segundo, o que é bastante satisfatório para um ambiente de testes executado localmente.

Conclusão💖

Neste artigo, realizamos a parametrização de algumas informações do nosso teste de performance. No entanto, há muitas outras a serem parametrizadas, como os parâmetros de headers, o payload request para as requisições, a leitura de arquivos externos, entre outras possibilidades.

Com a parametrização dessas informações, nosso script pode se tornar ainda mais flexível e adaptável às necessidades do nosso teste de performance.

Fica claro a flexibilidade que a Stackspot nos proporciona para resolvermos ou acelerarmos pontos relacionados ao processo de teste de software.

Deixo aqui o convite para você criar o seu próprio script utilizando esse plugin.😎

Sinta-se à vontade para qualquer questionamento, dúvida ou mesmo contribuição!😀

📩 linkedin
🐱‍👤 github

Quer sabe mais sobre Stackspot? vou esta deixando o link para o github oficial onde você pode encontrar os principais contatos para o time da Stackspot.✨

Top comments (0)

Read next

amberwallace profile image

xUnit Testing - an Advanced and Reliable Tool for Software Testing

Amber Wallace -

mspilari profile image

Integration Tests on Spring Boot with PostgreSQL and Testcontainers

Matheus Bernardes Spilari -

awwsmm profile image

There is No Such Thing as a Unit Test

Andrew (he/him) -

devrx profile image

API Testing Made Effortless : KushoAI

Abhinav Pandey -