A Black Friday de 2026 cai no dia 27 de novembro. Nas semanas que antecedem a data, boa parte das lojas virtuais faz a mesma coisa: investe em anúncio, monta a oferta, avisa a lista de e-mail e torce. Ninguém sabe de verdade se o site vai aguentar o dia em que mais gente vai tentar comprar ao mesmo tempo.
O problema é que “entrar na loja e comprar um produto para testar” não responde essa pergunta. Com uma pessoa por vez, quase todo site funciona. O que quebra, e quebra justo no dia de maior faturamento, só aparece quando muita gente chega junto.
Este artigo explica, sem jargão, o que é teste de carga, o que ele revela que o teste manual nunca revela e o que você deve perguntar para quem cuida da sua loja antes do próximo pico. No meio do caminho, mostro um caso real que executei: uma camiseta em estoque e 300 tentativas de compra no mesmo instante.
Teste de carga é um ensaio do dia de pico, feito antes do dia de pico. Em vez de esperar o movimento real chegar, você simula muita gente usando a loja ao mesmo tempo, de forma controlada, e mede o que acontece.
A confusão mais comum é achar que o teste serve só para medir velocidade. Ele responde três perguntas diferentes:
| Pergunta | O que o teste mostra |
|---|---|
| A loja continua no ar? | Se o site cai ou fica fora do ar quando o volume sobe. |
| A loja continua rápida? | Se o tempo de resposta degrada a ponto de o cliente desistir. |
| A loja continua correta? | Se as regras de negócio (estoque, preço, cupom, pedido) seguem certas quando tudo acontece junto. |
As duas primeiras perguntas todo mundo lembra. A terceira é a que quase ninguém testa, e é a que mais custa caro.
Uma loja pode falhar de três formas no dia de maior venda:
O terceiro tipo é o mais perigoso justamente porque nenhum monitoramento de “site no ar” o detecta. A loja está funcionando. Só está funcionando errado.
Para mostrar o terceiro tipo de falha com número, e não com opinião, montei um caso técnico público. O cenário é simples: uma camiseta em estoque e 300 tentativas de compra ao mesmo tempo.
Construí duas versões do fechamento de pedido:
O resultado, em 1 unidade de estoque e 300 requisições simultâneas:
| Versão | Pedidos aceitos |
|---|---|
| Ingênua | Entre 2 e 300, e nunca 1 (10 execuções registradas) |
| Correta | Exatamente 1, em todas as execuções |
Nas dez execuções da versão ingênua, o número de pedidos aceitos foi 300, 300, 300, 290, 300, 3, 300, 300, 300 e 2. O valor muda a cada rodada porque depende do instante exato em que as requisições chegam. O que não muda é que a versão ingênua nunca vendeu apenas uma camiseta.
Pense em um balcão com uma camiseta na prateleira e 300 pessoas chegando no mesmo segundo. No sistema ingênuo, o atendente olha a prateleira, confirma que tem camiseta e só depois risca uma no caderno. Como as 300 pessoas olham a prateleira antes de qualquer uma riscar o caderno, todas veem a camiseta e todas passam. No sistema correto, olhar e riscar são um gesto único. O primeiro leva a camiseta, e para os outros a prateleira já está vazia.
Esse bug funciona perfeitamente com um cliente por vez. É por isso que o teste manual jamais o encontra, e é por isso que ele aparece no pico. Você pode ver o passo a passo completo, com código e testes, no case técnico de venda duplicada de estoque.
Um detalhe do caso mostra bem o valor de testar em ambiente limpo: ao rodar tudo numa máquina nova, o teste automatizado encontrou um defeito que o meu computador escondia. A configuração do banco de dados guardada no repositório estava incompleta, e só funcionava na minha máquina porque o ambiente local tinha sido montado antes. Sem rodar do zero, esse problema só apareceria quando outra pessoa tentasse usar o projeto.
Muita loja acha que está coberta porque tem alguma forma de verificação. Na prática, cada tipo de teste enxerga uma parte do problema:
| Tipo de verificação | O que ela não percebe |
|---|---|
| Teste manual (você compra um item) | Qualquer problema que só aparece com várias pessoas ao mesmo tempo. |
| Nota de velocidade da página | Se o fechamento do pedido continua correto sob volume. |
| Monitoramento de site no ar | Erros de regra de negócio, porque o site continua respondendo normalmente. |
| Teste de carga com regra de negócio | Só cobre os cenários que foram escritos. O que não foi testado não está protegido. |
A última linha é a mais honesta: teste de carga não é um selo de qualidade geral. Ele garante que aquelas situações específicas se sustentam, e por isso a escolha dos cenários importa tanto quanto a execução.
Se você só tem tempo para poucos cenários, priorize os que envolvem dinheiro ou promessa ao cliente:
Não precisa testar tudo. Precisa testar o que, se der errado, vira cancelamento, reembolso ou reclamação.
Essas perguntas funcionam como um filtro. Quem cuida bem da loja responde sem enrolar:
Se alguma resposta for “não sei” ou “nunca testamos”, você acabou de descobrir onde está o risco. Se quiser um roteiro mais amplo de itens para cobrar do seu site, o checklist técnico que toda empresa deveria exigir do próprio site complementa este.
O ideal é testar com antecedência, porque corrigir o que o teste encontra leva tempo. Um cronograma realista:
Se faltam poucas semanas para a data, vá direto ao essencial: fechamento de pedido de itens com pouco estoque, cupom limitado e confirmação de pagamento repetida. Esses três cobrem a maior parte das perdas silenciosas.
Você não precisa de um teste para desconfiar. Alguns sinais indicam que vale testar antes da próxima campanha:
Se dois ou mais se aplicam, trate o teste como prioridade, não como luxo.
Um conteúdo sério diz onde ele para de valer. No meu caso, por exemplo:
O mesmo vale para a sua loja: um teste prova o que ele mediu. Se o site mudou depois, ou se o volume real passou do volume simulado, é preciso testar de novo.
Não existe um preço único, porque o custo depende do tamanho da loja, de quantos fluxos precisam ser cobertos e de como o ambiente está montado. O que dá para dizer é onde o esforço realmente está: no caso que descrevi, reproduzir o teste custa R$ 0 em licenças e infraestrutura, mas o maior gasto de tempo foi montar o ambiente, não escrever o código da correção.
Compare isso com o custo de um dia de pico com pedidos cancelados, reembolsos, atendimento sobrecarregado e avaliação ruim. Para a maioria das lojas, testar custa menos do que errar uma vez.
Quem deve fazer? Alguém que entenda tanto do negócio quanto do código do checkout, porque o teste mais útil é o que simula uma regra da sua loja, e não um teste genérico. É esse tipo de trabalho que faço em projetos de desenvolvimento sob medida e na manutenção contínua de sites, seja antes de uma data de pico ou como rotina.
É a simulação controlada de muitos clientes usando a loja ao mesmo tempo, para medir se o site continua no ar, rápido e correto. Ele serve para descobrir problemas antes de o movimento real chegar.
Não. O teste de velocidade mede como uma página carrega para uma pessoa. O teste de carga mede o comportamento do sistema com muita gente ao mesmo tempo, incluindo se as regras de negócio continuam certas.
Sim, porque o erro mais caro nem derruba o site. Ele aceita pedidos a mais do que o estoque, e só aparece quando muita gente compra junto. Uma loja que nunca caiu pode nunca ter sido exposta a esse tipo de pico.
Com pelo menos duas a quatro semanas de antecedência de uma data de pico, para ter tempo de corrigir e testar de novo. Se o tempo está curto, concentre-se nos cenários que envolvem estoque, cupom limitado e pagamento.
Sim. Qualquer alteração relevante no fechamento de pedido, no estoque ou na integração com pagamento pode reintroduzir o problema. Um teste vale para o site do jeito que ele estava quando foi rodado.
Pergunte o que acontece quando duas pessoas compram a última unidade no mesmo segundo. Quem já testou responde com um resultado. Quem nunca testou costuma responder com uma suposição.
Sim. O código e os testes estão em um repositório público, e o passo a passo está no case técnico.
O dia de maior venda é o pior momento para descobrir um problema. A maioria das falhas que custam dinheiro de verdade não derruba o site, e por isso passa por qualquer verificação superficial. Elas só aparecem quando muita gente compra junto, e só um teste que simule esse cenário consegue mostrar.
Se a sua loja tem estoque limitado, cupons com quantidade, vendas em vários canais ou uma campanha forte chegando, vale rodar esse tipo de teste antes da data, não depois. Se quiser ajuda para definir os cenários e executar o teste no seu checkout, posso fazer isso como desenvolvedor freelancer: do levantamento do que pode dar errado até o resultado em número, com a correção quando for preciso. Você também pode falar comigo direto.
Gustavo Assis. “300 compras para 1 item em estoque: como evitar venda duplicada”. Case técnico com o cenário, os números das 10 execuções, a lógica explicada para lojistas e para devs, os limites conhecidos e o passo a passo para reproduzir.
Repositório público do case (código, testes e histórico). Contém os testes automatizados que rodam localmente e em ambiente limpo.
Entenda o que é overselling, por que a loja vende mais unidades do que existem, quanto isso custa e como evitar a venda duplicada de estoque, com um caso real de 300 compras para 1 item.
E-commerce lento afasta clientes e derruba vendas. Descubra as causas reais, como diagnosticar cada gargalo e como resolver com precisão técnica em WooCommerce e OpenCart.
Guia prático para preparar seu site para a pesquisa multimodal do Google, com HTML de imagem, sitemap, dados estruturados, performance e medição no Search Console.
