Testes em projetos Back-End: loading tests + critérios de falha + relatórios com k6 | pt 2
Este é o segundo artigo da série que venho produzindo sobre a implementação e automação de testes envolvendo projetos Back-End, com dicas e truques úteis para Desenvolvedores e profissionais da área de Quality Assurance (QA) na validação de REST APIs, jobs/serviços de execução contínua, aplicações serverless. Deixo aqui o link do primeiro post caso não tenha acessado ou, até mesmo, deseje rever este conteúdo:
Testes em projetos Back-End: loading tests com k6, Postman + Newman em APIs REST | parte 1
E aproveito este espaço para um convite…
Nesta segunda 29/11 às 21:00 — horário de Brasília — teremos mais um evento online e gratuito no canal Canal .NET.
Será uma live com os MVPs Alexandre Malavasi e Gustavo Bigardi abordando novidades na implementação de Web Apps com Blazor + .NET 6, além de dicas e pacotes úteis para acelerar e descomplicar a criação de projetos com estas tecnologias.
Para participar faça sua inscrição no link a seguir, a transmissão acontecerá via YouTube:
Thresholds com k6: definindo critérios para sucesso ou falha em testes de carga
Na primeira parte desta série abordei a utilização do k6 como ferramenta para a implementação e execução de testes de carga em Web Apps. Extremamente flexível, esta solução gratuita baseada em JavaScript pode ser facilmente integrada a várias soluções open source e tecnologias em nuvem.
Além disso, podemos implementar critérios de sucesso ou falha na execução de testes. Esta funcionalidade chamada de Threshold é sem sombra de dúvidas extremamente útil quando pensamos em automações, permitindo interrupções no processamento de pipelines/workflows em serviços como Azure DevOps e GitHub Actions.
Na listagem a seguir temos um exemplo de uso de um Threshold. Uma verificação especificada no parâmetro thresholds de options (linhas 7 a 9) determina se o tempo médio de resposta das requisições HTTP enviadas a uma API REST de contagem de acessos (http_req_duration) ficará abaixo de 120 milissegundos (avg < 120):
O projeto a ser testado foi baseado em .NET 6 + ASP.NET Core e disponibilizado no seguinte repositório do GitHub:
https://github.com/renatogroffe/k6-LoadTests-Thresholds-Reports-ASPNETCore6-APIContagem
Para simular uma falha nos testes inseri uma instrução na implementação da API forçando uma parada de 100 milissegundos, como indicado na listagem a seguir (linha 35):
Ao executar o k6 emulando 50 usuários durante 10 segundos teremos um tempo médio de duração das requisições de 148,79 milissegundos, resultando em falha para a condição indicada via threshold:
Retirando o trecho para simular um tempo médio superior a 100 milissegundos:
O resultado agora indicará sucesso na execução dos testes (com um tempo médio de 26,42 milissegundos):
Apresentei um outro exemplo de uso de Thresholds (percentual de requisições com falhas ao acessar um site) em um vídeo recente do canal Azure na Prática, o qual pode ser assistido gratuitamente no YouTube e que também demonstra a automação dos testes com GitHub Actions:
k6-reporter: gerando relatórios HTML ao executar testes de carga
E se pudéssemos exportar o resultado dos testes como um relatório? No próprio portal do k6 é oferecida uma alternativa paga conhecida como Cloud Tests, com diversos planos para execução de testes e geração de dashboards com gráficos permitindo a análise de diferentes métricas.
É possível ainda assim nos valermos de soluções gratuitas que transformem as métricas obtidas em um relatório HTML, com o projeto open source k6-reporter representando uma excelente opção. Maiores informação sobre o k6-reporter podem ser encontradas no GitHub:
https://github.com/benc-uk/k6-reporter
Na próxima listagem temos a implementação dos testes de carga da seção anterior em uma versão refatorada (tests-apicontagem-report.js), com o código correspondente já adaptado para a geração de um arquivo HTML contendo os resultados de uma execução:
- As funções htmlReport (disponibilizada pelo projeto k6-reporter) e textSummary foram importadas no início da implementação (linhas 3 e 4);
- Dentro do callback handleSummary (linhas 19 a 24) estão sendo utilizadas as funções htmlReport e textSummary, com a exportação dos resultados para um arquivo chamado apicontagem-loadtests.html e sua a exibição na saída padrão/terminal (stdout).
A execução desta nova versão para os testes não difere em nada do exemplo anterior, sendo que utilizei para isto a instrução:
k6 run tests-apicontagem-report.jsNa animação a seguir temos o relatório gerado durante uma execução com falhas:
Já a próxima animação traz um relatório indicando sucesso durante o processamento dos testes:
