Jean Pierre Lessa e Santos Ferreira

Incidentes mostram a cultura real de uma empresa de tecnologia

Leon Vardssen
Por Leon Vardssen

Como explica o executivo Jean Pierre Lessa e Santos Ferreira, um teste de capacidade aprovado pode ser mais perigoso do que um reprovado. O resultado verde traz confiança, e essa confiança só se justifica se o teste reproduziu o mundo real.

A contradição é comum. Equipes investem semanas em ferramentas de carga, geram relatórios com milhares de requisições por segundo e, na primeira grande campanha, veem o sistema ceder muito antes do número prometido. O teste não mentiu, mas mediu outra coisa.

Na maior parte das vezes, a distância entre o laboratório e a produção nasce de erros repetidos de empresa para empresa. Reconhecê-los é o caminho mais curto para um teste que de fato antecipa o comportamento do sistema. Leia a seguir e saiba mais.

Testar num ambiente que não se parece com produção

O erro mais frequente é usar um ambiente reduzido e multiplicar o resultado. Se três servidores aguentam mil usuários, supõe-se que doze aguentarão quatro mil. Essa conta ignora que banco de dados, cache e rede não crescem na mesma proporção que os servidores de aplicação.

Jean Pierre Lessa e Santos Ferreira aponta o volume de dados como a diferença que mais distorce resultados. Uma consulta que responde rápido numa base com mil produtos pode se arrastar num catálogo de milhões. Índices, planos de execução e uso de memória mudam com o tamanho real das tabelas.

O estado do cache também pesa. Um teste que começa com o cache cheio mostra um sistema mais rápido do que ele será logo após uma implantação. Vale executar os dois cenários, com cache aquecido e vazio, para conhecer o intervalo real de desempenho.

Simular usuários que não existem

Imagine mil robôs acessando a mesma página, ao mesmo tempo, sem pausa. Nenhum cliente real se comporta assim. Pessoas navegam, comparam, abandonam carrinhos e voltam minutos depois, e essa mistura de operações define onde o sistema sofre de verdade.

Jean Pierre Lessa e Santos Ferreira
Jean Pierre Lessa e Santos Ferreira

Um roteiro de carga convincente parte dos registros de acesso de produção. Ele reproduz a proporção entre buscas, visualizações e compras, inclui intervalos entre cliques e distribui as requisições entre muitos produtos diferentes, para que o cache não mascare o custo das consultas.

Olhar apenas a média e parar cedo

Um relatório que mostra tempo médio de 200 milissegundos pode esconder que um em cada cem clientes espera oito segundos. Por isso, os percentis altos precisam ser o critério de aprovação. Eles revelam a experiência de quem está mais perto de desistir da compra.

Em complemento, Jean Pierre Lessa e Santos Ferreira sugere levar o teste além da meta, até o ponto de ruptura. Saber que o sistema aguenta o volume esperado é útil. Saber em que carga ele quebra e de que forma é o que permite planejar a margem de segurança.

A duração é a outra variável negligenciada. Testes de poucos minutos não revelam vazamentos de memória nem conexões que deixam de ser liberadas. Execuções de várias horas, com carga constante, expõem essas falhas lentas que costumam derrubar sistemas no segundo dia de uma promoção.

Esquecer o que está fora do próprio sistema

Serviços de pagamento, antifraude e cálculo de frete raramente entram no teste com seus limites reais. Em geral, são substituídos por simuladores que respondem instantaneamente e sem cota, o que deixa de fora justamente os pontos com maior chance de travar no pico.

Justamente por isso, Jean Pierre Lessa e Santos Ferreira elucida que o teste precisa incluir as dependências externas, seja com parceiros avisados e ambientes de homologação dimensionados, seja com simuladores configurados para reproduzir latência e limites contratuais. Outro cuidado é verificar se o próprio gerador de carga não virou o gargalo.

Capacidade medida uma vez envelhece rápido

Cada nova funcionalidade altera o custo das requisições. Uma consulta a mais na página do produto, repetida milhões de vezes, pode consumir a folga medida no trimestre anterior. Um teste de capacidade isolado retrata um sistema que talvez já não exista.

Por essa razão, as operações mais maduras incorporam testes de carga menores ao ciclo de entrega de software e reservam os testes completos para antes das datas críticas. Assim, a capacidade deixa de ser uma fotografia antiga e se torna um indicador acompanhado continuamente.

Share This Article