Azure Load Testing: análise do serviço da Microsoft

O Azure Load Testing é o serviço gerenciado da Microsoft para rodar testes JMeter e Locust em grande escala a partir do Azure, cobrado por hora de usuário virtual. Ele se encaixa bem quando o sistema testado roda no Azure, porque consegue puxar métricas de servidor do Azure Monitor e alcançar endpoints privados dentro de uma rede virtual. Times que escrevem scripts k6, não têm assinatura do Azure ou testam de fora das regiões do Azure vão achar outros serviços mais simples.

Não rodamos o Azure Load Testing para esta análise. Os fatos vêm da documentação e da página de preços da Microsoft, conferidas em 19 de outubro de 2026, e as avaliações são nossas.

O que é o Azure Load Testing?

É um serviço totalmente gerenciado que roda seu teste de carga nas engines de teste da Microsoft, então você nunca monta nem atualiza geradores de carga. Você cria um recurso de teste de carga numa região do Azure, adiciona testes a ele e dispara execuções pelo portal, pela Azure CLI ou por um pipeline.

A página de visão geral diz que a aplicação testada pode estar em qualquer lugar: no Azure, on-premises ou em outra nuvem. A Microsoft agora lista o serviço dentro do hub Azure App Testing, ao lado do Playwright Workspaces; o início rápido de Locust cria o recurso a partir desse hub (conferido em 19 de outubro de 2026).

Quais tipos de teste e ferramentas ele aceita?

Três caminhos: um teste rápido por URL, um script JMeter enviado ou um script Locust enviado. A documentação diz claramente que nenhum outro framework de teste é suportado.

O teste rápido aceita até cinco requisições HTTP e uma meta de usuários virtuais ou de requisições por segundo. Cada engine aguenta até 250 usuários virtuais, então 400 usuários rodam em duas engines com 200 cada.

Com JMeter, você pode usar plugins do jmeter-plugins.org ou enviar os seus, e a visão geral afirma que funciona qualquer protocolo que o JMeter suporta, como uma conexão com banco de dados ou uma fila de mensagens. Com Locust, você pode adicionar plugins do Locust e outras bibliotecas Python. A própria documentação do Locust aponta o serviço como sua opção hospedada, e nossa análise do Locust trata da ferramenta em si. Scripts k6, Gatling e Artillery não rodam aqui (conferido em 19 de outubro de 2026).

Como funcionam engines, usuários virtuais e limites?

Você escala um teste adicionando instâncias de engine. No JMeter, a carga total é o número de usuários do plano de teste multiplicado pelo número de engines; no Locust, você define o total de usuários e escolhe quantas engines os geram.

A página de conceitos traz as duas fórmulas, e a página de limites do serviço define os tetos por região e assinatura (conferido em 19 de outubro de 2026):

• Instâncias de engine por execução: de 1 a 400 por padrão conforme a oferta, no máximo 400.
• Instâncias de engine simultâneas: de 5 a 400 por padrão, até 1.000 sob pedido.
• Duração do teste: de 3 a 24 horas por padrão, no máximo 24 horas.
• Critérios de falha: até 50 por teste.
• Retenção: métricas de servidor 90 dias, métricas de cliente 365 dias, resultados e logs 6 meses.

Subir um limite padrão exige um chamado ao suporte; nada passa dos máximos indicados.

Ele testa endpoints privados e gera carga de várias regiões?

Sim para as duas coisas, com uma ressalva: elas não se combinam. Carga de várias regiões só funciona contra endpoints públicos.

Por padrão, as engines rodam na região do seu recurso de teste de carga. O guia de várias regiões deixa escolher até 5 regiões por teste e dividir a carga entre elas, e com isso muda o teste para tráfego público. Para serviços sem endpoint público, a injeção em rede virtual coloca as engines dentro da rede onde está a aplicação (conferido em 19 de outubro de 2026).

O que mostram os resultados e as métricas de servidor?

O dashboard mostra ao vivo, durante a execução, as métricas do lado do cliente, como usuários virtuais, tempo de resposta e requisições por segundo. Para apps hospedados no Azure, ele soma métricas do lado do servidor do Azure Monitor, do Application Insights e do Container Insights na mesma linha do tempo.

Essa combinação é a maior vantagem do serviço: você vê o banco de dados ou o contêiner que satura no momento em que os tempos de resposta sobem, sem montar um dashboard separado. O guia de métricas de servidor descreve os passos. Execuções anteriores ficam comparáveis lado a lado, e dá para baixar os resultados para outras ferramentas.

Como funcionam os critérios de aprovação e a CI?

Você define critérios de falha sobre métricas de cliente ou de servidor, e a execução é marcada como falha assim que algum deles é violado. Pipelines no Azure DevOps, no GitHub Actions ou em qualquer ferramenta de CI que consiga chamar a Azure CLI podem iniciar um teste e decidir com base nesse resultado.

Segundo o guia de critérios de falha, um critério é um agregado de uma métrica de cliente, como tempo médio de resposta ou porcentagem de erros, comparado com um limite, seja para o teste inteiro ou para uma requisição nomeada. Métricas de servidor exigem que a identidade gerenciada do recurso possa lê-las. A parada automática encerra uma execução quando a taxa de erros passa de um limite, para que uma URL errada não continue custando. O guia de CI/CD cobre GitHub Actions e Azure Pipelines (conferido em 19 de outubro de 2026). Nosso guia de critérios de aprovação de um teste de carga explica como escolher os limites.

Quanto custa o Azure Load Testing?

Você paga por hora de usuário virtual (VUH): US$ 0,15 por VUH nas primeiras 10.000 e US$ 0,06 por VUH depois disso, igual em todas as regiões da página de preços. Desde 1º de março de 2026 há também uma cobrança mínima por execução.

A página de preços define uma VUH como usuários virtuais vezes minutos, dividido por 60, contado a cada 10 segundos; 1.000 usuários por 30 minutos dão 500 VUH, ou US$ 75 no preço da primeira faixa. O mínimo é de 10 usuários virtuais por engine durante toda a execução, com pelo menos 10 minutos. Uma execução de 3 horas com 5 usuários numa engine é cobrada, portanto, como 30 VUH, e não 15 (conferido em 19 de outubro de 2026).

Quando escolher outra coisa?

Escolha outra opção quando seus scripts, sua nuvem ou seu orçamento apontarem para outro lado.

Nosso panorama de ferramentas de teste de carga open source cobre as ferramentas que você pode rodar por conta própria.

Escolha a LoadFocus, que publica este site, quando quiser rodar planos de teste JMeter e scripts k6 a partir de 25 regiões na nuvem sem assinatura do Azure. Ela não roda Locust e executa cenários arrival-rate do k6 com um número fixo de usuários.

Escolha o Grafana Cloud k6 ou o k6-operator quando seus testes forem escritos para o k6, que o Azure Load Testing não roda (conferido em 19 de outubro de 2026).

Escolha o Locust na sua própria infraestrutura quando você já tiver Kubernetes ou máquinas livres: o modo distribuído dele é gratuito, e você paga só o hardware.

FAQ

O Azure Load Testing suporta k6? Não. Ele roda testes Apache JMeter e Locust, além de testes rápidos por URL que ele mesmo transforma em script. Scripts k6 precisam de outro serviço ou da sua própria infraestrutura.

Posso usar o Azure Load Testing com uma aplicação que não está no Azure? Sim. As engines de teste podem mirar qualquer endpoint público. Métricas de servidor só são coletadas para recursos do Azure, então em outra hospedagem você lê as métricas de servidor no seu próprio monitoramento.

Existe um plano gratuito? A página de preços mostra só preços por hora para teste de carga, com um mínimo por execução. Contas novas do Azure ganham um crédito de US$ 200 para os primeiros 30 dias, segundo a mesma página.

Leituras relacionadas

• Teste de carga com Locust: análise da ferramenta Python
• Ferramentas de teste de carga open source: seis opções
• Critérios de aprovação de um teste de carga: como definir
• Locust vs JMeter: scripts Python ou planos do JMeter?
• Teste de carga no GitHub Actions: guia prático

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