¿Qué son las pruebas negativas? Casos de prueba con ejemplo

⚡ Resumen inteligente

Las pruebas negativas comprueban cómo se comporta una aplicación de software cuando recibe datos de entrada o condiciones de funcionamiento inesperadas, de modo que el producto se degrada de forma gradual en lugar de bloquearse, corromper datos o exponer una vulnerabilidad de seguridad.

  • 🔴 Propósito: Confirme que la aplicación rechaza correctamente los datos no válidos en lugar de fallar o bloquearse.
  • 🇧🇷 Contraste: Las pruebas positivas demuestran que todo va por buen camino; las pruebas negativas exploran todo lo que está fuera de él.
  • 🛗 Analogía: Un ascensor debe resistir sobrecargas, incendios y cortes de energía, no solo los viajes normales de pasajeros.
  • 🔒 Seguridad: Las cargas de archivos no válidas y los intentos de inyección SQL son escenarios de prueba negativos clásicos.
  • 🧪 Diseño: Los casos se generan mediante valores límite, clases de equivalencia, estimación de errores y pruebas de fuzzing.
  • 📊 Prioridad: Clasifique las entradas no válidas según su impacto, ya que una cobertura negativa exhaustiva resulta inasequible.
  • ⚠️ Compensación: El exceso de pruebas negativas consume un presupuesto que podría requerir más fondos para la cobertura de pruebas positivas.

Pruebas negativas en pruebas de software con ejemplos de entrada no válida

Prueba negativa

Prueba negativa Es un tipo de prueba de software que se utiliza para verificar una aplicación ante datos de entrada y condiciones inesperadas. Estos datos o condiciones inesperadas pueden variar desde un tipo de dato incorrecto en un campo de formulario simple hasta un ataque informático deliberado. El objetivo de las pruebas negativas es evitar que la aplicación falle ante entradas no válidas y mejorar la calidad y la estabilidad del producto.

Las pruebas positivas por sí solas solo demuestran que el sistema funciona en condiciones normales. Las pruebas negativas confirman que el mismo sistema también maneja condiciones anormales, que es lo que requiere un producto tolerante a fallos.

Ejemplo de prueba negativa

Un ascensor es el ejemplo que se usa con más frecuencia para explicar las pruebas negativas, porque tanto su comportamiento normal como su comportamiento ante fallos son fáciles de visualizar.

El funcionamiento de un ascensor es familiar: al pulsar el número de un piso, el ascensor se dirige a ese piso y la puerta se abre automáticamente una vez que llega al piso especificado.

A continuación se enumeran algunos escenarios negativos para el mismo levantamiento, junto con la suposición de que las pruebas positivas hacen en su lugar.

Prueba negativa Pruebas positivas
¿Qué sucede si el número de personas (peso) excede el límite especificado? Se asume que solo el número de personas especificado entrará en el ascensor.
¿Qué ocurre si alguien fuma o provoca un incendio dentro del ascensor? Se supone que no habrá humo ni fuego dentro del ascensor.
¿Qué sucede si hay un corte de energía durante la operación? Se supone que no habrá cortes de energía mientras el ascensor esté funcionando.

Todos estos casos dieron negativo en las pruebas. No se puede garantizar que ninguno de ellos nunca vuelva a ocurrir, por lo que cada uno debe ser contenido.

Supongamos que nunca se comprueba la condición de sobrepeso y que el ascensor se comporta de forma anómala una vez sobrecargado. Esa única deficiencia compromete la fiabilidad del sistema e incluso puede poner en peligro vidas. Esto es lo que significa en la práctica una prueba negativa y por qué es importante.

El software se comporta de la misma manera. Una prueba negativa se desvía deliberadamente del procedimiento operativo normal. Consideremos un formulario de registro.

Prueba negativa Pruebas positivas
Introduzca una dirección de correo electrónico no válida en el campo de correo electrónico. Solo se ingresan direcciones de correo electrónico válidas en el campo de correo electrónico.
Introduzca un número de teléfono no válido, como caracteres, en el campo correspondiente. Solo se introducen números en el campo numérico.
Sube una imagen con un tamaño fuera del límite especificado. Solo se subirán las imágenes que se encuentren dentro del límite de tamaño especificado.
Subir archivos no válidos como XML or SQL archivos en un campo de carga de imágenes Solo se permiten subir imágenes en formatos válidos como .jpg o .png.

Cada uno de estos casos negativos debe dejar el sistema funcionando. Si se introduce un carácter en un campo numérico, la aplicación no puede procesar los datos inesperados que nunca esperó y puede bloquearse. Peor aún, un inyección SQL Una cadena de caracteres en el mismo campo podría borrar el contenido de la base de datos. Este tipo de pérdidas son la razón por la que existen las pruebas negativas.

¿Por qué hacer pruebas negativas?

Las pruebas consumen tiempo y dinero, por lo que decidir qué, cómo y cuánto probar es fundamental. La justificación para destinar parte de ese presupuesto a pruebas negativas varía según la perspectiva de cada participante en un proyecto.

Perspectiva de la organización

La organización tiene la responsabilidad de entregar un producto de buena calidad al cliente, y las pruebas negativas forman parte de esa obligación. Además, constituyen la prueba de que la organización hizo todo lo posible para prevenir un fallo, aunque ningún sistema está completamente libre de errores.

El impacto es el factor decisivo. Un sitio de comercio electrónico puede superar todas las pruebas positivas y aun así contener una vulnerabilidad que permita a un atacante realizar una inyección SQL y borrar los datos. Esto constituye una grave brecha de seguridad, y solo las pruebas negativas la detectan.

Las aplicaciones de acceso público, especialmente los sitios web, ofrecen prácticamente ningún control sobre cómo las utilizan los visitantes, por lo que las pruebas negativas son la única forma de confirmar que se detecta y controla el uso inusual. Lo mismo ocurre con los usuarios malintencionados: los atacantes buscan activamente oportunidades para vulnerar un sistema, y ​​los escenarios de piratería informática se incluyen directamente en la cobertura de las pruebas negativas.

Perspectiva del cliente

Los clientes esperan un producto sin vulnerabilidades, y las pruebas negativas son las que respaldan esa expectativa. Para productos sensibles como el comercio electrónico o la compraventa de acciones en línea, pruebas de seguridad y las pruebas negativas son obligatorias, no opcionales.

La única preocupación real del cliente es el costo. Una vez analizado el impacto de un fallo, el cliente puede decidir hasta dónde debe llegar el esfuerzo de pruebas negativas.

Cómo realizar una prueba negativa

Las pruebas negativas comienzan considerando cada entrada que la aplicación puede recibir físicamente, no solo las entradas que se supone que debe recibir. Cada una de ellas pertenece a un Caso de prueba incluso cuando es obvio que no se está utilizando la función de la manera correcta. Un campo de correo electrónico se prueba con todo lo que no sea una dirección de correo electrónico válida, y un control de carga de imágenes se prueba con todos los tipos de archivo que no sean imágenes.

La lista de posibles entradas no válidas es prácticamente interminable, por lo que es necesario priorizar los casos de prueba negativos. Para un campo de imagen que solo acepta archivos .png, las posibles cargas incluyen .jpeg, .xml, .xls y muchos otros. Un archivo XML o SQL tiene un impacto potencial mucho mayor que un .jpeg, por lo que esos casos se ejecutan primero. Clasificar los casos por impacto antes de su ejecución es lo que permite que las pruebas negativas sean asequibles.

La mayoría de los casos de prueba negativos provienen de un pequeño conjunto de técnicas de diseño establecidas, en lugar de la improvisación:

  • Valores límite: Ejecute los valores inmediatamente fuera de un rango válido, como 0 y 101 para un campo que acepta de 1 a 100.
  • Clases de equivalencia no válidas: Seleccione un representante de cada clase de entrada rechazada, por ejemplo, letras en un campo numérico.
  • Error al adivinar: Utilice la experiencia de defectos anteriores para identificar las entradas con mayor probabilidad de provocar fallos en este tipo de funcionalidad.
  • Datos mal formados y hostiles: Etiquetas de script, fragmentos SQL y cargas útiles de gran tamaño que ponen a prueba la validación y el manejo de la seguridad.
  • Prueba de fuzz: Generar automáticamente grandes volúmenes de datos de entrada aleatorios o modificados para detectar fallos no controlados.
  • Flujos interrumpidos: cancelar, actualizar, agotar el tiempo de espera o perder la conectividad a mitad de una transacción.

Independientemente de la técnica que produzca el problema, el resultado esperado debe documentarse como un fallo controlado y legible (un mensaje de validación, una carga rechazada, una reversión limpia) y nunca simplemente como "el sistema no falla".

Ventajas y desventajas de las pruebas con resultado negativo

Al igual que cualquier otra técnica de análisis, las pruebas negativas tienen ventajas e inconvenientes que dependen de dónde, cuándo y en qué cantidad se apliquen.

Ventajas de las pruebas negativas

  • Protege directamente la calidad del producto, ya que un producto de buena calidad es aquel que no presenta vulnerabilidades explotables.
  • Amplía la cobertura. Los datos de entrada no válidos llegan a un sistema en funcionamiento, ya sea de forma intencionada o accidental, por lo que los casos negativos deben procesarse junto con los positivos para que la cobertura sea significativa.
  • Aumenta la confianza del cliente antes de que se publique un lanzamiento.
  • Este método pone de manifiesto defectos que las pruebas positivas no pueden detectar estructuralmente, como excepciones no controladas y una validación de entrada deficiente.

Desventajas de las pruebas negativas

  • En algunos casos, supone una pérdida de tiempo y energía. Si una aplicación está diseñada para un solo usuario, no merece la pena probarla con 100 usuarios simultáneos, por lo que elegir las condiciones adecuadas es fundamental, y algunos sistemas requieren muy pocas pruebas negativas.
  • Se necesitan personas cualificadas y con experiencia para diseñar los casos.
  • Desde el punto de vista del cliente, esto supone un coste adicional y puede retrasar el lanzamiento.
  • Compite por el esfuerzo. Un equipo que gasta mucho en pruebas negativas puede terminar invirtiendo menos en pruebas positivas.

Preguntas Frecuentes

Las pruebas positivas proporcionan datos válidos y confirman el resultado esperado. Las pruebas negativas proporcionan datos no válidos, formatos incorrectos y secuencias rotas, y confirman que la aplicación los rechaza con un mensaje controlado en lugar de fallar.

Credenciales en blanco, un usuario válido con una contraseña incorrecta, fragmentos SQL en el nombre de usuario, cadenas demasiado largas, espacios al principio o al final, cuentas deshabilitadas e intentos fallidos repetidos para confirmar que el comportamiento de bloqueo funciona.

No. Se superponen cuando se trata de entradas no válidas u hostiles, pero las pruebas de seguridad también abarcan la autenticación, la autorización, el cifrado y la gestión de sesiones. Las pruebas negativas son una técnica más amplia que considera tanto las entradas como las condiciones.

Los probadores y los ingenieros de control de calidad suelen redactarlos, a menudo con un desarrollador que revisa las rutas de error y un analista de negocios que confirma qué condiciones no válidas prohíben realmente los requisitos.

Suficiente para cubrir todas las clases de entrada rechazadas, todos los límites y todas las rutas de fallo de alto impacto. Más allá de eso, los casos añadidos aportan poco valor, por lo que el riesgo y el impacto establecen el límite.ping -punto.

Sí. Los casos de entrada no válida son altamente repetibles, por lo que se adaptan. pruebas de automatización y conjuntos de pruebas de regresión. Las herramientas de fuzzing automatizan la generación de entradas aleatorias, mientras que las aserciones comprueban que aparezcan los mensajes de validación.

Los modelos leen los requisitos o el esquema del formulario y proponen valores no válidos, condiciones límite y cadenas problemáticas que un evaluador podría no enumerar manualmente. Un revisor confirma que cada resultado esperado coincide con la especificación.

Sí, genera código de aserción, datos de prueba no válidos y casos parametrizados a partir de un archivo de prueba existente. Las expectativas generadas deben revisarse, ya que una aserción que parezca plausible puede codificar un comportamiento erróneo.

Resumir este post con: