Testes negativos de API

Verificações positivas mostram que uma API atende aos cenários esperados. As negativas revelam sua resistência a entradas inválidas, inesperadas e perigosas. Isso é especialmente valioso para QA porque costuma expor falhas na validação, no tratamento de erros, na segurança e na estabilidade do serviço.

Usuários e integrações raramente se comportam perfeitamente. Podem enviar campos vazios, tipos incorretos, tokens expirados, cargas muito grandes ou chamar endpoints em estados inválidos. Uma boa API deve responder de forma previsível e segura, além de simplesmente não falhar.

O que significa teste negativo de API

O teste negativo de API examina o comportamento do sistema com entradas inválidas, inesperadas, proibidas ou conflitantes.

Ele vai muito além de enviar um campo vazio:

→Campos obrigatórios ausentes
→Valores com formato incorreto
→Tipos de dados incompatíveis
→Valores fora do intervalo
→Combinações de campos que violam regras de negócio
→Usuários não autenticados ou sem autorização
→Cargas de dados muito grandes
→Content-Type inesperado
→Métodos que não deveriam ser aceitos naquele endpoint
→Requisições repetidas que criam conflitos

Portanto, o teste negativo verifica tanto a correção das entradas quanto a resistência da API ao uso inadequado.

Por que isso é especialmente importante para APIs

Uma interface oferece alguma proteção por meio de formulários, máscaras, listas e botões desabilitados. APIs não têm essa mesma camada. Elas recebem requisições diretamente e precisam decidir como tratá-las.

Testes negativos de API insuficientes costumam deixar três riscos:

→O serviço falha ao receber entradas inválidas.
→O serviço se comporta de maneira imprevisível.
→O serviço aceita algo que deveria rejeitar.

Se você testa apenas o caminho feliz, vê uma parcela muito limitada do comportamento real do sistema.

O que colocar à prova

Um bom teste negativo segue classes de entrada, em vez de tentativas arbitrárias de inserir valores sem sentido.

Teste regularmente estes grupos:

→Um campo obrigatório está ausente.
→Um campo está presente, mas vazio.
→Um campo está presente, mas é null.
→O tipo está errado: uma string no lugar de um número ou um objeto no lugar de um array.
→Uma string excede o tamanho máximo.
→Um número está abaixo do mínimo ou acima do máximo.
→Uma data, e-mail, telefone, UUID ou valor de enum tem formato inválido.
→Os parâmetros formam uma combinação inválida.
→Há campos extras inesperados.
→O método da requisição está incorreto.
→O Content-Type está incorreto.
→O token está corrompido ou expirado.
→A requisição acessa um recurso de outro usuário.
→O corpo da requisição é muito grande.
→A requisição se repete em um estado conflitante.

Uma abordagem sistemática transforma essas verificações em um modelo repetível de qualidade da API, em vez de tentativas caóticas de quebrar algo.

O que caracteriza um bom teste negativo

Um teste negativo fraco verifica apenas se ocorreu um erro. Um bom teste examina muito mais.

→O código de status está correto?
→O erro é compreensível para o cliente?
→A resposta expõe detalhes internos desnecessários?
→Algum dado mudou quando não deveria?
→Houve efeitos colaterais?
→Repetir a mesma requisição inválida produz um comportamento consistente?
→O serviço evita retornar 500 para um problema causado pelo cliente?

Por exemplo, JSON inválido geralmente justifica 400, em vez de 500. Uma tentativa de modificar um recurso de outro usuário normalmente exige 403 ou 404, em vez de sucesso. Um corpo excessivamente grande pode justificar 413. O objetivo é um tratamento consistente e compreensível, em vez de tentar adivinhar um código ideal para todos os casos.

O que inspecionar além do erro

Um bom hábito é sempre verificar o estado do sistema após uma requisição malsucedida.

→Nenhum registro foi realmente criado?
→O status do objeto permaneceu inalterado?
→Nenhum valor foi cobrado?
→Nenhum e-mail foi enviado?
→A auditoria e os logs registraram o evento corretamente?
→Repetir a requisição manteve o sistema em um estado válido?

Muitos defeitos perigosos se escondem aqui. A API retorna um erro externamente, mas já alterou parcialmente os dados internamente. Os usuários podem ver as consequências mais tarde como um bug aparentemente aleatório, embora a causa seja o tratamento inadequado de cenários negativos.

Exemplo prático

Considere um endpoint de criação de usuários.

O cenário positivo é simples: enviar e-mail, nome e senha válidos e receber 201 Created.

Agora considere cenários negativos:

→O e-mail está ausente.
→O e-mail está vazio.
→O e-mail é inválido.
→A senha é muito curta.
→Um campo do corpo tem um tipo inesperado.
→A autorização está ausente quando é obrigatória.
→O mesmo e-mail é cadastrado novamente.
→O corpo é muito grande.
→O Content-Type não é application/json.

QA deve verificar se:

→O servidor responde de forma previsível.
→O erro é suficientemente claro para o cliente.
→O código de status corresponde à classe do problema.
→Nenhum registro inválido é criado.
→Não ocorrem efeitos colaterais indesejados.
→Repetir a mesma requisição inválida não causa danos adicionais ao sistema.

Nesse ponto, o teste negativo se torna uma avaliação substancial da maturidade da API, em vez de um complemento opcional.

Pontos principais para profissionais de QA

→O teste negativo de API examina a resistência do sistema juntamente com os erros de entrada.
→Um bom teste negativo verifica o código de erro e o estado posterior do sistema.
→Uma API sólida trata requisições inválidas com segurança e previsibilidade.
→O caminho feliz sozinho quase nunca demonstra a confiabilidade real do serviço.
→Organize verificações negativas por classes de risco, em vez de tentativas aleatórias de quebrar algo.

Leitura adicional

→Nesta base de conhecimento: Métodos, códigos de status e cabeçalhos
→Nesta base de conhecimento: Autenticação e autorização
→Recurso externo: Guia de segurança REST da OWASP

Uma matriz local de testes negativos com verificações de efeitos colaterais

Use um contrato local sintético, em vez de adivinhar o que toda API deveria retornar. O ambiente de prática preparado aceita POST /items com um token de treinamento de administrador, Content-Type application/json, um nome com 3–12 letras ASCII e uma quantidade inteira de 1 a 5. O corpo deve conter exatamente esses dois campos. Os dados ficam na memória; inicie um servidor novo para cada teste independente.

plain text

Caso	Exemplo	Esperado neste ambiente
Campo ausente	{"name":"abc"}	422 invalid_fields
Tipo errado	{"name":"abc","quantity":"1"}	422 invalid_quantity
Fora do intervalo	{"name":"abc","quantity":6}	422 invalid_quantity
Campo extra	{"name":"abc","quantity":1,"admin":true}	422 invalid_fields
JSON malformado	{	400 malformed_json
Tipo de mídia errado	Content-Type: text/plain	415 json_required
Corpo acima de 1024 bytes	Corpo de 1025 bytes	413 payload_too_large

Antes de cada gravação rejeitada, execute GET /items e registre total; repita depois e exija que total não mude. Isso detecta uma implementação que retorna um erro depois de gravar um registro. Para um nome novo aceito, espere 201 e total + 1; enviá-lo novamente retorna 409 sem uma segunda inclusão. Esses status descrevem este contrato declarado, não uma regra obrigatória para todos os produtos.

plain text

python3 mock_api.py --port 8765
# In another terminal, using only the synthetic local token:
curl -i http://127.0.0.1:8765/items -H "Authorization: Bearer demo-admin" -H "Content-Type: application/json" --data '{"name":"abc","quantity":6}'
python3 -m unittest test_mock_api.py -v

O ambiente de teste é intencionalmente local e simplificado. Use-o para praticar a seleção de entradas e a coleta de evidências; não copie seus tokens fixos ou servidor HTTP para um sistema de autenticação em produção.

Continuar aprendendo

Baixe o laboratório de prática local (ZIP)

Verifique a autorização separadamente

Derive os valores-limite