Fatos principais
- Categoria
- Desenvolvimento e Web
- Tipos de entrada
- textarea, text, checkbox, number
- Tipo de saída
- json
- Cobertura de amostras
- 4
- API disponível
- Yes
Visão geral
O Testador de Estresse de Contrato de API é uma ferramenta avançada que analisa documentos OpenAPI 3.x para gerar automaticamente casos de teste de limite e exceção. Ele permite validar se a sua API real está em conformidade com o contrato documentado, identificando falhas em campos obrigatórios, limites numéricos, validações de string e tipos de dados, com a opção de executar as requisições diretamente contra o seu backend para detectar divergências de status HTTP.
Quando usar
- •Antes de integrar novos endpoints em produção, para garantir que o backend rejeita corretamente requisições malformadas ou fora dos limites.
- •Durante auditorias de segurança ou testes de robustez para descobrir vulnerabilidades de validação de entrada em APIs RESTful.
- •Ao atualizar a documentação OpenAPI, para verificar se as regras de schema (como minLength, maximum ou enum) correspondem ao comportamento real do servidor.
Como funciona
- •Cole a sua especificação OpenAPI 3.x (em formato YAML ou JSON) no campo principal da ferramenta.
- •Configure a URL base e o cabeçalho de autorização caso deseje que a ferramenta execute as requisições reais contra o seu servidor.
- •Ajuste o limite de casos por campo e o tempo limite da requisição para controlar o volume e a duração dos testes de estresse.
- •Analise o relatório JSON gerado, que detalha os casos de limite criados e aponta quaisquer divergências entre as respostas do servidor e o contrato documentado.
Casos de uso
Exemplos
1. Geração de plano de testes offline para API de cadastro
Engenheiro de QA- Contexto
- A equipe de desenvolvimento entregou a especificação de um novo endpoint de criação de usuários, mas o backend ainda não está pronto para receber chamadas.
- Problema
- Criar rapidamente uma lista de casos de teste de borda (strings curtas, enums inválidos, campos ausentes) para preparar os scripts de automação.
- Como usar
- Cole o YAML do OpenAPI no campo principal, deixe a URL base vazia e mantenha a execução de requisições reais desativada.
- Configuração de exemplo
-
{ "executeRequests": false, "maxCasesPerField": 3 } - Resultado
- A ferramenta gera um relatório JSON contendo todos os casos de limite (ex: e-mail ausente, role inválida) sem fazer chamadas de rede, servindo como base para os testes futuros.
2. Validação de contrato em ambiente de staging
Desenvolvedor Backend- Contexto
- Uma API de pagamentos foi atualizada e precisa rejeitar valores negativos ou nulos estritamente conforme o contrato OpenAPI.
- Problema
- Garantir que o servidor de staging retorne os códigos HTTP 400 corretos para requisições inválidas, sem precisar testar manualmente cada variação de erro.
- Como usar
- Insira o JSON do OpenAPI, defina a URL base para o ambiente de staging, ative as requisições reais e insira o token de autorização necessário.
- Configuração de exemplo
-
{ "baseUrl": "https://staging.api.empresa.com", "executeRequests": true, "authorizationHeader": "Bearer token123", "timeoutMs": 10000 } - Resultado
- A ferramenta dispara as requisições malformadas contra o staging e aponta no relatório se algum endpoint falhou ao validar os dados ou retornou um erro 500 não documentado.
Testar com amostras
developmentHubs relacionados
FAQ
Quais formatos de especificação são suportados?
A ferramenta suporta documentos OpenAPI 3.x válidos nos formatos YAML e JSON.
A ferramenta testa todos os tipos de requisição?
Atualmente, ela cobre parâmetros de path, query, header e corpos de requisição em formato JSON (application/json).
É obrigatório executar requisições reais contra a minha API?
Não. Se a opção 'Executar requisições reais' estiver desativada, a ferramenta apenas gerará um plano de testes focado no contrato, sem fazer chamadas de rede.
Como a ferramenta lida com endpoints que exigem autenticação?
Você pode fornecer um token no campo 'Cabeçalho de autorização' (por exemplo, Bearer <token>) que será incluído em todas as requisições reais executadas.
O que acontece se o servidor retornar um status HTTP não documentado?
O relatório final marcará esse comportamento como uma divergência (mismatch), indicando que o status HTTP observado na prática não está definido nas respostas do seu OpenAPI.