Pruebas de Caja

blanca/negra y de grafos

Nombre: Fernando González

Curso: 3ºD
Fecha: 17/10/2018
Asignatura: PYBD
Profesora: Rosa Carreño
 Las pruebas de caja blanca y negras
Caja blanca
Las pruebas de caja blanca (también conocidas como pruebas de caja de
cristal o pruebas estructurales) tiene de función verificar que líneas específicas
de código funcionan tal como está definido centralmente en los detalles
procedimentales del software, por lo que su diseño está fuertemente ligado al
código fuente. El testeador 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.
Al estar basadas en una implementación concreta, si ésta se modifica, por
regla general las pruebas también deberán rediseñarse.
Aunque las pruebas de caja blanca son aplicables a varios niveles de la unidad,
integración y sistema, habitualmente se aplican a las unidades de software. Su
cometido es comprobar los flujos de ejecución dentro de cada unidad (función,
clase, módulo, etc.) pero también pueden testear los flujos entre unidades
durante la integración, e incluso entre subsistemas, durante las pruebas de
sistema.
A pesar de que este enfoque permite diseñar pruebas que cubran una amplia
variedad de casos de prueba, podría pasar por alto partes incompletas de la
especificación o requisitos faltantes, pese a garantizar la prueba exhaustiva de
todos los flujos de ejecución del código analizado.
Las principales técnicas de diseño de pruebas de caja blanca son:
• Pruebas de flujo de control
• Pruebas de flujo de datos
• Pruebas de bifurcación (branch testing)
• Pruebas de caminos básicos
 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 de tipo
dinámica u estatica. 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.

Caja negra y programación modular

En programación modular, donde un programa (o un algoritmo) es dividido en
módulos, en la fase de diseño se buscará que cada módulo sea una caja negra
dentro del sistema global que es el programa que se pretende desarrollar, de
esta manera se consigue una independencia entre los módulos que facilita su
implementación separada por un equipo de trabajo donde cada miembro va a
encargarse de implementar una parte (un módulo) del programa global; el
implementador de un módulo concreto deberá conocer como es la
comunicación con los otros módulos (la interfaz), pero no necesitará conocer
cómo trabajan esos otros módulos internamente; en otras palabras, para el
desarrollador de un módulo, idealmente, el resto de módulos serán cajas
negras.
 Notación de Grafo de Flujo
Para aplicar la técnica del camino básico se debe introducir una sencilla
notación para la representación del flujo de control, el cual puede representarse
por un Grafo de Flujo. Cada nodo del grafo corresponde a una o más
sentencias de código fuente. Todo segmento de código de cualquier programa
se puede traducir a un Grafo de Flujo. Para construir el grafo se debe tener en
cuenta la notación para las instrucciones. Un Grafo de Flujo está formado por 3
componentes fundamentales que ayudan a su elaboración, comprensión y nos
brinda información para confirmar que el trabajo se está haciendo
adecuadamente.
Los componentes son:
Nodo
Cada círculo representado se denomina nodo del Grafo de Flujo, el cual
representa una o más secuencias procedimentales. Un solo nodo puede
corresponder a una secuencia de procesos o a una sentencia de decisión.
Puede ser también que hallan nodos que no se asocien, se utilizan
principalmente al inicio y final del grafo.
Aristas
Las flechas del grafo se denominan aristas y representan el flujo de control, son
análogas a las representadas en un diagrama de flujo. Una arista debe terminar
en un nodo, incluso aunque el nodo no represente ninguna sentencia
procedimental.
Regiones
Las regiones son las áreas delimitadas por las aristas y nodos. También se
incluye el área exterior del grafo, contando como una región más. Las regiones
se enumeran. La cantidad de regiones es equivalente a la cantidad de caminos
independientes del conjunto básico de un programa.
Cualquier representación del diseño procedimental se puede traducir a un grafo
de flujo. Cuando en un diseño se encuentran condiciones compuestas (uno o
más operadores AND, NAND, NOR lógicos en una sentencia condicional), la
generación del grafo de flujo se hace un poco más complicada.
 Prueba de Caja Negra
Las pruebas de caja negra se llevan a cabo sobre la interfaz del software,
obviando el comportamiento interno y la estructura del programa. Los casos de
prueba de la caja negra pretenden demostrar que:
• Las funciones del software son operativas
• La entrada se acepta de forma correcta
• Se produce una salida correcta
• La integridad de la información externa se mantiene
Después se derivan conjuntos de condiciones de entrada que utilicen todos los
requisitos funcionales de un programa. Las pruebas de caja negra pretenden
encontrar estos tipos de errores:
• Funciones incorrectas o ausentes.
• Errores en la 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.

Métodos de prueba de caja negra

El primer paso en la prueba de la caja negra es entender los objetos que se
modelan en el software y las relaciones que conectan a estos mismos
Algunos de los métodos empleados en las pruebas de caja negra.
• Métodos de prueba basados en grafos:
En este método se debe entender los objetos (objetos de datos, objetos de
programa tales como módulos o colecciones de sentencias del lenguaje de
programación) que se modelan en el software y las relaciones que conectan a
estos objetos. Una vez que se ha llevado a cabo esto, el siguiente paso es
definir una serie de pruebas que verifiquen que todos los objetos tienen entre
ellos las relaciones esperadas.
En este método:
1. Se crea un grafo de objetos importantes y sus relaciones.
2. Se diseña una serie de pruebas que cubran el grafo de manera que se
ejerciten todos los objetos y sus relaciones para descubrir errores.
Beizer describe un número de modelados para pruebas de comportamiento
que pueden hacer uso delos grafos:
Modelado del flujo de transacción. Los nodos representan los pasos de
alguna transacción (por ejemplo, los pasos necesarios para una reserva en una
línea aérea usando un servicio en línea), y los enlaces representan las
conexiones lógicas entre los pasos (por ejemplo, vuelo.información.entrada es
seguida de validación /disponibilidad.procesamiento).

Modelado de estado finito. Los nodos representan diferentes estados del

software observables por el usuario (por ejemplo, cada una de las pantallas
que aparecen cuando un telefonista coge una petición por teléfono), y los
enlaces representan las transiciones que ocurren para moverse de estado a
estado (por ejemplo, petición-información se verifica durante inventario-
disponibilidad-búsqueda y es seguido por cliente-factura-información-entrada).

Modelado de flujo de datos. Los nodos objetos de datos y los enlaces

son las transformaciones que ocurren para convertir un objeto de datos en otro.

Grafos
Es un conjunto de puntos (Nodos o Vertices) unidos por líneas (Arcos o Aristas)

Un grafo en el ámbito de las ciencias de la computación es un tipo abstracto de

datos (TAD), que consiste en un conjunto de nodos (también llamados vértices)
y un conjunto de arcos (aristas) que establecen relaciones entre los nodos. El
concepto de grafo TAD desciende directamente del concepto matemático de
grafo. Identificando:
• Datos
• Transacción
• Módulos
• Estados
• Colecciones
• Relación
 Tipos
Los grafos simples, en este sentido, son aquellos que surgen cuando una única
arista logra unir dos vértices. Los grafos complejos, en cambio, presentan más
de una arista en unión con los vértices.
En cambio, un grafo es fuertemente conexo si el par de vértices tiene conexión
a través de, como mínimo, dos caminos diferentes.
Un grafo simple, además, puede ser completo si las aristas están en
condiciones de unir todos los pares de vértices, mientras que un grafo es
bipartito si sus vértices surgen por la unión de un par de conjuntos de vértices y
si se cumple una serie de condiciones.