Diagrama y Grafo.

POSIBLES CAMINOS:

1. P1 P2 
2. P1 P3
3. P2
4. P3
5. P1 P2 P3 
6. P1 P3 P2
7. P4 P5
8. P4 P6
9. P4 P5 P4 P5
10. P4 P6 P4 P6 
11. P4 P5 P4 P6
12. P4 P6 P4 P5

INTRODUCCIÓN.

Una prueba es el chequeo o revisión de algo para comprobar que se encuentre en buen estado o cumpla con lo que se le especificó además de que se hacen para encontrar posibles fallas, errores o desperfectos que puedan afectar el rendimiento o funcionalidad del objeto en cuestión..


DESARROLLO


PRUEBAS DE CAJA BLANCA

Permiten examinar la estructura interna del programa. Se diseñan casos de prueba para examinar la lógica del programa, se basan en el diseño de casos de prueba que usa la estructura de control del diseño procedimental para derivarlos. Mediante la prueba de la caja blanca el ingeniero del software puede obtener casos de prueba que:

1. Garanticen que se ejerciten por lo menos una vez todos los caminos independientes de cada módulo, programa o método.
2. Ejerciten todas las decisiones lógicas en las vertientes verdadera y falsa.
3. Ejecuten todos los bucles en sus límites operacionales.
4. Ejerciten las estructuras internas de datos para asegurar su validez.

Es por ello que se considera a la prueba de Caja Blanca como uno de los tipos de pruebas más importantes que se le aplican a los software, logrando como resultado que disminuya en un gran por ciento el número de errores existentes en los sistemas y por ende una mayor calidad y confiabilidad.


PRUEBAS DE CAJA NEGRA

Las pruebas se llevan a cabo sobre la interfaz del software, y es completamente indiferente el comportamiento interno y la estructura del programa.

Las pruebas de caja negra son, ni más ni menos que, pruebas funcionales dedicadas a “mirar” en el exterior de lo que se prueba.

Estas pruebas se denominan de varias formas, pruebas de caja “opaca”, pruebas de entrada/salida, pruebas inducidas por datos…los sinónimos son muchos y muy variados.

Las pruebas de caja negra se centran principalmente en lo que “se quiere” de un módulo, charter o sección específica de un software, es decir, es una manera de encontrar casos específicos en ese modulo que atiendan a su especificación.

Las pruebas de caja negra se limitan a que el tester pruebe con “datos” de entrada y estudie como salen, sin preocuparse de lo que ocurre en el interior.

Éstas, principalmente, se centran en módulos o charters de interfaz de usuario (pantalla, ficheros, canales de comunicación…) pero suelen ser útiles en cualquier módulo ya que todos o la mayoría tienen datos de entrada y salida que se pueden comprobar y verificar.

CONCLUSIONES

Las pruebas son una parte fundamental del software porque nos permiten evitar cualquier error y/o corregirlo para hacer más confiable nuestro software.

BIBLIOGRAFÍA

http://www.ecured.cu/index.php/Pruebas_de_caja_blanca
http://indalog.ual.es/mtorres/LP/Prueba.pdf
http://www.globetesting.com/2012/08/pruebas-de-caja-negra/