Dá um exemplo de como escolherias os casos de teste para uma requisição PUT.

A seleção de casos de teste para pedidos PUT destina-se a verificar a atualização correta do recurso, o tratamento de diferentes tipos de dados e cenários negativos.

Exemplos de casos de teste:

1. Cenário positivo (atualização bem-sucedida):

   • Atualizar o recurso com todos os campos válidos.
   • Atualizar o recurso apenas com parte dos campos válidos (se a API permitir atualização parcial).
   • Atualizar campos com diferentes tipos de dados (strings, números, valores booleanos), se previsto no esquema.
   • Atualizar o recurso com valores mínimos permitidos (se aplicável).
   • Atualizar o recurso com valores máximos permitidos (se aplicável).

2. Cenários negativos (erros e exceções):

   • Tentar atualizar um recurso inexistente. Resposta esperada: 404 Not Found.
   • Enviar requisição sem corpo. Resposta esperada: 400 Bad Request ou 422 Unprocessable Entity.
   • Enviar requisição com formato de corpo inválido (por exemplo, JSON inválido). Resposta esperada: 400 Bad Request.
   • Enviar requisição com tipos de dados inválidos para os campos. Por exemplo, string em vez de número. Resposta esperada: 400 Bad Request ou 422 Unprocessable Entity.
   • Enviar requisição com campos obrigatórios omitidos no corpo. Resposta esperada: 400 Bad Request ou 422 Unprocessable Entity.
   • Enviar requisição com campos que excedem o comprimento ou intervalo permitido. Resposta esperada: 400 Bad Request ou 422 Unprocessable Entity.
   • Enviar requisição com valor inválido na rota (por exemplo, ID inválido). Resposta esperada: 400 Bad Request ou 404 Not Found.
   • Tentar atualizar um recurso bloqueado ou inacessível (se aplicável). Resposta esperada: 403 Forbidden ou 409 Conflict.
   • Enviar requisição com cabeçalhos incorretos (por exemplo, Content-Type). Resposta esperada: 415 Unsupported Media Type ou 400 Bad Request.
   • Atualizar usando caracteres especiais ou emoji em campos de texto.

3. Condições limites:

   • Atualizar campos com valores limite (por exemplo, data mínima/máxima, números limite).
   • Atualizar campos com strings vazias ou valores null (se permitido).

4. Cenários de acesso paralelo:

   • Tentativa simultânea de atualizar o mesmo recurso de múltiplas fontes (se relevante para o sistema testado).

5. Verificação das consequências da atualização:

   • Verificar se os dados foram atualizados corretamente na base de dados ou outros sistemas.
   • Verificar se recursos ou dados dependentes foram atualizados/modificados de forma adequada (se houver dependências).
   • Verificar se uma requisição GET ao recurso atualizado retorna dados atuais.
   • Verificar se outras operações (DELETE, POST) com o recurso atualizado funcionam corretamente.

Os critérios para selecionar casos de teste específicos dependem da especificação da API, requisitos de negócios, análise de riscos e prioridades. Técnicas de design de testes, como particionamento de equivalência e análise de limites, são usadas para determinar as opções de entrada mais representativas.