Quais validações devo Realizar em uma API? (Postman — Parte 01)
Bom dia pessoal, estou fazendo um guia do que deve ser validado em testes de API, e dando alguns exemplos via Postman. O motivo desse post foi algumas dúvidas que geralmente recebo de juniores em Qualidade, ou em entrevista que faço, acredito que o mesmo vai ser muito útil em entrevistas para Analista de QA para o seu primeiro emprego.
A validação dos dados de uma API é sempre usando o Response (a resposta da nossa requisição). No Postman é a aba de “Tests”.
1. A primeira dúvida que uma pessoa Junior vai ter ao criar os testes, é “como devo organizar os meus testes?”. Geralmente eu organizo as pastas por features, já a organização da criação das requests tenho como base no CRUD, criar, ler, atualizar e deletar, a regra básica aqui é criar do zero os dados, e trabalhar com que você criou e no final deletar\apagar os dados criados, não utilizar dados já criados, isso pode gerar erros na automação.
Exemplo, crio a pasta Hotéis e as requests na ordem abaixo:
Hotéis
- Criar Hotel (Criar com massa randômica do zero, não utilize dados fixos, e armazenar os dados para os próximos testes).
- Ler Todos os Hotéis (aqui você pode validar pelo json schema ou validar o último adicionado).
- Ler o Hotel Criado.
- Atualizar os dados do Hotel criado.
- Deletar o Hotel criado.
** A informação mais importante a ser armazenada é o ID do Hotel criado, vai trabalhar com ele nas próximas requisições.
2. A segunda dúvida é “Quais são os testes que deve fazer?”.
Listamos primeiro os testes positivos, agora vamos partir para os negativos, coloquei dessa forma por uma questão prioridade na hora que formos construir nossos testes, não faz muito sentido fazer os testes negativos primeiro sendo que não fez os testes básicos a serem realizados.
Testes Positivos:
- Validar o Status Code de sucesso para aquela requisição;
- Validar as Regras de Negócio (se dar através dos dados do body de retorno);
- Validação campo a campo (validar todos os dados que estão retornando no body);
- Validar os dados importantes do header;
- Validar o json schema (quando fizer sentido, uma vez que está validando campo a campo o mesmo não faz sentido);
Testes Negativos:
- Regras de Negócio em caso de falha;
1.1 Mensagens e Códigos de Erros;
1.2 Indisponibilidade da aplicação e dos serviços;
1.3 Estrutura incorreta;
1.4 Falta de campos obrigatórios no body (Vai remover campos obrigatórios e analisar a mensagem de erro);
1.5 Valores incorretos (Mudar o tipagem dos campos, se for string mandar um inteiro, ou o inverso);
2. End point não encontrado (famoso 404);
Validar o Status Code correto em caso de erro (analise a tabela abaixo, pode acontecer de um status code de error está incorreto);
Os códigos de status das respostas HTTP indicam se uma requisição HTTP foi corretamente concluída. As respostas são agrupadas em cinco classes:
Status Code / Descrição
100–199 / Respostas de informação.
200–299 / Respostas de sucesso.
300–399 / Redirecionamentos.
400–499 / Erros do lado do cliente (Erros nos dados enviados ou na estrutura da requisição, ou seja a mesma foi mal formulada).
500–599 / Erros do lado do servidor (erros de Banco de Dados, Indisponibilidade de algum serviço, erros de tempo de resposta)
# Server Error.
500: (‘internal_server_error’, ‘server_error’, ‘/o\\’, ‘✗’),
501: (‘not_implemented’,),
502: (‘bad_gateway’,),
503: (‘service_unavailable’, ‘unavailable’),
504: (‘gateway_timeout’,),
505: (‘http_version_not_supported’, ‘http_version’),
506: (‘variant_also_negotiates’,),
507: (‘insufficient_storage’,),
509: (‘bandwidth_limit_exceeded’, ‘bandwidth’),
510: (‘not_extended’,),
511: (‘network_authentication_required’, ‘network_auth’, ‘network_authentication’),
Vamos pegar a API abaixo para darmos nossos exemplos:
Primeira coisa que fiz é ler o Swagger da API com os end points, sem a documentação da API é muito difícil construir os testes, o nosso primeiro trabalho seria atuar na documentação, antes de fazer os testes caso ela não existisse:
Fiz o exemplo do login, primeiro exemplo dado pelo Swagger, a resposta foi ”Email e/ou senha inválidos” já caiu no primeiro caso que falei “Não use dados fixos!!!”, crie sua massa de dados do zero, isso vai evitar inúmeras manutenções, a nossa primeira requisição deveria ser o criar usuário para não ter nenhum problema:
{
"message": "Email e/ou senha inválidos"
}
Obrigado pessoal espero que tenham gostado, eu continuo as validações no próximo POST, para não ficar um mega POST é melhor quebrar em partes, volto com os exemplos no Postman com base no que foi discutido sobre as validações dos testes.
;)
Referências:
https://learning.postman.com/docs/getting-started/introduction/
https://www.chaijs.com/api/bdd/