Dê um exemplo de como você escolheria casos de teste para uma requisição PUT.

Ao selecionar casos de teste para uma requisição PUT, eu guiaria-me pelos seguintes princípios:

1. Cenários positivos:

   • Atualização completa bem-sucedida de um recurso existente com dados válidos.
   • Atualização parcial bem-sucedida de um recurso existente (se a API suportar).
   • Atualização do recurso usando valores limite para os campos.

2. Cenários negativos:

   • Recurso não encontrado pelo ID especificado.
   • Formato de ID de recurso inválido.
   • Tipo de dado inválido nos campos da requisição.
   • Campos obrigatórios ausentes no corpo da requisição.
   • Formato incorreto do corpo da requisição (por exemplo, não JSON).
   • Tentativa de atualizar campos que não devem ser modificados (por exemplo, ID, data de criação).
   • Direitos de acesso insuficientes para atualizar o recurso.
   • Atualização concorrente do recurso (para verificar o tratamento de conflitos).

3. Condições limite:

   • Valores máximos permitidos para campos numéricos.
   • Strings vazias para campos de texto (se permitido).
   • Caracteres especiais em campos de texto.
   • Strings longas para campos de texto.

4. Verificação de efeitos colaterais:

   • Alteração de outros recursos relacionados após a atualização.
   • Correta exibição dos dados atualizados em outras partes do sistema (por exemplo, na interface do usuário).

Exemplo de estrutura de casos de teste (para o recurso user com campos id, name, email):

ID do Caso de Teste	Descrição	URL da Requisição	Corpo da Requisição	Código de Estado Esperado	Comportamento / Corpo da Resposta Esperado
PUT_USR_001	Atualização completa bem-sucedida	/users/123	{"name": "Novo Nome", "email": "novo@exemplo.com"}	200	Dados do usuário atualizados retornados
PUT_USR_002	Usuário não encontrado	/users/999	{"name": "Novo Nome"}	404	Mensagem de erro indicando que o usuário não foi encontrado
PUT_USR_003	Formato de email inválido	/users/123	{"email": "email-invalido"}	400	Mensagem de erro indicando formato de email inválido
PUT_USR_004	Campo obrigatório ausente (se aplicável)	/users/123	{}	400	Mensagem de erro indicando campo ausente
PUT_USR_005	Valor limite máximo para um campo	/users/123	{"name": "A" * 255}	200	Dados do usuário atualizados com nome longo
PUT_USR_006	Tentativa de atualizar campo não atualizável (id)	/users/123	{"id": 456, "name": "Novo Nome"}	400/403	Mensagem de erro indicando requisição proibida ou incorreta

Claro, o conjunto específico de casos de teste dependerá da especificação da API, da lógica de negócio e da arquitetura do sistema.