PRUEBAS DE CAJA BLANCA Y NEGRA

Univ. : Rolando Javier Mendoza

INTRODUCCION
Imaginamos que vamos a una tienda y el vendedor nos quiere vender una caja negra en la que nos asegura que si pones dentro X bolivianos salen 2*X Bs, la condicin es que no puedes saber que hay dentro de la caja. Sin pensarnos la compraramos, pero antes deberamos comprobar que no es un timo y por eso probaramos la caja. Las pruebas que podramos realizar son: insertar 5 Bs y comprobar que salen 10

insertar 10 Bs y comprobar que salen 20

Y as sucesivamente

INTRODUCCION
De esta manera comprobaramos la funcionalidad de la caja sin saber como funciona. Este es lo que se conoce como pruebas de caja negra. Por otro lado imaginaros ahora que el vendedor os dice que podmos ver como funciona la caja, como somos testers muy curiosos vemos todos los mecanismos que hay dentro de la caja y vemos que tiene una sofisticada mquina de fabricar billetes con muchos conductos (uno para cada tipo de billete), es decir vemos todas las entradas, las salidas y los pasos intermedios (los conductos de los billetes). Para asegurarnos que funciona perfectamente la mquina (ya que el precio ha subido desde que podemos ver como funciona) decidimos probar todos los caminos posibles intermedios que podemos ver. En este caso estaramos realizando pruebas de caja blanca ya que sabemos el contenido de la caja.

INTRODUCCION
Si trasladamos la analoga al mundo real, las pruebas de caja negra sera aquellas en las que no tenemos acceso al cdigo fuente, solo podemos probar la funcionalidad mediante entradas y salidas mientras que las pruebas de caja blanca seran probando cada una de las condiciones o caminos del cdigo teniendo acceso a l.
Cual de las dos tcnicas es mejor?

INTRODUCCION
La fase de pruebas es una de las ms costosas del ciclo de vida software. En sentido estricto, deben realizarse pruebas de todos los artefactos generados durante la construccin de un producto, lo que incluye especificaciones de requisitos, casos de uso, diagramas de diversos tipos y, por supuesto, el cdigo fuente y el resto de productos que forman parte de la aplicacin. Obviamente, se aplican diferentes tcnicas de prueba a cada tipo de producto software.

INTRODUCCION
Una vez generado el cdigo el software debe ser probado para descubrir el mximo de errores posibles antes de su entrega al cliente. Es probado para descubrir errores cometidos sin darse cuenta al realizar su diseo y construccin La prueba requiere una mayor cantidad del esfuerzo dedicado al proyecto que cualquier otra actividad de ingeniera del software. El ingeniero crea una serie de casos de prueba que intentan "demoler" el software que ha sido construido. Tiene como objetivos: 1. La prueba es un proceso de ejecucin de un programa con la intencin de descubrir un error. 2. Un buen caso de prueba es aquel que tiene una alta probabilidad de mostrar un error no descubierto hasta entonces. 3. Una prueba tiene xito si descubre un error no detectado hasta entonces.

INTRODUCCION
Hay dos maneras de probar cualquier producto: Si se conoce la funcin especfica para la que se diseo el producto se aplican pruebas que demuestren que cada funcin es plenamente operacional, mientras se buscan los errores de cada funcin. Si se conoce el funcionamiento interno el producto, se aplican pruebas para asegurar que todas las piezas encajen, es decir, que las operaciones internas se realicen de acuerdo con las especificaciones.

CRITERIOS DE COBERTURA
De acuerdo con (Cornett 2002), el anlisis de cobertura del cdigo es el proceso de: Encontrar fragmentos del programa que no son ejecutados por los casos de prueba. Crear casos de prueba adicionales que incrementen la cobertura. Determinar un valor cuantitativo de la cobertura (que es, de manera indirecta, una medida de la calidad del programa). Adicionalmente, el anlisis de cobertura tambin permite la identificacin de casos de prueba redundantes, que no incrementan la cobertura.

CRITERIOS DE COBERTURA

1. COBERTURA DE SENTENCIAS:
Comprueba el nmero de sentencias ejecutables que se han ejecutado. Mantenimiento Avanzado de Sistemas de Informacin Pruebas del software. Por segmento se entiende una secuencia de sentencias sin puntos de decisin. Como el ordenador est obligado a ejecutarlas una tras otra, es lo mismo decir que se han ejecutado todas las sentencias o todos los segmentos. El nmero de sentencias de un programa es finito. Basta coger el cdigo fuente e ir contando. Se puede disear un plan de pruebas que vaya ejercitando ms y ms sentencias, hasta que hayamos pasado por todas, o por una inmensa mayora. En la prctica, el proceso de pruebas termina antes de llegar al 100%, pues puede ser excesivamente laborioso y costoso provocar el paso por todas y cada una de las sentencias.

CRITERIOS DE COBERTURA

2. COBERTURA DE DECISIONES:
Comprueba el nmero de decisiones ejecutadas, considerando que se ha ejecutado una decisin cuando se han recorrido todas sus posible ramas (la que la hace true y la que la hace false, pero tambin todas las posibles ramas de un switch). Desde el punto de vista de cobertura de segmentos, basta ejecutar una vez, con xito en la condicin, para cubrir todas las sentencias posibles. Sin embargo, desde el punto de vista de la lgica del programa, tambin debe ser importante el caso de que la condicin falle (si no lo fuera, sobra el IF). Sin embargo, como en la rama ELSE no hay sentencias, con 0 ejecuciones tenemos el 100%.

CRITERIOS DE COBERTURA
3. Cobertura de condiciones: Comprueba el nmero de condiciones ejecutadas, entendiendo que se ha ejecutado una condicin cuando se han ejecutado todas sus posibles ramas. 4. Cobertura de condiciones mltiples: Comprueba el nmero de condiciones mltiples ejecutadas, considerando que se ha ejecutado una condicin mltiple cuando se han ejecutado todas sus correspondientes ramas con todas las posibles variantes de la instruccin condicional. 5. Cobertura de condiciones/decisiones: Comprueba el nmero de condiciones y decisiones que se han ejecutado. 6. Cobertura de caminos: Comprueba el nmero de caminos linealmente independientes que se han ejecutado en el grafo de flujo de la unidad que se est probando. El nmero de caminos linealmente independientes coincide con la complejidad ciclomtica de McCabe. 7. Cobertura de funciones: Comprueba el nmero de funciones y procedimientos que han sido llamados.

CRITERIOS DE COBERTURA
8. Cobertura de llamadas: Comprueba el nmero de llamadas a funciones y procedimientos que se han ejecutado. 9. Cubrimiento de bucles: Comprueba el nmero de bucles que han sido ejecutados cero veces (excepto para bucles do -While), una vez y ms de una vez. Los bucles no son ms que segmentos controlados por decisiones. 10. Cubrimiento de carrera: Comprueba el nmero de tareas o hilos que han ejecutado simultneamente el mismo bloque de cdigo. 11. Cobertura de operadores relacionales: Comprueba si se han ejecutado los valores lmite en los operadores relacionales (>, <, >=, <=), ya que se asume la hiptesis de que estas situaciones son propensas a errores. 12. Cobertura de tablas: Comprueba si se ha hecho referencia a todos los elementos de los arrays.

PRUEBAS DE CAJA BLANCA

verificar que lneas especficas de cdigo funcionan tal como esta definido

INTENTAN GARANTIZAR QUE

Se utilizan las decisiones en su parte verdadera y en su parte falsa Se ejecuten todos los bucles en sus lmites Se utilizan todas las estructuras de datos internas.

EJEMPLO