Estratégias de testes em APIs REST Link para o cabeçalho

Compreendendo principais estratégias de teste para as APIs REST Link para o cabeçalho

Esse artigo, com esses pontos, foi inteiramente baseado no original em inglês, escrito pelo time da Sisense. Os créditos são deles. Isso é apenas uma tradução livre, mesclada com um resumo.

Primeira preocupação: testes funcionais Link para o cabeçalho

  • temos que garantir que não tenhamos bugs
  • certificar que a funcionalidade esteja de acordo com a especificação
  • evitar que merges e novas releases quebrem o que nós já temos

O que verificar no teste funcional? Link para o cabeçalho

  1. se o contrato está ok: os endpoints estão corretos? recursos refletem o que o objeto traz? existem erros de funcionalidade? relações entre os recursos estão ok? os verbos fazem sentido?
  2. as ações/verbos no teste: validar o status code, os JSON fields (no request e no response), cabeçalhos, verificar como fica o app (se aplicável), como fica o desempenho (em tempo)
  3. categorias de cenários de teste: testes positivos básicos (o famoso caminho feliz), testes positivos com parâmetros opcionais, testes negativos com entradas válidas (por ex, criar um usuário com e-mail já existente), testes negativos com entradas inválidas (por ex, criar um usuário com e-mail nulo), testes destrutivos (por ex, como quebrar a API por mandar campos muito grandes em um request), testes de segurança (autenticação, permissão)
  4. fluxos de teste:
    • testar solicitações isoladamente começar com esses testes, executando uma única solicitação de API e verificando a resposta de acordo
    • testar fluxo com várias etapas e solicitações
    • testes combinados de API e interface de usuário

O que garantir nos testes não-funcionais Link para o cabeçalho

Segurança e autenticação Link para o cabeçalho

Verificar se alguns princípios são respeitados:

  1. deny-by-default - quando o acesso é negado, a menos que quem está fazendo a requisição está especificamente autorizado
  2. fail securely - a menos que um usuário receba acesso explícito a um objeto, deve ser negado o acesso a esse objeto; este princípio requer que o acesso padrão a um objeto seja nenhum
  3. least privilege principle (princípio de privilégio mínimo):
    • um usuário deve receber apenas os privilégios necessários para completar sua tarefa
    • se um usuário não precisa de um direito de acesso, ele não deve ter esse direito
    • além disso, a função do usuário (em oposição à sua identidade) deve controlar a atribuição de direitos
  4. Rejeição de todas as entradas ilegais, lembrando que:
    • teste positivo: garantir que a API responda à autorização correta por meio de todos os métodos de autenticação definidos (auth token, cookies, etc) de acordo com a especificação
    • teste negativo: garanta que a API recuse todas as chamadas não autorizadas

É importante verificar também se:

  • o protocolo HTTP/HTTPS está sendo respeitado
  • garantir que informações de APIs privadas se mantenham privadas
  • ver se rate limit (controle de taxa de solicitações enviadas ou recebidas) e o throttling (limite do número de solicitações de API que um usuário pode fazer em um determinado período) estão sendo respeitados

Performance Link para o cabeçalho

  • validar tempo de resposta da API
  • verificar a latência
  • TTFB / TTLB em cenários isolados e sob carga

Testes de carga Link para o cabeçalho

  • sempre em cenários positivos
  • verificar se o sistema funciona sob carga

Testes de stress Link para o cabeçalho

  • sempre em cenários negativos
  • verificar se ele falha normalmente sob stress

Usabilidade Link para o cabeçalho

  • para APIs públicas, é bom um teste a nível de produto, para ver se a documentação de integração com a API está ok
  • a ideia é garantir a usabilidade da API para usuários sem conhecimento prévio do sistema

Postagem migrada do Medium. Link para o cabeçalho