Las comprobaciones positivas muestran que una API maneja los escenarios esperados. Las negativas revelan su resistencia ante entradas no válidas, inesperadas y peligrosas. Esto es especialmente valioso para QA porque suele descubrir debilidades en la validación, el tratamiento de errores, la seguridad y la estabilidad del servicio.
Los usuarios y las integraciones rara vez se comportan perfectamente. Pueden enviar campos vacíos, tipos incorrectos, tokens caducados, cuerpos demasiado grandes o invocar endpoints en estados no válidos. Una buena API debe responder de manera predecible y segura, no limitarse a evitar una caída.
Qué significan las pruebas negativas de API
Las pruebas negativas de API examinan el comportamiento del sistema con entradas no válidas, inesperadas, prohibidas o contradictorias.
Abarcan mucho más que enviar un campo vacío:
- →Campos obligatorios ausentes
- →Valores con formato incorrecto
- →Tipos de datos incompatibles
- →Valores fuera de rango
- →Combinaciones de campos que incumplen reglas de negocio
- →Usuarios no autenticados o sin autorización
- →Cuerpos de solicitudes demasiado grandes
- →Content-Type inesperado
- →Métodos que no deberían admitirse en ese endpoint
- →Solicitudes repetidas que crean conflictos
Por tanto, las pruebas negativas comprueban tanto la corrección de las entradas como la resistencia de la API ante un uso incorrecto.
Por qué es especialmente importante en las API
La interfaz ofrece cierta protección mediante formularios, máscaras, listas desplegables y botones deshabilitados. Las API no tienen esa misma capa. Reciben solicitudes directamente y deben decidir cómo tratarlas.
Unas pruebas negativas de API deficientes suelen dejar tres riesgos:
- →El servicio falla ante una entrada incorrecta.
- →El servicio se comporta de manera impredecible.
- →El servicio acepta algo que debería rechazar.
Si solo pruebas el recorrido correcto, observas una parte muy limitada del comportamiento real del sistema.
Qué poner a prueba
Unas buenas pruebas negativas siguen clases de entradas, en lugar de intentar introducir datos sin sentido de forma arbitraria.
Prueba regularmente estos grupos:
- →Falta un campo obligatorio.
- →Un campo está presente, pero vacío.
- →Un campo está presente, pero contiene null.
- →El tipo es incorrecto: una cadena en lugar de un número o un objeto en lugar de un array.
- →Una cadena supera la longitud máxima.
- →Un número está por debajo del mínimo o por encima del máximo.
- →Una fecha, correo electrónico, teléfono, UUID o valor de enumeración tiene un formato no válido.
- →Los parámetros forman una combinación no válida.
- →Se incluyen campos adicionales inesperados.
- →El método de la solicitud es incorrecto.
- →Content-Type es incorrecto.
- →El token está dañado o ha caducado.
- →La solicitud apunta a un recurso de otro usuario.
- →El cuerpo de la solicitud es demasiado grande.
- →La solicitud se repite en un estado que provoca un conflicto.
Un enfoque sistemático convierte estas comprobaciones en un modelo repetible de calidad de la API, no en intentos caóticos de romper algo.
Qué caracteriza una buena prueba negativa
Una prueba negativa débil solo comprueba que se produjo un error. Una sólida examina mucho más.
- →¿El código de estado es correcto?
- →¿El cliente puede entender el error?
- →¿La respuesta expone detalles internos innecesarios?
- →¿Cambió algún dato cuando no debía hacerlo?
- →¿Hubo efectos secundarios?
- →¿Repetir la misma solicitud no válida produce un comportamiento coherente?
- →¿El servicio evita devolver 500 por un problema del lado del cliente?
Por ejemplo, un JSON no válido suele justificar 400 en lugar de 500. Intentar modificar un recurso de otro usuario normalmente requiere 403 o 404, no un éxito. Un cuerpo demasiado grande puede justificar 413. El objetivo es un tratamiento coherente y comprensible, no adivinar un código ideal para todos los casos.
Qué inspeccionar además del error
Un hábito sólido es comprobar siempre el estado del sistema después de una solicitud fallida.
- →¿Realmente no se creó ningún registro?
- →¿El estado del objeto permaneció igual?
- →¿No se cobró dinero?
- →¿No se envió ningún correo?
- →¿La auditoría y los registros guardaron correctamente el evento?
- →¿Repetir la solicitud dejó el sistema en un estado válido?
Aquí se esconden muchos defectos peligrosos. La API devuelve un error externamente, pero internamente ya ha modificado parcialmente los datos. Los usuarios pueden ver las consecuencias más tarde como un defecto aparentemente aleatorio, aunque la causa real fuera un tratamiento deficiente de los escenarios negativos.
Ejemplo práctico
Considera un endpoint de creación de usuarios.
El escenario positivo es sencillo: enviar un correo, nombre y contraseña válidos y recibir 201 Created.
Ahora considera los escenarios negativos:
- →Falta el correo electrónico.
- →El correo está vacío.
- →El correo no es válido.
- →La contraseña es demasiado corta.
- →Un campo del cuerpo tiene un tipo inesperado.
- →Falta la autorización cuando es obligatoria.
- →Se registra de nuevo el mismo correo.
- →El cuerpo es demasiado grande.
- →Content-Type no es application/json.
QA debe verificar lo siguiente:
- →El servidor responde de manera predecible.
- →El error es suficientemente claro para el cliente.
- →El código de estado corresponde a la clase de problema.
- →No se crea ningún registro no válido.
- →No se producen efectos secundarios no deseados.
- →Repetir la misma solicitud no válida no deteriora más el sistema.
En este punto, las pruebas negativas se convierten en una evaluación sustancial de la madurez de la API, no en un añadido opcional.
Ideas clave para profesionales de QA
- →Las pruebas negativas de API examinan la resistencia del sistema junto con los errores de entrada.
- →Una buena prueba negativa comprueba tanto el código de error como el estado posterior del sistema.
- →Una API sólida trata las solicitudes incorrectas de forma segura y predecible.
- →El recorrido correcto por sí solo casi nunca demuestra la fiabilidad real del servicio.
- →Organiza las comprobaciones negativas en torno a clases de riesgo, no a intentos aleatorios de romper algo.
Lecturas adicionales
- →En esta base de conocimientos: métodos, códigos de estado y cabeceras
- →En esta base de conocimientos: autenticación y autorización
- →Recurso externo: Guía de seguridad REST de OWASP
Una matriz local de pruebas negativas con comprobación de efectos secundarios
Utiliza un contrato local ficticio en lugar de adivinar qué debería devolver cualquier API. El fixture de práctica preparado acepta POST /items con un token didáctico de administrador, Content-Type application/json, un name de entre 3 y 12 letras ASCII y una quantity entera entre 1 y 5. El cuerpo debe contener exactamente esos dos campos. Los datos permanecen en memoria; inicia un servidor nuevo para cada prueba independiente.
Caso Ejemplo Esperado en este entorno de prueba
Campo ausente {"name":"abc"} 422 invalid_fields
Tipo incorrecto {"name":"abc","quantity":"1"} 422 invalid_quantity
Fuera de rango {"name":"abc","quantity":6} 422 invalid_quantity
Campo adicional {"name":"abc","quantity":1,"admin":true} 422 invalid_fields
JSON malformado { 400 malformed_json
Tipo de medio incorrecto Content-Type: text/plain 415 json_required
Cuerpo de más de 1024 bytes Cuerpo de 1025 bytes 413 payload_too_largeAntes de cada escritura rechazada, ejecuta GET /items y registra total; repite después y exige que total no cambie. Esto detecta una implementación que devuelve un error después de escribir un registro. Para un nombre nuevo aceptado, espera 201 y total + 1; enviarlo otra vez devuelve 409 sin una segunda incorporación. Estos estados describen el contrato declarado, no una regla que todos los productos deban utilizar.
python3 mock_api.py --port 8765
# In another terminal, using only the synthetic local token:
curl -i http://127.0.0.1:8765/items -H "Authorization: Bearer demo-admin" -H "Content-Type: application/json" --data '{"name":"abc","quantity":6}'
python3 -m unittest test_mock_api.py -vEl fixture de prueba es deliberadamente local y simplificado. Utilízalo para practicar la selección de entradas y la recopilación de evidencias; no copies sus tokens fijos ni su servidor HTTP a un sistema de autenticación de producción.
Seguir aprendiendo
Descargar el laboratorio de práctica local (ZIP)