Reingenieria de programa

REPUBLICA BOLIVARIANA DE VENEZUELA
MINISTERIO DEL PODER POPULAR PARA LA EDUCACIÓN SUPERIOR
INSTITUTO UNIVERSITARIO DE BARLOVENTO EXTENSIÓN “EL SARAO”
INGENIERÍA EN INFORMÁTICA
CÁTEDRA: ERQUITECTURA DEL COMPUTADOR.

TECNICA DE PRUEBA DE CAJA NEGRA

PROFESOR:
JEAN CARLOS GUZMÁN



Introducción
Una de las últimas fases del ciclo de vida antes de entregar un programa para suexplotación, es la fase de pruebas.
Una de las sorpresas con las que suelen encontrar los nuevos programadores es la enorme cantidad de tiempo y esfuerzo que requiere esta fase. Se estima que la mitad del esfuerzo de desarrollo de un programa (tanto en tiempo como en gastos) se va en esta fase. Si hablamos de programas que involucran vidas humanas (medicina, equipos nucleares, etc.) el costo de lafase de pruebas puede fácilmente superar el 80%.
Pese a su enorme impacto en el coste de desarrollo, es una fase que muchos programadores aún consideran clasificable como un arte y, por tanto, como difícilmente conceptualizable. Es muy difícil entrenar a los nuevos programadores, que aprenderán mucho más de su experiencia que de lo que les cuenten en los cursos de programación.



Técnicade Prueba de Caja Negra.
Sinónimos:
• pruebas de caja opaca
• pruebas funcionales
• pruebas de entrada/salida
• pruebas inducidas por los datos
Las pruebas de caja negra se centran en lo que se espera de un módulo, es decir, intentan encontrar casos en que el módulo no se atiene a su especificación. Por ello se denominan pruebas funcionales, y el probador se limita a suministrarle datoscomo entrada y estudiar la salida, sin preocuparse de lo que pueda estar haciendo el módulo por dentro.
Las pruebas de caja negra están especialmente indicadas en aquellos módulos que van a ser interfaz con el usuario (en sentido general: teclado, pantalla, ficheros, canales de comunicaciones, etc. etc.) Este comentario no obsta para que sean útiles en cualquier módulo del sistema.
Las pruebasde caja negra se apoyan en la especificación de requisitos del módulo. De hecho, se habla de "cobertura de especificación" para dar una medida del número de requisitos que se han probado. Es fácil obtener coberturas del 100% en módulos internos, aunque puede ser más laborioso en módulos con interfaz al exterior. En cualquier caso, es muy recomendable conseguir una alta cobertura en esta línea.El problema con las pruebas de caja negra no suele estar en el número de funciones proporcionadas por el módulo (que siempre es un número muy limitado en diseños razonables); sino en los datos que se le pasan a estas funciones. El conjunto de datos posibles suele ser muy amplio (por ejemplo, un entero).
A la vista de los requisitos de un módulo, se sigue una técnica algebraica conocida como"clases de equivalencia". Esta técnica trata cada parámetro como un modelo algebraico donde unos datos son equivalentes a otros. Si logramos partir un rango excesivamente amplio de posibles valores reales a un conjunto reducido de clases de equivalencia, entonces es suficiente probar un caso de cada clase, pues los demás datos de la misma clase son equivalentes.
El problema está pues en identificarclases de equivalencia, tarea para la que no existe una regla de aplicación universal; pero hay recetas para la mayor parte de los casos prácticos:
• si un parámetro de entrada debe estar comprendido en un cierto rango, aparecen 3 clases de equivalencia: por debajo, en y por encima del rango.
• si una entrada requiere un valor concreto, aparecen 3 clases de equivalencia: por debajo, en y porencima del rango.
• si una entrada requiere un valor de entre los de un conjunto, aparecen 2 clases de equivalencia: en el conjunto o fuera de él.
• si una entrada es booleana, hay 2 clases: si o no.
• los mismos criterios se aplican a las salidas esperadas: hay que intentar generar resultados en todas y cada una de las clases.
Ejemplo: utilizamos un entero para identificar el día del...