k6 vs Artillery: qual ferramenta de teste de carga escolher

k6 e Artillery são ferramentas de teste de carga open source em que os testes são escritos como código, e qualquer uma das duas testa bem uma API HTTP sob carga. Escolha o k6 se você quer um único binário, a lógica do teste em JavaScript e limites de aprovação já embutidos. Escolha o Artillery se o seu time já vive no Node.js, prefere cenários curtos em YAML ou precisa de testes de navegador com Playwright e execuções distribuídas na AWS ou no Azure direto da linha de comando.

Os dados abaixo vêm da documentação e do repositório de cada projeto, conferidos em 8 de outubro de 2026.

Qual é a diferença entre k6 e Artillery?

Eles se diferenciam principalmente no ambiente de execução e na forma de descrever a carga. O k6 é uma ferramenta compilada em Go que executa código de teste em JavaScript, enquanto o Artillery é uma ferramenta Node.js que lê cenários em YAML ou JavaScript.

Essa diferença aparece logo no primeiro dia. Instalar o k6 é instalar um pacote ou um binário independente, sem um ambiente de execução para manter. O Artillery precisa do Node.js e é instalado pelo npm, o que é natural num projeto JavaScript e é mais um ambiente para manter atualizado em qualquer outro lugar.

Em protocolos, o que os dois têm em comum cobre quase todo o trabalho web: ambos falam HTTP e WebSockets de fábrica. O k6 traz também gRPC, e o Artillery, Socket.IO. O Artillery ganha gRPC e Kinesis com engines adicionais instaladas à parte (conferido em 9 de outubro de 2026), e o k6 vai além com seu ecossistema de extensões.

Como se escreve um teste em cada ferramenta?

No k6 você escreve um módulo JavaScript com as opções no topo e uma função padrão que cada usuário virtual executa. No Artillery você normalmente escreve um arquivo YAML com um bloco config para a carga e um bloco scenarios para o que cada usuário virtual faz.

Um teste k6 que sobe para 20 usuários virtuais e falha se o percentil 95 do tempo de resposta passar de 500 ms:

import http from "k6/http";
import { check, sleep } from "k6";

export const options = {
  stages: [
    { duration: "30s", target: 20 },
    { duration: "1m", target: 20 },
    { duration: "15s", target: 0 },
  ],
  thresholds: { http_req_duration: ["p(95)<500"] },
};

export default function () {
  const res = http.get("https://staging.example.com/api/users");
  check(res, { "status is 200": (r) => r.status === 200 });
  sleep(1);
}

A mesma ideia no formato YAML do Artillery, com dez novos usuários virtuais por segundo durante um minuto:

config:
  target: "https://staging.example.com"
  phases:
    - duration: 60
      arrivalRate: 10
  plugins:
    ensure:
      thresholds:
        - "http.response_time.p95": 500
scenarios:
  - flow:
      - get:
          url: "/api/users"

Os dois exemplos modelam a carga de jeitos diferentes. O script k6 define um número de usuários virtuais simultâneos, e o arquivo do Artillery define quantos usuários virtuais novos chegam a cada segundo. O k6 também consegue controlar taxas de chegada com seus executors de cenários, e o Artillery pode limitar a concorrência com maxVusers, então escolha o modelo que se parece com o jeito que o tráfego real chega ao seu sistema, e não o que cada ferramenta mostra primeiro.

Como o k6 e o Artillery decidem se um teste passou?

Os dois transformam uma meta de desempenho em código de saída, que é o que um pipeline de CI precisa. Uma meta não cumprida encerra a execução com código de saída diferente de zero nas duas ferramentas.

No k6 as metas são thresholds e ficam nas opções do script, como no exemplo acima. No Artillery elas ficam no plugin ensure, que aceita limites simples e condições que combinam várias métricas.

A diferença prática está em onde as metas ficam. Os thresholds do k6 ficam no mesmo arquivo da lógica do teste. As verificações do Artillery ficam no bloco config, onde alguém que nunca mexe nos cenários ainda consegue ajustá-las.

Como rodar um teste maior do que uma máquina consegue gerar?

As duas ferramentas conseguem distribuir um teste entre várias máquinas, por caminhos bem diferentes. O k6 se apoia no Kubernetes ou no serviço hospedado da Grafana, e o Artillery na sua própria conta da AWS ou do Azure.

Para o k6, o k6-operator divide um teste entre pods de um cluster Kubernetes, e o Grafana Cloud k6 roda os mesmos scripts como serviço hospedado. Para o Artillery, os comandos run-lambda e run-fargate sobem workers na sua conta da AWS depois de uma configuração de IAM feita uma única vez com uma stack do CloudFormation. No Azure, o run-aci faz o mesmo com Azure Container Instances, mas exige uma assinatura paga do Artillery para qualquer uso além de avaliação (conferido em 9 de outubro de 2026). Se você já usa Kubernetes, o caminho do operator vai parecer familiar. Se prefere não operar nada, o caminho serverless do Artillery tem menos peças móveis, desde que o teste possa viver na AWS ou no Azure.

Existe um terceiro caminho para scripts k6. A LoadFocus roda scripts k6 na própria infraestrutura de nuvem a partir de 25 regiões, então o script que você roda no notebook vira um teste distribuído sem cluster nem conta da AWS. A LoadFocus não roda scripts do Artillery, então para o Artillery os próprios comandos dele para AWS e Azure continuam sendo o jeito de escalar.

Para onde vão os resultados?

As duas ferramentas mostram um resumo no fim de cada execução e podem enviar métricas para outros sistemas, para painéis e alertas.

Segundo o repositório, o k6 oferece estatísticas resumidas ou métricas detalhadas exportadas para o serviço que você escolher. O Artillery lista no repositório mais de 20 integrações de monitoramento, observabilidade e CI/CD. As duas conseguem alimentar os painéis que você já tem. Antes de decidir, confira se a saída exata de que você precisa está na lista, porque as duas listas mudam de uma versão para outra.

Qual delas você deve escolher?

Escolha o k6 quando quiser um único binário na CI, lógica de teste em JavaScript com controle de fluxo de verdade e thresholds no mesmo arquivo do teste. Ele também combina com times que já usam Grafana, porque a ferramenta open source e o serviço hospedado compartilham a mesma API de scripts.

Escolha o Artillery quando o seu time escreve Node.js todo dia, quando um arquivo YAML curto é mais fácil para o resto do time revisar do que um script, ou quando você precisa de testes de navegador com Playwright e de Socket.IO na mesma ferramenta. O escalonamento serverless dele também é o caminho mais curto se a sua infraestrutura já vive na AWS e o Kubernetes não faz parte dela.

Se ainda estiver em dúvida, escreva o mesmo teste de fumaça nas duas. Vinte linhas bastam para ver qual delas o seu time lê com mais facilidade numa revisão de código.

FAQ

O k6 é gratuito? Sim. O k6 é open source sob a licença AGPL-3.0 e roda de graça nas suas próprias máquinas. O Grafana Cloud k6 é um serviço hospedado separado, com preços próprios.

O Artillery é gratuito? Em grande parte. A maior parte do Artillery está sob a licença MPL-2.0, mas alguns módulos específicos de Azure usam uma licença source-available que exige licença comercial para uso em produção no Azure, segundo o repositório do projeto (conferido em 8 de outubro de 2026).

A LoadFocus consegue rodar testes do Artillery? Não. A LoadFocus roda scripts k6 e JMeter. Para escalar um teste do Artillery além de uma máquina, use os comandos do próprio Artillery para AWS Lambda, Fargate ou Azure Container Instances na sua própria conta de nuvem.

Qual ferramenta consome menos recursos no gerador de carga? Não medimos isso nós mesmos, então não apontamos um vencedor. O projeto k6 diz que até máquinas mais simples conseguem simular muito tráfego, e a comparação justa é rodar o mesmo cenário com as duas ferramentas no seu próprio hardware.

Leituras relacionadas

• Gatling vs k6: simulações na JVM ou um único binário Go?
• Como fazer um teste de carga: guia passo a passo
• Ferramentas de teste de carga open source: seis opções
• Teste de carga no GitHub Actions: guia prático
• k6 vs Locust: scripts JavaScript ou usuários Python?
• Teste de carga com Artillery: análise da ferramenta Node.js

As afirmações técnicas deste artigo não foram revisadas de forma independente.