Da un ejemplo de cómo seleccionarías casos de prueba para una solicitud PUT.

La selección de casos de prueba para solicitudes PUT está dirigida a verificar la actualización correcta del recurso, el manejo de diferentes tipos de datos y escenarios negativos.

Ejemplos de casos de prueba:

1. Escenario positivo (actualización exitosa):

   • Actualización del recurso con todos los campos válidos.
   • Actualización del recurso solo con una parte de los campos válidos (si la API permite actualizaciones parciales).
   • Actualización de campos con diferentes tipos de datos (cadenas, números, valores booleanos), si está previsto en el esquema.
   • Actualización del recurso con valores mínimos permitidos (si aplica).
   • Actualización del recurso con valores máximos permitidos (si aplica).

2. Escenarios negativos (errores y excepciones):

   • Intento de actualizar un recurso inexistente. Respuesta esperada: 404 Not Found.
   • Envío de solicitud sin cuerpo. Respuesta esperada: 400 Bad Request o 422 Unprocessable Entity.
   • Envío de solicitud con formato de cuerpo no válido (por ejemplo, JSON no válido). Respuesta esperada: 400 Bad Request.
   • Envío de solicitud con tipos de datos no válidos para los campos. Por ejemplo, cadena en lugar de número. Respuesta esperada: 400 Bad Request o 422 Unprocessable Entity.
   • Envío de solicitud con campos obligatorios omitidos en el cuerpo. Respuesta esperada: 400 Bad Request o 422 Unprocessable Entity.
   • Envío de solicitud con campos que exceden la longitud/rango permitido. Respuesta esperada: 400 Bad Request o 422 Unprocessable Entity.
   • Envío de solicitud con valor no válido en la ruta (por ejemplo, ID no válido). Respuesta esperada: 400 Bad Request o 404 Not Found.
   • Intento de actualizar un recurso bloqueado o no accesible (si aplica). Respuesta esperada: 403 Forbidden o 409 Conflict.
   • Envío de solicitud con encabezados incorrectos (por ejemplo, Content-Type). Respuesta esperada: 415 Unsupported Media Type o 400 Bad Request.
   • Actualización usando caracteres especiales o emoji en campos de texto.

3. Condiciones límite:

   • Actualización de campos con valores límite (por ejemplo, fecha mínima/máxima, números límite).
   • Actualización de campos con cadenas vacías o valores null (si es permitido).

4. Escenarios de acceso paralelo:

   • Intento simultáneo de actualizar el mismo recurso desde múltiples fuentes (si es relevante para el sistema probado).

5. Verificación de las consecuencias de la actualización:

   • Verificación de que los datos se actualizaron correctamente en la base de datos u otros sistemas.
   • Verificación de que los recursos o datos dependientes fueron actualizados/modificados en consecuencia (si hay dependencias).
   • Verificación de que la solicitud GET al recurso actualizado devuelve datos actuales.
   • Verificación de que otras operaciones (DELETE, POST) con el recurso actualizado funcionan correctamente.

Los criterios para seleccionar casos de prueba específicos dependen de la especificación de la API, los requisitos comerciales, el análisis de riesgos y las prioridades. Se utiliza técnicas de diseño de pruebas, como partición equivalente y análisis de límites, para determinar las opciones más representativas de entrada.