Skip to main content

Testes em APIs

Objetivo desta página

Esta página descreve como o QA deve validar APIs na prática, garantindo que elas funcionem corretamente de forma isolada e integrada, respeitem contratos, tratem erros adequadamente e não causem impactos silenciosos em sistemas consumidores.

Em sistemas como os da DBSeller, APIs não são apenas suporte do front-end, elas são:

  • base de integrações internas

  • ponto de comunicação entre módulos

  • responsáveis por regras críticas de negócio

Contexto de APIs na DBSeller

Nos sistemas da DBSeller, APIs são amplamente utilizadas para:

  • comunicação entre módulos

  • consumo por interfaces web

  • integração com serviços externos

  • processamento de regras centralizadas

Um erro em API muitas vezes:

  • não quebra visualmente o sistema

  • gera dados incorretos

  • causa efeitos colaterais difíceis de rastrear

Por isso, testar API exige olhar técnico e analítico.

Validações funcionais em APIs

Testar API não é apenas validar status 200.

O QA deve validar o comportamento completo da API.

1. Validação de métodos HTTP

O QA deve validar:

  • método correto (GET, POST, PUT, DELETE)

  • comportamento esperado por método

  • rejeição de métodos inválidos

Exemplo prático:
Uma API de consulta não deve aceitar POST para retornar dados.

Por que entender os métodos HTTP é essencial para QA

Os métodos HTTP definem a intenção da requisição.
Quando um método é usado de forma incorreta, o problema não é só técnico, ele vira:

  • risco de segurança

  • inconsistência de dados

  • falha de integração

  • regressão silenciosa

QA que entende métodos HTTP consegue:

  • identificar falhas de contrato

  • validar regras de negócio corretamente

  • detectar uso indevido de APIs

GET

O que é

O método GET é utilizado para consultar ou buscar dados.

Ele não deve alterar estado, nem criar, nem atualizar informações.

Como usar GET nos testes

O QA deve validar que:

  • o GET apenas retorna dados

  • nenhuma informação é alterada após a requisição

  • filtros e parâmetros funcionam corretamente

Validações comuns em GET

  • resposta correta com parâmetros válidos

  • retorno vazio quando não há dados

  • comportamento ao omitir parâmetros

  • paginação e ordenação

  • status code adequado

Exemplos de teste com GET

  • buscar registro existente

  • buscar registro inexistente

  • buscar com filtro válido

  • buscar com filtro inválido

  • repetir a requisição várias vezes e validar que os dados não mudam

Erros comuns com GET

  • GET que altera dados

  • GET que exige body

  • retorno 200 com erro no payload

POST

O que é

O método POST é utilizado para criar novos recursos ou executar ações.

Ele normalmente altera o estado do sistema.

Como usar POST nos testes

O QA deve validar que:

  • o recurso é criado corretamente

  • campos obrigatórios são validados

  • duplicidade é tratada

  • regras de negócio são respeitadas

Validações comuns em POST

  • criação com dados válidos

  • erro ao faltar campo obrigatório

  • erro ao enviar dado inválido

  • comportamento ao enviar payload duplicado

Exemplos de teste com POST

  • criar registro com payload completo

  • tentar criar registro sem campo obrigatório

  • tentar criar registro com formato inválido

  • repetir POST e validar regra de duplicidade

Erros comuns com POST

  • POST que atualiza recurso existente sem controle

  • ausência de validação de entrada

  • retorno 200 para erro de criação

PUT

O que é

O método PUT é utilizado para atualizar um recurso existente.

Normalmente, o PUT substitui o estado atual do recurso.

Como usar PUT nos testes

O QA deve validar que:

  • apenas registros existentes são atualizados

  • campos são sobrescritos corretamente

  • validações continuam sendo aplicadas

Validações comuns em PUT

  • atualização com dados válidos

  • tentativa de atualizar registro inexistente

  • impacto em campos não enviados

  • consistência após atualização

Exemplos de teste com PUT

  • atualizar todos os campos do recurso

  • atualizar apenas parte dos dados

  • validar comportamento ao omitir campos

  • validar resposta após atualização

Erros comuns com PUT

  • PUT criando novo registro indevidamente

  • perda de dados por sobrescrita incorreta

  • atualização parcial não documentada

DELETE

O que é

O método DELETE é utilizado para remover um recurso.

Pode ser:

  • exclusão física

  • exclusão lógica

Como usar DELETE nos testes

O QA deve validar que:

  • o recurso deixa de existir ou fica inativo

  • exclusões respeitam regras de negócio

  • exclusões indevidas são bloqueadas

Validações comuns em DELETE

  • exclusão de registro existente

  • tentativa de excluir registro inexistente

  • exclusão com dependências

  • comportamento após exclusão

Exemplos de teste com DELETE

  • excluir registro sem dependências

  • tentar excluir registro com vínculos

  • validar se o registro desaparece da consulta

  • validar se exclusão é lógica ou física

Erros comuns com DELETE

  • exclusão sem validação de dependência

  • exclusão irreversível sem aviso

  • retorno 200 para exclusão que não ocorreu

Relação entre métodos e testes de regressão

Cada método pode gerar impactos indiretos.

QA deve sempre avaliar:

  • POST pode impactar GET

  • PUT pode impactar relatórios

  • DELETE pode quebrar integrações

Por isso, testes de API sempre se conectam com fluxo de regressão.

Boas práticas gerais para QA ao testar métodos HTTP

  • nunca assumir que o método está correto

  • testar uso indevido do método

  • validar status code e payload juntos

  • registrar evidências completas

  • pensar em impacto sistêmico

Resumo rápido

  • GET: consultar

  • POST: criar

  • PUT: atualizar

  • DELETE: remover

Testar método HTTP não é detalhe técnico.
É garantir que a API faça exatamente o que promete e nada além disso.

2. Validação de parâmetros de entrada

Verificar:

  • parâmetros obrigatórios

  • parâmetros opcionais

  • formatos esperados

  • limites de tamanho

  • valores inválidos

Aplicação prática:

  • enviar parâmetros vazios

  • enviar valores fora do padrão

  • omitir parâmetros obrigatórios

Isso conecta diretamente com Testes de Integridade e Precisão.

3. Validação de resposta

O QA deve validar:

  • status code correto

  • estrutura do payload

  • valores retornados

  • consistência entre campos

Exemplo prático:
API retorna status 200, mas payload indica erro. Isso é bug.

4. Validação de regras de negócio

APIs frequentemente concentram regras críticas.

O QA deve validar:

  • aplicação correta das regras

  • comportamento em cenários limite

  • exceções previstas

Aqui entram Testes Baseados em Risco, pois um erro de regra na API afeta múltiplos consumidores.

Validação de contratos de API

API é contrato.
Quando o contrato quebra, tudo quebra.

O que é o contrato da API

Contrato é:

  • estrutura da requisição

  • estrutura da resposta

  • tipos de dados

  • regras de obrigatoriedade

O QA valida se:

  • campos esperados existem

  • tipos de dados são respeitados

  • campos não somem sem aviso

Validação de versionamento

Quando a API possui versão, o QA deve validar:

  • compatibilidade entre versões

  • impacto em consumidores antigos

  • comportamento ao consumir versão errada

Mudança de contrato sem versionamento é alto risco de regressão.

Testes de integração via API

APIs raramente vivem sozinhas.

O QA deve validar:

  • integração entre APIs

  • integração entre API e banco

  • integração entre API e front-end

Exemplos práticos de integração

  • API de cadastro impacta relatório

  • API de atualização reflete em listagens

  • API de cálculo influencia valores exibidos

Aqui o QA precisa sempre responder:

Quem consome essa API e o que pode quebrar?

Tratamento de erros em APIs

Erros bem tratados são parte da qualidade.

O QA deve validar:

  • mensagens claras

  • status code adequado

  • ausência de stacktrace exposto

  • comportamento previsível

Exemplos de erro bem tratado

  • 400 para requisição inválida

  • 401 para acesso não autorizado

  • 404 para recurso inexistente

  • 500 apenas para erro interno real

Erro genérico sem contexto dificulta integração e suporte.

Erros comuns em testes de API

Aqui estão falhas recorrentes que o QA deve ficar atento:

1. Status code correto com payload errado

API retorna 200, mas o conteúdo indica falha.

2. Contrato quebrado silenciosamente

Campo removido ou alterado sem aviso.

3. Falta de validação de entrada

API aceita dados inválidos e processa incorretamente.

4. Regra aplicada no front e não na API

Quando a regra só existe na interface, a API vira um risco.

5. Integrações não testadas

API funciona isolada, mas quebra ao ser consumida.

Aplicação prática do fluxo de QA em APIs

Ao testar uma API, o QA deve:

  1. Entender o objetivo da API

  2. Identificar consumidores

  3. Validar contrato

  4. Executar testes funcionais

  5. Simular cenários de erro

  6. Avaliar impacto sistêmico

  7. Registrar evidências

  8. Comunicar riscos

Esse fluxo conecta diretamente com:

  • Estratégia de Teste

  • Testes Baseados em Risco

  • Fluxo de Regressão

  • Go / No-Go

Evidências em testes de API

Sempre registrar:

  • requisição enviada

  • resposta recebida

  • status code

  • payload

Ferramentas como Postman ou Insomnia devem ser usadas com organização e clareza.

Resultado esperado desta abordagem

Seguindo este modelo, a DBSeller garante:

  • APIs estáveis

  • integrações confiáveis

  • menos falhas silenciosas

  • decisões de liberação mais seguras

Testar API não é só validar resposta.
É garantir que o sistema se comunique corretamente consigo mesmo e com o mundo.

Back to top