Tudo o que achamos que é teste de Performance pode não ser nem 5% do que realmente é, e se alguém te vender que é somente usar uma ferramenta e pronto, desconfie, porque é muito mais do que isso.
Quando falamos de testes de performance logo nos vem as ferramentas (Jmeter,Gatling,k6 e outras), e uma grande parte da comunidade de qualidade usa tais ferramentas para validar se a aplicação é performática o suficiente, mas o que ninguém fala é que para testar performance precisamos saber muito mais do que ferramentas, é necessário ter conhecimento em como avaliar os resultados e métricas.
Recentemente tivemos um fórum sobre Performance dentro do chapter de Qualidade aqui dentro da idwall, onde os nossos QA’s especialistas em Performance (Amanda Gouveia e Tarso Roberto) responderam algumas dúvidas, descobrimos que esse mundo de performance é muito maior do que parece, e gostaríamos muito de compartilhar esse conteúdo com você.
Mas afinal, o que é teste de Performance, carga e stress? 🤔
Testar a performance é quando submetemos nas aplicações uma carga de trabalho em condições específicas a fim de observar diferentes comportamentos (nos quais podem trazer alguns questionamentos como o da imagem abaixo).
Com isso, podemos dizer que o teste de Performance é como se fosse um guarda-chuva, ele possui um conjunto de cenários diferentes de testes e cada um pode ter um objetivo, segue alguns tipos de testes:
Testes de fumaça (Smoke testing)
Nesses testes verificamos a funcionalidade bem básica da aplicação, usando um conjunto mínimo de testes ou scripts de performance que podem ser executados a cada interação de forma mais rápida. Caso queiram entender melhor esse teste indico esse artigo , mas usando a imagem abaixo como exemplo, a cada commit realizado nós rodamos em diversos ambientes e de forma mais ágil somente os cenários essenciais/críticos.
Testes de Estresse (Stress test)
É um teste que consiste em estressar a sua aplicação (enviaremos várias requisições até “quebrar”), ou seja, verificamos qual é o limite que o sistema “aguenta” receber requisições sem causar indisponibilidade.
Testes de Carga (Load test)
Para esse tipo de teste faremos vários acessos simultâneos, e o pré-requisito será conhecer a quantidade de requisições que a aplicação “aguenta”, no fim o objetivo é validar se em um período a aplicação perdeu alguma performance.
Testes de Pico (Spike test)
É quando geramos carga na aplicação simulando momentos de pico repentino.
Por exemplo: Quando uma loja faz uma promoção no site, geralmente a quantidade de clientes fazendo requisições é de 200 por minuto, de repente ela lança uma promoção e o salto de requisições é de 600 por minuto, durante essa situação você monitora a aplicação para ver se ela não irá causar uma queda de performance.
Testes de Longa Duração (Endurance test)
É um teste de longa duração que usa carga alta com o intuito de validar a disponibilidade da aplicação por esse período mais longo.
Testes de Volumetria
Nesse teste avaliamos o volume de informações processadas pela aplicação.
Testes de Escalabilidade
De acordo com esse artigo, o teste de escalabilidade refere-se a analisar como um sistema responde a alterações no número de usuários simultâneos (e a validação também pode ser feita em hardware, recursos de rede e bancos de dados). E podemos acrescentar, que também é uma maneira de validar estratégias de autoescala em sistemas de cloud.
Caso você tenha interesse em se aprofundar mais nos tipos de testes, sugiro que veja esse artigo.
Quando falamos de testes de performance, onde encontramos os requisitos para os testes, e caso não houver, como pensamos em testar a performance?
Na fase inicial temos 2 formas de abordar as informações para testar, que seriam:
Através de requisitos não-funcionais;
Ou de SLAs ou SLOs definidos;
Imagem explicando a diferença entre SLA e SLOs
SLA é um acordo de nível de serviço (entre empresa e cliente), onde o cliente estipula (muitas vezes em contrato) o tempo de resposta máximo que aquele serviço deve responder.
SLO é um objetivo de nível de serviço, que basicamente é o tempo de resposta que os times de tecnologia vão usar como referência.
Exemplo: O tempo máximo(aceitável) de resposta(SLA) é de 10s, mas o SLO é de 4s (que nesse caso o time de tecnologia internamente se comprometeu em entregar um resultado melhor para o cliente e dentro da expectativa dele).
Nos casos em que não temos requisitos, podemos ir para uma abordagem de:
Fazer um Benchmarking: onde comparamos com o padrão de mercado e podemos usar como exemplo uma premissa básica que seria o tempo de resposta acima de 500 ms, onde causaria percepção de lentidão pro cliente final.
Ou usar uma Baseline: que seria fazer uma comparação com desempenhos históricos (dentro da sua própria empresa). Nesse caso podemos fazer um comparativo com as últimas execuções de testes.
E quais são as ferramentas mais utilizadas para esses testes?
Para geração de massas que serão utilizadas na análise dos testes, podemos usar:
Apache Jmeter (mais utilizado);
LoadRunner (mais utilizado);
K6;
Gatling;
NeoLoad.
Para monitoração de volumetria ( onde entenderemos o comportamento das aplicações, e observar a execução dos testes/ e volumetria), podemos usar:
Dynatrace;
DataDog;
Grafana.
Logo das ferramentas de monitoração das ferramentas
A Amanda e o Tarso deram algumas dicas importantes quanto ao uso dessas ferramentas:
Para as ferramentas de monitoria, procure manter próximo o time de especialistas nessas ferramentas (por exemplo: time de Infra, CloudOPs,SRE’s — dependendo da empresa) e os desenvolvedores, o acompanhamento deles é muito importante, pois em caso de problemas essas pessoas podem ajudar a resolver.
E para os frameworks de massas de dados, é bem importante escolher uma ferramenta que seja útil ao seu time, existem algumas perguntas que podem te ajudar na hora da escolha:
Meu time conhece esse framework? Consigo escrever os scripts dos testes sozinho? Eu vou ter um bom suporte caso eu tenha dificuldade?
Essa ferramenta é performática? Se rodar os testes, eles terão uma boa performance?
Se essa ferramenta não for útil pro meu time, consigo converter o script para outra ferramenta com facilidade?
Entrando no assunto de métricas: quais são as principais métricas para Performance?
As métricas mais utilizadas são:
Média do tempo de resposta (mas não nos baseamos 100% nela, geralmente utilizamos com a métrica de Percentis);
Percentis (90,95,99) — esse artigo explica muito bem como funciona;
Percentual de erros;
Throughput — é utilizado para verificar quantas solicitações um software poderá processar por segundo, por minuto ou por hora;
Status code dos erros;
Apdex — que é um cálculo que mede a satisfação do usuário, indico esse artigo que pode te ajudar a entender melhor.
Métrica Bônus: Auditoria de performance em uma aplicação de Front-end
Quando falamos de validação de performance de aplicações back-end, o foco é o tempo da comunicação cliente-servidor, agora quando se trata de front-end avaliamos e monitoramos a performance da sua aplicação baseado em boas práticas como: respeito da hierarquia na estrutura do HTML da página, arquivos em cache, uso de estratégias de minificação de arquivos JS, a experiência do usuário, tempo de carregamento dos sites, e um exemplo de ferramenta que usamos seria: o LightHouse .
Exemplo de uma execução do LightHouse em uma página web
Um ponto bem importante a ser mencionado, é que testes de performance não é tão simples quanto usar ferramentas, entenda muito mais de métricas e arquitetura da aplicação porque elas te ajudarão a ser um bom profissional especialista no assunto.
Quando falamos sobre testes de Performance quais são os passos a passos que os times podem realizar?
Quando surge a necessidade de testar esses tipos de testes é muito importante:
Definir o baseline da aplicação;
Mapear os endpoints e o cálculo da volumetria;
Planejar a estratégia do tipo de testes (quais testes serão utilizados? É um teste de carga, estresse, endurance ou outro? ) e preparar os scripts;
Rodar os testes do tipo x y ou z de acordo com a necessidade;
Gerar os relatórios com as métricas x, y, z;
E apresentar para o time responsável pela aplicação com sugestões de melhorias.
Mas aí você pode trazer o questionamento: E se os resultados apresentados nos testes não forem satisfatórios, o que é importante fazer?
O que geralmente o time de performance faz nestes casos é:
É analisar os resultados gerados nos logs e relatórios;
Gerar relatórios com as informações dos testes e da análise efetuada;
Compartilhar os resultados para o que time responsável pela aplicação realize os ajustes necessários;
E planejar uma nova bateria de testes após as devidas correções.
Chegando ao final, algumas dicas importantes para saber o que aprender sobre performance:
Conheça o objetivo do teste de performance;
Entenda o cenário que será testado — por o teste ser importante para prevenção de possíveis problemas;
Aprenda e entenda sobre métricas;
Estude como criar e dar manutenção no script da ferramenta utilizada — saiba quais são as boas práticas porque quando criamos scripts complexos ou “ruins” eles impactam nos resultados dos testes/e relatórios;
Aprenda a coletar a volumetria;
Entenda o impacto dos testes na infra utilizada;
E compreenda os resultados dos testes para montar o report.
E aqui deixamos cursos e conteúdos que indicamos para quem quer se aprofundar nessa área:
Cursos:
Curso de K6 no BeeLab: https://treinamento.beelab.com.br/testes-de-perfomance-com-k6
Curso de K6 no Udemy: https://www.udemy.com/course/performance-test-primeiros-passos-com-o-k6/
Jmeter: https://www.udemy.com/course/testes-de-performance-com-jmeter-basico-ao-avancado/
Vídeos:
Canais no youtube: Automation Step By Step, PSTA: Performance & Security Testing Academy, DevTestsBR.
Trilha de testes de Performance do Júlio de Lima: https://www.youtube.com/watch?v=cED7k0YyNwA&list=PLf8x7B3nFTl0Xfw3lXu8XY-TsJrbREQJD
Livro:
High Performance Web Sites: Essential Knowledge for Front-End Engineers: https://www.amazon.com.br/High-Performance-Sites-Steve-Souders/dp/0596529309
Referência do conteúdo:
Apresentação sobre o tema da Amanda Gouveia e Tarso Roberto — QA’s de Performance na Idwall
https://github.com/grafana/k6-learn
Revisores do conteúdo técnico:
Amandarcgouveia
e Paulo Silva
Espero que tenham gostado do conteúdo e das dicas, e que esse material te ajude a aprender mais sobre essa área.Até mais!