O que deveríamos considerar ao traçar a melhor estratégia para o Teste de Performance?

Ariane Izac
Elo — Tecnologia e Inovação
6 min readMay 31, 2023
Performance

Quando falamos sobre teste de performance muitos focam somente em aprender ferramentas que vão ajudar simular os usuários virtuais (como Jmeter, K6, etc) ou ferramentas que vão ajudar a monitorar a aplicação (como DataDog, NewRelic, etc). É evidente que esses itens são essenciais, no entanto, é necessário pensarmos além das ferramentas.

É importante lembrar das etapas do teste de performance:

Principais etapas do Teste de Performance

E dentre essas etapas, é no planejamento que traçamos a melhor estratégia a ser adotada para garantir a efetividade e assertividade do teste de performance.

O foco desse artigo é detalhar os tópicos listados abaixo que podem ajudar a deixar sua estratégia mais robusta:

Estratégias de Teste de Performance

1. Definir os Critérios de Aceite

Os critérios de aceite são as métricas a serem atingidas baseado no contexto/necessidade de negócio.

As métricas mais comuns aplicadas em critérios de aceite são TPS (Transações por Segundo) e tempo médio de resposta.

Mas no geral, outras métricas, como o % de erros (se a taxa for alta pode indicar problemas na aplicação), % de consumo de recursos computacionais, memória e CPU, são importantes.

Nunca analise uma métrica isolada, faça a interpretação do cenário baseado no conjunto de métricas.

2. Definir o Escopo e Não Escopo do Teste de Performance

Nos alinhamentos da demanda de performance falamos sobre o escopo, e é na estratégia que ele será consolidado.

Só podemos partir para o script com o cenário do teste de performance definido.

Alguns pontos importantes que podem influenciar na definição do fluxo de cada cenário são:

· Definição dos passos da jornada (quando web)

Jornada do usuário prevista com volume que será percorrida, por exemplo, realizar cadastro, quais janelas/campos importantes a serem contemplados.

· Parâmetros API

Quando API, entender quais parâmetros são passados. Às vezes opta-se por passar somente os obrigatórios sem considerar como de fato essa API será chamada no cenário real e isso pode influenciar nos resultados/gaps que estamos buscando.

· Integrações

Entre as aplicações, entender quando faz sentido usar mock ou não?

Além do escopo, é indicado deixar claro o que se trata de não escopo, ou seja, que não será tratado nesse teste de performance. Pode ser um cenário específico, a utilização de mocks, enfim, sempre levando em consideração com os riscos e criticidades envolvidos.

3. Identificar se existem Integrações

Entrando mais no detalhe de integrações, é muito importante na estratégia pensar nos possíveis impactos em fazer teste integrado, ou fazer o teste isolado.

Sempre procure trazer uma visão sistêmica, ponderando criticidade e riscos para negócio. Entender se o fluxo que está validando a performance, não afeta um próximo passo/etapa que seja crítico.

4. Definir Tipo de Teste de Performance a ser aplicado

Baseado no objetivo, ou seja, entendido o que queremos encontrar com teste de performance, é necessário selecionar qual/quais tipos de teste de performance mais adequados a aplicar. Pode ser Teste de Carga, Capacidade, Estresse, Escalabilidade, Pico, Resistência e Concorrência.

Nota: Para maiores informações sobre Tipos de Teste de Performance, veja o tópico 1.2 Tipos de Teste de Performance o Sylllabus da CT-PT Performance Testing https://bstqb.org.br/b9/sobre-ctfl-pt

5. Identificar Massa de Dados para utilização no script

A massa de dados é de extrema importância para assertividade do teste.

É preciso projetar no script a massa de dados pensando que será usada em larga escala, pensar nos campos chave, pré-cadastrados, campos que daria para usar variáveis com valores randômicos. Além de considerar reutilização, portanto, a massa e sua estrutura devem ser reprocessáveis.

Leve em consideração para aplicações já existentes insumos de uso em produção.

6. Definir Quantidade de Usuários Virtuais (Threads)

Os usuários virtuais ajudam a simular um cenário com concorrência, utilizando Threads para reproduzir as chamadas como o usuário/outra aplicação integrada faria em maior escala, simultaneamente.

Uma dúvida comum é quantas Threads utilizar? Como fazer a distribuição da carga? Como reproduzir o teste de forma que os usuários virtuais estejam próximos dos reais?

É importante ressaltar que não teremos uma resposta pronta, dependerá do objetivo do teste baseado no contexto de negócio da aplicação.

Alguns tópicos a serem considerados para chegar nessas respostas:

· Quantidade de usuários esperado simultâneos:

Em casos que já temos um determinado pico esperado de usuários simultâneos, o teste pode ser estruturado para avaliar o comportamento da aplicação diante dessa quantidade de usuários versus critérios de aceite estabelecido, se a aplicação atende a carga esperada respeitando os tempos de resposta aceitáveis.

Nota: Nesse caso, para jornada web, precisamos considerar o thinking time, ou seja, o tempo entre a as ações do usuários na navegação, deixando um usuário virtual bem próximo do real.

Por exemplo, o tempo entre clicar em um botão cadastrar, preencher os campos do formulário e clicar em salvar. Uma Thread não equivale a 1 usuário real sem considerar esses tempos de interações.

· Quantidade de usuários para alcançar um TPS:

Se o principal foco do teste é atender um determinado TPS, baseado no tempo médio de resposta é possível fazer um cálculo de quantos usuários virtuais precisaríamos no teste, sempre considerando uma gordura pois naturalmente com aumento da carga aumenta um pouco o tempo de resposta.

Essa calculadora pode ajudar: https://calculator.academy/tps-calculator/

· Distribuição da carga

Vai depender da projeção que tiver para montagem do cenário.

Por exemplo: Um cenário onde se tem 20% de uma API realizando cadastro e 80% consulta que podem serem acessados simultaneamente, essa deveria ser sua distribuição da carga, mas poderia ter nesse cenário tipos de cadastros diferentes que passam por fluxos diferente no código que precisaria distribuir a carga. Análise o seu contexto para a decisão de distribuição.

7. Definir Ambiente de Testes

A definição do ambiente de teste vai ser o alicerce para execução da bateria de performance.

É importante considerar um ambiente com mais capacidade para a máquina injetora para execução do script.

Uma pergunta frequente aqui é qual tamanho do ambiente? Deveria ser uma réplica do ambiente de produção?

Sabemos que ter uma réplica de ambiente de PRD em ambientes de homologação por questões de custos é praticamente inviável, o que não é um problema desde que façamos projeções e respeitamos os limites de cada ambiente.

8. Definir Ramp-up e Duração da Bateria

O ramp-up é a forma com que usamos para ir incrementando as Threads até chegar na carga máxima do teste, chamado de steps. Em testes de performance, tentamos simular o mais próximo do real, o ideal é incrementar a carga gradativamente (a não ser que seja um teste de pico), para acompanhar melhor o comportamento da aplicação, principalmente, em momentos de ruptura, que pode ser restarts no sistema, instabilidade, aumento do tempo de resposta, etc.

Quanto a duração da bateria, sempre considere o contexto que será analisado. Uma dica, pensando em tempo de execução na carga máxima é de no mínimo de 20 minutos para acompanhar possíveis degradações do ambiente trabalhando em maior tempo com maior volume, consumirá mais recursos nesse período.

Um exemplo de ramp-up mais carga máxima no Jmeter com o plugin bzm — Concurrency Thread Group (https://jmeter-plugins.org/wiki/ConcurrencyThreadGroup/ ):

Nesse exemplo temos:

5 minutos de ramp-up, ou seja, nos 5 primeiros minutos da bateria estamos subindo a carga, 1Thread de cada vez de 8 em 8s, até chegar em 30Threads.

Chegando na carga máxima, no exemplo o total de 30 Threads, a bateria é executada por mais 25 minutos.

Nesse caso, o total da bateria são 30 minutos.

Conclusão

Para concluir, dado todos esses itens que precisamos considerar pensando somente em estratégias, fica evidente que o teste de performance não é só desenvolver um script e executar. São inúmeros fatores e passos que vão compor o teste de performance. Entenda os conceitos da disciplina, olhe para cada o contexto e pondere os pontos listados para traçar a melhor estratégia do teste de performance para seu cenário, de forma que os testes tragam mais segurança para os deploys em produção.

Sugestão de Materiais complementares

Testes de performance e suas estratégias (Fala Galera! 7&7 Ep. 9):

https://www.youtube.com/watch?v=Qy6qaMZbVCE

Sylllabus da CT-PT Performance Testing:

https://bstqb.org.br/b9/sobre-ctfl-pt

Thinking Time: https://www.perfmatrix.com/think-time/

Mais sobre conceitos de Performance e Jmeter — Workshop sobre primeiros passos em testes de performance:

DIA 1 — Conceitos de performance: https://lnkd.in/daTTQMbC
DIA 2 — Conceitos do JMeter: DIA 2 — https://lnkd.in/dQggqwiS
DIA 3 — Análise e feedback ao vivo dos desafios: https://lnkd.in/dNiH8V-9

--

--

Ariane Izac
Elo — Tecnologia e Inovação

Especialista em testes de performance em transição para SRE. Apaixonada por testes, qualidade de software, especialmente, performance.