Introdução a CI de Testes de Performance — Jenkins com Jmeter
Em desenvolvimento de software é inquestionável as vantagens que temos em automatizar processos e testes ganhando escala, reduzindo custos e aumentando a qualidade do software que desenvolvemos.
A ideia desse artigo é trazer insumos para você que já tem scripts desenvolvidos em JMeter, e possui as métricas (critérios de aceite) estabelecidos, automatize a execução de uma bateria de teste de performance.
É importante ressaltar que apesar de não abordado nesse texto, todo planejamento e análise para construção de um teste de performance deverá ser levado em consideração antes de pensar em criar uma CI de teste de performance. Temos um artigo que aborda sobre planejamento/estratégia O que deveríamos considerar ao traçar a melhor estratégia para o Teste de Performance.
Dessa forma, partindo do princípio de que a primeira triagem já foi realizada, ou seja:
1. Requisitos para entendimento da demanda e objetivo do teste de performance já foram alinhados/compreendidos
2. Necessidade de negócio e técnica já foram entendidas e consideradas na decisão das melhores estratégias para construir o teste de performance
3. Os critérios de aceite já foram estabelecidos e foram alinhados/acordados com todos envolvidos
E que o script que executará o teste de performance já foi desenvolvido podemos ir para a criação de uma pipeline de testes de performance.
Pré-requisitos
· Nesse artigo a ferramenta utilizada como exemplo é o JMeter, espera-se que tenha o jmx validado e funcionando
· Jenkins instalado e configurado
- Usaremos o JMeter Performance Plugin para validação e asserts da pipeline
· Considere ter configurado uma máquina que será nossa injetora para execução do script com Java e JMeter instalados
· Ferramenta para armazenar o script no repositório, com script commitado.
Nota: Nesse repositório commitaremos também o arquivo de configuração dos estágios no Jenkins, o jenkinsfile
Passo a passo para criação da pipeline:
Dado o contexto e os pré-requisitos, vamos ao passo a passo, mas antes um resumo de forma bem macro de como será o fluxo dessa pipeline:
1.Configuração do JenkinsFile
O Jenkinsfile é o arquivo que conterá todos os stages da pipeline de performance, um exemplo simples de configuração considerando que o agente (ambiente) já está criado seria:
Nota: Uma dica/sugestão é criar o ambiente do injetor em tempo de build, não está aplicado para esse exemplo, pode ser tema de outro artigo, fizemos usando outras ferramentas e para efeito de custos/concorrência na execução em cloud entendemos que é melhor maneira de estruturar a pipeline. Estes ambientes serão criados com algumas automações, usando imagens pré-configuradas já com ferramentas necessárias para execução, e após a execução dos testes esse ambiente é removido da estrutura.
pipeline {
agent {
label 'substituir_nome_maquina_injetora-agent'
}
stages {
stage('1. Doing Checkout SCM') {
steps {
dir('substituir_nome_projeto') {
checkout([$class: 'GitSCM', branches: [
], doGenerateSubmoduleConfigurations: false, extensions: [], submoduleCfg: [], userRemoteConfigs: [
[credentialsId: 'substituir_nome_credencial_gitlab', url: 'https://substitui_caminho_url_git.git']
]])
}
}
}
stage('2. Executing Performance Testing') {
steps {
script {
try {
dir('substituir_nome_projeto') {
dir('substituir_folder_jmx'){
sh "jmeter -jjmeter.save.saveservice.output_format=xml -n -t substituir_nome_script.jmx -l substituir_nome_log.jtl"
}
}
} catch (exc) {
echo 'Something failed'
}
}
}
}
stage('3. Post Build - Analyzing ResponseTime Validate') {
steps {
perfReport compareBuildPrevious: true, filterRegex: '', ignoreFailedBuilds: true, ignoreUnstableBuilds: true, modeOfThreshold: true, persistConstraintLog: true, relativeFailedThresholdPositive: 10.0, relativeUnstableThresholdPositive: 5.0, sourceDataFiles: 'substituir_caminho_nome_log.jtl'
}
}
stage('4. Post Build - Analyzing Error Validate') {
steps {
perfReport errorFailedThreshold:0.5, errorUnstableThreshold:0.2, sourceDataFiles: 'substituir_caminho_nome_log.jtl'
}
}
}
}Nota: Onde estiver com substituir_ troque por seus valores reais e faça os ajustes de acordo com seu contexto.
Ajustes dos Asserts no JMeter Performance Plugin
Uma das principais etapas em um CI de Teste de Performance é a validação da execução, através dos critérios de aceite (Quality Gates) pré-estabelecidos. É através desses gates/asserts que vamos garantir que a validação dessa execução de forma automática nos indique que os números estão satisfatórios, build Passed ou se não estão de acordo com o esperado, build Failed ou build Unstable.
No script acima, em Post Build é que teremos o assert do plugin. Para deixarmos de forma mais didática, separamos os stages que avaliam o tempo médio de resposta e a taxa de erro. Os principais campos serão salientados abaixo:
Tempo Médio de Resposta
Através do JMeter Performance plugin é possível configurar o % para deixar a build instável ou falhar a build comparando a diferença de acréscimo no tempo médio de resposta (geral) com a última build executada com sucesso:
stage('3. Post Build - Analyzing ResponseTime Validate') {
steps {
perfReport compareBuildPrevious: true, filterRegex: '', ignoreFailedBuilds: true, ignoreUnstableBuilds: true, modeOfThreshold: true, persistConstraintLog: true, relativeFailedThresholdPositive: 10.0, relativeUnstableThresholdPositive: 5.0, sourceDataFiles: 'substituir_caminho_nome_log.jtl'
}
}· compareBuildPrevious: Configurar como true para fazer o comparativo entre builds.
· ignoreFailedBuilds: true, ignoreUnstableBuilds: true: Configurar como true ambos os campos para ignorar a comparação com última build que estiver com status Failed ou Unstable.
· modeOfThreshold: true, persistConstraintLog: true: Configurar como true para ligar a validação.
· relativeFailedThresholdPositive: 10.0: Configurar com % que entende que acima desse valor de acréscimo no tempo de resposta, comparado com a build anterior, com status sucesso, considera que a build falhou.
· relativeUnstableThresholdPositive: 5.0: Configurar com % que entende que acima desse valor de acréscimo no tempo de resposta, comparado com a build anterior, com status sucesso, considera que a build é instável.
Nesse exemplo, acima de 5% para acréscimo de avg do response time é considerada build instável e acima de 10% a build ficará como falha.
% Taxa de Erro
Também é possível configurar a falha ou instabilidade por quantidade de falhas (se houver uma instabilidade no ambiente, devido aos últimos commits), por exemplo, conseguimos “barrar” e analisar esse comportamento configurando o % de falhas:
stage('4. Post Build - Analyzing Error Validate') {
steps {
perfReport errorFailedThreshold:0.5, errorUnstableThreshold:0.2, sourceDataFiles: 'substituir_caminho_nome_log.jtl'
}
}· errorFailedThreshold:0.5: Configurar com % que entende que acima desse valor para % de taxa de erro, considera que a build falhou.
· errorUnstableThreshold:0.2: Configurar com % que entende que acima desse valor para % de taxa de erro, considera que a build é instável (alerta).
Nota: Esse caso não é uma comparação, é analisado o % taxa de erro da build executada para classificação do status da build.
Nesse exemplo, acima de 0.2% a build é considerada instável e acima de 0.5% a build ficará como falha.
Importante: Lembrando que são números hipotéticos, exemplos de teste, mas para números reais entendemos que acima de 0,x% já pode ser um número alto (considerar o contexto de negócio, riscos, criticidade da aplicação). Não esqueça de levar isso em consideração em sua configuração.
2.Criação da Pipeline no Jenkins
No Jenkins o processo de criação da pipeline pode ser pela opção que você já referencia seu repositório, indicando onde está o código e jenkinsfile configurado:
Não vãos mostrar essa etapa passo a passo, focamos em comentar as informações relacionadas a configuração do plugin.
Havendo dúvidas pode consultar o vídeo Jenkins em 5mim — 03 Criando um freestyle job no Jenkins.
Espero ter trazido insights, um norte para começarem a implementar CI de Teste de Performance no projeto de vocês.
Em um próximo artigo traremos um exemplo em Azure DevOps.
Não deixem de validar performance!
Referências
Documentação Plugin Performance Jenkins
https://www.jenkins.io/doc/book/using/using-jmeter-with-jenkins/
https://jenkinsci.github.io/performance-plugin/Reporting.html
