k6 vs Locust: scripts JavaScript ou usuários Python?

k6 e Locust são duas ferramentas de código aberto que mantêm um teste de carga como código no seu repositório, e qualquer uma delas testa bem uma API HTTP sob carga. Escolha o Locust se sua equipe escreve Python e quer a lógica do teste em Python puro. Escolha o k6 se você escreve JavaScript, quer thresholds de aprovação embutidos ou precisa de um teste que mantenha uma taxa de chegada.

Os fatos desta comparação entre k6 e Locust vêm da documentação e do repositório de cada projeto, conferidos em 13 de outubro de 2026.

Qual é a diferença entre k6 e Locust?

A principal diferença é a linguagem em que você escreve os testes. O k6 executa JavaScript dentro de um programa Go compilado, enquanto o Locust executa seu código Python e usa o gevent para muitos usuários simultâneos.

O k6 é instalado como pacote ou binário independente, sem outro ambiente de execução. Ele também executa arquivos .ts, mas seu suporte a TypeScript remove os tipos sem verificá-los. O Locust é instalado com pip install locust, e a página What is Locust diz que os testes são Python comum, que você mantém em controle de versão como qualquer outro código (conferido em 13 de outubro de 2026).

Como escrever o mesmo teste em cada ferramenta?

Ambas expressam o teste como um programa curto. Aqui vai um teste com 50 usuários por cinco minutos, que falha se o percentil 95 passar de 500 ms ou se mais de 1% das requisições falharem.

No k6 os objetivos fazem parte do script, como thresholds:

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

export const options = {
  vus: 50,
  duration: "5m",
  thresholds: {
    http_req_duration: ["p(95)<500"],
    http_req_failed: ["rate<0.01"],
  },
};

export default function () {
  http.get("https://staging.example.com/api/users");
  sleep(1);
}

No Locust o usuário é uma classe, e os mesmos objetivos vão em um listener, seguindo o padrão da documentação do modo headless:

import logging
from locust import HttpUser, between, events, task


class ApiUser(HttpUser):
    wait_time = between(1, 2)

    @task
    def list_users(self):
        self.client.get("/api/users")


@events.quitting.add_listener
def _(environment, **kw):
    stats = environment.stats.total
    if stats.fail_ratio > 0.01:
        environment.process_exit_code = 1
    elif stats.get_response_time_percentile(0.95) > 500:
        environment.process_exit_code = 1

Eles são executados com k6 run script.js e locust -f locustfile.py --headless -u 50 -r 10 -t 5m --host https://staging.example.com (conferido em 13 de outubro de 2026).

Como k6 e Locust modelam a carga?

O k6 aceita os dois modelos de carga, enquanto o Locust descreve a carga como um número fixo de usuários. No k6 você escolhe o modelo pelo executor, e no Locust pelo número de usuários e pelo tempo de espera.

O k6 tem seis executors. Quatro são fechados: um usuário virtual só começa a próxima iteração quando a anterior termina. Os dois executors arrival-rate seguem o modelo aberto, em que as iterações começam independentemente de quanto as anteriores demoram. O guia do locustfile diz que o tempo de espera só pode limitar a vazão e não pode iniciar novos usuários para atingir uma taxa-alvo (conferido em 13 de outubro de 2026).

Se o seu objetivo é “300 requisições chegam a cada segundo, não importa o tempo de resposta”, o k6 consegue expressar isso diretamente. Nosso guia sobre o modelo de carga aberto e fechado explica quando cada um se encaixa.

Como k6 e Locust decidem se um teste passou?

O k6 tem critérios de aprovação como recurso central, e o Locust deixa a maior parte para o seu código. Um threshold do k6 violado encerra a execução com código de saída diferente de zero, e abortOnFail interrompe o teste no instante em que ele falha.

O Locust encerra com código 1 se alguma requisição falhou. Para limites sobre a taxa de falhas, a média ou o percentil 95, a documentação mostra um listener como o de cima, que define o código de saída por conta própria (conferido em 13 de outubro de 2026). Nosso guia sobre critérios de aprovação em testes de carga ajuda a escolher os limites.

Quais protocolos cada ferramenta cobre?

O k6 traz quatro protocolos e um módulo de navegador; o Locust traz HTTP e HTTPS e deixa você envolver qualquer cliente Python para o resto.

O k6 lista HTTP/1.1, HTTP/2, WebSockets e gRPC como protocolos embutidos, com outros por extensões xk6, e um módulo de navegador que controla um navegador baseado em Chromium. A página do Locust sobre outros sistemas diz que ele só traz suporte embutido a HTTP/HTTPS, mas pode ser estendido para testar quase qualquer sistema, envolvendo uma biblioteca de protocolo e relatando cada chamada como uma requisição. A biblioteca precisa cooperar com o gevent (conferido em 13 de outubro de 2026).

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

O Locust escala com um master e workers, e o k6 com um operador Kubernetes ou um serviço hospedado. Os dois conseguem dividir um teste entre muitas máquinas.

A documentação do modo distribuído do Locust diz que um processo faz mais de mil requisições por segundo em um plano de teste simples, então testes maiores usam um worker por núcleo de processador em quantas máquinas forem necessárias. O k6-operator divide um teste entre várias instâncias do k6 em um cluster Kubernetes, e o Grafana Cloud k6 é o caminho hospedado (conferido em 13 de outubro de 2026).

Há um terceiro caminho para scripts k6. A LoadFocus, que publica este site, executa scripts k6 a partir de 25 regiões na nuvem, com usuários e duração vindos das configurações do teste. O validador de scripts avisa que cenários arrival-rate rodam lá com um número fixo de usuários, então um script de modelo aberto não mantém sua taxa de chegada na LoadFocus. A LoadFocus não executa Locust: ela executa apenas scripts k6 e planos de teste JMeter.

Que relatórios você recebe?

O k6 imprime um resumo ao fim do teste e pode exportar um relatório HTML do seu painel web. O Locust mostra gráficos ao vivo na interface web e grava arquivos sob demanda.

O resumo de fim de teste do k6 vai para o terminal, e seu painel web exporta um relatório HTML autônomo quando você define K6_WEB_DASHBOARD_EXPORT. O Locust serve uma interface web na porta 8089 com gráficos ao vivo, e sua referência de configuração lista as saídas --csv, --html e --json (conferido em 13 de outubro de 2026).

Qual você deve escolher?

O Locust combina com equipes Python, e o k6 com equipes que querem thresholds embutidos e um modelo de carga aberto. Protocolos e escala decidem a maioria dos outros casos.

Escolha o Locust em vez do k6 se sua equipe escreve Python e quer laços, ramificações, dados gerados e seu próprio cliente de API em Python puro, se você quer reaproveitar bibliotecas Python para um protocolo, ou se quer uma interface web com gráficos ao vivo para explorar um sistema. Escolha o k6 em vez do Locust se sua equipe escreve JavaScript ou TypeScript, se thresholds devem reprovar um build de CI e parar cedo uma execução ruim, se você precisa de uma taxa de chegada constante, ou se quer gRPC e testes de navegador na mesma ferramenta.

Para uma visão mais ampla, veja nossa análise de teste de carga com Locust.

FAQ

O Locust é mais rápido que o k6? Não medimos isso nós mesmos, então não apontamos um vencedor. O teste justo é o mesmo cenário nas duas ferramentas, no seu próprio hardware.

O Locust consegue executar scripts k6? Não segundo a documentação do Locust, que descreve testes como código Python em um locustfile. Um script k6 é JavaScript, então precisa ser reescrito como uma classe de usuário Python, e os thresholds viram um listener.

A LoadFocus consegue executar testes Locust? Não. A LoadFocus executa scripts k6 e planos de teste JMeter. Para escalar um teste Locust, use o modo master e workers, o operador Kubernetes ou o Azure Load Testing.

Leituras relacionadas

• Teste de carga com Locust: análise da ferramenta Python
• Locust vs JMeter: scripts Python ou planos de teste JMeter?
• Gatling vs k6: simulações JVM ou um binário Go?
• k6 vs Artillery: qual ferramenta de teste de carga escolher
• Modelo de carga aberto vs fechado: qual usar?
• Azure Load Testing: análise do serviço da Microsoft

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