O termo “esportes de endurance” foi se tornando mais comum ao longo do tempo e quer dizer “resistência”. Algumas modalidades tradicionais de endurance são corridas, ciclismo e Ironman. Trata-se de esportes em que é preciso resistir a um determinado tipo de esforço por muito tempo, horas ou até mesmo dias. Mas você já ouviu falar de Endurance Test?
Voltando aos esportes, o interessante é que, provavelmente, você não resistirá por muito tempo utilizando sua capacidade máxima. É preciso estar abaixo disso, caso contrário você não irá aguentar um longo período (guarde esta analogia, ela será utilizada mais para frente).
Mas o que isso tem a ver com Endurance Test? Confira este artigo que nós vamos explicar!
O que é o Endurance test?
O Endurance Test, também conhecido como soak test, é um tipo de teste não funcional para testar a resistência de um software. Ele se preocupa com a confiabilidade relacionada a um número crescente (ou constante) de usuários por um longo período de tempo. Com isso, é possível garantir que um software suporta/resiste a uma determinada carga de usuários por um período de tempo pré-estabelecido.
Esse tipo de teste revela problemas que surgem apenas após horas ou dias de uso. Isso é o grande diferencial do Endurance Test: nenhum outro é capaz de identificar questões que se manifestam nestes casos.
Em um planejamento, o Endurance Test é um dos últimos testes executados, porque, historicamente, é um dos tipos que revela menos erros, porém, normalmente, são de alta criticidade e complexos para serem corrigidos.
Como executar um Endurance test?
Como esse teste é feito por um longo período de tempo, geralmente deve ser feito nos finais de semana, durante a noite ou mesmo reservando um período estratégico maior (caso esteja contemplado na estratégia de testes). Com esses cuidados, é possível garantir o mínimo de interrupção para a equipe de desenvolvimento, além de evitar influências externas.
Devido à longa duração do Endurance Test, ele precisará ser conduzido com a ajuda de uma ferramenta de automação apropriada e, portanto, sua equipe precisará possuir o conhecimento técnico para executá-lo. Qualquer ferramenta de teste de performance de mercado, possivelmente, conseguirá realizar essa tarefa.
Um ponto importante é a disponibilidade de ambiente. Como estes testes podem ser executados por dias, é necessário ter alta disponibilidade. Afinal, você não vai querer que seu ambiente fique indisponível nos últimos minutos de um teste que pode estar rodando por dias, certo?
O Endurance Test segue uma lógica muito parecida com a dos testes de performance mais tradicionais. Normalmente, um teste de performance “normal” pode durar alguns minutos, horas, mas dificilmente vai ultrapassar dias. Porém, em um teste de endurance isso pode ser comum.
Normalmente, o sistema é submetido a uma quantidade média de usuários (por dia, semana, mês ou ano), com base em um histórico de acessos já existente.
Vejamos o exemplo: durante um ano, a média de usuários acessando simultaneamente o sistema é 100. Não faz sentido utilizar 1000. Para o acesso de um grande número de usuários em um determinado período (como em época de Black Friday) outros tipos de teste de performance são indicados.
Outra abordagem para definir a quantidade de usuários é utilizar 80% da capacidade do sistema. Por exemplo: se seu sistema suporta 100 usuários simultâneos, realize o teste de endurance com 80.
Quando se trata de um sistema novo, que ainda não está no mercado, é recomendado ter um requisito não funcional para identificar a quantidade média de usuários x tempo de execução x tempo de resposta de um processo. Imaginando que o sistema não suporte esta quantidade de usuários por um determinado período, o mais comum a ser feito é corrigir o sistema. Em últimos casos (desde que alinhado com os stakeholders), corrigir o requisito.
O planejamento nestes tipos de teste é importante, porque é necessário contar com um hardware específico, cenários de testes definidos, datas, expectativas, etc.
Objetivos do Endurance test
O objetivo básico do Endurance Test é garantir que o sistema se comporte exatamente da mesma maneira no final e no início do teste. O uso contínuo do sistema por usuários de forma simultânea não pode deteriorar o funcionamento. Além destes, temos mais algumas metas, como por exemplo:
- Determinar o número de usuários que o sistema suporta durante longos períodos de uso (principalmente no caso de sistemas novos);
- Identificar se o sistema está com algum bug relacionado ou se de fato os requisitos mínimos para funcionamento do sistema precisam ser revistos;
- Identificar crash no sistema;
- Identificar problemas em conexões com banco de dados ou outras partes do sistema;
- Encontrar problemas referente a limites de armazenamento;
- Problemas relacionados a grandes quantidades de dados gerados;
- Identificar problemas de concorrência que podem ocorrer apenas em longos períodos de uso;
- Problemas na geração de logs;
- Garantir que serviços externos continuem funcionando após um longo período de uso.
Mas o principal objetivo é ficar de olho em vazamentos de memória. Este é o principal e, com certeza, o erro mais grave que esse tipo de teste pode revelar.
Os principais sintomas de vazamento de memória são o aumento no consumo com uma mesma quantidade de usuários ou mesmo consumo de memória alta após o término do teste. Também podemos monitorar o tempo de resposta do sistema, assim como identificar como o sistema está se comportando referente a conexões.
É importante lembrar que, normalmente, os erros de endurance estão relacionados ao tempo, e não ao número total de requisições executadas.
Exemplo prático
Abaixo, temos um exemplo de código clássico, utilizando o K6, disponível aqui.
Veja que o diferencial aqui é que o teste irá executar por 3 horas e 56 minutos, utilizando 400 usuários simultâneos.
import http from ‘k6/http’;
import { sleep } from ‘k6’;
export const options = {
stages: [
{ duration: ‘2m’, target: 400 }, // Escalando para 400 usuários simultâneos em um período de 2 minutos
{ duration: ‘3h56m’, target: 400 }, // 400 usuários simultâneos acessando o sistema por 3 horas e 56 min
{ duration: ‘2m’, target: 0 }, // Retornando gradualmente a 0 usuários em 2 minutos
],
};
const API_BASE_URL = ‘https://test-api.k6.io’;
export default function () {
http.batch([
[‘GET’, `${API_BASE_URL}/public/crocodiles/1/`],
[‘GET’, `${API_BASE_URL}/public/crocodiles/2/`],
[‘GET’, `${API_BASE_URL}/public/crocodiles/3/`],
[‘GET’, `${API_BASE_URL}/public/crocodiles/4/`],
]);
sleep(1);
}
A execução deste teste gera um gráfico similar a este:
Conclusão sobre o tema
Concluímos que o Endurance Test não é um teste muito comum. Muitas empresas acabam não executando por ser necessário uma estratégia mais bem elaborada, disponibilidade de recursos, além do fato de o número de erros historicamente encontrados ser baixo.
Realizar uma análise de riscos também é essencial: se um erro de vazamento de memória existir, qual o impacto para os seus clientes? Como estes erros são complexos de serem corrigidos, pode ser que seu sistema fique inutilizável por muito tempo, acarretando prejuízos e riscos em diversos níveis.
Normalmente, os erros mais graves são encontrados apenas pelo Endurance Test, por isso é extremamente importante considerá-lo em um planejamento estratégico.
