Técnicas de prueba de software

CAJA NEGRA
En teoría de sistemas y física, se denomina caja negra a aquel elemento que es estudiado desde el punto de vista de las entradas que recibe y las salidas o respuestas que produce, sin tener en cuenta su funcionamiento interno. En otras palabras, de una caja negra nos interesará su forma de interactuar con el medio que le rodea (en ocasiones, otros elementos que también podrían ser cajas negras) entendiendo qué es lo que hace, pero sin dar importancia a cómo lo hace. Por tanto, de una caja negra deben estar muy bien definidas sus entradas y salidas, es decir, su interfaz; en cambio, no se precisa definir ni conocer los detalles internos de su funcionamiento.
A continuación se detalla el caso de prueba para el cálculo de métricas con Cocomo básico:
Caso de prueba 4
Cálculo de métricas de proyecto con Cocomo básico

Caja negra, entornos especializados y aplicaciones
Se probará el comportamiento del programa en el ingreso de diversos valores para los campos de texto correspondientes a los atributos del sistema.

RESULTADOS
Luego de encontrar los casos de prueba, se procede a ejecutar la aplicación para detectar los errores. Estos son los resultados obtenidos de la aplicación de cada uno de los casos de prueba.
Caso de prueba 1:
Se ejecuta el método con los datos de entrada especificados en el caso de prueba. Para este caso de prueba se está usando un valor para el factor de peso que está por debajo del límite establecido, por lo tanto no es válido. Luego de la ejecución del método el programa arroja siguiente resultado:
Punto de fusión= -1
El resultado obtenido después de la prueba es el resultado esperado, es decir, la prueba no tuvo éxito en detectar un error.
Caso de prueba 2:
Se ejecuta el método con los datos de entrada especificados en el caso de prueba. El valor usado para el factor de peso está dentro debajo de los límites, por lo tanto es válido. Luego de la ejecución del método el programa arroja siguiente resultado:
Punto de fusión = 129
El resultado obtenido es el esperado, la prueba no tuvo éxito en detectar un error.
Caso de prueba 3:
Se ejecuta el método con los datos de entrada especificados en el caso de prueba. El valor usado para el factor de peso que está por encima del límite, por lo tanto no es válido. Luego de la ejecución del método el programa arroja siguiente resultado:
Punto de fusión = -1
El resultado obtenido es el esperado, la prueba no tuvo éxito en detectar un error.
Caso de prueba 4:
Se ejecuta la aplicación con los datos de entrada especificados en el caso de prueba, los cuales se muestran en la imagen
 

Los resultados obtenidos luego de ejecutar la prueba son:
Punto de fusión: 431.6 Líneas de código: 13.811200000000000 Esfuerzo: 38 Tiempo de desarrollo: 10
Los cuales corresponden con los resultados esperados que se han especificado en el caso de prueba, por lo tanto ha fracasado en la búsqueda de errores.
Caso de prueba 5:
Esta prueba tiene como objetivo comprobar que el programa acepte sólo datos válidos en los campos de texto correspondientes a los atributos del sistema. Luego de la ejecución de la prueba estos son los resultados obtenidos:

La prueba ha tenido éxito, puesto que ha encontrado errores. El programa permite la entrada de números negativos, números con números decimales, números mesclados con símbolos o caracteres especiales
DEPURACIÓN
Luego de ejecutar un caso prueba exitoso se procede después con la etapa de depuración, esta consiste en encontrar la ubicación del error dentro del programa y corregirlo.
Tras encontrar y corregir el error, se ejecuta nuevamente la prueba y se obtienen los siguientes resultados:

La aplicación de la segunda prueba no tiene éxito, es decir el proceso de depuración ha permitido encontrar y corregir los errores encontrados.

CAJA BLANCA
En programación, se denomina cajas blancas a un tipo de pruebas de software que se realiza sobre las funciones internas de un módulo. Así como las pruebas de caja negra ejercitan los requisitos funcionales desde el exterior del módulo, las de caja blanca están dirigidas a las funciones internas. Entre las técnicas usadas se encuentran; la cobertura de caminos (pruebas que hagan que se recorran todos los posibles caminos de ejecución), pruebas sobre las expresiones lógico-aritméticas, pruebas de camino de datos (definición-uso de variables), comprobación de bucles (se verifican los bucles para 0,1 y n iteraciones, y luego para las iteraciones máximas, máximas menos uno y más uno.

 

 

Mediante el gráfico podemos observar las vías de ejecución del programa.
- 1,2,3,4
- 1,2,3,5,6
- 1,2,3,5,7,8,9
El número de caminos también se puede calcular a través de la complejidad ciclomática:
V(G) = A + N – 2
Donde A es el número de aristas en el grafo y N es el número de nodos
Para cada camino básico encontrado en el grafo de flujo se establece un caso de prueba:

Primer caso: Los atributos están por debajo del límite: factorPeso < 0
Segundo caso: Los atributos están por debajo del límite: factorPeso < 0
Tercer caso: Los atributos están por debajo del límite: factorPeso < 0
A continuación se detalla el primer caso de prueba, los casos 2 y 3 son similares:

INTEGRACIÓN INCREMENTAL.
Cuando nuevas funciones son ingresadas al sistema se hace la prueba basándose en la funcionalidad, la dependencia con otros módulos y la integración con el programa completo. ESTA PRUEBA NO ES APLICABLE PORQUE EL PROGRAMA NO REQUIERE DE NUEVOS MODULOS.

PRUEBA DE INTEGRACIÓN
Se basa en las pruebas de conexiones y comunicaciones entre diferentes módulos. Es esencial en sistemas de cliente_servidor o red. LA PRUEBA NO ES APLICABLE YA QUE EL PROGRAMA EN SI ES UNA APLCACION DE ESCRITORIO Y NO UTILIZA REDES.

PRUEBA DE FIN A FIN
Es similar a la prueba de sistema pero esta involucra la interacción con otro hardware, bases de datos y redes. ESTA PRUEBA NO SE PUEDE APLICAR YA QUE NO SE UTILIZA BASES DE DATOS EN EL PROCESO DE ESTIMACION ATRAVEZ DEL MODELO COCOMO, NI TAMPOCO HARDWARE EXTERNO ADICIONAL.

PRUEBA DE SANIDAD
Determina si la nueva versión de un software está bien realizada y si necesita un nuevo esfuerzo en la prueba de software. Por ejemplo la nueva versión de un programa cumple con casi todos los requisitos pero destruye la base de datos al leerla, por lo tanto se dice que este software no está en una condición sana.