Pruebas positivas y pruebas negativas con ejemplos
Tomas Hamilton
⚡ Resumen inteligente
Las pruebas positivas y negativas, en conjunto, determinan si el software acepta lo que debe y rechaza lo que no. Este artículo explica ambos enfoques, las técnicas que los sustentan, ejemplos prácticos y las prácticas que minimizan la fuga de defectos.
Las pruebas de software consisten en verificar y validar una aplicación para comprobar si funciona según lo previsto. El objetivo es detectar defectos y mejorar la calidad del producto. Existen dos métodos para probar el software: las pruebas positivas y las pruebas negativas.
Ambos enfoques responden a preguntas opuestas: ¿la aplicación funciona cuando todo va bien y se mantiene estable cuando algo falla?
¿Qué es un resultado positivo en la prueba?
Pruebas positivas Es un tipo de prueba que se realiza en una aplicación de software proporcionándole conjuntos de datos válidos como entrada. Comprueba si la aplicación de software se comporta como se espera con entradas positivas o no.
Las pruebas positivas se realizan para comprobar si la aplicación de software hace exactamente lo que se espera de ella. Por lo tanto, también se las conoce como pruebas de funcionamiento normal.
Por ejemplo, considere el cuadro de texto numérico que se muestra a continuación.
.png)
Hay un cuadro de texto en una aplicación que solo puede aceptar números. El sistema aceptará valores de hasta 99999 y no aceptará ningún otro valor que no sea este. Para realizar una prueba positiva, configure los valores de entrada válidos de 0 a 99999 y verifique si el sistema acepta los valores.
¿Qué son las pruebas negativas?
Prueba negativa Es un método de prueba que se aplica a la aplicación de software proporcionándole conjuntos de datos no válidos o incorrectos como entrada. Comprueba si la aplicación se comporta como se espera ante entradas de usuario negativas o no deseadas.
El objetivo de las pruebas negativas es garantizar que la aplicación de software no falle y se mantenga estable ante la introducción de datos no válidos. Por ello, también se las conoce como pruebas de ruta de error o pruebas de fallo.
Por ejemplo, consideremos el mismo campo recibiendo caracteres en lugar de dígitos.
.png)
Se pueden realizar pruebas negativas ingresando los caracteres de la A a la Z o de la A a la Z. Cualquiera de los sistemas de software no debería aceptar los valores o debería generar un mensaje de error por estas entradas de datos no válidas.
En ambos tipos de pruebas, se debe tener en cuenta lo siguiente:
- Datos de entrada
- Una acción que debe realizarse
- Resultado de salida
Pruebas positivas frente a pruebas negativas: diferencias clave
Ambos enfoques comparten la misma caso de prueba estructura. La diferencia radica en la información que se proporciona y en lo que demuestra un resultado satisfactorio.
| Parámetro | Pruebas positivas | Prueba negativa |
|---|---|---|
| También conocido como | Pruebas de ruta feliz | Pruebas de ruta de error o fallos |
| Entrada utilizada | Datos válidos y esperados | Datos no válidos, extremos o inesperados |
| Objetivo | Confirma que la función hace lo que debería. | Confirma que la función rechaza lo que no debería. |
| Gastos esperados | El flujo se completa con éxito. | Aparece un error claro y el sistema permanece estable. |
| Manejo de errores | No es el objetivo. | Todo el enfoque |
| Global | Estrecho, cumple con las especificaciones. | Amplio, explora todo lo que está fuera de las especificaciones. |
| Riesgo típico si se omite | Las características principales se envían defectuosas | Los fallos y las vulnerabilidades de seguridad llegan a la producción. |
Una prueba positiva fallida indica un funcionamiento defectuoso. Una prueba negativa fallida indica la falta de una protección, cuya reparación resulta mucho más costosa una vez que los usuarios la detectan.
Técnicas de análisis utilizadas para pruebas positivas y negativas
En la práctica, dos técnicas clásicas de diseño de entradas generan casos tanto positivos como negativos a partir del mismo requisito:
- Análisis de valor límite
- Partición de equivalencia
Análisis de valor límite
Esta es una de las técnicas de prueba de software en la que los casos de prueba están diseñados para incluir valores en el límite. Si los datos de entrada se utilizan dentro de los límites del valor límite, se dice que es una prueba positiva. Si los datos de entrada se seleccionan fuera de los límites del valor límite, se dice que es una prueba negativa.
Por ejemplo, observe el rango aceptado que se muestra a continuación.
.png)
Un sistema puede aceptar números del 0 al 10. Todos los demás números son valores no válidos. Con esta técnica, se probarán los valores límite -1,0,1, 9,10,11, XNUMX y XNUMX, XNUMX, XNUMX.
Partición de equivalencia
Esto es una pruebas de software Técnica que divide los datos de entrada en muchas particiones. Los valores de cada partición se deben probar al menos una vez. Las particiones con valores válidos se utilizan para pruebas positivas. Mientras que las particiones con valores no válidos se utilizan para pruebas negativas.
Por ejemplo, estudie las dos particiones que se muestran a continuación.
.png)
Los valores numéricos del cero al diez se pueden dividir en dos (o tres) particiones. En nuestro caso, tenemos dos particiones: de -10 a -1 y de 0 a 10. Se pueden tomar valores de muestra (5 y -5) de cada parte para probar los escenarios. Consulte la partición de equivalencia y análisis de valores límite lección para más ejemplos resueltos.
Cómo realizar pruebas positivas y negativas
La siguiente secuencia convierte un requisito en un conjunto equilibrado de casos positivos y negativos.
- Lea los requisitos para los límites. Tenga en cuenta todos los formatos, rangos y campos obligatorios aceptados. Todo lo que la especificación permite se considera un caso positivo, y todo lo que excluye, un caso negativo.
- Escribe primero el caso positivo. Proporcione datos válidos, realice la acción y registre el resultado de éxito esperado como punto de partida.
- Derive los casos negativos a partir de los mismos límites. Utilice el análisis de valores límite y la partición de equivalencia para producir campos en blanco, tipos de datos incorrectos y números fuera de rango.
- Agregar entrada hostil. incluyen inyección SQL cadenas, tokens caducados y cargas útiles de API mal formadas, por lo que pruebas de seguridad Las deficiencias salen a la luz pronto.
- Ampliar a comprobaciones no funcionales. A prueba de carga en el recuento de usuarios admitidos es positivo, mientras que un prueba de estrés Más allá de ese límite se encuentra el caso negativo correspondiente.
- Elige dónde se desarrolla cada caso. Mantenga los casos negativos fuera de Pruebas de humo y cordura, que son puertas rápidas positivas, y las ejecuta en modo funcional y pruebas de regresión ciclos
Un retiro en cajero automático muestra la vinculación. En el caso positivo, se ingresa el PIN correcto y un monto válido, por lo que se recibe el efectivo y el recibo. En el caso negativo, se ingresa un PIN incorrecto y se espera un mensaje de rechazo, seguido del bloqueo de la tarjeta.
Mejores prácticas para mantener el equilibrio correcto
- Antes de que comience el desarrollo, redacte al menos dos casos por cada requisito, uno positivo y otro negativo.
- Priorice los casos negativos según su impacto, de modo que los fallos de inyección y pago tengan prioridad sobre los errores estéticos de introducción de datos.
- Asegúrese de que el mensaje de error sea el correcto, no solo que la acción haya fallado, porque los mensajes vagos también son defectos.
- Deje espacio para Prueba exploratoriay registre los hallazgos a través de su proceso de gestión de defectos.
⚠️ Advertencia: Nunca ejecutes casos negativos en un entorno de producción real. Su propósito es provocar fallos, y un fallo provocado intencionadamente afecta a usuarios reales y a datos reales.
