1

ContenidoIntroducción.............................................................................................................................2

Glosario de términos............................................................................................................3

Clasificación.............................................................................................................................3

Definiciones.............................................................................................................................3

Caja negra............................................................................................................................3

Caja blanca..........................................................................................................................4

Ejemplos...................................................................................................................................5

Caja negra............................................................................................................................5

Caja blanca..........................................................................................................................6

Conclusiones...........................................................................................................................8

Bibliografía...............................................................................................................................8

IntroducciónLos términos caja negra y caja blanca son muy utilizados dentro de la teoría en sistemas con respecto al tipo de perspectiva con la cual es estudiado un sistema. Estos dos tipos de estudios dentro de un sistema son usados dependiendo de lo que exactamente deseemos estudiar, si queremos saber cómo funciona internamente un elemento de un sistema se utiliza el termino caja blanca. Si lo que queremos es estudiar la interacción de dicho modulo con los demás módulos del sistema se utiliza el termino caja negra. [1]

2

El objetivo principal de realizar estas pruebas es el de encontrar defectos en el software, verificando se cumple las especificaciones de diseño (Prueba de Verificación) o verificando que cumpla los requisitos de análisis (Prueba de Validación), con esto logramos demostrar al desarrollador y al cliente de que el software satisface sus requerimientos y saber cuáles son los defectos del software para posteriormente corregirlos. [4]

Para esto existe un modelo de los casos de prueba que nos permitirá hacerlas correctamente, dicho modelo se presenta en la figura 1.

Figura 1 – Modelo del proceso de Pruebas del software [4]

Glosario de términosComplejidad ciclomática.- es una métrica del software que proporciona una medición cuantitativa de la complejidad lógica de un programa. Es una de las métricas de software de mayor aceptación, ya que ha sido concebida para ser independiente del lenguaje. [7]

Sistemáticamente.- significa que se sigue un sistema o un orden; siempre de la misma manera. [8]

ClasificaciónLa prueba del software es un elemento crítico para la garantía de la calidad del software. El objetivo de la etapa de pruebas es garantizar la calidad del producto desarrollado. Además, esta etapa implica [1]:

- Verificar la integración adecuada de los componentes- Verificar que todos los requisitos se han implementado

correctamente.- Identificar y asegurar que los defectos encontrados se han corregido

antes de entregar el software al cliente.

3

- Diseñar pruebas que sistemáticamente saquen a la luz diferentes clases de errores, haciéndolo con la menor cantidad de tiempo y esfuerzo.

La prueba es un proceso que se enfoca sobre la lógica interna del software y las funciones externas. La prueba es un proceso de ejecución de un programa con la intención de descubrir un error. Un buen caso de prueba es aquel que tiene alta probabilidad de mostrar un error no descubierto hasta entonces. Una prueba tiene éxito si descubre un error no detectado hasta entonces [1].

En nuestro caso hemos clasificado en dos ramas, pruebas de caja negra y pruebas de caja blanca.

DefinicionesCaja negraLas pruebas se llevan a cabo sobre la interfaz del software, y es completamente indiferente el comportamiento interno y la estructura del programa, esto 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[6].

Figura 2 - Caja Negra [6]

Los casos de prueba de la caja negra pretende demostrar que:

- Las funciones del software son operativas.- La entrada se acepta de forma adecuada.- Se produce una salida correcta, y- La integridad de la información externa se mantiene.

Se derivan conjuntos de condiciones de entrada que ejerciten completamente todos los requerimientos funcionales del programa. La prueba de la caja negra intenta encontrar errores de las siguientes categorías [1].

- Funciones incorrectas o ausentes.- Errores de interfaz.- Errores en estructuras de datos o en accesos a bases de datos

externas.- Errores de rendimiento.- Errores de inicialización y de terminación.

4

Los casos de prueba deben satisfacer los siguientes criterios:

- Reducir, en un coeficiente que es mayor que uno, el número de casos de prueba adicionales.

- Que digan algo sobre la presencia o ausencia de clases de errores.

Caja blancaPermiten examinar la estructura interna del programa. Se diseñan casos de prueba para examinar la lógica del programa. Es un método de diseño de casos de prueba que usa la estructura de control del diseño procedimental para derivar casos de prueba que garanticen que [6]:

- Se ejercitan todos los caminos independientes de cada módulo.- Se ejercitan todas las decisiones lógicas.- Se ejecutan todos los bucles.- Se ejecutan las estructuras de datos internas.

Las pruebas de caja blanca se centran en los detalles procedimentales del software, por lo que su diseño está fuertemente ligado al código fuente. La(s) persona(s) encargada(s) de las pruebas escoge distintos valores de entrada para examinar cada uno de los posibles flujos de ejecución del programa y cerciorarse de que se devuelven los valores de salida adecuados. [1]

Al estar basadas en una implementación concreta, si ésta se modifica, por regla general las pruebas también deberán rediseñarse.

Figura 3 - Caja Blanca [6]

EjemplosCaja negraUn chip de memoria puede considerarse una caja negra. Muchas personas utilizan chips de memoria, e incluso los diseñan para los equipos informáticos, pero por lo general sólo los diseñadores de chips de memoria necesitan comprender su funcionamiento interno [1].

Casi cualquier cosa puede ser descrita como una caja negra [3]:

- un transistor- un algoritmo- un programa de computación- un mainboard- parlantes, etc.

5

Las Pruebas a ejecutarse son:

- Prueba de unidad.- este tipo de prueba es considerada una de las primordiales ya que los resultados obtenidos de esta repercutirá directamente en la ejecución de las demás pruebas. [3]

- Prueba de integración.- Este busca que el programa corra sin problemas. [3]

- Prueba de validación.- tras la culminación de las pruebas de integración, el software está completamente ensamblado como un paquete; se han encontrado y corregido los errores de interfaces, y debe comenzar una serie final de pruebas del software, la prueba de validación. [3]

- Prueba de recuperación.- muchos sistemas basados en computadoras deben recuperarse de los fallos y asumir el procesamiento en un tiempo previamente especificado. En algunos casos un sistema debe ser tolerante a fallos, o sea, los fallos de procesamiento no deben hacer que cese el funcionamiento de todo el sistema. [3]

- Prueba de seguridad.- estas pruebas intentan verificar que los mecanismos de protección incorporados en el sistema, lo protejan, de hecho de la penetración impropia. Durante la prueba de seguridad, el encargado de la prueba juega el papel de un individuo que desea penetrar el sistema. [3]

Caja blancaLas principales pruebas son:

- Pruebas de flujo de control.- En estas pruebas se quiere encontrar errores en la parte lógica del programa. Utilizando las condiciones simples (operador-relación) o con condiciones complejas (N x [operador-relación]). Por ejemplo este encuentra errores con los paréntesis, con variables y hasta de operaciones aritméticas. [2]

- Pruebas de flujo de datos.- Por medio de esta herramienta se hace la selección más adecuada del flujo de datos, para llegar a una resolución correcta. Esto para probar las variables y definiciones en el programa.[2]

- Pruebas de bifurcación (branch testing).- Como lo dice su título, es ligado a una bifurcación o para bucles. Con ella podemos definir si algún bucle está correctamente implementado y si las líneas de código donde exista una condición es la mejor opción o si debería ser cambiada. [2]

- Pruebas de caminos básicos.- Esta prueba lo que demuestra es el conjunto de pasos base del programa, lo que quiere lograr es que cada sentencia de código se ejecute mínimo una vez. Acá se usan herramientas como grafos, diagramas de flujo, la complejidad ciclomática, entre otros. [2]

Como se menciona anteriormente es para revisar un producto terminado, por lo tanto lo que podemos revisar seria:

6

Datos de entrada: Por ejemplo si vamos a revisar una función que solo recibe números correspondientes a los días de la semana, tendríamos un rango de [1 - 7], lo que nos da 3 posibilidades para las pruebas [2].

1. No hay dato de entrada.2. El dato de entrada es menor a 1.3. El dato de entrada esta entre 1 y 74. El dato de entrada es mayor a 7.

Funcionalidad: Este es más sencillo, ya que es probar que el código cumpla con un requerimiento en específico, por ejemplo si es una función de suma de dos datos, que el resultado sea la suma del mismo. Al igual que el anterior tenemos las siguientes posibilidades [2]

1. La función no da el resultado correcto.2. La función da el resultado correcto.3. La función no recibe parámetros.4. La función no devuelve parámetros.

ConclusionesComo pudimos mostrar se tiene gran variedad de formas de realizar estas pruebas y todo dependerá de la necesidad que tengamos, es decir, del problema que hayamos resuelto. Por lo tanto para saber cuál de las dos pruebas usar deberíamos tener en cuenta con qué recursos contamos, si tenemos el código fuente de un sistema podríamos aplicar fácilmente las pruebas de caja blanca, por el contrario, si no nos proporcionaron los códigos y únicamente contamos con el producto final, no nos queda otra opción más que optar por las pruebas de caja negra.

Bibliografía[1]

Arbones Malisani, E. A. (12/2009 http://site.ebrary.com/lib/uasuaysp/docDetail.action?docID=10357620&p00=caja%20negra). Ingeniería de sistemas. España: Marcombo.

[2] Brenes, E. (1 de Noviembre de 2013). Obtenido de http://erick.comunidadcr.com/test-caja-blanca-vs-test-caja-negra/

[3] Eveline, P. (1 de Noviembre de 2013). Obtenido de http://prezi.com/4ionwccdonr2/caja-negra-y-caja-blanca/

[4] Gladys Maria Rodriguez, D. F. (01 de Noviembre de 2013). Slideshare. Obtenido de http://www.slideshare.net/gladisha/pruebas-del-software-13788769#btnNext

[5] Quintero, J. (31 de Octubre de 2013). Analisis y desarrollo de sistemas de información. Obtenido de Slideshare: http://www.slideshare.net/jaquintero775/caja-negra-2522077

[6] Valero, E. (1 de Noviembre de 2013). Slideshare. Obtenido de http://www.slideshare.net/valero340/auditoria-ii-7621665

7

[7] Aranda, N. (1 de Noviembre de 2013). Slideshare. Obtenido de www.slideshare.net/NielsHenryk/ed-complejidad-ciclomtica

[8] Sensagent. (1 de Noviembre de 2013). Obtenido de http://diccionario.sensagent.com/sistem%C3%A1ticamente/es-es/