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

Para a seleção de casos de teste para a solicitação PUT, aplicaria as seguintes abordagens, focando em diferentes aspetos:

• Dados válidos:

  • Criação / alteração de um registo com dados corretos e completos.
  • Alteração apenas de alguns campos, mantendo os restantes inalterados.
  • Alteração de todos os campos para novos valores válidos.
  • Uso de valores limite para campos numéricos (mínimo, máximo).
  • Uso de diferentes formatos de dados permitidos pela especificação (por exemplo, data, hora).

• Dados inválidos:

  • Envio de dados com um tipo de campo incorreto (por exemplo, string em vez de número).
  • Envio de dados que violam restrições de comprimento de string ou intervalo de números.
  • Envio de dados que violam a unicidade do campo (se aplicável).
  • Envio de dados com formato incorreto (data inválida, email).
  • Falta de campos obrigatórios.
  • Envio de strings vazias ou null para campos que não devem estar vazios.

• Existência do recurso:

  • Requisição PUT a um recurso existente.
  • Requisição PUT a um recurso que não existe (resposta esperada 404).

• Autorização e autenticação:

  • Requisição PUT com credenciais corretas de um utilizador autorizado a modificar o recurso.
  • Requisição PUT com credenciais incorretas ou ausentes (esperado 401 Não autorizado ou 403 Proibido).
  • Requisição PUT de um utilizador sem os direitos necessários para modificar o recurso (esperado 403 Proibido).

• Sincronização e concorrência:

  • Requisições PUT simultâneas ao mesmo recurso (por exemplo, usando etag).

• Tratamento de erros:

  • Requisição PUT que deve causar um erro no lado do servidor (por exemplo, devido a uma falha interna).

Exemplo de tabela com casos de teste:

ID	Descrição do caso de teste	Pré-condições	Dados de teste (parte da requisição)	Resultado esperado	Código HTTP
PUT-001	Alteração de um recurso existente com dados válidos	Recurso com ID=123 existe	{ "name": "Novo Nome", "value": 100 }	Recurso atualizado com sucesso, os dados correspondem à requisição	200
PUT-002	Alteração de um recurso existente com atualização parcial	Recurso com ID=123 existe	{ "name": "Apenas nome alterado" }	Recurso atualizado com sucesso, apenas o campo name alterado	200
PUT-003	Tentativa de alteração de um recurso inexistente	Recurso com ID=999 não existe	{ "name": "Atualização inexistente" }	Recurso não encontrado	404
PUT-004	Alteração de recurso com tipo de dado inválido	Recurso com ID=123 existe	{ "value": "não_um_numero" }	Erro de validação de dados	400
PUT-005	Alteração de recurso sem autenticação	Recurso com ID=123 existe, requisição sem token	{ "name": "Alteração não autorizada" }	Não autorizado	401

Cada caso de teste deve ser atômico e verificar um aspeto específico da funcionalidade da requisição PUT.