Estratégias de teste de carga para aplicativos da Web: encontre pontos de ruptura antes que os usuários o façam

80% dos problemas de desempenho são descobertos pelos usuários finais, não por meio de testes. Os testes de carga invertem essa proporção simulando padrões de tráfego reais em seu aplicativo antes que os usuários encontrem problemas. A diferença entre um site que lida com o tráfego da Black Friday e outro que trava é quase sempre se alguém executou um teste de carga primeiro.

Este guia cobre metodologia de teste de carga, seleção de ferramentas, design de teste e interpretação de resultados para aplicativos da web, plataformas de comércio eletrônico e sistemas ERP.

Principais conclusões

• O teste de carga deve simular um comportamento realista do usuário, e não apenas martelar um único endpoint
• Estabeleça linhas de base de desempenho antes de otimizar --- você não pode melhorar o que não mediu
• Executar testes de carga em ambiente de produção; os resultados da preparação podem não refletir o comportamento da produção
• Automatize testes de carga em CI/CD para detectar regressões de desempenho antes da implantação

---

Tipos de testes de carga

---

Teste de carga com k6

Teste de carga básico

// k6/load-test.js
import http from 'k6/http';
import { check, sleep } from 'k6';

export const options = {
  stages: [
    { duration: '2m', target: 50 },   // Ramp up to 50 users
    { duration: '5m', target: 50 },   // Stay at 50 users
    { duration: '2m', target: 100 },  // Ramp up to 100 users
    { duration: '5m', target: 100 },  // Stay at 100 users
    { duration: '2m', target: 0 },    // Ramp down
  ],
  thresholds: {
    http_req_duration: ['p(95)<500', 'p(99)<1000'],
    http_req_failed: ['rate<0.01'],
    http_reqs: ['rate>100'],
  },
};

export default function () {
  // Simulate realistic user behavior
  const homeResponse = http.get('https://example.com/');
  check(homeResponse, {
    'homepage status is 200': (r) => r.status === 200,
    'homepage loads in under 1s': (r) => r.timings.duration < 1000,
  });
  sleep(Math.random() * 3 + 1); // 1-4 seconds think time

  const productsResponse = http.get('https://example.com/api/v1/products');
  check(productsResponse, {
    'products API is 200': (r) => r.status === 200,
    'products API under 500ms': (r) => r.timings.duration < 500,
  });
  sleep(Math.random() * 2 + 1);
}

Teste de jornada do usuário de comércio eletrônico

// k6/ecommerce-journey.js
import http from 'k6/http';
import { check, group, sleep } from 'k6';

export const options = {
  scenarios: {
    browsing: {
      executor: 'ramping-vus',
      startVUs: 0,
      stages: [
        { duration: '5m', target: 200 },
        { duration: '10m', target: 200 },
        { duration: '5m', target: 0 },
      ],
      exec: 'browsingScenario',
    },
    purchasing: {
      executor: 'ramping-vus',
      startVUs: 0,
      stages: [
        { duration: '5m', target: 20 },
        { duration: '10m', target: 20 },
        { duration: '5m', target: 0 },
      ],
      exec: 'purchaseScenario',
    },
  },
  thresholds: {
    'http_req_duration{scenario:browsing}': ['p(95)<800'],
    'http_req_duration{scenario:purchasing}': ['p(95)<2000'],
    http_req_failed: ['rate<0.01'],
  },
};

export function browsingScenario() {
  group('Browse Products', () => {
    http.get('https://store.example.com/');
    sleep(2);
    http.get('https://store.example.com/products');
    sleep(3);
    http.get('https://store.example.com/products/sample-product');
    sleep(2);
  });
}

export function purchaseScenario() {
  group('Purchase Flow', () => {
    // Browse
    http.get('https://store.example.com/products/sample-product');
    sleep(1);

    // Add to cart
    http.post('https://store.example.com/api/cart', JSON.stringify({
      productId: 'prod_123',
      quantity: 1,
    }), { headers: { 'Content-Type': 'application/json' } });
    sleep(2);

    // Checkout
    http.get('https://store.example.com/cart');
    sleep(3);

    // Place order (simulated)
    const orderResponse = http.post('https://store.example.com/api/checkout/validate', JSON.stringify({
      email: `test-${__VU}@example.com`,
    }), { headers: { 'Content-Type': 'application/json' } });

    check(orderResponse, {
      'checkout validates': (r) => r.status === 200 || r.status === 201,
    });
    sleep(1);
  });
}

Teste de estresse (encontre o ponto de ruptura)

// k6/stress-test.js
import http from 'k6/http';
import { check } from 'k6';

export const options = {
  stages: [
    { duration: '2m', target: 100 },
    { duration: '5m', target: 100 },
    { duration: '2m', target: 200 },
    { duration: '5m', target: 200 },
    { duration: '2m', target: 500 },
    { duration: '5m', target: 500 },
    { duration: '2m', target: 1000 },
    { duration: '5m', target: 1000 },
    { duration: '5m', target: 0 },
  ],
};

export default function () {
  const res = http.get('https://example.com/api/v1/products');
  check(res, {
    'status is 200': (r) => r.status === 200,
  });
}

---

Interpretando resultados

Principais métricas

Padrões comuns de gargalos

Gargalo vinculado à CPU: o tempo de resposta aumenta linearmente com a carga. P95 e P99 divergem lentamente.

• Correção: otimize caminhos de código ativo, adicione capacidade de CPU ou dimensione horizontalmente

Gargalo do banco de dados: o tempo de resposta aumenta exponencialmente em um limite de carga específico. Esgotamento do conjunto de conexões.

• Correção: otimização de consulta, pool de conexões, réplicas de leitura (consulte guia de escalonamento de banco de dados)

Gargalo de memória: degradação gradual ao longo do tempo. As pausas do GC causam picos de latência.

• Correção: Aumente a memória, corrija vazamentos de memória, otimize a alocação de objetos

Gargalo de rede: o tempo de resposta aumenta uniformemente em todos os endpoints. Saturação de largura de banda.

• Correção: CDN para ativos estáticos, compactação, redução do tamanho da carga útil

---

Linhas de base de desempenho

Estabelecendo uma linha de base

Antes de otimizar, documente seu desempenho atual:

# Run baseline test
k6 run --out json=baseline-results.json k6/load-test.js

# Compare after optimization
k6 run --out json=optimized-results.json k6/load-test.js

Orçamento de desempenho

Defina o desempenho aceitável para cada endpoint:

---

Integração CI/CD

Teste automatizado de regressão de desempenho

# .github/workflows/performance.yml
name: Performance Test
on:
  push:
    branches: [main]

jobs:
  load-test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Run k6 load test
        uses: grafana/k6-action@v0.3.1
        with:
          filename: k6/load-test.js
          flags: --out json=results.json
        env:
          K6_TARGET_URL: ${{ secrets.STAGING_URL }}

      - name: Check thresholds
        run: |
          if grep -q '"thresholds":{".*":"fail"' results.json; then
            echo "Performance thresholds exceeded!"
            exit 1
          fi

---

Lista de verificação de teste de carga

Antes do teste

• [] O ambiente corresponde à produção (tipos de instância, tamanho do banco de dados)
• [] Os dados de teste são representativos (contagem realista de produtos, contagem de usuários)
• [] O monitoramento está ativo (rastreie as métricas do servidor durante o teste)
• [] As partes interessadas são notificadas (testes de carga podem disparar alertas)
• [] CDN e cache são configurados como em produção

Durante o teste

• [] Monitorar CPU do servidor, memória, E/S de disco
• [] Monitore conexões de banco de dados e latência de consulta
• [] Observe os aumentos na taxa de erro
• [] Verifique o esgotamento de recursos (descritores de arquivos, conexões)
• [] Observe o nível de carga onde o desempenho diminui

Após o teste

• [] Documentar resultados de linha de base
• [] Identificar gargalos e seus limites de carga
• [] Criar tickets para melhorias de desempenho
• [] Comparar com o orçamento de desempenho
• [] Agendar teste de acompanhamento após otimizações

---

Perguntas frequentes

Devemos carregar a produção ou teste de teste?

Ambos, se possível. Preparação para testes regulares e integração CI/CD. Produção para validação periódica (durante horários de baixo tráfego), porque a preparação geralmente difere no tamanho do banco de dados, na capacidade do cache, na configuração do CDN e na topologia da rede. Se você puder testar apenas um ambiente, teste a preparação, mas torne-a o mais parecida com a produção possível.

Com que frequência devemos executar testes de carga?

Testes de fumaça em cada implantação (automatizados em CI/CD). Testes de carga completa semanalmente ou antes dos principais lançamentos. Testes de estresse trimestralmente ou antes de eventos conhecidos de alto tráfego (vendas, lançamentos). Faça testes trimestrais para detectar vazamentos de memória e degradação de longo prazo.

Como testamos a carga de um sistema ERP?

O teste de carga do ERP requer a simulação de usuários simultâneos executando diferentes tarefas: geração de faturas, criação de pedidos de compra, execução de relatórios, importação de dados. Concentre-se nas operações mais pesadas (geração de relatórios, importação de dados) e nas operações mais simultâneas (entrada de pedidos em horários de pico). ECOSIRE fornece testes de desempenho Odoo como parte de nossos serviços de suporte.

Qual é o tempo de reflexão realista entre as solicitações?

Para navegação em comércio eletrônico: 2 a 5 segundos. Para preenchimento de formulário: 10-30 segundos. Para finalização da compra: 15-60 segundos. Para uso administrativo/ERP: 5 a 15 segundos. Sempre adicione tempo de reflexão aleatório aos seus testes de carga – intervalos constantes criam padrões de carga sincronizados irrealistas.

---

O que vem a seguir

O teste de carga revela gargalos que orientam seus esforços de otimização. Acompanhe com escalonamento de banco de dados para gargalos de banco de dados, otimização de CDN para entrega de ativos estáticos e escalonamento automático para capacidade elástica.

Entre em contato com a ECOSIRE para testes de desempenho e otimização ou explore nosso guia DevOps para obter a estratégia de infraestrutura completa.

---

Publicado pela ECOSIRE – ajudando empresas a criar aplicativos que funcionam sob pressão.